História das integrações na TOTVS
Desde sua fundação, em 2005, a TOTVS preocupa-se em oferecer o melhor produto aos seus milhares de clientes e para tal, além de promover o desenvolvimento utilizando talentos espalhados em diversas empresas adquiridas ao longo de sua história, a TOTVS optou por permitir que clientes e parceiros criem e integrem outros produtos ao seu.
Ao longo de sua história, o processo de integração passou por diversos estágios e, em cada um, aprendemos e evoluímos para o seguinte primando pela qualidade e facilidade, alinhados com a tecnologia da época:
Estágio 1: Transferência de arquivos:
Neste modelo de integração, múltiplos produtos desenvolvidos em diferentes linguagens e plataformas podiam compartilhar informações através da transferência de arquivos. Com este recurso, exportava-se e importava-se arquivos no formato de texto com campos delimitados por caracteres específicos ou com tamanhos fixos. Posteriormente, passamos a trabalhar também com o conteúdo no formato XML.
Apesar de prático e fácil de implementar, este modelo possui diversas falhas de segurança e de processo. Um mesmo arquivo pode ser importado várias vezes, o usuário pode manipular os valores diretamente no arquivo e deixá-lo incompatível com a origem ou simplesmente decidir não importar um arquivo importante. Claro que ferramentas de automação da exportação e importação foram desenvolvidas com o intuito de minimizar tais problemas, ainda assim o alto delay das atualizações mostrou-se inadequado à demanda crescente de informações em tempo real ou próximo disso.
Estágio 2: Compartilhamento de Banco de Dados
Apesar de fácil de implementar, a integração via transferência de arquivo foi substituída pela possiblidade de compartilhar informações direto da base de dados.
O compartilhamento de registros direto do banco de dados resolve o problema de delay da atualização da informação nos diversos sistemas e garante a replicação da informação independente da fonte. Todavia, tal abordagem obriga que todos os atores de uma integração conheçam o schema dos bancos provedores de informação. Além disto, a atualização dos aplicativos consumidores deste banco fica comprometida, uma vez que a leitura e atualização é feita considerando um schema previamente acordado. É característica do ERP evoluir a cada versão, que podem trazer consigo alterações na estrutura das tabelas e, consequentemente, tais alterações podem quebrar a integração.
A integração via banco de dados permite que um produto externo faça atualização de uma determinada entidade do produto diretamente na base de dados, com a possibilidade de burlar todas as regras de negócio relacionadas. Como exemplo, podemos citar que um determinado aplicativo pode incluir um produto na base de dados sem preencher informações necessárias para o vínculo do mesmo em uma Nota Fiscal e cálculo de impostos.
Outro ponto importante que torna complexa a integração compartilhando banco de dados é que cada produto pode trabalhar com diferentes sistemas gerenciadores de banco de dados. Como exemplo, podemos citar Oracle, SQL Server, Progress etc. Além disto, bancos de dados podem estar em diferentes redes impossibilitando o acesso, ou criando brechas para ataques externos diretos.
Estágio 3: Webservices
O compartilhamento de banco de dados garante a disponibilização da informação independente da origem, porém, como vimos, impede que sistemas distribuídos em diversas redes compartilhem informações de forma segura e confiável, além de obrigar o uso de licenças e adaptações para múltiplos bancos. Para resolver tais gaps, passamos a disponibilizar webservices para acesso às principais entidades e processos de nossos produtos.
Webservices é a forma inteligente de encapsular uma regra de negócio e disponibilizá-la através de funções na WEB. Com isto, é possível garantir que uma informação só será aplicada na base de dados se atender todos os quesitos do objeto de negócio. Além disto, a leitura de uma informação só acontecerá se o usuário consumidor do serviço possuir permissões suficientes para tal. Acrescenta-se, ainda, que a revogação da permissão poderia ser feita na camada de negócio. Outro ponto positivo dos webservices é o fato de independer de linguagem de programação ou banco de dados.
Apesar das muitas plataformas de desenvolvimento usadas pela TOTVS, adotamos, em um primeiro momento, o protocolo SOAP em todas elas, e posteriormente passamos a aceitar o protocolo REST compartilhando JSON e XML, ambos compatíveis com as principais tecnologias do mercado.
Estágio 4: Mensagem Padronizada.
Ainda que a abordagem usando webservices seja mais segura do que o compartilhamento de banco de dados ou transferência de arquivos, o consumidor da informação, todavia, é obrigado a conhecer a estrutura de dados de cada webservice disponibilizado pelo provedor. Como a TOTVS possui em seu portfólio vários produtos desenvolvidos em diversas linguagens, plataformas e banco de dados, o consumidor do serviço precisa conhecer e dominar estruturas diversas, bem como suas particularidades.
Por isso, alinhados com o modelo de integração implementado por diversas empresas desenvolvedoras de ERP em outros países, adotamos o modelo de mensagem padronizada.
Mensagem Padronizada é o modelo de padronização da exposição de serviços e conteúdo dos produtos TOTVS. Usando mensagem padronizada, o consumidor de um serviço não precisa se preocupar se o provedor é o Protheus, Datasul, RM ou qualquer um dos produtos da TOTVS. Todos disponibilizarão seus serviços utilizando um mesmo protocolo e formato de conteúdo.
Podemos dividir mensagem padronizada em duas partes:
1) Canal de comunicação
Padronizamos o canal de comunicação de mensagem padronizada utilizando o protocolo SOAP. Padronizamos o servicename como EAIService e a assinatura do método como “string RECEIVEMESSAGE(string inMsg)”, desta forma, qualquer produto integrado a um dos produtos TOTVS está automaticamente apto a integrar com todos os outros que implementaram o modelo de mensagem padronizada.
Em 2018, evoluiremos o canal de comunicação para o protocolo REST.
2) Conteúdo da mensagem
Esta é a parte mais importante da mensageria. Hoje, a TOTVS possui diversos produtos que implementaram entidades comuns como, por exemplo, o cadastro de cliente, o cadastro de produto, o item contábil, entre outros. Tais entidades, apesar de possuírem conceitos semelhantes, apresentam estruturas de dados divergentes em virtude da cultura de desenvolvimento do produto, do propósito ou motivação para sua implementação. Como exemplo, podemos citar a entidade de cliente no Protheus e RM:
Observem que um determinado produto externo, para conversar com o Protheus e enviar o nome de um cliente, deveria utilizar uma estrutura parecida com:
SA1.A1_NOME
Para o RM, teria que utilizar algo como:
FCFO.NOMEFANASIA
É um cenário de relativa complexidade considerando apenas Protheus e RM. Se levarmos em consideração as dezenas de produtos que a TOTVS possui, multiplicamos a dificuldade.
Com o propósito de tornar todo o cenário mais fácil, criamos um contrato padrão para as principais entidades dos produtos TOTVS. Desta forma, um programador com a tarefa de integrar com a entidade “Clientes” da TOTVS não precisará conhecer a estrutura das tabelas SA1 ou FCFO. Deverá conhecer apenas a estrutura do contrato padrão, que no caso de cliente é a customerVendor. Caso queira enviar um cadastro de produto, deverá utilizar o conteúdo respeitando o contrato de item e assim por diante.
Percebam que, com isto, uma vez integrado com o registro de clientes do Protheus, o programador poderá utilizar o mesmo serviço e conteúdo para enviar um registro de cliente para o Datasul, Logix e outros produtos da TOTVS.
A estrutura do XML de uma mensagem padronizada é parecida com o abaixo:
Importante destacar que mensagem padronizada suporta o envio e recebimento de forma síncrona e assíncrona. Desta forma, é possível definir em tempo de projeto se a mensagem será processada no momento do envio ou enfileirada para posterior processamento.
Independente da forma de envio, implementamos controles que garantem que uma mensagem será entregue, além de permitir o acompanhamento do status de seu processamento.
Para facilitar o rastreamento de uma mensagem, bem como a identificação e correção de erros, implementamos um monitor unificado dos produtos TOTVS que analisa a saúde de uma mensagem em todas as pontas envolvidas em uma integração.
Através deste dashboard é possível detalhar quais são as mensagens envolvidas em uma determinada transação, bem como a situação atual de seu processamento.
Para conhecer mais sobre mensagem padronizada, consulte o site abaixo:
