O TOTVS Connector é uma ferramenta/plataforma que possibilita a integração entre softwares e plataformas (TOTVS e não-TOTVS), independente da forma de distribuição de tal solução. Desta forma, utiliza-se o TOTVS Connector para integrar dados, por exemplo, entre aplicações OnPremise, Cloud Privada/Pública e plataforma SaaS (TOTVS Apps).
Por meio de dois componentes dispostos em contextos/ambientes distintos, é possível garantir que uma aplicação OnPremise fique sincronizada com uma aplicação em Cloud/SaaS. Para viabilizar este cenário, um dos componentes é o TOTVS Connector Client, ferramenta que é instalada em ambiente OnPremise/Nuvem Privada (Private Cloud). Outro componente, o TOTVS Connector Server, gerenciado pela TOTVS, é responsável de receber todo o fluxo de dados, assim como expor APIs e se comunicar com as demais soluções em Cloud/SaaS. Em ambiente do cliente (OnPremise/Cloud), deve ser instalado e configurado apenas o TOTVS Connector Client.
É o componente responsável por ler os dados das aplicações OnPremise, sejam aplicações TOTVS ou de terceiros. A instalação é realizada em uma máquina que de forma a conectar-se com o banco de dados do produto OnPremise/Nuvem Privada (Private Cloud), podendo este ser Oracle, Microsoft SQL Server e PostgreSQL. O TOTVS Connector Client precisa de uma instância do PostgreSQL e, dependendo da configuração standalone, mencionado no tópico 2 (Integração com produtos TOTVS e externos), uma instância do RabbitMQ (para comunicação via mensageria AMQP).
TOTVS Connector Server
O TOTVS Connector Server é responsável por receber os dados que serão integrados, originados em aplicações OnPremise/Nuvem Privada (Private Cloud), aplicações SaaS e até não-TOTVS, por meio de aplicações de terceiros. Este componente fica em um ambiente exposto na nuvem, uma vez que todos os demais TOTVS Connector Client devem ser capazes de acessá-lo via requisição Internet/HTTP.
Este tópico apresenta e descreve as entidades utilizadas no TOTVS Connector Server e TOTVS Connector Client.
A entidade Client Environment representa o ambiente do cliente e é necessário realizar seu cadastro para o correto funcionamento do TOTVS Connector Client, assim como para a integração da TOTVS Carol. Ao cadastrar um novo ambiente (Client Environment), a entidade gerará um token para este ambiente. O token gerado representa a identificação do cliente/ambiente que será utilizado para enviar os dados. Além disso, o token deve ser informado na instalação do TOTVS Connector Client, pois a plataforma TOTVS Connector verifica se o token é válido ou não. As aplicações Cloud/SaaS também devem enviar esse token nas mensagens para o TOTVS Connector Server.
O SchemaDefinition é a estrutura de dados que o mapeamento estrutural e de metadados de persistência (por exemplo, nomes de Tabela e Coluna). Para isto, a entidade SchemaDefinition possui as informações da tabela de origem do dado e como se dá a conversão para ser enviado ao TOTVS Connector Server. A gestão do SchemaDefinition é realizada apenas no TOTVS Connector Server. Uma vez publicado o SchemaDefinition, será gerada uma nova versão do SchemaDefinition. Assim, todos os TOTVS Connector Client também são responsáveis pelo processo de sincronismo de novos SchemaDefinition.
A estrutura do SchemaDefinition é representada pelo JSON:
|
Segue novo exemplo de SchemaDefinition:
|
A entidade ProductConnection representa as informações da conexão do banco de dados do produto que será integrado. O TOTVS Connector Client suporta conexões com vários bancos de dados ao mesmo tempo, possibilitando que uma mesma instalação de TOTVS Connector Client monitore e integre dados a partir de múltiplos ProductConnection (por exemplo, Oracle, Microsoft SQL Server e PostgreSQL). Cada banco de dados deve possuir uma tabela chamada TCC_PRODUCT_METADATA, responsável pelo controle de nome do produto (NAME) e a versão do produto que está sendo monitorado/integrado (VERSION). Estas informações são necessárias para relacionar as entidades ProductConnection e SchemaDefinition.
A estrutura da tabela TCC_PRODUCT_METADATA deve possuir duas colunas de texto: NAME e VERSION.
Os bancos de dados suportados são Oracle (11g e 12c), Microsoft SQL Server e PostgreSQL.
O usuário do banco de dados deve ter permissão de criar, alterar remover registros, colunas e triggers nas tabelas.
ProductConnection para conexões com banco de dados Microsoft SQL Server:
|
ProductConnection para conexões com banco de dados Oracle 11g:
|
ProductConnection para conexões com banco de dados PostgreSQL:
|
A entidade ProducConnectionSchema representa a relação entre as entidades ProductConnection e SchemaDefinition. Esta relação significa que uma determinada conexão integrará determinados SchemaDefinition. Por exemplo: a conexão A possui integração com os schemas Schema_A e Schema_B, e a conexão B, com os schemas Schema_B e Schema_C. Portanto, é possível configurar duas conexões com diferentes SchemaDefinition. A entidade SchemaDefinition é cadastrada no TOTVS Connector Server e a própria aplicação TOTVS Connector Client encarrega-se de sincronizar, automaticamente, esta entidade.
Após realizar o relacionamento, o TOTVS Connector Client iniciará o monitoramento das tabelas definidas no SchemaDefinition. Assim que houver qualquer alteração em um ou mais registros das tabelas monitoradas, o TOTVS Connector Client será notificado e processará este registro, enviando-o à plataforma TOTVS Connector Server.
{ |
O Modo Standalone é uma forma de trabalhar apenas no ambiente OnPremise. Por exemplo, integrar dois ou mais produtos que estão em ambientes OnPremise/Nuvem Privada (Private Cloud). Para habilitar o Modo Standalone é preciso inicializar o TOTVS Connector Client com o standalone ligado. Ao habilitar o standalone, o TOTVS Connector Client exigirá uma conexão com uma instância do RabbitMQ, instalada, por padrão, no mesmo ambiente. Uma vez definido o TOTVS Connector Client como standalone, deve-se habilitar o ProductConnectionSchema como standalone.
Para fins explicativos, suponha que exista um produto A, com um ambiente OnPremise com banco de dados, TOTVS Connector Client e RabbitMQ instalados.
Com o standalone desabilitado, qualquer alteração de registros no banco de dados do produto A, o TOTVS Connector Client será notificado e enviará estes registros para o TOTVS Connector Server, que está disposta em Cloud.
Com o standalone habilitado, o TOTVS Connector Client enviará os registros do produto A para a instância do RabbitMQ, que também está no OnPremise. Com isso, outros produtos que estão no OnPremise, por exemplo os produtos B e C, poderão "escutar" uma fila na instância do RabbitMQ para receber estes mesmos registros. Além disso, é possível que os produtos B e C publiquem os registros no RabbitMQ. Desta forma, o TOTVS Connector Client será notificado e processará os registros no banco de dados do produto A.
Na representação seguinte, é apresentado o diagrama do Modo Standalone:
Um ExternalEvent (ou Evento Externo, em Português), é um endpoint no TOTVS Connector Client que aceita mensagens via requisição HTTP POST, sendo possível enviar dados por aplicações que não possuem integração com o RabbitMQ. Este endpoint aceita apenas o envio de mensagens. Importante mencionar que não há um endpoint que seja possível recuperar mensagens. As mensagens somente são disponibilizadas no RabbitMQ (local) via modo standalone.
Devido à necessidade de existência de objetos de banco de dados para o correto funcionamento do TOTVS Connector Client, existe uma funcionalidade que checa/verifica, de tempos em tempos, a consistência ou integridade desses objetos.
Cada tabela do SchemaDefinition origina a criação de uma trigger e de duas colunas (gerenciais) no banco de dados do produto OnPremise. Caso algum desses objetos sofra alterações indevidas, o TOTVS Connector Client validará e exibirá esta falta de conformidade/integridade, facilitando verificações de problemas no funcionamento desejado.
Fluxo de mensagens das aplicações OnPremise/Nuvem Privada (Private Cloud) e Cloud, por meio do TOTVS Connector Server e Totvs Connector Client:
A entidade EventData é utilizada para encapsular os dados enviados ao TOTVS Connector Server, componente destinado às aplicações OnPremise e Cloud/SaaS.
|
Para enviar os dados via mensageria para o TOTVS Connector Server, deve-se enviar a entidade TOTVSMessage<T>. A entidade TOTVSMessage é uma classe da biblioteca TJF que encapsula a mensagem a ser enviada por mensageria.
O tipo genérico T é a entidade a ser encapsulada que, no contexto atual, representa o EventData. Portanto, para enviar uma mensagem para o TOTVS Connector Server, deverá ser enviado um objeto com tipagem TOTVSMessage<EventData>.
{ "header": { "content": { } } |
Exemplo de uma mensagem com um schema fictício que define PESSOA:
{
|
A TOTVS Carol é uma plataforma de dados e inteligência artificial da TOTVS, podendo-se aplicar as funcionalidades de um MDM (Master Data Management ou Gestão de Dados Mestre), como, por exemplo: capacidade de receber dados de qualquer fonte, garantir a integridade dos dados e centralizar os dados de sua aplicação. Além disso, também possui a capacidade de desenvolver aplicativos e os implantar na plataforma, por meio de Carol Apps e Carol Assistant. Para saber mais sobre a plataforma Carol, pode-se acessar sua documentação.
O TOTVS Connector possui integração com a TOTVS Carol, possibilitando a disponibilização de dados de aplicações OnPremise ou SaaS para a plataforma Carol. Neste tópico, são explicados os processo de configuração e uso do TOTVS Connector Server junto à plataforma TOTVS Carol.
Para enviar dados à TOTVS Carol, torna-se necessária a realização da autenticação do usuário, podendo esta ser feita de duas maneiras: pelo accessToken ou pelo connectorToken. Para o TOTVS Connector Server, a autenticação será feita pelo connectorToken. Portanto, gera-se o connectorToken na plataforma Carol e, após geração, o connectorToken é utilizado no cadastro da entidade CarolConnector.
Como mencionado anteriormente (tópico 2. Integrações com aplicações TOTVS e terceiros), a entidade Client Environment representa o ambiente e o token gerado por ele representa a identificação do cliente. Assim, o token é utilizado para identificar as mensagens do cliente e direcionar para a TOTVS Carol.
A entidade CarolUser contempla as informações de autenticação/login da plataforma Carol e deve ser cadastrada no TOTVS Connector Server.
O atributo "organizationSubdomain" corresponde ao atributo "orgDomain" da TOTVS Carol;
O atributo "subdomain" corresponde ao atributo "subdomain" da TOTVS Carol, que se refere ao ambiente (tenant) que está se autenticando;
Os atributos "username" e "password" são informações do seu login na TOTVS Carol;
{ "organizationSubdomain": "ambienteteste", "password": "senha_carol", "subdomain": "clienteteste", "username": "usuario_carol" } |
A entidade CarolConnector representa quais Connectors (da TOTVS Carol) que o usuário possui no ambiente, assim como seus Connector Tokens. Na TOTVS Carol, pode-se gerar um Connector Token para cada Connector e são utilizados para o processo de autenticação/identificação de usuário para autorização nas requisições das APIs.
O Connector Token é diferente do token gerado na entidade Client Environment. O Connector Token é gerado na TOTVS Carol para um Connector e é utilizado na identificação do usuário na TOTVS Carol para um mesmo Connector. Diferentes Connectors possuem diferentes Connector Token para o mesmo usuário. Por fim, o token da entidade Client Environment é utilizado para identificação no TOTVS Connector.
Portanto, CarolConnector é a relação do Connector (connectorId) com o Connector Token gerado para esse mesmo Connector na TOTVS Carol.
O atributo connectorId é o id do connector na TOTVS Carol;
O atributo connectorToken é o identificador gerado para o connectorId na TOTVS Carol;
|
A entidade CarolStagingTable representa uma StagingTable na TOTVS Carol.
A entidade CarolStagingTable possui dois atributos similares que representam abstrações diferentes: name e stagingTableName.
O atributo stagingTableName representa exatamente o nome da StagingTable na TOTVS Carol. Por exemplo, se na TOTVS Carol existe uma StagingTable com o nome "fazenda", o atributo stagingTableName deverá ser, exatamente, "fazenda";
O atributo name representa um "apelido" para o TOTVS Connector Server diferenciar dos nomes das StagingTable. Por exemplo, na TOTVS Carol contém uma StagingTable chamada "inspecao" e no TOTVS Connector Server, contém duas CarolStagingTable que apontam para a StagingTable "inspecao" na TOTVS Carol. Para diferenciar as duas CarolStagingTable, utiliza-se o atributo name;
O atributo description representa uma descrição sobre a CarolStagingTable;
Isto pode ser configurado de forma a conter duas ou mais formas responsáveis pelo envio dados para o TOTVS Connector Server. Por exemplo, dois produtos diferentes de um mesmo cliente enviando para a mesma StagingTable na TOTVS Carol.
|
Quando enviar uma mensagem para o TOTVS Connector Server, destinada à TOTVS Carol, a entidade EventDataCarolRequest deverá conter, exatamente, o valor do atributo name. Portanto, não deverá enviar o atributo stagingTableName na mensagem.
A entidade EventDataCarolRequest será explicada no tópico a seguir.
O diagrama a seguir apresenta o fluxo de dados para enviar à TOTVS Carol:
A entidade EventDataCarolRequest é utilizada para encapsular os dados para enviar ao TOTVS Connector Server, destinada à TOTVS Carol.
O atributo environmentToken é o token gerado na entidade Client Environment;
O atributo stagingTableName é exatamente o apelido (atributo name) cadastrada na entidade CarolStagingTable;
O atributo originApp é o nome do produto que está enviando os dados (produto de origem);
O atributo dataList é uma lista de objetos que será enviada para a StagingTable na TOTVS Carol, ou seja, os objetos são as próprias representações da StagingTable;
|
A seguir, são explicados os métodos de envio de dados para o TOTVS Connector Server, direcionados à TOTVS Carol.
Como os envios de dados são feitos de forma assíncrona, pode-se levar algum tempo até os dados serem processados e enviados.
Para enviar os dados via requisição HTTP, utiliza-se o endpoint do TOTVS Connector Server: /v1/environment/carol/eventsDataCarol
No corpo da requisição, passa-se uma lista de EventDataCarolRequest. Após o envio de dados via HTTP, o TOTVS Connector Server validará as informações e direcionar para TOTVS Carol.
Via Mensageria
Para enviar os dados via mensageria para o TOTVS Connector Server, deve-se enviar a entidade TOTVSMessage<T>. A entidade TOTVSMessage é uma classe da biblioteca TJF, que encapsula a mensagem a ser enviada por mensageria.
O tipo genérico T é a entidade a ser encapsulada que, no nosso caso, será a EventDataCarolRequest. Portanto, para enviar uma mensagem para o TOTVS Connector Server, destinada à Carol, deverá enviar um objeto TOTVSMessage<EventDataCarolRequest>.
{ "header": { "content": { } } |
{ |
Como as aplicações estão em servidores diferentes, TOTVS Connector Client no OnPremise/Nuvem Privada (Private Cloud), TOTVS Connector Server na nuvem e as aplicações de terceiros podendo estar tanto na nuvem quanto OnPremise, é possível acontecer atrasos e lentidões no envio dos dados, devido à conexão utilizada.