Integração de sistemas com Pentaho Data Integration (PDI)

Há mais de uma década, retomei a escrita técnica justamente porque integração entre sistemas deixou de ser luxo e virou sobrevivência para empresas brasileiras. Como arquiteto e fundador da TEK Softwares, vejo diariamente o padrão que chamei de "aproveitamento": cada software faz o que faz melhor — fiscal em um módulo, financeiro em outro, RH em um terceiro — e o desafio é fazer os dados fluírem sem duplicar regra de negócio em dez planilhas. Neste artigo, compartilho por que o Pentaho Data Integration (PDI) continua relevante no meu portfólio e como encaixá-lo em arquiteturas modernas.

O problema real: silos que custam caro

ERP legado, e-commerce, CRM, planilha do financeiro e e-mail do fiscal não conversam nativamente. A tentação é exportar CSV manualmente às sextas. Funciona até o CFOP mudar, até o estoque divergir, até alguém esquecer uma coluna. Integração não é sobre ferramenta bonita — é sobre confiabilidade operacional. Quando um amigo me mostrou o PDI em um dia, entendi que visualizar transformações acelera onboarding de analistas que não vivem em IDE o dia inteiro.

Por que Pentaho Data Integration

O PDI é open source, roda em Java (multiplataforma), estável e transparente: você vê registros processados, gargalos e steps falhando. Para tarefas como mover arquivos entre pastas, arquivar anexos de e-mail, sincronizar tabelas entre Oracle e MySQL ou preparar carga para data warehouse, a curva de entrada é menor que escrever ETL do zero em código sem testes.

Código aberto e comunidade ativa.
Componentes visuais para entrada, transformação e saída.
Agendamento via Carte, Kitchen ou orquestrador externo.
Documentação inline no grafo — onboarding mais rápido.

Isso não substitui API REST bem desenhada onde tempo real importa. Complementa cenários batch, reconciliação noturna e migrações pontuais — comuns em arquitetura ERP e integrações.

Quando uso PDI versus código puro

Prefiro PDI quando: equipe mista (DBA + analista + dev), regras mudam com frequência moderada, volume batch é previsível e auditoria visual ajuda compliance. Prefiro código (Java, Python, Node) quando: latência sub-segundo, lógica extremamente custom, testes unitários densos e deploy containerizado padronizado são mandatórios. A decisão errada é religiosa — "só low-code" ou "só microserviço".

Parametrização: evite duplicar jobs

Um erro clássico que corrigi para colegas: copiar o mesmo job dez vezes com pequenas variações em vez de passar parâmetros. Duplicação no PDI vira pesadelo de manutenção igual duplicação em código. Documentei o passo a passo em passagem de parâmetros no Pentaho. Parâmetros bem nomeados, valores default sensatos e validação no step inicial economizam horas em produção.

Integração com stack moderna

Hoje combino PDI com filas (RabbitMQ, SQS), webhooks e observabilidade. Job Pentaho termina → publica evento → microsserviço atualiza cache. Não preciso escolher um único padrão. O importante é contrato de dados versionado e idempotência na entrada.

-- Exemplo conceitual: staging table antes do merge
INSERT INTO stg_pedidos (id, cfop, valor, dt_carga)
SELECT id, cfop, valor, NOW() FROM origem_erp;

Staging isola falhas parciais e facilita reprocessamento — lição que reaplico em pipelines CI/CD (CI/CD para times pequenos).

Segurança e credenciais

Conexões JDBC no PDI carregam segredos. Use repositório criptografado, variáveis de ambiente no servidor de execução, rotação de senha documentada. Integração sem segurança vira porta dos fundos — alinho com práticas de segurança web 2026: least privilege, logs sem dados sensíveis, rede segmentada.

Operação e monitoramento

Job verde na tela do Spoon não basta. Agendo alertas quando registros rejeitados excedem limiar, quando duração dobra a mediana ou quando arquivo de entrada não chega. Runbook curto: quem acorda, qual step reexecutar, como rollback staging.

Limitações honestas

PDI não é stream processor. Versionamento de .ktr/.kjb em Git funciona, mas diffs são barulhentos. Testes automatizados exigem disciplina extra (unit tests em Java auxiliar, datasets de regressão). Para equipe só de devs cloud-native, talvez Kafka + dbt seja melhor fit — avalie maturidade antes de impor ferramenta.

Histórias de campo

Lembro cliente varejo cujo estoque divergia porque integração CSV manual substituía API — consertamos com job Pentaho parametrizado e fila noturna; em duas semanas fechamento mensal deixou de ser pesadelo. Outro caso: indústria precisava peça plástica fora de catálogo; TEK 3D prototipou em PETG, validou encaixe, produziu lote cinquenta unidades — software e físico no mesmo relacionamento de confiança.

Essas histórias definem marca mais que slogan. Indicação vem quando problema some, não quando slide promete transformação.

Valores operacionais compartilhados

Transparencia sobre prazo: digo quando três meses é irreal. Qualidade sobre volume: recuso projeto 3D sem tolerancia especificada. Documentação sobre memória oral: DECISIONS.md, perfil slicer exportado, diagrama integração versionado.

Caso prático: arquivos fiscais

Cliente recebia XML NF-e em pasta SFTP; contador queria planilha consolidada; ERP precisava status pagamento. Job Pentaho: input Get File Names, parse XML, lookup tabela pedidos, output CSV + update JDBC. Parametros DATA_INICIO e DATA_FIM permitem reprocesso sem duplicar job. Antes eram quatro scripts Python cron sem log unificado — migração visual facilitou auditoria interna.

Capacitação do time cliente

Entrego Spoon project + vídeo gravado + runbook. Analista financeiro ajusta filtro; dev só entra se step novo. Reduz dependência eterna consultoria — bom para cliente, sustentável para TEK.

Comparativo rápido com Airbyte e dbt

Airbyte excelente SaaS connectors modernos; dbt forte em transform warehouse SQL. Pentaho ganha onde ambiente on-premise, JDBC legado obscuro e equipe precisa GUI. Maturity do cliente manda — não vendo religião.

Modelo comercial híbrido

Software: hora consultoria, projeto fechado escopo, ou retainer mensal sustentação. TEK 3D: unitário peça + encomenda custom MOQ baixo. Margem diferente, fluxo caixa diferente — separo contabilidade categorias desde início. Imposto serviço vs produto exige contador alinhado; não improviso nota errada.

Cross-sell orgânico: cliente ERP pede brinde evento → TEK 3D imprime com logo; cliente 3D precisa integração e-commerce → TEK Softwares API WooCommerce estoque. Marca única facilita confiança já estabelecida.

Stack digital TEK 3D

Site Astro/Vercel performance Core Web Vitals, imagem WebP catálogo, checkout contato WhatsApp Business API futuro. Analytics privacy-friendly. Mesmas práticas DNS HTTPS artigo web iniciantes — dogfooding.

Sustentabilidade e materiais TEK 3D

Escolho filamentos com ficha técnica e lote rastreável. PLA para peças decorativas internas; PETG para vasos com água ou peças sujeitas a calor moderado; ABS apenas quando cliente exige resistência mecânica e aceita odor na impressão. Documento perfil slicer — temperatura bico, mesa, retracção, velocidade — por material e por impressora. Repetibilidade é o que transforma hobby em produto vendável na Shopee sem avaliação uma estrela por deformação.

Sucata de suporte e failed print separo para reciclagem quando cooperativa local aceita PLA; transparência ambiental opcional na embalagem. Cliente corporativo brinde evento perguntou origem material — ter resposta pronta fechou pedido recorrente.

Conclusão

Integração de sistemas continua sendo o coração de projetos TEK Softwares. Pentaho Data Integration permanece ferramenta pragmática para batch, visualização e times híbridos. Parametrize, documente, conecte com APIs modernas onde necessário e nunca trate ETL como "job esquecido no servidor". Próximo passo prático: revise seus jobs duplicados esta semana e consolide parâmetros — link detalhado no artigo de passagem de parâmetros.