Licenças TOTVS I: por que as integrações do Protheus e do RM consomem licenças e como reduzir

Um dia o portal do fornecedor fica lento, a integração com o e-commerce começa a dar erro e, no fim da tarde, alguém do financeiro não consegue entrar no ERP. A causa costuma ser a mesma: as licenças acabaram no License Server.

Quase sempre o que esgotou as licenças não foram as pessoas, foram as integrações.

Como o Protheus consome licença nas APIs

No Protheus, a licença TOTVS I é consumida pelas threads HTTP que respondem portais e web services. Duas configurações definem esse consumo:

• Instances: define quantas threads o serviço HTTP abre no mínimo e no máximo. Em uma configuração Instances=5,20, o serviço começa ocupando 5 licenças e pode chegar a 20 conforme a demanda. Se vários servidores têm essa chave, o máximo é a soma de todos.
• Tempo da requisição: a licença fica presa enquanto a requisição é processada. Uma consulta que leva 3 segundos segura a licença por 3 segundos.

Uma thread ociosa só libera a licença depois de 60 minutos, por padrão. Por isso, um pico de acesso pela manhã pode manter licenças ocupadas boa parte do dia.

E no RM

No RM, desde a versão 12.1.15, todos os web services SOAP e REST expostos pelo RM.Host controlam licença. Cada chamada ocupa uma licença TOTVS I durante a execução: três requisições simultâneas pedem três licenças.

O ponto que mais surpreende: quando as licenças TOTVS I chegam a 100%, o RM passa a consumir outros tipos de licença, inclusive a Full. Na prática, uma integração com pico de volume pode tirar o acesso de usuários do sistema.

E no Fluig

No Fluig a lógica é outra: a licença é contada por usuário ativo cadastrado. O problema aparece quando a empresa quer abrir um processo para fornecedores ou clientes. Cada pessoa de fora com login no Fluig ocupa uma licença, mesmo que só entre uma vez por mês para consultar um status.

Como estimar quantas licenças suas integrações usam

Uma conta simples dá uma boa ideia:

licenças simultâneas = requisições por segundo no pico × tempo médio de resposta em segundos

Exemplo: um portal de clientes recebe 20 requisições por segundo no pico, e cada consulta ao ERP leva 1,5 segundo.

20 × 1,5 = 30 licenças TOTVS I ocupadas ao mesmo tempo, só com esse portal.

Agora olhe o que essas requisições fazem. Em portais e aplicativos, a maior parte é leitura: consultar status de pedido, buscar cliente, listar títulos em aberto, ver estoque. A gravação, como criar um cliente ou incluir um pedido, costuma ser uma fração pequena do tráfego.

Se o mesmo portal faz 200 cadastros por dia, e cada gravação leva 2 segundos, isso representa menos de 7 minutos de licença por dia. Uma ou duas licenças resolvem a gravação com folga.

Para saber quanto isso custa, multiplique as licenças pelo valor do seu contrato. A TOTVS não publica tabela de preços e negocia caso a caso, então o número certo está no seu contrato, não na internet.

Três formas de reduzir o consumo

1. Ajustar o próprio Protheus

Antes de construir qualquer coisa, vale revisar a configuração:

• Stateless no REST: com Stateless=1 na seção da URI, o REST do Protheus só consome licença enquanto uma API está sendo usada, em vez de manter uma licença por thread aberta. Não funciona em web services SOAP.
• Instances bem dimensionado: um mínimo alto demais mantém licenças presas sem uso.
• Consultas mais rápidas: índices, filtros e paginação reduzem o tempo de resposta, e menos tempo é menos licença presa.

Esse ajuste é rápido e, em ambientes com pouco volume, pode bastar.

2. Separar leitura de gravação

Quando o volume de consultas é alto, a mudança de arquitetura traz a maior economia:

• As consultas são atendidas por um backend próprio, que lê o banco do ERP ou uma réplica, com usuário somente leitura e views preparadas. Não passam pelo License Server.
• As gravações continuam passando pelo ERP, com ExecAuto ou pela API oficial. As validações e a licença valem na hora de criar ou alterar o registro.

O ERP continua sendo a fonte da verdade e o dono das regras. O backend só tira dele o trabalho repetitivo de responder a mesma consulta milhares de vezes.

Esse backend roda na infraestrutura da própria empresa, ao lado do ERP. Os dados não saem do ambiente que a TI já controla.

Antes de adotar esse modelo, valide o desenho com o seu contrato de licenciamento TOTVS. A gravação nunca deve ir direto ao banco.

3. Usar recursos que o servidor do ERP não tem

Um backend moderno, em Node.js por exemplo, traz ferramentas que o REST do ERP não oferece de forma nativa:

• Cache: a lista de produtos consultada mil vezes por hora é lida do banco uma vez a cada poucos minutos.
• Fila de gravação: o pedido entra na fila, o portal responde na hora e o ERP grava no seu ritmo, com reprocessamento automático se algo falhar.
• Controle por parceiro: cada integração tem sua chave, seus escopos e seu limite de requisições. Dá para saber quem chamou o quê e bloquear um parceiro sem afetar os outros.
• Webhooks: em vez de o parceiro perguntar a cada minuto se o pedido foi faturado, o backend avisa quando acontece.
• Documentação automática: as rotas ficam descritas em OpenAPI, e um novo parceiro integra sem depender de reunião.
• Monitoramento: tempo de resposta, erros e volume por rota em um painel, antes de o usuário reclamar.

Por onde começar

1. Liste as integrações, portais e aplicativos que chamam o ERP.
2. Separe, em cada um, o que é leitura e o que é gravação.
3. Meça o pico de requisições e o tempo médio de resposta.
4. Aplique a conta acima e compare com as licenças do seu contrato.

Se o resultado mostrar muitas licenças presas em consultas, a separação entre leitura e gravação costuma se pagar rápido.

Na MyQube, desenvolvemos APIs e backend para Protheus, RM e Fluig que reduzem o consumo de licenças, com gravação sempre pelo caminho oficial do ERP. Se quiser, fazemos o mapa de consumo do seu ambiente em uma primeira conversa gratuita.