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.