# Sistemas

Systems representam conexões reutilizáveis com recursos externos consumidos por automações e APIs.

## Por que usar systems

Em vez de colocar credenciais e endpoints no código, o TunnelHub centraliza esses dados em entidades configuráveis por ambiente.

Isso permite:

* trocar credenciais sem alterar o código da automação;
* separar DEV, QAS e PRD com segurança;
* reutilizar a mesma configuração em múltiplas automações;
* transportar configurações entre ambientes com mais controle.

## Tipos suportados

Os tipos expostos atualmente no produto incluem:

* `DATABASE`
* `FTP`
* `LDAP`
* `MAIL`
* `HTTP`
* `SFTP`
* `SAPRFC`
* `SMB`
* `SOAP`

Dependendo do tipo, a aba de parâmetros muda para refletir o formato de autenticação e conexão esperado.

## Como modelar um system

Além dos campos básicos, cada system normalmente combina:

* `internalName` estável para uso técnico;
* parâmetros tipados conforme o tipo do system;
* parâmetros customizados, quando o contexto pede valores extras;
* status ativo ou inativo;
* vínculo com o ambiente correto.

Trocar o tipo de um system não é um ajuste cosmético: isso muda a estrutura esperada de parâmetros e, em muitos casos, a própria forma de autenticação.

## Campos principais

* **Nome**: nome amigável.
* **Nome interno**: identificador técnico único dentro do ambiente.
* **Tipo**: tipo do system.
* **Status**: ativo ou inativo.
* **Descrição**: contexto funcional.

Dependendo do caso, o produto também permite logo ou imagem e parâmetros customizados adicionais.

## Exemplos de parâmetros por tipo

* **HTTP**: URL base, autenticação, headers ou query string.
* **DATABASE**: tipo do banco, host, porta, usuário, senha e database ou schema.
* **FTP/SFTP**: host, porta, usuário, credencial, timeout e política de reconexão.
* **SOAP**: WSDL URL e autenticação, quando aplicável.
* **SAP RFC**: host, usuário, mandante, número do sistema e trace.

## Uso em automações

Systems precisam ser associados a uma automação para ficarem disponíveis em tempo de execução.

No SDK, eles chegam pelo payload de execução e podem ser acessados pela lista `systems` ou pelos utilitários públicos.

Em projetos mais maduros, o padrão é localizar o system pelo `internalName` e deixar o resto da configuração no produto.

## Boas práticas

* use `internalName` previsível e estável;
* cadastre credenciais por ambiente;
* mantenha descrições claras sobre finalidade e dono da integração;
* desative systems obsoletos em vez de manter configurações ambíguas;
* evite reutilizar um mesmo system para contextos de negócio sem relação.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.tunnelhub.io/produto/systems.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.