Histórico da Página

...

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.Image Removed

...

• 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

...

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.