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.