Detalhamento técnico da integração de registros

Potenciais questões

1. Quais são os componentes tecnológicos envolvidos no processo de integração e o que eles fazem exatamente?

RabbitMQ

É um servidor de mensageria de código aberto, desenvolvido em Erlang, responsável por criar a ponte de comunicação entre o ERP XT e a senior X Platform. Há sempre uma instância do RabbitMQ instalada localmente no ERP (que pode estar OnPremise ou no ambiente Cloud da Senior, administrado por IT Services) e outra instância instalada localmente na senior X Platform (administrada pela equipe de arquitetura da Plataforma Senior X da Senior).

ETL ERP
É o componente responsável por enviar os dados do ERP para a Senior X Platform. Esse componente se baseia em pendências de integração que são gerados baseados em triggers de replicação. É obrigatório a sua utilização quando a integração não está configurada para ser executada SEM ETL.
• Para que a comunicação seja realizada, o ETL utiliza o canal de comunicação aberto pelo RabbitMQ;
• O ETL segue um fluxo de replicação das pendências, processando da mais antiga para a mais recente, independentemente da tabela envolvida. Assim, o ETL não possui uma lógica de priorização baseada na criticidade do processo de integração (por exemplo, a integração do WMS não é priorizada sobre a integração com o Senior X Suprimentos). O ETL lê os registros e os envia para a Plataforma sem considerar a lógica de negócios;
• Por este motivo, o ETL não é recomendado para integração com WMS em cenários de alta volumetria de registros e criticidade de integração, sendo recomendado o uso do Processo agendado 165.
ISL

É um componente da integração alocado na própria plataforma, responsável por receber dados dos sistemas (ERP ou WMS) e transformá-los para que sejam compatíveis com cada sistema. Por exemplo, quando uma Ordem de Separação é transferida do ERP para o WMS, após a exportação do registro da Ordem de Separação do ERP para a Plataforma Senior X (seja através do ETL ou do processo agendado 165), o registro é processado pelo ETL. O ETL então monta um pacote para envio ao WMS, transformando as informações em um padrão de comunicação interpretável pelo WMS. Após o processamento da Ordem de Separação no WMS, são executados os processos adequados de separação. Concluído o processo no WMS, este envia as informações de volta para a Plataforma Senior X, onde o componente ISL converte os dados recebidos em um formato que possa ser interpretado e processado pelo ERP XT (no ERP, o ERP_Service atua na recepção das informações).

ERP_Service

O componente ERP_Service é responsável por receber informações oriundas da senior X Platform e processá-las dentro do ERP . No processo de integração com WMS, o ERP_Service é acionado após o processamento de algum registro que seja retornado do WMS e já tenha sido processado também pelo ISL. O ERP_Service obrigatoriamente precisa de conexão com o RabbitMQ, que faz a ponte de comunicação entre ERP e a plataforma.

Na prática, o ERP_Service é responsável por receber mensagens no padrão de comunicação JSON (utilizado pela plataforma), interpretá-las e processá-las dentro do ERP. Ele atua de forma semelhante a uma instância de Middleware, porém, atende a requisições JSON em vez de requisições SOAP.

Quando utilizado o processo agendado 165 para envio de registros do ERP para a plataforma, o ERP_Service atua como uma ponte na busca dos dados a serem exportados do ERP. Exemplo de cenário para esse processo:

• Existe uma Ordem de Separação pendente para ser exportada no ERP (registro presente na tabela E998OSC e na tabela RTC_PENDENCIES;
• O processo agendado 165 é executado, localiza essa ordem e envia um sinal para o ISL de que essa ordem precisa ser exportada;
• No ISL o registro é gerado com o status “Aguardando exportação” (status que é possível ser verificado no Monitor Logística);
• A partir disso, o ISL aciona o ERP_Service para buscar os dados da Ordem de Separação no ERP e, em seguida, realizar a exportação completa da Ordem para o ISL;
• Ao final desse processo, a Ordem de Separação estará disponível no ISL, que seguirá o processo interno de integração, marcando o registro com a Situação ERP como “Concluído” e enviando o registro para o WMS.

Importante

O ERP_Service não pode ser acionado por outros sistemas de terceiros para o processamento de registros no padrão JSON. Ele é um componente exclusivo para integração com a Plataforma Senior X, utilizado apenas nos modelos de integração padrão desenvolvidos pela Senior.

AppManager

O AppManager é o Gerenciador de Instâncias do ERP_Service. Em uma analogia, o AppManager é para a comunicação com a Plataforma Senior X o que o Gerenciador de Middleware é para o Middleware Senior. O AppManager não processa registros, mas se estiver desabilitado ou desativado, as instâncias do ERP_Service não estarão disponíveis na memória, impedindo o processamento do tráfego de informações entre a Plataforma Senior X e o ERP XT.

SeniorMiddleware

O SeniorMiddleware é utilizado para execução dos processos agendados através de uma instância do SapiensServer – sapiensserv.exe que são utilizados na integração. Os processos diretamente ligados à integração são o 130 e o 165.

O SeniorMiddleware não é responsável por executar nenhuma transformação de dados do padrão do ERP XT para padrão de comunicação Plataforma Senior X (padrão JSON). Essa responsabilidade é da rotina interna do ERP. O SeniorMiddleware é utilizado apenas para gerenciar a execução do processo agendado.

ETL Logística

Em descontinuação, pois a integração com protocolo REST elimina necessidade desse componente.

É o componente responsável por coletar dados do sistema WMS SILT e enviá-los para a plataforma. Ele é obrigatório em versões do WMS que requerem a utilização deste componente.

Este componente funciona de forma semelhante ao ETL do ERP, mas opera localmente no WMS. Ele também necessita de comunicação com o RabbitMQ, que serve como mensageria para a Senior X Platform.

DML Logística

Em descontinuação, pois a integração com protocolo REST elimina necessidade desse componente.

É o componente responsável por receber os dados da plataforma e enviá-los para o WMS SILT. Ele é obrigatório em versões do WMS que exijam a utilização deste componente. Ele é basicamente o “ERP_Service do WMS SILT” para versões que exigem esse componente.

2. Como funciona a replicação de registros do ERP XT para plataforma senior X?

Processo

O processo de replicação é baseado nas pendências de integração registradas na tabela RTC_Pendencies, localizada no banco de dados do ERP XT;

Essas pendências são populadas pela execução das triggers 'RTC_XXXX', que são geradas em diversas tabelas do banco de dados do ERP XT, conforme o processo de carga inicial realizado através da plataforma;

Quando a integração ocorre via ETL ERP, a tabela RTC_REPLICATIONDEF recebe a indicação das tabelas que devem gerar pendências, seguindo o padrão abaixo:

• COLUNA: IDREPLICATOR = ERP_AWS;
• COLUNA: TABLENAME = Nome da tabela a ser replicada (E140IDE, E000PRS, dentre várias outras).

Quando a integração ocorre via Protocolo Rest (Processo agendado 165), a tabela RTC_REPLICATIONDEF recebe a indicação das tabelas que devem gerar pendências, seguindo o padrão abaixo:

• COLUNA: IDREPLICATOR = ERP_LOG;
• COLUNA: TABLENAME = Nome da tabela a ser replicada (neste caso, apenas as tabelas E998OSC, E998ORC e E185CFG, pois são as únicas que possuem dependências de registro quando a integração ocorre via Protocolo Rest).

Quanto à inserção dos registros 'IDREPLICATOR = ERP_LOG' na tabela RTC_REPLICATIONDEF, eles são adicionados via script de correção na base do ERP a partir da versão que permite a integração via Protocolo REST, através do processo agendado 165. Nenhuma ação específica por parte do usuário é necessária, pois tudo é automatizado pelo sistema;

A tabela RTC_REPLICATORDEF registra os tipos de replicação ativos na base de dados e a tabela onde os status de processamento das pendências serão gravados;

Quando pendências são geradas na tabela RTC_Pendencies, elas estão sempre associadas a um tipo, definido na coluna IDREPLICATOR da tabela RTC_REPLICATIONDEF. Assim, quando uma pendência é gerada via trigger, por exemplo, na tabela E998OSC, e uma versão do ERP que permite integração via Protocolo REST está aplicada, duas pendências serão registradas na tabela RTC_PENDENCIES:

• Uma pendência terá o tipo 'ERP_AWS' e será consumida pelo serviço do ETL, sendo enviada para a Plataforma Senior X via ETL ERP;
• Outra pendência terá o tipo 'ERP_LOG' e será consumida pelo processo agendado 165, sendo enviada para a Plataforma Senior X pelo próprio processo agendado, que executa a função do ETL;
• Dessa forma, embora as pendências trafeguem dentro da mesma tabela (RTC_Pendencies), elas não são consumidas pelos mesmos processos.

A tabela RTC_INATIVE_REPLICATION pode ser utilizada para definir tabelas que tiveram pendências geradas através das triggers de replicação, mas cujos registros não devem ser replicados pelo ETL por algum motivo. Por exemplo, pode-se desativar temporariamente a replicação de uma tabela para que o ETL priorize a replicação de outras tabelas;

Abaixo segue como os registros da tabela RTC_REPLICATIONDEF ficam quando, na mesma base de dados, há replicação de registros baseada no ETL (tipo 'ERP_AWS') e no processo agendado 165 (tipo 'ERP_LOG'):

Exemplo



Informações complementares

Você encontrará mais informações sobre o processo de replicação de registros do ERP XT para a XPlatform na documentação de Replicação. A documentação explica o processo baseado em ETL, mas tenha em mente que o processo de replicação através do processo agendado 165 segue o mesmo conceito; apenas o tipo de pendência e o componente de integração utilizado são diferentes;

O processo agendado 165 se baseia nas pendências geradas na tabela RTC_Pendencies para as tabelas E998OSC, E998ORC e E185CFG. Portanto, mesmo que o ETL ERP não seja utilizado na integração com o WMS, é obrigatório implantar o processo de integração do ERP com a Plataforma Senior baseado nas triggers de replicação, o que exige que o ETL esteja corretamente instalado no ambiente;

Para verificar informações detalhadas sobre a exportação de cadastros do ERP XT para a plataforma, consulte a documentação de integração de Cadastros.

3. Como é possível verificar as pendências de integração que não foram integradas na XPlatform ainda?

Para realizar essa análise, é necessário executar consultas (SELECTs) na base de dados do ERP XT utilizando CBDS ou outra ferramenta de banco de dados.

Select para analisar se os integradores ETL e o processo agendado 165 estão consumindo pendências na base de dados do ERP. A consulta agrupará os resultados pelo tipo de replicação: ERP_AWS (referente à replicação via ETL) e ERP_LOG (referente à replicação via processo agendado 165).

Veja

SELECT  
   'ERP_AWS' AS REPLICATOR, COUNT(*), TABLENAME  
FROM  
   RTC_PENDENCIES A 
WHERE  
   TABLENAME IN (SELECT TABLENAME FROM rtc_replicationdef WHERE idreplicator = 'ERP_AWS') AND 
   ID NOT IN (  
     SELECT  
       OPERATIONID  
     FROM  
       RTC_ERP_AWS_STATUS)  
GROUP BY  
   TABLENAME 
UNION ALL 
SELECT  
   'ERP_LOG' AS REPLICATOR, COUNT(*), TABLENAME  
FROM  
   RTC_PENDENCIES A 
WHERE  
   TABLENAME IN (SELECT TABLENAME FROM rtc_replicationdef WHERE idreplicator = 'ERP_LOG') AND 
   ID NOT IN (  
     SELECT  
       OPERATIONID  
     FROM  
       RTC_ERP_LOG_STATUS ) 
GROUP BY  
   TABLENAME 

No resultado exibido, o Integrador “ERP_AWS” são pendencias consumidas pelo ETL. Já o “ERP_LOG” são pendências consumidas pelo processo 165.

Select para analisar se os integradores ETL e o processo agendado 165 estão consumindo pendências na base de dados do ERP, excluindo da lista as tabelas que não possuem replicação ativada (ou seja, aquelas presentes na RTC_INATIVE_REPLICATION).

Veja

SELECT  
   'ERP_AWS' AS REPLICATOR, COUNT(*), TABLENAME  
FROM  
   RTC_PENDENCIES A 
WHERE  
   TABLENAME IN (SELECT TABLENAME FROM rtc_replicationdef WHERE idreplicator = 'ERP_AWS') AND 
   ID NOT IN (  
     SELECT  
       OPERATIONID  
     FROM  
       RTC_ERP_AWS_STATUS) and tablename not in (select tablename from RTC_INATIVE_REPLICATION) 
GROUP BY  
   TABLENAME 
UNION ALL 
SELECT  
   'ERP_LOG' AS REPLICATOR, COUNT(*), TABLENAME  
FROM  
   RTC_PENDENCIES A 
WHERE  
   TABLENAME IN (SELECT TABLENAME FROM rtc_replicationdef WHERE idreplicator = 'ERP_LOG') AND 
   ID NOT IN (  
     SELECT  
       OPERATIONID  
     FROM  
       RTC_ERP_LOG_STATUS ) 
GROUP BY  
   TABLENAME 

Select para analisar se a Replicação de Registros está ativa na Plataforma (aplicável apenas quando o tráfego dos registros de integração com WMS ainda passa pelo ETL do ERP). Esse comando, executado na base do ERP G5, verifica se a replicação está ativada na Senior X (Menu Tecnologia > Administração > Integração > Replicação).

Veja

SELECT 
  PRMVAL AS STATE 
FROM 
  R900GPR 
WHERE 
  PRMID = 211 

Se o resultado desse comando for 'RUNNING', isso significa que a replicação está em execução. Se o resultado for 'STOPPED', significa que a replicação está parada.

Visualização pela plataforma



Log

No log do ETL é possível verificar a seguinte frase: The continuos replication route state is: 1-Started



Quando no log estiver como Started quer dizer que está ativa, se estiver como Stopped quer dizer que está desativada.

4. Como ocorre a limpeza das pendências de integração da tabela RTC_PENDENCIES?

A limpeza das pendências dos tipos 'ERP_AWS' e 'ERP_LOG' na tabela RTC_Pendencies é realizada pelo ETL, mesmo que o tráfego dessas pendências ocorra em fluxos separados. Portanto, o ETL não pode ser desativado, mesmo que o tráfego de integração com o WMS seja completamente migrado para o processo agendado 165 e não haja mais nenhuma rotina integrada com a XPlatform além do WMS.

A limpeza das pendências ocorre conforme a documentação do Integrador ETL. Para mais detalhes, consulte o tópico Limpeza de pendências.

5. Como fazer o teste de conectividade dos componentes de integração entre ERP XT e a XPlatform que afetam a integração entre ERP e WMS?

Acesse o artigo TECNOLOGIA – Integração Senior X – Como testar a conectividade dos componentes ERP Service, ETL e RabbitMQ e verificar tráfego de integrações específicas entre ERP e WMS SILT/ALCIS.

6. No processo de migração da integração do ETL do ERP para Processo Agendado de rotina 165, é necessária fazer alguma limpeza de pendências?

Sim, é necessária. Se a limpeza de pendências não for realizada antes da ativação do Processo Agendado de Rotina 165, há o risco de que pendências já exportadas anteriormente via ETL sejam exportadas novamente para a Plataforma Senior X, causando diversas inconsistências nas integrações.

Nessa situação, recomendamos a execução dos seguintes passos:

1. Execute o select

Execute o select descrito no tópico 3 desta documentação: Select para analisar se os integradores ETL e o processo agendado 165 estão consumindo pendências na base de dados do ERP, excluindo da lista as tabelas que não possuem replicação ativada (ou seja, aquelas presentes na RTC_INATIVE_REPLICATION).

2. Verifique pendências

Verifique se existem pendências com o campo REPLICATOR definido como "ERP_LOG". Exemplo abaixo:



O objetivo deste select é verificar que existem de fato pendências do tipo "ERP_LOG" que precisam ser limpos antes da ativação do processo agendado.

3. Acompanhe as pendências

Acompanhamento das pendências de integração com replicator "ERP_AWS". Realize o acompanhamento para assegurar que todas as pendências de integração que trafegam via ETL do ERP sejam corretamente exportadas para a Plataforma Senior X. Pode ser necessário alinhar com os usuários uma parada temporária dos processos em execução, a fim de evitar a geração de novas pendências durante o procedimento.

4. Pare a integração antiga

É necessário interromper temporariamente o ETL ERP assim que todas as pendências do tipo "ERP_AWS" forem consumidas. Para clientes em ambiente Cloud, é necessário acionar a equipe de IT Services por meio da abertura de um ticket.

5. Limpe as pendências

Efetue a limpeza das pendências de integração do tipo ERP_LOG.

Comando a ser executado: DELETE FROM RTC_PENDENCIES WHERE TABLENAME IN ('E998OSC', 'E998ORC') and id in (select operationid from rtc_erp_aws_status).

Observação

O comando está relacionado especificamente com as tabelas E998OSC e E998ORC. De acordo com o select executado no como primeiro passo dessa orientação, você poderá editar o comando acima adicionando as demais tabelas que esteja retornadas pelo Select (lembre-se de ser apenas as tabelas cujo o campo REPLICATOR esteja definido como "ERP_LOG").

6. Altere configurações do keyint da E185CFG.

Efetue as alterações adequadas no Keyint da tabela E185CFG para que o ISL na Plataforma Senior X reconheça que a integração passará a trafegar através do processo agendado 165 (sem ETL). A alteração deverá ser realizada conforme documentação descrita em Integração Gestão Empresarial | ERP x Gestão de Armazenagem | WMS.

7. Ative o ETL ERP.

A ativação do ETL do ERP servirá para que a integração das configurações da tabela E185CFG sejam reconhecidas pelo ETL. No Monitor Logística da Plataforma Senior X, ao verificar os componentes que estão sendo utilizados para a integração, deverá aparecer apenas o "ERP_Service", indicando que o ISL já interpretou a alteração trafegada através da tabela E185CFG pelo ETL.

8. Habilite processo agendado de rotina 165

Somente após ser realizado todos os passos acima é que o processo agendado 165 deverá ser devidamente habilitado na base que está sendo configurada.