Do Food Truck à Cozinha Industrial: Entendendo a Arquitetura do ERP TOTVS RM através de uma Pizzaria

Gerenciar um ERP robusto, com mais de 20 anos de estrada e milhares de clientes, é um desafio de engenharia que muitas vezes parece impenetrável para quem não está no dia a dia do código. Para simplificar, resolvi explicar como a Linha RM funciona usando algo que todo mundo entende: Pizza.

A topologia do RM traduzida para o mundo real: uma representação visual de como a arquitetura gerencia concorrência, isolamento de falhas, múltiplos canais de comunicação e resiliência na entrega.

1. O Ponto de Contato: Food Truck vs. Restaurante

A base de tudo é o modelo Cliente/Servidor.

• O Cliente (Client): É quem faz o pedido. Pode ser a MDI .Net (rm.exe), o Portal Corpore.Net ou um sistema externo via WebAPI.
• Ambiente Local (O Food Truck): Sabe quando você instala tudo na sua máquina para desenvolver? É como um Food Truck. O balcão (Client) e a cozinha (Server) estão no mesmo veículo. É ágil para o dono, mas se o pneu fura ou o motor falha, a operação inteira para, não assa pizza mesmo que o forno esteja em plenas condições!
• Três Camadas (O Restaurante): Aqui o negócio escala. Temos um salão para os clientes e uma cozinha central (Servidor) que atende várias mesas e até pedidos de delivery simultaneamente. Se você precisar de mais mesas, não precisa construir outra cozinha.

2. O Cardápio e as Receitas (O misterioso _broker.dat)

Para que um garçom saiba o que a cozinha pode entregar, ele precisa de um cardápio. No RM, esse papel é do _broker.dat.

Ele é o mapa que diz ao sistema em qual “estante” (DLL) está cada funcionalidade (Actions, DataServers, Forms).

Curiosidade de “Cozinha”: Antigamente, ao atualizar o sistema, era preciso deletar o cardápio para o pizzaiolo reescrevê-lo do zero. Hoje, a Engenharia já entrega o cardápio pronto no instalador. Apenas, para quem “inventa novas receitas” (Desenvolvedores), deletar o broker ainda é o segredo para o Host reconhecer a nova interface criada.

3. A Gestão da Cozinha: Atendente ou Pizzaiolo? (Job Server)

Este é o ponto onde a performance do seu negócio é decidida.

• Job Server Desabilitado: Imagine uma pizzaria onde o atendente recebe o pedido, larga o telefone, vai para a cozinha bater a massa, assa a pizza e depois volta para atender o próximo cliente. Enquanto ele faz a pizza, ninguém consegue pedir nada. É o processamento síncrono: o AppServer fica “preso” até terminar a tarefa.
• Job Server Habilitado: O atendente apenas registra o pedido no sistema e volta a atender. Os pizzaiolos (JobServer) ficam na cozinha focados apenas em assar as pizzas (RmsProcess como um GJobXExecucao).

4. Escalando a Produção: Fornos e JobRunners

Quando o movimento cresce, você contrata mais pizzaiolos (JobRunners). Mas cuidado: não adianta ter 20 pizzaiolos se você só tem um forno pequeno. Na arquitetura RM, precisamos equilibrar a quantidade de JobRunners com o “forno” disponível (CPU e Memória do servidor).

• Processo Isolado (O Forninho Próprio): Para evitar que uma pizza queimada defume a pizzaria inteira, usamos o RM.Host.JobRunner.exe. Cada pizzaiolo tem seu próprio mini-forno isolado. Se um processo falhar criticamente, os outros continuam assando normalmente.

5. Canais de Venda: Telefone, App e iFood (WCF e WebAPI)

Como o cliente chega até a pizzaria?

• WCF: É o rádio de comunicação interna ou o telefone fixo. É robusto e o padrão da casa, suportando diversos protocolos (TCP, SOAP).
• WebAPI: É o canal moderno. Como um app de delivery, fala uma língua universal (REST/JSON), entregando os pedidos com agilidade e integrando com qualquer outro sistema do mercado.

6. A Rede de Franquias (Multi-Alias e TGM)

• Multi-Alias (Cozinha Compartilhada): Imagine 5 empreendedores que usam a mesma cozinha industrial, mas cada um tem sua própria marca e seus próprios ingredientes. No RM, um único Host pode atender diferentes bases de dados (Alias) de forma independente.
• Balanceamento nativo (para WCF) / TGM (para APIs) (O iFood da Rede): O Balanceamento nativo e o TGM são os orquestradores (cada um para seu formato). O cliente abre o app, pede a pizza e não precisa saber se ela vem da loja da Rua A ou da Rua B. Ele apenas faz a requisição e o orquestrador garante que ela chegue ao destino correto, abstraindo a complexidade da rede.

7. Garantia de Entrega (Reliable Connection)

O que acontece se o sinal do celular do cliente cair bem na hora de confirmar o pedido? Sem o Reliable Connection, o pedido se perde. Com ele (habilitado por padrão no Smart Client), o sistema mantém a “intenção” do pedido viva. Se a conexão oscilar, ele retoma de onde parou, garantindo que a pizza chegue à mesa sem erros de comunicação.

Conclusão

A arquitetura RM foi desenhada para ser resiliente. Por trás de cada tela do ERP, existe uma logística complexa de cozinheiros, garçons e entregadores trabalhando em sincronia. Entender essa engrenagem é o primeiro passo para extrair o máximo de performance do sistema que move o negócio de milhares de empresas.

Gostou dessa analogia? Gostaria de maior explicação sobre algum dos itens? Qual outra parte do ERP você gostaria de ver “traduzida” assim? Deixe nos comentários!