De todos os artefatos que decidem se um upgrade JD Edwards será entregue no prazo, o Data DictionaryA camada de metadados JDE que define cada data item — alias, comprimento, casas decimais, glossário, edit rules. É o contrato em que cada form, BSFN, UBE e integração se apoia. é o que a maioria dos planos de upgrade subestima. O DD é onde as mudanças da Oracle de uma release para outra encontram seu código custom, e uma única alteração de casas decimais em um data item padrão, não percebida durante o cut-over, já custou a mais de uma equipe financeira um mês de trabalho de conciliação após o go-live.

É assim que eu trabalho o Data Dictionary em um upgrade real: como construir o diff entre a release origem e a release destino, como inventariar os itens custom com prefixo 55-69 que vão acompanhar você para sempre, como identificar as mudanças silenciosas de comprimento e casas decimais que quebram o retrofittingO processo de reaplicar modificações custom sobre uma nova release JDE, depois que a Oracle entregou suas próprias mudanças nos mesmos objetos padrão., e como validar o resultado antes que o primeiro usuário faça login.

Por que o Data Dictionary é o artefato de upgrade de maior alavancagem

Cada form, cada UBE, cada BSFNBusiness Function: código C compilado que roda dentro do kernel JDE Call Object. As estruturas BSFN são construídas a partir das definições dos Data Dictionary items, então qualquer mudança no DD força uma rebuild das BSFNs. no JDE lê o DD para saber como interpretar as colunas da tabela que ele toca. O dado está na tabela; o significado do dado está no DD. Quando o DD diz que um item é 15.2 (15 dígitos, 2 casas decimais) e a tabela contém um inteiro com decimais implícitos, a aplicação recoloca o decimal no lugar correto no momento da exibição. Mude a contagem de decimais do DD sem reconstruir tudo que o referencia, e a mesma linha de banco de dados passa a ser exibida de repente como 100x ou 1/100x do seu valor real.

Entre releases, a Oracle realmente altera DD items. Os comprimentos aumentam conforme o produto padrão evolui (valores monetários que eram 15.2 em releases antigas passaram para 18.2 em algumas tabelas padrão). A precisão decimal muda em itens semelhantes a taxas. Alguns itens são depreciados e substituídos por novos aliases. Nada disso é catastrófico se você encontra antes do cut-over; tudo isso é catastrófico se você encontra depois.

O ponto de alavancagem é que a análise DD é barata em relação ao restante do upgrade. Algumas consultas bem delimitadas em F9200, F9202, F9203, F9210 contra as releases origem e destino dão uma visão completa em horas, não em semanas. Pule essa etapa, e as mesmas horas voltam depois como tickets de suporte em produção — só que então o custo inclui a confiança dos usuários que você já queimou.

O workflow DD em cinco etapas que executo em todo upgrade

O workflow é o mesmo, esteja você indo de B9 para 9.2 ou de 9.2 para uma release futura. Os volumes mudam; as etapas não.

Etapa um — baseline diff. Exporte F9200 e F9210 da release origem e da release destino para dois schemas lado a lado. Uma instância JDE típica tem 15.000-20.000 DD items, dos quais aproximadamente 12.000-15.000 são entregues pela Oracle e o restante é custom. A consulta de diff é simples — left join em FRDTAI/FROMDTAI, marcando qualquer linha em que comprimento, casas decimais ou data type diferem — mas o volume de resultados é a surpresa. Mesmo entre duas ESUs consecutivas na mesma release, já vi 50-150 mudanças DD entregues pela Oracle; entre releases completas, o número chega aos poucos milhares.

Etapa dois — inventário custom. Todo DD item custom deveria estar na faixa de prefixos de alias 55-69. Execute SELECT FRDTAI, FRSY FROM F9200 WHERE FRDTAI BETWEEN '55' AND '69' contra a origem. Um ambiente custom saudável tem 200-500 itens. Qualquer coisa acima de 1.000 é ou um ambiente antigo que precisa de limpeza, ou sinal de que alguém criou DD items na faixa de prefixos errada. De qualquer forma, você quer saber disso antes do upgrade, não durante.

Etapa três — varredura de conflitos. Cruze o inventário custom com o diff Oracle. Na maior parte do tempo, itens custom e Oracle ficam em faixas de prefixo separadas e não há colisão. Os casos que preocupam são: itens custom que copiam ou estendem um item padrão que a Oracle agora alterou, e código custom (BSFNs, NERs, UBEs) que usa hard-coded um alias padrão cuja definição mudou. O segundo caso é o perigoso porque o DD item em si não precisa de correção — o código que o usa precisa.

Etapa quatro — plano de retrofit. Para cada conflito, três opções: manter o alias padrão como a Oracle agora o entrega e adaptar o código custom, manter o comportamento custom antigo e documentar por quê, ou mesclar o custom ao padrão se a Oracle agora incorporou aquilo para o qual o item custom havia sido adicionado. Cada opção entra no plano de projeto de retrofit com estimativas de esforço e aprovação de um responsável funcional. A etapa quatro é documentação — e essa documentação é o que salva você nas discussões pós-go-live.

Etapa cinco — validação pós-upgrade. Depois da execução do upgrade, antes que os usuários façam login: execute R9202 (Data Dictionary integrity report) na release destino, limpe os caches de cima para baixo, do HTML Server aos kernels Enterprise Server, reconstrua as specs de quaisquer DD items custom que precisem disso. Faça uma checagem pontual de 10-20 itens de alto valor (valores em F4211, F0411, F0911) com uma consulta que una a tabela à F9210 e confirme que o posicionamento decimal corresponde ao que a aplicação agora mostra.

As três mudanças DD entregues pela Oracle que quebram upgrades

De todas as coisas que mudam no DD entre releases, três padrões explicam praticamente todos os incidentes pós-upgrade que já vi.

O comprimento aumentou. A Oracle amplia um item existente — normalmente um valor ou quantidade — para suportar valores maiores exigidos por clientes globais. A coluna da tabela é alterada para corresponder, suas BSFNs custom que alocam um buffer baseado no comprimento antigo ainda compilam, mas truncam em runtime. A correção é mecânica, porém exaustiva: reconstruir toda BSFN custom que referencia o alias afetado. A consulta XREF (SELECT FOOBNM, FOMODNAME FROM F980011 WHERE FOPONM = 'AMOUNT_ALIAS') fornece a lista. O esforço escala com o tamanho do ambiente custom — uma instalação com pouco custom leva 1-2 dias; um site fortemente customizado pode exigir 1-2 semanas de rebuilds.

As casas decimais mudaram. Este é o assassino silencioso. A Oracle muda um item semelhante a taxa de 2 casas decimais para 4 (ou vice-versa), a coluna do banco de dados não muda, os dados não mudam, mas a interpretação da aplicação muda. Todo relatório, toda tela, todo export agora mostra o valor 100x fora. A parte brutal: o sistema não gera erro. O número aparece, é formatado corretamente, parece plausível. O financeiro só percebe quando os totais deixam de conciliar. Sempre inclua itens com mudança decimal na UAT de cut-over com comparação numérica explícita antes/depois — inspeção visual não basta.

O item foi removido. A Oracle deprecia um alias e entrega um substituto, esperando que os consumidores migrem. O alias depreciado pode continuar em F9200/F9210 por uma ou duas releases como cortesia, mas novos objetos usam o novo alias. O código custom que deixou hard-coded o alias antigo continua funcionando até a janela de depreciação fechar, então quebra. Planeje a migração durante o próprio upgrade, não durante a release que remove a linha depreciada.

Fazendo cross-reference dos DD items com os objetos que dependem deles

O DD sozinho não diz o que vai quebrar — quem diz é a F980011, a tabela de cross-reference. Após cada checkout que altera o uso de DD, o JDE atualiza a F980011 com a relação entre objetos e os DD items que eles referenciam. O índice XREF é reconstruído pelo R980011 (ou seu equivalente moderno nas Tools Releases atuais); com um índice desatualizado, a cross-reference fica incompleta e a análise de impacto subestima.

A consulta que conduz a análise é direta:

SELECT FOOBNM, FOMODNAME, FOOBJTYPE
FROM   F980011
WHERE  FOPONM = 'TARGET_ALIAS'
ORDER  BY FOOBJTYPE, FOOBNM;

A saída é a lista completa de UBEs, APPLs, NERs e BSFNs que referenciam o alias, agrupada por object type. Para um alias usado em uma dúzia de objetos, isso é uma revisão de impacto limpa de duas horas. Para um alias como AN8 (Address Number) — referenciado em milhares de objetos no produto padrão — a lista é ilegível como está, e a melhor abordagem é confirmar que a Oracle não alterou a definição do item e seguir em frente. AN8 não muda; os itens mais prováveis de mudar são os específicos de uma área funcional.

Para DD items de alto valor (valores monetários, quantidades, custo unitário, taxas de câmbio) em tabelas padrão de finance e distribution, faça a cross-reference manualmente mesmo que o diff diga que a Oracle não os alterou. Os 20 DD items mais importantes merecem 20 minutos de atenção cada — muito mais barato do que descobrir um retrofit perdido na terceira semana após o go-live.

Ferramentas e scripts que pagam seu custo em todo upgrade

Algumas ferramentas direcionadas transformam a análise DD de um trabalho de vários dias em um exercício de meio dia. O formato dessas ferramentas é mais importante que a implementação específica — o que importa é tê-las, e que sobrevivam entre upgrades para estarem prontas para o próximo.

Um baseline differ que consome dois exports F9200/F9210 e produz um diff categorizado (mudanças em comprimento, casas decimais, data type, edit rule, glossário) é a peça mais reutilizada. SQL é suficiente; um script de 200 linhas em Python ou pandas gera uma saída estilo spreadsheet que a equipe funcional pode revisar.

Um script de inventário de prefixos custom (a consulta 55-69 mais cross-reference com F980011) dá a pegada DD custom por object type. Qualquer item com mais de 100 objetos dependentes é destacado explicitamente; qualquer órfão (DD item com zero referências F980011) é marcado para limpeza antes do upgrade, não depois.

Um decimal-change validator roda após o upgrade contra tabelas de alto valor: para cada linha em, digamos, F0911, calcula o valor exibido usando tanto a definição decimal antiga quanto a nova, e marca qualquer linha em que as duas diferem. Rodando em uma amostra de 10.000-50.000 linhas, leva segundos e dá uma resposta sim/não sobre se o upgrade mudou a interpretação do dinheiro.

Essas três ferramentas, combinadas, transformam o trabalho DD de upgrade em uma tarefa de engenharia tratável em vez de um item vago no plano de projeto dizendo "vamos verificar o DD".

Os erros que silenciosamente estendem um upgrade por semanas

O primeiro é tratar a análise DD como trabalho apenas da equipe CNC. A equipe CNC é dona da promoção técnica das mudanças DD entre ambientes; a equipe funcional é dona da decisão sobre se uma mudança de 2dp para 4dp em uma taxa de câmbio é aceitável para o negócio. As duas equipes precisam estar na revisão DD, ou a aprovação técnica entrega mudanças que o negócio nunca aceitou.

O segundo é pular o inventário de prefixos custom porque "não temos muitas customizações". Ambientes JDE antigos acumulam DD items custom ao longo de décadas — itens criados por consultores que saíram, itens adicionados para projetos cancelados, itens duplicados porque duas equipes não sabiam uma da outra. O primeiro inventário de um ambiente de 10 anos invariavelmente surpreende alguém.

O terceiro é fazer o diff entre releases origem e destino, mas não entre a Tools Release atual e a Tools Release destino na mesma product release. Tools Releases entregam suas próprias mudanças DD — normalmente pequenas em volume, mas altas em impacto porque tocam itens runtime padrão que todo objeto referencia. O diff da Tools Release é uma consulta separada e uma revisão separada.

O quarto é esquecer que F9202 e F9203 (alpha description e traduções) também precisam de uma passagem de upgrade. Novos DD items entregues pela Oracle vêm com descrições em inglês e às vezes com um subconjunto de traduções de idioma. Se seu ambiente é multilíngue, a gap analysis pós-upgrade em F9203 evita que usuários vejam rótulos em branco no primeiro dia.

O quinto é não congelar o DD durante o cut-over. A janela entre iniciar o upgrade e concluir a validação pós-go-live não é hora de alguém adicionar um novo DD item "para uma correção rápida". Bloqueie o P92001 via segurança, e desbloqueie somente quando o upgrade estiver aprovado.

Se esse tipo de análise do lado do upgrade é o que você precisa para o seu próprio ambiente JDE, os artigos relacionados neste site cobrem padrões de projeto OMW, scripts custom code analyzer para escopo de upgrade e o dashboard de risco de retrofit que resume esse tipo de trabalho para steering committees. O portfólio de projetos mostra onde essas técnicas foram aplicadas em upgrades reais de B9 para 9.2 e de 9.2 para releases futuras.