Histórico da Página

Integração

Visando ofertar uma solução do seguimento Agro x BackOffice Protheus mais adequada a necessidade do cliente, foi criado o PIMSConnector . Responsável pelo processo de integração com arquitetura responsável por realizar integrações entre PIMS X Protheus.

...

A seguir serão apresentadas seções com as principais visões arquiteturais da aplicação. Cada uma possui um foco distinto e possivelmente um público específico.

• Visão Geral do Modelo de Componentes da Solução

Image Removed

Figura 1 - Visão dos Componentes da SoluçãoGeral do Modelo de Componentes do PIMSConnector

Segue abaixo as especificações de cada componente mostrado na figura acima:

• Aplicações PIMS: são as aplicações especializadas desenvolvidas pela TOTVS Agro que precisam trocar dados com ERP's utilizados pelos clientes. Exemplos: PIMS Multicultivos, PIMS CS, PIMS PI e PIMS MI

...

• ;

• Aplicações ERP: são produtos como Protheus, Datasul, que são utilizados pelos clientes e que precisam trocar informações com as aplicações especializadas da TOTVS Agro

...

Drivers: são os componentes responsáveis pela implementação das regras de validação e integração. Estes podem ser divididos em dois tipos: drivers de coleta de dados (DataDriver) e drivers de processamento de integração (ProcessDriver).

DataDriver: um driver de coleta de dados é o componente responsável por obter os dados de uma aplicação em uma das pontas (aplicação PIMS ou ERP) e enviá-los para o PIMSConnector Bridge para serem processados e integrados.

ProcessDriver: um driver de processamento de integração que é invocado pelo PIMSConnector Bridge para processar os dados recebidos e enviá-los (integrá-los) à aplicação na outra ponta.

Bridge: é responsável por intermediar a comunicação entre drivers do tipo DataDriver e ProcessDriver, identificando os drivers adequados para o processamento das integrações. Este módulo disponibiliza serviços de registro e invocação de integrações (envio de dados) aos drivers.

Considerações Sobre Acoplamento

Os drivers de coleta de dados não saberão quais drivers de processamento de integração serão invocados para o processamento dos dados enviados para a Bridge, nem os drivers de processamento de integração saberão sobre os drivers de coleta de dados que originaram os dados. Isto garante um baixo acoplamento entre estes componentes e a fácil substituição dos mesmos quando necessário.

Registro de Drivers

...

• ;

Considerações Sobre Tecnologias de Comunicação

Uma das características importantes a considerar neste projeto é que, a comunicação feita pelos drivers com as aplicações a serem integradas, poderão dar-se de diversas formas e com tecnologias distintas. Há integrações feitas através da comunicação direta com bancos de dados, comunicação através de web services SOAP, web services REST, chamadas HTTP, troca de mensagens através de middlewares orientados a mensagens, sockets, e quaisquer outras que possam surgir derivadas das anteriores. É importante que cada driver implementado seja independente da forma de comunicação adotada, para que se possa permitir que a regra de negócio seja a mesma em cada situação, para não haver duplicação. Para isso existe o conceito de Wrapper de Comunicação. Wrappers de Comunicação são componentes responsáveis exclusivamente pela comunicação do driver com as aplicações que precisam ser integradas, ou seja, das quais os drivers recebem os dados e para as quais eles enviam estes dados, após o processamento da integração. 

Visão dos Componentes Driver

Esta visão apresenta, ainda em alto nível, possíveis estratégias de implementação para os Drivers. 
Image RemovedSe pensarmos em um componente de Driver como sendo um arquivo .jar, este poderá apresentar os componentes de um DataDriver, de um ProcessDriver ou os dois, ao mesmo tempo, sendo cada tipo implementado por uma classe distinta. 

Visão dos Componentes ProcessDriverWrapper

Esta visão apresenta, ainda em alto nível, possíveis estratégias de implementação para os Wrappers de ProcessDrivers. 
Image Removed
A ideia é que os Wrappers implementem uma interface que possui um método que possa ser chamado pelo ProcessDriver para a entrega dos dados processados. Neste caso o ProcessDriver é ativo, no sentido em que invoca o Wrapper quando necessário. Cada Wrapper terá acesso ao ProcessDriver em questão para repassar as respostas recebidas. 
Visão dos Componentes DataDriverWrapper
Esta visão apresenta, ainda em alto nível, possíveis estratégias de implementação para os Wrappers de DataDrivers. 
Image Removed
A ideia é que os Wrappers implementem uma interface que possui um método que possa ser chamado pelos aplicativos envolvidos na integração para a entrega dos dados (obtenção passiva de dados), ou então o Wrapper implementará uma estratégia de recuperação dos dados (obtenção ativa dos dados). Uma vez que tenha obtido os dados, o Wrapper invocará no DataDriver o método responsável por receber os dados e o DataDriver passará os dados adiante, fazendo qualquer alteração necessária. Neste processo o DataDriver será passivo na obtenção dos dados, uma vez que ela é dependente da tecnologia de comunicação. 
Visão Geral do Modelo de Componentes da Solução com WrappersEsta visão apresenta a utilização dos Wrappers na relação entre os componentes da solução. 
Image Removed

EAI PIMSConnector

O EAI PIMSConnector permite a troca de mensagens no formato XML (eXtensible Markup Language), com qualquer produto ou software que disponibilize um WebService para esta finalidade. O EAI PIMSConnector interpreta e gerencia as informações enviadas ou recebidas por aplicativos PIMS ou por outro Software. Após interpretar as informações o EAI PIMSConnector entrega aos Adapters para realizar o processo de validação de negócio. Aos finalizar estas validações o EAI PIMSConnector devolverá ao software que originou as informações um aviso (XML) que identifica se o processamento foi realizado com sucesso ou falha. É importante ressaltar que o EAI PIMSConnector não é responsável por realizar a validação de negócio, apenas envia e recebe mensagens. Ele também é responsável por tentar entregar a mensagem novamente, quando a entrega anterior não foi possível. Desta maneira, erros no processamento da mensagem, problemas na regra de negócio envolvida na integração, problemas com consumo de memória, normalmente são decorrentes da rotina envolvida no processamento da mensagem e não do EAI PIMSConnector.

...

O EAI PIMSConnector possui duas URLs distintas, que podem ser acessadas conforme os endereços abaixo:

URL1: http://<servidor-PIMSConnector>:<porta-PIMSConnector>/ PIMSConnectorWS/EAIService?wsdl

URL2: http://<servidor-PIMSConnector>:<porta-PIMSConnector>/ PIMSConnectorWS/PIMSConnectorWS?wsdl

InternalID

É uma ferramenta utilizada para converter campos de chaves primárias de aplicativos externos para a chave primária do aplicativo interno. Pode ser referenciada como EAI de – para ou depara.

Durante a troca de mensagens, o aplicativo externo pode ter mais, menos ou diferentes campos correspondentes à chave primária. Assim, fica impossível identificar qual registro corresponde aos valores recebidos na mensagem. Isso pode ocorrer com vários aplicativos externos ao mesmo tempo e para a mesma mensagem. Para resolver essa situação, tornando-a invisível para o Helper e o Adapter durante a extração dos dados recebidos, foram criadas as funções do InternalId.

Foi adicionado um código interno (InternalId) no XML da mensagem para identificar os campos chaves do aplicativo externo. Chegando ao destino, os campos são convertidos para os valores locais no corpo da estrutura.