Conectores

Prev Next

Visão geral

Conecte sistemas de software existentes ao Tulip

O Tulip é uma plataforma aberta projetada para se integrar perfeitamente à sua infraestrutura de TI existente. Essa integração é facilitada por meio dos conectores.

Os conectores são um recurso do Tulip que permite a troca de dados entre APIs HTTP, MQTT, bancos de dados SQL e o Tulip. Eles são essenciais para conectar-se a servidores e sistemas externos, incluindo a API Table. Configurar um conector permite que você importe informações externas para seus aplicativos do Tulip, otimizando seus processos.

Tipos de conectores

  1. HTTP — Acesse dados de APIs externas.
  2. MQTT — Grave em seu namespace MQTT.
  3. SQL — Acesse bancos de dados externos fora do Tulip.

Para acessar os conectores, passe o mouse sobre a aba “Aplicativos” e selecione “Conectores”.

Accessing Connectors

Na página “Conectores”, você pode visualizar o status, a descrição e a data da última atualização dos seus conectores.

Connector Status

Ao clicar na linha correspondente a esse conector e rolar a tela para baixo, você pode ver em quais níveis de desenvolvimento os aplicativos ou automações estão utilizando esse conector.Image}

Passar o mouse sobre o botão de status fornece informações adicionais sobre o status de cada Environment.

Status Information

Cada conector pode ter várias funções de conector ou consultas que são acionadas dentro de um aplicativo.
Aqui está um exemplo de uma função de conector:

image.png

Como usar conectores

Os conectores podem ser usados em gatilhos ou em Automation Action Blocks.

Exemplo 1

  1. “Quando o operador escaneia um código de barras”
  2. “Pesquise esse código de barras no meu banco de dados SQL”
  3. “Em seguida, avance para uma das três etapas diferentes com base nesses dados.”

Exemplo 2

  1. “Quando o operador pressionar este botão”
  2. "Envie uma solicitação à minha API HTTP que monitora problemas de produção no chão de fábrica."

Ambos os exemplos são de autoatendimento. Se você puder consultar um banco de dados SQL ou um serviço de software externo (como um MES ou ERP), poderá escrever a consulta dentro do Tulip.

A imagem abaixo mostra a lógica do editor de gatilhos para executar uma função do conector:

Calling a Connector Function

Ambientes de conectores

A aba “Ambientes” permite que você configure vários servidores para cada função de conector. Os ambientes permitem que você segmente onde as informações são afetadas, com base no ciclo de vida de seus aplicativos e automações.

Environments Tab

Mais detalhes sobre ambientes estão disponíveis aqui.

Detalhes técnicos

Como os conectores se comunicam com sistemas externos, é essencial entender como configurá-los para se adequarem ao seu ambiente de TI personalizado. O Connector Host é um componente da plataforma Tulip que gerencia essas conexões.

Para bancos de dados e APIs que estão abertamente disponíveis na sua Tulip Cloud, não é necessária nenhuma configuração adicional. No entanto, se surgirem problemas ou se você precisar se conectar a um banco de dados, API ou máquina que não esteja abertamente disponível na Tulip Cloud, consulte este artigo sobre Hosts de Conectores.

Criar um conector

Configurar um novo conector não requer conhecimento aprofundado de APIs ou bancos de dados, mas é útil estar familiarizado com os tipos de conexão.

Para criar um conector, acesse a página “Conectores” na seção “Aplicativos”. Clique em “+ Criar conector ” no canto superior direito. Você pode selecionar um conector rápido já existente ou clicar em “Criar conector personalizado”.

Configuração de um novo conector

image.png

Informações básicas

  1. Adicione um nome e uma descrição para o seu conector. Essas informações podem ser editadas a qualquer momento.
  2. Selecione um tipo de conector. Isso não pode ser alterado após a criação do conector.
  3. [opcional] A ativação de subdomínios personalizados permite que você configure subdomínios exclusivos para cada função, facilitando a integração com arquiteturas de serviço mais complexas.

Por exemplo, se o endereço do servidor for tulip.co, a função um poderia usar community.tulip.co e a função dois poderia usar support.tulip.co.

Quando os subdomínios personalizados estão ativados, é necessário fornecer um subdomínio padrão para verificar o status do conector.

Em execução em: host do conector

Selecione o host do conector que executará suas solicitações. O host do Cloud Connector, fornecido pela Tulip, faz solicitações por meio da Tulip Cloud. Qualquer host de conector local registrado em sua conta também será exibido.

Saiba mais sobre hosts de conectores aqui.

Connector host capabilities

Some connector hosts do not support certain features. These hosts will be disabled or hidden in the connector host dropdown.

Configuração do conector HTTP

Saiba como configurar as funções do conector HTTP aqui.

Permitir subdomínio personalizado

Quando ativada, subdomínios podem ser adicionados no nível da função. Quando ativada, um subdomínio padrão deve ser adicionado para verificar o status de conexão do conector.

**Exemplo:**O servidor é acme.co, e você tem algumas funções que consultam sales.acme.co, outras que acessam shipping.acme.co, etc.

Endereço do servidor

Especifique o endereço de rede, ou seja, um nome de host ou endereço IP, ao qual o Tulip se conecta.

TLS

O Transport Layer Security (TLS) é um protocolo criptográfico projetado para fornecer comunicação segura em uma rede de computadores. Ele garante a privacidade e a integridade dos dados ao criptografar os dados transmitidos entre as partes. O TLS é o sucessor do Secure Sockets Layer (SSL) e é amplamente utilizado para proteger conexões à Internet.

Porta

Seu servidor escuta solicitações em uma porta de rede específica fornecida pelo seu provedor de servidor. A porta 443 é a mais comum para serviços HTTPS, e a porta 80 é a mais comum para serviços HTTP.

Autenticação

Connector Host Version

For the OAuth Client Credential flow, Cloud Connector Host or On Prem Connector Host of version LTS13 or newer must be used.

  • Sem autenticação – Não é necessária autenticação, ou a autenticação está contida em outros cabeçalhos de solicitação, como x-auth-token.
  • Autenticação básica — Autenticação básica, que utiliza nome de usuário e senha.
  • OAuth 2.0 (token Bearer) — Os tokens Bearer são o tipo predominante de token de acesso utilizado. Eles consistem em uma sequência de caracteres opaca, que não tem significado para os clientes que a utilizam.
  • OAuth 2.0 (Credenciais do usuário) — Normalmente usado para clientes que precisam acessar um conjunto limitado de recursos em nome de um usuário, como um aplicativo móvel que precisa acessar os contatos ou eventos da agenda de um usuário. O usuário deve conceder permissão explicitamente.
  • OAuth 2.0 (Credenciais do cliente) — as credenciais do cliente são um tipo de concessão usado pelo Tulip para obter um token de acesso por meio da autenticação no servidor de autorização usando as credenciais do cliente (ID do cliente e segredo do cliente), normalmente para acessar recursos em nome do próprio cliente, e não em nome de um usuário.
  • OAuth 2.0 (Conta de Serviço) — Usado para clientes que precisam de acesso a uma gama mais ampla de recursos ou funções administrativas. Essa função concede acesso abrangente à conta e aos recursos do usuário, como gerenciar configurações da conta, criar ou excluir recursos ou realizar tarefas administrativas.
  • OAuth 1.0 — Uma versão anterior do OAuth que lida principalmente com fluxos de trabalho na web.

Saiba mais sobre o OAuth aqui.

Cabeçalhos (opcional)

Os cabeçalhos fornecem autenticação da origem dos dados, integridade dos dados e proteção contra repetição. Esses cabeçalhos serão adicionados a todas as funções do conector.

Ampliação das autoridades certificadoras

image.png

Arquivos no formato.pem podem ser enviados para ampliar as autoridades de certificação TLS padrão do Node.js. Este campo atualiza o campo ca na biblioteca TLS do Node.js.

“Opcionalmente, substitua os certificados de autoridades certificadoras (CA) confiáveis. O padrão é confiar nas autoridades certificadoras bem conhecidas selecionadas pela Mozilla. As autoridades certificadoras da Mozilla são completamente substituídas quando outras autoridades certificadoras são explicitamente especificadas usando esta opção. O valor pode ser uma string ou um Buffer, ou uma matriz de strings e/ou Buffers. Qualquer string ou Buffer pode conter várias CAs no formato PEM concatenadas entre si. O certificado do par deve ser encadeável a uma CA confiável para o servidor para que a conexão seja autenticada. Ao usar certificados que não são encadeáveis a uma CA bem conhecida, a CA do certificado deve ser explicitamente especificada como confiável; caso contrário, a autenticação da conexão falhará. Se o par usar um certificado que não corresponda ou não possa ser encadeado a uma das CAs padrão, use a opção ca para fornecer um certificado de CA com o qual o certificado do par possa corresponder ou ser encadeado. Para certificados autoassinados, o próprio certificado funciona como sua CA e deve ser fornecido. Para certificados codificados em PEM, os tipos suportados são “TRUSTED CERTIFICATE”, “X509 CERTIFICATE” e “CERTIFICATE”. Consulte também tls.rootCertificates.”

Um exemplo de CA válida deve ter uma aparência semelhante a esta:

-----BEGIN CERTIFICATE-----MIIDXTCCAkWgAwIBAgIJALaEfh0WW6ZcMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNVBAYTAlVTMRYwFAYDVQQIDA1TYW4gRnJhbmNpc2NvMRIwEAYDVQQHDAlTYW4gSm9zZTEPMA0GA1UECgwGQ29tcGFueTAeFw0xNzA1MjUyMDE2NDRaFw0xNzA2MjQyMDE2NDRaMEUxCzAJBgNVBAYTAlVTMRYwFAYDVQQIDA1TYW4gRnJhbmNpc2NvMRIwEAYDVQQHDAlTYW4gSm9zZTEPMA0GA1UECgwGQ29tcGFueTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK9b+GVsTsmP7z9T2sh79uI/57pI1DBYNyOlwC0lfn8SebVKRg0qAsaF3V4rQ/RPZFGkTb2G7IKnWQZ6VB8AFLF6A9xuGe7vSG9ZcJ1AKM2uOwYXzWQNWRFiW1XPOEIOXB+N7kMFTF6ZzE6RkV68hVqVn7Kx4s0RYAKM4ESJIMyF64IHo5Rf6k3UtrOzy6M3LXM3axgUPHkHZh6/Pi3hecaF7w0qDhlS8UJLA4Gn1I6nrFt1URVd7aSIEiOQhs7wAGDzCjNYMEQK9ih0GLd9ybCm0flYo5fJqfOhWiCFm2z3SuGH9MSnVdrzxY6x23J/gE3spPvBopF6bRjQl0qiw1ZAgMBAAGjUDBOMB0GA1UdDgQWBBRZtdl2jSWpITThx8JZL4Jx0zCBdTAfBgNVHSMEGDAWgBRZtdl2jSWpITThx8JZL4Jx0zCBdTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQARzA8ydRMOfbU0QLOEp9V4B6nO8XBpe9uvtYwQjmb5ZX1bR2/P71bzeJwHK6v4RZl6V5fwGzFdsMFI8JAlLJChM1BpsU7a5R+U/X6XJpCzjErhZ68Z3G+TQ4Bk9LhRlQTH5ld9lR8aWpVPvPIqMtkJhbvWn9P4ysc8q3WYfILy9m9J8Hz3i3AaAEjS5WWm4BjKUMvOFOxaxHHh+ZjNTVrpePyPDrWBkMKn9CF1lwVItJf2JdSYvX1kH5P/M5bsKdwZ95O6d5xUl5Q09gxz/P0j4/QU+fTYhh8RUjKo4vvear9kKxQ2b/8IoQ6A54WHeFzG+h

Configuração do conector SQL

Campo Descrição
Endereço do servidor O endereço IP ou nome do host do servidor de banco de dados. É onde o banco de dados está hospedado e pode ser acessado.
Porta O número da porta na qual o servidor de banco de dados está escutando. Números de porta comuns incluem 3306 para MySQL, 5432 para PostgreSQL e 1433 para SQL Server.
SSL Especifica se o SSL (Secure Sockets Layer) é usado para criptografar a conexão com o servidor de banco de dados. Normalmente, inclui configurações para o modo SSL e certificados.
Banco de dados O nome do banco de dados específico no servidor ao qual você deseja se conectar. É aqui que seus dados estão armazenados.
Nome de usuário O nome de usuário necessário para autenticar-se e obter acesso ao banco de dados. Esse usuário deve ter as permissões necessárias para realizar operações no banco de dados.
Senha A senha associada ao nome de usuário, usada para autenticar o usuário no banco de dados. Isso garante um controle de acesso seguro.

Configuração do conector MQTT

Saiba como criar conectores MQTT aqui.

Leitura complementar