Node-RED na Prática: Como Migrei um Orquestrador de RPA

Eu nunca tinha ouvido falar do Node-RED até ter que migrá-lo. Na empresa onde trabalho, ele é o orquestrador dos nossos robôs de RPA: comanda 50 robôs feitos em Python, inclusive o robô do faturamento. Quando a equipe de infraestrutura migrou o banco de dados e o DNS, o orquestrador precisava continuar funcionando, sem afetar as áreas da empresa.

Neste artigo, conto como fiz essa migração, que somou 16 horas de trabalho divididas em etapas, com a ajuda do Claude para entender a plataforma, e deixo um checklist para quem precisar migrar um Node-RED.

O que é o Node-RED?

O Node-RED é uma plataforma de programação low-code: em vez de escrever todo o código, você monta fluxos ligando blocos, chamados de nós, num editor que abre no navegador. Cada nó faz uma coisa: receber uma requisição, consultar um banco de dados, enviar uma mensagem, executar uma função em JavaScript.

Ele foi criado pela IBM, hoje é mantido pela OpenJS Foundation e roda sobre o Node.js. É open source e gratuito, e a maior parte do conteúdo sobre ele fala de IoT, como Arduino e Raspberry Pi. Mas ele também funciona muito bem para orquestrar automações de empresa, como no meu caso.

Como funcionava o nosso orquestrador de RPA?

O orquestrador foi desenvolvido em Node-RED antes de eu chegar, e a arquitetura tem quatro partes:

1. O servidor do Node-RED: fica num servidor que a equipe de infraestrutura administra. É onde rodam os fluxos do orquestrador.
2. O servidor dos robôs: os robôs de RPA, escritos em Python, ficam em outro servidor. Na pasta dos projetos cadastrados no orquestrador, há uma pasta do Node-RED, e é lá que eu inicio a conexão com um comando do PM2 (um gerenciador de processos para aplicações Node.js).
3. O banco de dados (SQL Server): o Node-RED grava as informações em três tabelas: uma de controle da execução dos robôs, uma de log de execução e uma de controle de usuários.
4. O MQTT: é o protocolo de mensagens que liga o orquestrador aos robôs.

No dia a dia, eu acesso o orquestrador por uma URL com login e consigo disparar manualmente qualquer robô cadastrado. Se um robô dá problema, eu dou o play ali mesmo, e ele executa direto no servidor.

O desafio: migrar o banco de dados e o DNS

A equipe de infraestrutura migrou o banco de dados para um novo servidor e mudou o DNS. Para o orquestrador, isso significava duas tarefas:

• Apontar o Node-RED para o novo banco de dados, sem perder o histórico de execuções.
• Apontar o servidor dos robôs para o novo endereço do orquestrador.

O cuidado era grande: os 50 robôs atendem áreas diferentes da empresa, e o mais crítico deles é o do faturamento. Qualquer erro afetaria diretamente essas áreas.

Como organizei a migração

A migração não foi feita de uma vez. Foram 16 horas de trabalho no total, divididas em etapas:

1. Planejamento e entendimento: antes de mexer em qualquer coisa, entendi como o orquestrador funcionava e o que precisaria mudar.
2. Migração do banco de dados: depois que a equipe de infraestrutura criou o banco novo, apontei o Node-RED para ele.
3. Apontamento do DNS: com o banco migrado, atualizei os endereços do orquestrador no servidor dos robôs.

Para reduzir o risco, a parte mais crítica foi planejada para um domingo, um dia em que a empresa não tem faturamento. Assim, se algo desse errado, o robô do faturamento não seria afetado.

Também tínhamos um plano de volta (rollback): no teste da migração, a plataforma antiga só foi desligada, e não apagada. Se algo desse errado, bastaria ligá-la de novo. E foi exatamente o que aconteceu, como conto no passo 3.

Passo 1: entender o Node-RED com ajuda da IA

Como eu não conhecia a plataforma, usei o Claude para acelerar o entendimento. Enviei a ele os fluxos do orquestrador, prints das telas e um resumo da arquitetura, e ele foi me guiando: o que cada nó fazia, onde estavam as conexões com o banco de dados e como os robôs se comunicavam com o Node-RED.

Isso fez muita diferença. Em vez de passar dias lendo documentação, em pouco tempo eu já sabia exatamente onde precisaria mexer.

Passo 2: apontar os nós para o novo banco de dados

A parte do banco foi a mais simples. O Node-RED acessa o SQL Server por um nó de banco de dados MSSQL, e cada nó usa uma configuração de conexão (servidor, banco e credenciais).

Eu só precisei entrar nos nós que apontavam para as tabelas e trocar a conexão para o banco novo. Como os nomes das tabelas continuaram os mesmos e o histórico foi migrado junto, o Node-RED assumiu o novo banco de dados na hora, sem nenhuma outra mudança nos fluxos.

Passo 3: encontrar as URLs antigas no servidor dos robôs

O segundo desafio foi mais difícil: descobrir, no servidor dos robôs, todos os lugares que ainda apontavam para o endereço antigo do orquestrador.

1. Busca no VS Code: abri a pasta dos projetos no Visual Studio Code e usei a busca global pela URL antiga. Encontrei três pontos para substituir.
2. O primeiro ponto: troquei pela URL nova, seguindo a orientação da equipe de infraestrutura.
3. O problema: com a plataforma antiga desligada, os robôs não conseguiam se conectar ao Node-RED novo. Só a URL nova não bastava.
4. O rollback: como a plataforma antiga estava só desligada, pedi para voltar a conexão antiga, já usando o banco de dados novo. Os robôs voltaram a funcionar enquanto eu investigava o problema, sem afetar as áreas da empresa.
5. A causa: analisando o caso com o Claude, ele percebeu que os outros dois pontos eram configurações do MQTT, que precisavam de um endereço e de uma porta diferentes.
6. A solução: passei isso para a equipe de infraestrutura, que criou uma URL própria para o MQTT. Com os dois pontos apontando para ela, na porta correta, refizemos a migração, desligando de novo a plataforma antiga, e dessa vez os robôs se conectaram.
7. A remoção do antigo: deixamos o novo orquestrador rodando por dois ou três dias. Com tudo funcionando 100%, aí sim removemos a plataforma antiga de vez.

A lição aqui é que, numa migração, a URL principal não é a única conexão que importa. Protocolos como o MQTT costumam ter endereço e porta próprios, e é fácil esquecer deles.

Checklist para migrar um Node-RED

Se você precisar fazer uma migração parecida, este é o roteiro que eu seguiria:

1. Faça backup dos fluxos antes de qualquer mudança (pelo menu Export do editor ou copiando a pasta de dados do Node-RED).
2. Entenda a arquitetura: liste os servidores, o banco de dados e os protocolos usados. Uma IA ajuda muito nessa etapa.
3. Mapeie os nós de banco de dados e as configurações de conexão de cada um.
4. Mapeie as conexões MQTT (endereço do servidor MQTT e porta) e qualquer outra conexão de rede.
5. Procure o endereço antigo em todos os projetos que se conectam ao Node-RED, com a busca global do editor de código.
6. Combine com a infraestrutura os endereços novos, incluindo os de protocolos como o MQTT, e as portas liberadas.
7. Escolha uma janela sem operação crítica para a parte arriscada. No meu caso, foi o domingo, quando não há faturamento.
8. Tenha um plano de volta: desligue a plataforma antiga em vez de apagá-la, para poder religá-la se algo der errado.
9. Teste primeiro com um robô que não seja crítico, e só depois libere os demais.
10. Acompanhe os logs de execução nas primeiras execuções depois da migração.
11. Só remova a plataforma antiga depois de alguns dias com a nova funcionando sem problemas.

Node-RED ainda vale a pena como orquestrador?

O nosso orquestrador é um sistema legado: foi feito em Node-RED, e a prioridade era fazê-lo funcionar de novo, não reescrever. Para isso, o Node-RED se mostrou flexível e fácil de ajustar, mesmo para quem nunca tinha usado.

Para um orquestrador novo, eu avaliaria outras opções:

• n8n: focado em automação de negócios, com centenas de integrações prontas com aplicativos.
• Um orquestrador próprio em Python: como os robôs já são em Python, ter tudo na mesma linguagem facilita a manutenção e permite um projeto feito sob medida.

O resultado da migração foi bom: hoje o orquestrador roda num servidor mais seguro, com a mesma interface e a mesma forma de uso de antes. E a experiência abriu espaço para pensar em melhorias futuras, inclusive num projeto próprio.

O que eu aprendi

Essa migração me ensinou muito sobre migração de plataformas e sobre a comunicação entre servidores na rede: DNS, portas e protocolos como o MQTT. Também mostrou como a IA acelera o trabalho com sistemas que você não conhece. Em vez de substituir o meu raciocínio, o Claude me ajudou a entender a arquitetura e a encontrar o problema do MQTT mais rápido.

Se você trabalha com automação, vale conhecer também os modelos de decisão para agentes de IA e ver como criar um aplicativo com inteligência artificial. Para acompanhar os próximos artigos, entre no canal do Telegram.