Conexões e credenciais

Conexões Externas — /external-connections

Dados de conexão reutilizáveis, cadastrados uma vez e referenciados por várias Coletas e Entregas:

Toda conexão tem testar conexão na própria tela — use antes de criar a Coleta, para separar problema de rede/credencial de problema de configuração.

Salvar uma conexão reinicia as sessões que dependem dela. As Coletas e Entregas com sessão persistente — MQTT, Sparkplug, OPC UA, Modbus, SAP IDoc, pasta observada e os gates de escrita em equipamento — reconectam com os dados novos na hora. Antes, a sessão aberta continuava com o endereço antigo, e uma conexão corrigida podia seguir “desligada” até a API reiniciar.

O tipo de uma conexão não muda depois de criada: para outro tipo, cadastre uma conexão nova. A tela sempre travou o campo, e desde a Conexão HTTP o servidor também recusa a troca feita pela API, pelo MCP ou por import. Numa conexão InfluxDB, a versão (1.8, 2.x, 3.x) também fica travada enquanto alguma Coleta ou Entrega InfluxDB depender dela: cada versão fala uma linguagem de consulta e grava por um endereço diferente, e a troca quebraria essas integrações na próxima execução. O campo mostra quantas são.

Conexão HTTP

Quando várias Aplicações falam com o mesmo servidor HTTP, cadastre o servidor uma vez aqui e ligue as Aplicações a ele. Trocar o endereço, a URL de Keep Alive ou o certificado passa a ser feito num lugar só.

• Usuário e senha não ficam aqui. A Credencial continua em cada Aplicação, porque Aplicações no mesmo servidor podem entrar com logins diferentes.
• As Aplicações ligadas ficam ON e OFF juntas. O Keep Alive é do servidor, não de cada uma.
• Salvar uma conexão em uso pede confirmação. Quando a URL, o Keep Alive ou o certificado mudam, a tela lista as Aplicações ligadas antes de gravar: o endereço de todas elas, e o das Entregas HTTP delas, muda junto.
• Desativar a conexão segura as Entregas das Aplicações ligadas e as deixa OFF, como nos outros tipos.
• Uma conexão HTTP em uso não pode ser excluída. Passe as Aplicações para URL própria ou para outra conexão antes.

Para ligar uma Aplicação, escolha Conexão Externa no campo Endereço do cadastro dela. Para criar a conexão a partir de uma Aplicação que já existe, use Transformar em Conexão Externa — ver URL própria ou Conexão Externa.

A listagem também diz de onde veio cada conexão: duas colunas mostram quem a criou e quem a alterou por último. O autor é sempre quem estava autenticado na hora — nunca um campo enviado no formulário —, e fica guardado como e-mail, então o registro sobrevive à exclusão daquele usuário.

Os campos de uma conexão também podem ser consultados de dentro da Coleta e da Entrega que a usam, sem passar por esta tela — ver Detalhes da conexão.

Ver catálogo

Conexões de banco e de arquivo ganham um segundo botão: Ver catálogo. Ele navega pela estrutura real — esquemas, tabelas, colunas e chave; ou pastas e arquivos — sem gerar nada.

Vale por si: depois de cadastrar um banco, a primeira coisa que se quer saber é se aquela credencial enxerga o que deveria. E é dali que se abre o assistente que gera a Coleta e a Entrega prontas — ver Catálogo de banco e Catálogo de pastas.

Credenciais — /credentials

Autenticação das chamadas HTTP/SOAP. São armazenadas cifradas em repouso e nunca reexibidas pela API.

Login → Token cobre as APIs corporativas que inventaram o próprio login: o token pode vir aninhado na resposta (data.session.token), o corpo do login aceita parâmetros extras além de usuário e senha, e a senha pode ser hasheada antes do envio, quando é isso que a API espera.

OAuth2 suporta scope, parâmetros extras e as duas formas de enviar o client_id / client_secret: no header Basic (o preferido pela RFC, padrão de Keycloak e Auth0) ou no corpo do form, exigido por parte dos provedores. Só existe client_credentials — o CMS é máquina-a-máquina, não tem browser para o redirect nem usuário para consentir.

Entrada e saída

A Credencial tem uma direção:

• Saída — usada pelo CMS ao chamar a Aplicação. É o caso das quatro acima.
• Entrada — um login e senha que uma aplicação externa usa para enviar mensagens ao CMS, como alternativa ao API Token. Tem usuário responsável e Interfaces permitidas.

As Credenciais de Entrada têm também o botão Conectar via MCP: o mesmo login e senha autenticam um agente de IA no Servidor MCP de integrações da Aplicação, e o popup mostra o endereço e o trecho de configuração do cliente, em Basic Auth.

API Tokens — /api-tokens

Tokens que autenticam quem envia mensagens ao CMS, emitidos por aplicação. Aceitos como:

• header x-api-token: <token>
• header Authorization: Bearer <token>
• header Authorization: Basic com o token na posição da senha

Cada cópia do token é registrada em um histórico de cópias — quem copiou e quando.

O botão Conectar via MCP, na linha de cada chave, mostra como usar a mesma API Key num agente de IA: o endereço do Servidor MCP de integrações da Aplicação e um exemplo de configuração do cliente. O valor da chave não aparece ali — o exemplo traz um marcador, e o valor real continua saindo só pelo Copiar, com registro.

Entregar a credencial a quem vai usá-la

Credencial, API Key e token MCP têm o mesmo problema prático: alguém precisa receber o segredo para configurar o outro lado, e o caminho fácil — copiar da tela e colar no chat da equipe — é o pior possível. Por isso as três telas têm o botão Enviar por e-mail.

O que ele faz, e por que assim:

O e-mail chega com o contexto junto do valor — Aplicação, Aplicação usuária, direção, Interfaces permitidas e o endereço desta instalação — para que quem recebe consiga configurar sem precisar voltar e perguntar.

No caso do token MCP há uma diferença: o destinatário não é escolhido. É sempre o usuário de serviço dono do token, porque é o acesso dele que a IA vai usar.

Variáveis — /global-variables e /application-variables

Pares nome/valor com descrição opcional, reutilizáveis nas configurações. Servem para não repetir (nem espalhar) valores que mudam por ambiente — URLs base, códigos de planta, prefixos.

São duas telas, uma para cada escopo — com Ferramentas separadas, então a permissão de uma não dá acesso à outra:

Onde uma variável pode ser usada, as duas aparecem juntas — no seletor {} dos campos de Coleta e Entrega, no painel de placeholders do Comando SQL e do Modelo de Conteúdo, e como global.NOME no script do Transformer. A variável da Aplicação tem prioridade: se existir uma Global com o mesmo nome, é o valor da Aplicação que entra na resolução.

Onde a variável é usada

Cada linha traz a coluna Onde é usada, com a contagem de referências e um popup que lista cada uma: a Coleta, a Entrega ou o Transformer que a menciona, com a Aplicação, o campo e o trecho onde ela aparece. A varredura cobre três formas de uso: Template ({{VAR}}), Bind SQL (:VAR) e Script (global.VAR).

É o que se consulta antes de renomear ou excluir. Excluir uma variável referenciada não dá erro: as referências passam a resolver para vazio, em silêncio — e a tela avisa disso na confirmação.

Nas Globais há ainda Sobreposta em: as Aplicações que têm uma Variável de Aplicação com aquele mesmo nome. Dentro delas o valor global não vale.

Os dois escopos entram juntos no import/export da Danger Zone, sob o mesmo item Variáveis (Globais e de Aplicação) — as de Aplicação são referenciadas pela sigla da Aplicação, então importe Aplicações junto.

As duas telas também mostram quem criou e quem alterou por último cada variável, com data, na mesma regra das Conexões: o autor é quem estava autenticado na hora, guardado como e-mail. Variável criada por import ou por Pack, sem ninguém conduzindo, aparece com um traço.

Achar um registro no meio de muitos

Estas telas, como as demais agrupadas por Aplicação, têm um campo de busca que filtra por Aplicação, Interface e Definição ao mesmo tempo — e também pelo que identifica o próprio registro. Em Credenciais e API Keys, isso inclui as duas Aplicações envolvidas: a dona e a usuária.

O mesmo campo existe em Erros de Negócio (pelo código do erro), em Regras de Criptografia (pelo texto coringa), em Alertas (pelo login do destinatário) e em Chaves de Criptografia.