Integração RM x Smart Link Data Sharing 2.0

INTRODUÇÃO 

Aqui você encontrará as informações necessárias para utilizar a Integração RM com Smart Link DataSharing v2. Para essa integração será utilizado o protocolo de comunicação grpc. 

Nesse modelo de integração, o dado é recuperado do RM e enviado para o Smartlink server (serviço hospedado na plataforma TotvsApp).

Na versão anterior de integração com Smart Link DataSharing v1 , o dado é recuperado do RM e enviado diretamente para a Carol (mais detalhes disponível em https://tdn.totvs.com/x/l-55IQ,).

01. Configurando a integração 

a) - Solicitar a criação do app junto a equipe de plataforma do TotvsApp. 

b) - Abrir uma issue de apoio para equipe de framework BH (DFRWFOUNDATION) solicitando o registro do app em questão nos arquivos de configuração (TotvsAppSaas.json), O identificador do App deve ser enviado nessa issue.

c) - Efetuar ativação do app através do "Processo de ativação do TotvsApp" disponível em: "Integração/TotvsApp".

c) - Informar o "RAC clienteId" e "RAC clientSecret" enviados para o cliente e selecionar o App a ser ativado. 

e) Limpeza de Histórico: 

Para facilitar o uso da funcionalidade de limpeza de histórico da tabela GTOTVSAPPCONCEITOHST, foi implementada uma nova opção de "Limpeza de Histórico" no sistema.

Como Utilizar:

1. Acessar a Opção de Limpeza:

   • No processo de atividades com o TOTVS APP, haverá um botão chamado "LIMPEZA DE HISTÓRICO".

2. Configurar a Limpeza:

   • Dias que devem ser mantidos no histórico: Defina quantos dias de histórico você deseja preservar. Os registros dentro desse período não serão removidos.
   • Número máximo de registros a serem removidos: Determine quantos registros antigos devem ser apagados, começando dos mais antigos até os mais recentes.

1. Executar a Limpeza:

   • Após configurar as opções de limpeza, clique em "Executar" para realizar a limpeza dos registros conforme as configurações selecionadas.

Observação:

O sistema sempre preservará o último registro executado com sucesso para cada conceito na tabela, garantindo que as informações essenciais sejam mantidas.

02. Serviço RM de envio dos dados

Na integração anterior (Smart Link DataSharing v1) os dados são enviados em ciclos de execução de Job's (mecanismo de  Job do RM - https://tdn.totvs.com/x/_Z4YIQ).

Já na integração Smart Link DataSharing v2, os dados serão enviados através da execução automática de um serviço de Host chamado NotifyServer.

Nesse mecanismo, somente uma máquina do ambiente do cliente (seja um servidor de aplicação ou um servidor de Job) terá a responsabilidade de enviar os dados. Em nenhum momento duas ou mais máquinas poderão enviar  os dados simultaneamente.

Caso ocorra algum problema com a máquina responsável pelo envio, ficando portanto indisponível, outra máquina assumirá o papel de envio.

O envio dos dados ocorrerá de 5 em 5 segundos, ou seja, caso um algum registro (de alguma tabela integrada) seja alterado, a alteração será enviada para o Smart Link Server após 5 segundos. 

03. Envio dos pacotes (batchs)

Nesta versão, a sincronização de dados entre o RM → Smart LIink → Carol seguirá o conceito de envio por pacotes (batchs). Cada pacote possui um identificador que será utilizado para rastreio dos dados conforme são enviados pelo Smart Link, para a Carol e por fim até ao app.

O batch será  composto por múltiplas mensagens que irão conter os registros das tabelas que deverão ser enviadas para o serviço de ingestão utilizando o protocolo de comunicação gRPC.

Cada mensagem é formada por 200 registros. 

No RM, o rastreio dos dados enviados podem ser verificados através de uma sentença sql na tabela "GDataShareRecords'. 

04. Serviço de entidades 

As entidades consistem em uma parte fundamental do processo. Elas determinam todas as entidades que o RM deve subir de acordo com os app's contratados.

A lista das tabelas que participarão do processo de envio é recuperada através da chamada de um serviço com endpoint "/api/carol-definitions/v1/entities/RM".

O retorno da chamada desse serviço terá o seguinte padrão de objeto:

{
    "uploadVersion": 2,
    "uploadVersionInfo": "Gestão de Upload de Dados via gRPC",
    "queries": [
        {
            "table": "TMOV,
            "filter": null,
            "forceReload": true,
            "isNative": true,
            "isCustom": false,
            "metadata": null
        },
        {
            "table": "FLAN",
            "filter": "FLAN.IDLAN > 1000",
            "forceReload": false,
            "isNative": true,
            "isCustom": false,
            "metadata": null
        },

Características:

1. Cada item da lista "queries", representa uma tabela do RM que será integrada. No exemplo acima, teremos a integração das tabelas TMOV e FLAN. 
2. Filtro de dados (atributo filter): clausula SQL ANSI obrigatória para entidades que possuem dados históricos ou de movimentação. Será utilizado sempre que o ciclo de envio estiver enviando a tabela pela primeira vez (carga inicial) ou quando uma solicitação de recarga dessa tabela (force reload = true) seja sinalizada para o RM. 

     3. Recarga de uma tabela específica (atributo forceReload): é um campo do tipo booleano que indicará para o RM efetuar a recarga desta tabela. . Recurso importante para tratar cenários com problema sem a necessidade de acessar o ambiente do cliente.