Integrador

Procedimento de instalação do Integrador e configuração do RabbitMQ para um ambiente híbrido em Windows, utilizando o Instalador dos sistemas.

Arquitetura

Os serviços senior X são contratados na nuvem mas com integração de dados a partir da base de dados dos sistemas que está no ambiente on-premises. A integração de dados ocorre através dos componentes Integrador e RabbitMQ instalados no on-premises e se comunicando com a nuvem de forma segura. Para isso é necessário:

• ambiente senior X na nuvem;
• base de dados dos sistemas Senior no on-premises;
• RabbitMQ e Integrador instalados no on-premises;
• RabbitMQ exposto na internet para permitir comunicação a partir da nuvem;
• comunicação configurada e segura entre RabbitMQ Shovel da nuvem e o RabbitMQ no on-premises via internet.

Pré-requisitos

Artefatos

• Mídia de instalação dos sistemas Senior: pacote de instalação distribuído para implantação no ambiente do usuário;
• RabbitMQ, versão 3.6.9 ou superior, instalado e em execução.

Segurança

• Portas publicadas na internet no on-premises:
  • com certificado digital, por padrão são: 5671 (AMQPS) e 15671 (HTTPS);
  • sem certificado digital, por padrão são: 5672 (AMQP) e 15672 (HTTP).
• Regras de entrada no firewall do on-premises. Permitir tráfego de origem a partir do IP 52.67.76.60 (AWS);
• Certificado digital (recomendado):
  • No on-premises, o certificado é utilizado para criptografar a comunicação entre o on-premises e a nuvem através dos protocolos AMQPS e HTTPS;
  • Na nuvem, o certificado cliente é utilizado para garantir a comunicação segura, iniciada pela nuvem, para com o RabbitMQ no on-premises. É necessário o upload do certificado cliente nas configurações do inquilino, na nuvem;
  • Não é exigido que o certificado seja autorizado internacionalmente.

Acessos

• Pasta compartilhada dos sistemas para obter informações de configuração disponíveis no arquivo de configuração dos sistemas, na Central de Configurações Senior;
• Banco de dados dos sistemas. Para o banco SQL Server somente são homologadas as versões 2012, 2014, 2016 e 2017.
• RabbitMQ via AMQP.

Replicação de dados

A replicação de dados consiste em quatro etapas:

1. Buscar as pendências das tabelas monitoradas, que ainda não foram tratadas;
2. Ler os dados correspondentes às pendências;
3. Publicar um evento com estes dados;
4. Marcar a pendência como tratada.

É considerado o conceito de zero ser nulo da base de dados dos sistemas G5. Portanto, caso o campo possuir um valor zerado e puder receber o valor nulo, este será o valor enviado. Por exemplo, um campo VARCHAR no banco de dados Oracle que tenha como valor ' ' (espaço em branco) será enviado como null.

Tabelas de replicação

Monitore as pendências geradas pelas triggers da base G5 que estão cadastradas para tal. Este cadastro é feito na tabela RTC_REPLICATIONDEF com os dados:

• id: consultar range para o domínio;
• idreplicator: erp_aws;
• tablename: nome da tabela da G5 a receber as triggers.

Em seguida, faça a consistência da base de dados pelo CBDS.

Identificação de triggers ausentes

Comandos para identificar triggers do banco de dados faltantes, ou, no caso do Oracle, inválidas:

Oracle

select * from(

select 'RTC_'||Upper(tablename)||'_I' nm from rtc_replicationdef

union

select 'RTC_'||Upper(tablename)||'_D' nm from rtc_replicationdef

union

select 'RTC_'||Upper(tablename)||'_U' nm from rtc_replicationdef

) sts where not exists(

select 1 from (select object_name, status from user_objects where object_type ='TRIGGER' and UPPER(object_name) like 'RTC_%')sts2

where sts2.object_name = sts.nm and status = 'VALID')

SQL Server

select * from(

select 'RTC_'+Upper(tablename)+'_I' nm from dbo.rtc_replicationdef

union

select 'RTC_'+Upper(tablename)+'_D' nm from rtc_replicationdef

union

select 'RTC_'+Upper(tablename)+'_U' nm from rtc_replicationdef

) sts where not exists(

select 1 from (select name from sysobjects where xtype = 'TR' and UPPER(name) like 'RTC_%')sts2

where sts2.name = sts.nm)

Limpeza de pendências

O Integrador efetua a limpeza das pendências de integração através da Stored Procedure SP_CLEARREPLICATION. Essa SP deve existir na base de dados para que o ETL acione-a e efetue a limpeza. Essa SP é padrão do ERP G5 quando a integração com a Plataforma Senior X é ativada.

O intervalo é definido em horas. Para ambientes com fluxo de integração alto, a recomendação é efetuar a limpeza a cada 1 hora.

Utilização do Integrador ETL

Atualmente, qualquer sistema da versão senior X pode utilizar o integrador ETL, porém apenas alguns optam por utilizá-lo. Verifique os tipos de integração utilizados por cada solução da versão senior X:

• HCM X: utiliza um integrador próprio (caso opte por usar o Integrador ETL e o Integrador do HCM simultaneamente, é necessário fazer configurações adicionais para garantir o funcionamento correto da integração);
• ERP X: a integração é feita com eventos para replicações;
• Ronda X: utiliza um integrador próprio;
• CRM X: utiliza um integrador próprio;
• TMS X: a integração feita via serviços Windows em Delphi;
• Roteirização: utiliza um integrador próprio;
• Gestão de Fretes/FIS: a integração feita via SDL;
• Gestão de Pátio/YMS: utiliza o integrador ETL para integrar os dados do ERP G5.

Quais integradores utilizar?