Sumário

1. Introdução
2. Representação Arquitetural
3. Metas e Restrições da Arquitetura
4. Metas e Restrições da Arquitetura
5. Visão Lógica dos Processos
6. Configuração Base do TOTVS ESB
7. PIMS
8. Protheus
9. Glossário

Introdução


Finalidade
Este documento tem como objetivo apresentar uma visão geral arquitetural abrangente de como funciona o processo de
Integração entre os ambiente envolvidos.


Escopo
Documentar o modelo de integração, suas interfaces e evidencias de homologação.

Representação Arquitetural

Devido á necessidades de tolerância a falhas, garantia de entrega e suporte a grandes volumes, a integração do PIMS com o Protheus via TOTVS ESB foi projetada utilizando o conceito de mensageria assíncrona, com filas específicas para envio e recebimento de dados. Os dados trocados entre os processos são constituídos de arquivos XML que devem ser integrados, seguindo o formato e padrões necessários de cada processo, provendo a independência evolutiva dos produtos e reduzindo as interfaces de contato entre os processos. Tanto para o envio como para o recebimento, o TOTVS ESB provê a tradução dos arquivos XML usando o padrão XSLT ( XML Stylesheet Transformation ) desenhado num mapa de tradução para cada processo/transação.


Nesse caso a Transação EAI consiste na troca de documentos XML específicos para cada processo dentro dos aplicativos envolvidos.

Metas e Restrições da Arquitetura


Tolerância a Falhas – em caso de interrupção inesperada dos serviços, o ambiente é capaz de restabelecer as comunicações
Modelo Assíncrono de Mensagens – melhor desempenho e desacoplamento, maior complexidade, maior garantia de tolerância a falhas.
Desacoplamento – os aplicativos integrados têm seus documentos padronizados e independentes do ESB, e para cada transação o próprio ESB executa a identificação / transformação específica.
Modelo ACID – as transações de negócio respeitam o modelo ACID para evitar dados inconsistentes.

 

Metas e Restrições da Arquitetura

Nessas versões envolvidas temos 12 transações homologadas, como segue na listagem abaixo:

Nome Lógico ERP

Nome Lógico PIMS

Nome Técnico

Fluxo

1 - Centro de Custo

Centro de Custos (CCUSTO)

CostCenter

Protheus → PIMS

2 - Fornecedores

Fornecedores (PRESTSERV)

CustomerVendor

Protheus → PIMS

3 - Saldos Contábeis do Período

Despesas Gerais (BRG_INTDG)

PeriodGLBalance

Protheus → PIMS

4 – Depreciações de Bens

Depreciações (BRG_INTDE)

AssetDepreciation

Protheus → PIMS

Nome Lógico ERP

Nome Lógico PIMS

Nome Técnico

Fluxo

5 - Custos dos Itens

Valores de Materiais
(BRG_BXMATERIAL_EMS)

ItemCosting

Protheus → PIMS


6 - Família de Material

Grupo de Insumos
(GRPINSUMO)

Grupo de Material
(GRPMATERIAL)



MaterialFamily



Protheus → PIMS


7 - Item

Insumos
(INSUMO)

Material
(MATERIAL)



Item



Protheus → PIMS

8- Unidade de Medida

Unidade de Medida (UNIMEDIA)

UnitOfMeasure

Protheus → PIMS

9 - Movimento de Estoque

Baixa de Materiais (BRG_BXMATERIAL_EMS)

InventoryTransaction

PIMS → Protheus

9 – Retorno do Movimento de Estoque

Baixa de Materiais

InventoryTransaction

Protheus → PIMS

Nome Lógico ERP

Nome Lógico PIMS

Nome Técnico

Fluxo

10 – Cargos

Cargos (CARGO)

Position

Protheus → PIMS

11 – Funcionários

Funcionários (FUNCIONAR)

Employee

Protheus → PIMS

12 – Disponibilidade Funcionário

Disponibilidade Funcionário (Afastamento e férias)

Situations

Protheus → PIMS

 

Visão Lógica dos Processos

Envio do EMS para o PIMS
O Processo no Protheus insere na Fila EAI de Saída ( Protheus EAI ) a mensagem, que é dispara via WS-I para o TOTVS ESB ( Integrator 5.1.X ) usando o componente ProtheusReceiver, que por sua vez identifica a mensagem, traduz usando o XSL específico para o processo do PIMS, e deposita a mensagem XML na fila JMS de Inbound (Entrada) que será consumida pelo MessageReceiver, que por sua vez traduz a mensagem para as tabelas do PIMS.

Nessa situação as mensagens são processadas no sentido Protheus → PIMS, não necessitando de controle de processamento, e em caso de erro podem ser reenviadas novamente, pois, caso o registro já exista no PIMS, ele será atualizado, e caso não exista será inserido.
Em nenhum dos cadastros, foi contemplada a exclusão de dados nesse sentido, pois o PIMS tem severas restrições de integridade de dados.



Diagrama do envio de transação no sentido Protheus → PIMS dos cadastros e retorno da Baixa:

Usamos o IdentifierMensagem que identifica a mensagem e roteia adequadamente para o tradutor específico para o processo do PIMS (veja nomes lógicos), usando o JMSSender para o servidor do PIMS.

Configurações do ESB:
ProtheusReceiver:



PIMSJMSSender:




Envio do PIMS para o Protheus
O Processo no PIMS insere registros na tabela de controle das baixas (BRG_BXMATERIAL_EMS) e gera um XML baseado no modelo XSD:BaixaMaterial.xsd que é depositado numa fila interna JMS de Outbound que será consumida via JMS ( Java Message Service ) pelo TOTVS ESB usando o JMSReceiver, que por sua vez traduz o documento XML usando o XSL específico para a InventoryTransaction, e envia o XML traduzido para o Protheus WS, nesse momento o Agente do ERP consome as mensagens de requisição de baixa de material. Após consumir as mensagens, o processo do Protheus gera o retorno no Protheus EAI que é consumido pelo TOTVS ESB e enviado para o PIMS informado o sucesso ou erro das baixas.


Diagrama do envio de transação no sentido PIMS → Protheus da Baixa de Material:




Configurações do ESB:
ProtheusSender:


PIMSReceiver:


Para o retorno do Protheus para o PIMS da Baixa de Material usamos o mesmo diagrama dos cadastros, pois o Protheus WS usa o mesmo canal de retorno WS Protheus Receiver:

Configuração Base do TOTVS ESB

Usamos o WS-Channel do HTTP Server do ESB configurado na porta 8085 do ESB conforme configuração abaixo:





Configuração do WS-Channel

PIMS

O PIMS deve estar devidamente instalado e configurado em ambiente de Homologação e Produção, com versão Novembro 2014 ou superior.


Parâmetros
O Sistema PIMS utiliza configurações padronizadas ou específicas, chamadas de parâmetros.
Um parâmetro é uma variável que atua como elemento chave na execução de determinados processamentos. De acordo com seu conteúdo é possível obter diferentes resultados.

          Valor – True

          Valor – InventoryTransaction

          Valor – 204

          Valor – True

          Valor – True

          Valor – false

          Valor – True / False – A definir na Implantação

          Valor – True / False – A definir na Implantação

          Valor – A definir na Implantação

Configurações services_client.xml
O Sistema PIMS realiza algumas configurações específicas de seus clientes em arquivo XML, chamadas services_client.xml. Dentro do arquivo services_client.xml, existe variáveis que precisam ser preenchidas conforme as necessidades de cada cliente.
Abaixo serão listadas as variáveis que deverão ser preenchidas respeitando o valor pré-definido pelo ERP.
Variáveis referentes ao processo de integração


Variáveis referentes ao processo de Aplicação Insumos


Variáveis referentes ao processo de Blocagem


Variáveis referentes ao processo de Tratamento Semente


Variáveis referentes ao processo de Pesagem


Variáveis referentes ao processo de Abastecimento


Variáveis referentes ao processo de Lubrificação


Variáveis referentes ao processo de Beneficiamento


Variáveis referentes ao processo de Plantio


Variáveis referentes ao processo de Serviço Campo


Variáveis referentes ao processo de Estorno da Aplicação Insumos


Variáveis referentes ao processo de Estorno da Blocagem


Variáveis referentes ao processo de Estorno do Tratamento de Semente


Variáveis referentes ao processo de Estorno da Pesagem


Variáveis referentes ao processo de Estorno do Abastecimento


Variáveis referentes ao processo de Estorno da Lubrificação


Variáveis referentes ao processo de Estorno do Beneficiamento


Valores padrão por Transação
Devido aos modelos conceituais, os cadastros a seguir têm valores padrão quando os registros são provenientes do EMS para o PIMS:
Centro de Custo – CostCenter
Deve haver um Ramo de Custo com Código 1 cadastrado no PIMS com nome a A DEFINIR
Deve haver uma Fase de Custo com cadastrado no PIMS com nome a A DEFINIR
Deve haver uma Ocupação com cadastrado no PIMS com nome a A DEFINIR
Insumo – Item
Deve haver um Principio Ativo com cadastrado no PIMS com Código 999 e nome a A DEFINIR
Cargo - Positions
Deve haver um Cargo com cadastrado no PIMS com nome a A DEFINIR
Baixa de Material – InventoryTransaction
Os dados são gravados na tabela BRG_BXMATERIAL_EMS.
Restrições: Devem estar parametrizados: Unidade Administrativa (CD_INT_ERP) para Empresa,
Centro de Custo (ver CD_INT_ERP), Insumo e Material (CD_INT_ERP e CD_CONTA_ERP) como
Código, Depósito (CD_INT_ERP), Fazenda (CD_INT_ERP) como Estabelecimento.

 

Configurações do PIMS EAI
Nos arquivos de configurações XML do PIMS ( /proxima/pims/config ) devem haver os parâmetros de tipoDocumento e tipoMovimento com dados específicos do cliente:
<!-- Protheus acima de 000-->
<var name="brg.tipoDocumento" type="java.lang.String" value="001" />
<!-- Protheus acima de 500 -->
<var name="brg.tipoMovimento" type="java.lang.String" value="501" />

 

Protheus

O BackOffice Protheus deve estar devidamente instalado e Configurado em ambiente de Homologação e Produção, com versão 11.80 ou superior.


Parâmetros
O Sistema Microsiga Protheus utiliza em suas rotinas configurações padronizadas ou específicas, chamadas de parâmetros.
Um parâmetro é uma variável que atua como elemento chave na execução de determinados processamentos. De acordo com seu conteúdo é possível obter diferentes resultados.
Todas as variáveis são iniciadas pelo prefixo MV_ e agem sobre diversas operações no Sistema.

(Exemplo: http://10.10.0.246:8080/ws/esb/wsdl11/literal/rpc - Endereço WS-I do TOTVS ESP).

Valor .T.

Valor ProtheusReceiver

 

Glossário

Java EE – Java Enterprise Edition – Ferramenta Java para desenvolvimento de aplicativos corporativos usando tecnologias Web e persistência em banco de dados relacionais e transacionais.
ACID – ( Atomicity, Consistence, Isolation e Durability ): modelo de transações de negócio/dados independentes e garantidas
XSLT – (XML Stylesheet Transformation ) : transformação de documentos XML usando um processador que lê uma configuração XSL e gera outro documento XML no formato e padrão desejado.
EAI – (Enterprise Application Integration ): mecanismo usado para controlar envio/recebimento de mensagens de dados para processamento assíncrono de transações de integração.
JMSSender – (Java Message Service Sender ): conector de envio de dados para filas JMS dentro do TOTVS ESB
JMSReceiver – (Java Message Service Receiver ): conector de consumo de dados de filas JMS dentro do TOTVS ESB
JBOSS – servidor Java EE 1.4 que hospeda o aplicativo do PIMS.