Sistemas

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

Por que usar sistemas

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

• SAP RFC

• 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 sistema

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

• internalName estável para uso técnico;

• parâmetros tipados conforme o tipo do sistema;

• parâmetros customizados, quando o contexto pede valores extras;

• status ativo ou inativo;

• vínculo com o ambiente correto.

Trocar o tipo de um sistema 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 sistema.

• Status: ativo ou inativo.

• Descrição: contexto funcional.

Dependendo do caso, o produto também permite logo/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/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

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

No SDK, eles chegam pelo ProcessorPayload e podem ser acessados pela lista systems ou pelos utilitários públicos.

Em projetos mais maduros, o padrão é localizar o sistema 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 sistemas obsoletos em vez de manter configurações ambíguas;

• evite reutilizar um mesmo sistema para contextos de negócio sem relação;

• documente internamente autenticação, owner e criticidade operacional.