Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.


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 ERP RM e enviado para o Smartlink server (serviço hospedado na plataforma TotvsApp).

Informações


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


01.Configurando a integração 

incluir componente desk card contendo os passos...

1 - Deve abrir uma issue de apoio para equipe de framework BH (DFRWFOUNDATION) solicitando o registro do app em questão nas configurações gerais de integração (disponíveis no arquivo TotvsAppSaas.json).


incluir print do wizard.. está dando erro na tela

2 - Informar o clienteId e clientSecret enviados para o cliente no "Assistente de ativaçaõ" selecionando o app em questão.


02.Serviço RM de envio dos dados

Na integração Smart Link DataSharing v1, os dados são enviados em ciclos 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 ao mesmo tempo.

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


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'. 


Informações

A tabela GDataShareRecords é responsável em manter um rastro dos registros que já foram enviados (por tabelas).

Portanto, operações de update, delete e insert não poderão ser efetuadas nessa tabela de forma manual. 

O processo de limpeza dessa tabela é feito automaticamente pelo serviço de envio de dados.


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:

Bloco de código
{
    "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, atualmente a plataforma trabalha com dados no máximo até de 2 anos para trás. Deve 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) seja sinalizada para o ERP.
  3. Recarga de uma tabela específica (atributo forceReload): é um campo do tipo booleano que indicará para o ERP efetuar a recarga desta tabela. Uma vez que a recarga foi solicitada, na próxima chamada feita para o serviço de Entities ela virá como 'true' para sinalizar o reenvio e as chamadas subsequentes irão trazer ela imediatamente como 'false'. Recurso importante para tratar cenários com problema sem a necessidade de acessar o ambiente do cliente.

Informações

Solicitações de inclusão / exclusão de tabelas devem ser tratadas diretamente com a equipe de plataformas do TotvsApp.

04.Dados disponíveis no Smart Link 05.Dados disponíveis na Carol