A maioria das equipes de JDE trata o Object Management Workbench apenas como uma interface de controle de versão com botões de check-in e check-out. Na realidade, gerenciar o ciclo de vida de projetos no JD Edwards OMW, do desenvolvimento à promoção, significa orquestrar uma máquina de estados relacional envolvendo retenção de tokens, modificações de especificações em Central Objects e sincronização de pathcodes nas tabelas de controle F98220 e F98222. Tratar esse processo de forma descuidada é a razão pela qual aproximadamente 15% a 20% das falhas de promoção de customizações decorrem diretamente de tokens órfãos, arquivos de cabeçalho C BSFN não comitados ou divergências silenciosas de especificações locais.
Todo sistema JD Edwards com alguns anos de uso carrega uma pergunta sem resposta fácil: quantos dos objetos customizados desenvolvidos ao longo do tempo ainda são fundamentalmente idênticos ao padrão Oracle do qual derivam, e quantos evoluíram a ponto de se tornarem algo completamente diferente? Essa pergunta se torna urgente quando se enfrenta um upgrade, uma migração ou uma auditoria das customizações. Na maioria dos casos, a resposta não existe — porque ninguém jamais a buscou de forma sistemática. Neste artigo, descrevo como abordo esse problema no meu trabalho e a ferramenta proprietária que desenvolvi para resolvê-lo.
Página 16 de 16