O SmartLink é um conjunto de serviços, componentes e estratégias cujo objetivo principal é conectar a Plataforma de Aplicações TOTVS a produtos on-premise (Protheus, Datasul, RM).

A solução foi desenhada para garantir uma conexão segura, resiliente e performática, permitindo dois tipos principais de tráfego:

1.  Compartilhamento de Dados Massivos (Data Sharing): Envio de grandes volumes de dados para a plataforma de dados Carol.
2.  Troca de Eventos (Behavior Sharing): Comunicação bi-direcional de mensagens curtas (eventos e comandos).

Uma das principais vantagens arquiteturais do SmartLink é que ele atua de forma não invasiva na infraestrutura de rede do cliente. Não é necessário liberar portas de entrada (inbound) no firewall; a comunicação é estabelecida via acesso de saída (outbound) para portas comuns como HTTP e HTTPS

Definição

O Behavior Sharing é a estratégia voltada para a troca de eventos, comandos e consultas entre as aplicações TOTVS Apps (nuvem) e os ERPs.

Diferente do Data Sharing, este modelo não é recomendado para tráfego massivo de dados, sendo ideal para mensagens pequenas (entre 250kb e 350kb) com baixa latência.

Arquitetura e Comunicação

A comunicação é assíncrona e baseada em filas, utilizando um Platform Message Broker (RabbitMQ) e o protocolo AMQP.

• SmartLink Server: Componente na nuvem que gerencia conexões e cria filas no Broker.
• SmartLink Client: Componente que reside no ERP (ou infraestrutura local) responsável por conectar-se ao Server, preferencialmente via gRPC (ou REST), para consumir e publicar mensagens.

Fluxo de Mensagens

O tráfego de mensagens ocorre em dois sentidos (Bi-direcional):

1. Inbound (TOTVS App → ERP):

   • A aplicação na nuvem publica na exchange link-input.
   • O Broker direciona a mensagem para a fila do tenant específico.
   • O Client no ERP consome a mensagem e a entrega para processamento da regra de negócio.

2. Outbound (ERP → TOTVS App):

   • O ERP envia a mensagem através do Client.
   • O Server publica na exchange link-output.
   • A mensagem é entregue aos Apps interessados, podendo usar filtros de "audiência" para direcionamento específico.

Tratamento de Erros e Resiliência

O sistema possui mecanismos robustos para garantir a entrega e processamento:

• ACK (Acknowledge): Sinaliza sucesso e retira a mensagem da fila.
• NACK (Not Acknowledge): Sinaliza erro temporário; a mensagem é mantida na fila para nova tentativa.
• Requeue: O Client solicita que a mensagem vá para o final da fila para ser processada posteriormente. Existe um limite configurável de requeues (padrão é 10).
• DLQ (Dead-Letter Queue): Se o limite de tentativas exceder ou ocorrer um erro permanente, a mensagem é movida para uma fila de "mensagens mortas" para análise posterior.

Definição

O Upstreaming Data Sharing é a estratégia focada no envio de volumes massivos de dados do ERP para a nuvem, especificamente para a plataforma de dados Carol. O fluxo é unidirecional (ERP → Nuvem).

Estrutura de Envio (Protocolo v2 - gRPC)

O envio é organizado em pacotes (batches) para garantir rastreabilidade e integridade:

1. Pacote (Batch): Identificado por um timestamp sequencial (Unix Timestamp).
2. Mensagem (Table): Cada pacote contém mensagens que representam registros de uma tabela do ERP. As mensagens devem ser enviadas em ordem sequencial estrita.
3. Schema: Define a estrutura dos dados, incluindo chave primária e colunas. O schema é flexível (flexible=true), permitindo a criação automática de colunas na Carol.
4. Sumário: Enviado ao final do pacote, contendo a contagem de mensagens e registros. Serve para sinalizar à Carol que o lote está completo e pronto para processamento.

Tipos de Sincronização

O mecanismo suporta diferentes modos de carga:

• Carga Inicial (Base Load): Envio completo das tabelas.
• Delta: Envio apenas dos dados alterados ou criados desde o último envio.
• Force Reload: Solicitação da nuvem para que o ERP reenvie uma tabela específica (correção de dados ou inconsistências).

A comunicação é assíncrona e baseada em filas, utilizando um Platform Message Broker (RabbitMQ) e o protocolo AMQP.

• SmartLink Server: Componente na nuvem que gerencia conexões e cria filas no Broker.
• SmartLink Client: Componente que reside no ERP (ou infraestrutura local) responsável por conectar-se ao Server, preferencialmente via gRPC (ou REST), para consumir e publicar mensagens.