# 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.