Âncora
_Toc383790614 _Toc383790614

Âncora
_Toc410641825 _Toc410641825

Âncora
_Toc434314406 _Toc434314406

Âncora
_Toc435193508 _Toc435193508

Âncora
_Toc445907630 _Toc445907630

Sumário

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

Âncora
_Toc445907631 _Toc445907631

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 , e suas interfaces e evidencias de homologação..

Âncora
_Toc445907632 _Toc445907632

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.

Âncora
_Toc445907633 _Toc445907633

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.

...

Âncora
_Toc445907634 _Toc445907634

Visão Lógica das Integrações

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

Âncora
_Toc445907635 _Toc445907635

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:
Image RemovedImage Added
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:
Image Modified


PIMSJMSSender:
Image Modified



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:
Image Modified



Configurações do ESB:
ProtheusSender:
Image Modified

PIMSReceiver:
Image Modified

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:
Image Modified

Âncora
_Toc445907636 _Toc445907636

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:
Image Modified




Configuração do WS-Channel
Image Modified

Âncora
_

...

Toc445907637 _

...

Toc445907637

...

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.

• USING_INVENTORY_LIST - Determina se o envio de dados será em lista de itens ou item a item

          Valor – True

• NOME_TRANSACAO_BAIXA - Nome da transação de Movimento de Estoque

Valor           Valor – InventoryTransaction

• CD_CCUSTO_PADRAO_DISP - Código do CCUSTO Padrão para Disponibilidades

Valor           Valor – 204

• EMPRESA_FILIAL_EAI - Controle por Empresa x Filial

Valor           Valor – True

• ESTORNO_BAIXA - Se executa estorno de baixa de material

Valor           Valor – True

• FG_MOV_ESTOQUE_SINC - Permite configurar as integrações de movimentação de estoque para executarem de forma síncrona ou assíncrona.

Valor           Valor – false

• CHAR_CD_CCUSTO - Caracteres a serem retirados do Código do Centro de Custo

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

• FG_CENTRALIZAR_REGIAO_ADM - Centralizar dados por Região Administrativa

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

• CD_UNI_NEGOCIO_BX - Unidade de Negócio ERP

Valor           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

...

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" />

Âncora
_Toc445907638 _Toc445907638

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.

...

• MV_PORT: ProtheusReceiver – Nome do Canal WS do TOTVS ESB

Valor ProtheusReceiver

Âncora
_Toc445907639 _Toc445907639

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.