Em mais de duas décadas resgatando bases de código JDESistema de gestão empresarial (ERP) da Oracle usado para gerenciar processos de negócios. customizadas, a falha arquitetural mais persistente que vejo é tratar versões de Aplicações Interativas (APPL)Programas do JD Edwards com os quais os usuários interagem através de telas e formulários. como versões de Aplicações em Lote (UBE)Motor do JD Edwards responsável por executar processos em lote, como relatórios e processamentos massivos de dados.. Enquanto uma versão de UBE contém especificações independentes de seleção de dados e sequenciamento, uma versão de APPL é simplesmente um ponteiro para valores de Processing OptionParâmetros de configuração que permitem alterar o comportamento de um programa sem modificar o código-fonte. armazenados na tabela F983051Tabela do banco de dados que armazena a lista de versões e configurações de programas.. O mal-entendido sobre essa distinção leva os desenvolvedores a fixarem nomes de versões (hardcodingPrática de escrever valores fixos diretamente no código, o que dificulta mudanças e atualizações futuras.) dentro das Event RulesLinguagem de programação proprietária do JD Edwards usada para criar lógica de negócios., o que gera forks no código e infla o impacto nos seus upgrades.

Ao executar um ER CompareFerramenta do JD Edwards usada para comparar e mesclar regras de evento entre diferentes versões de um objeto durante upgrades. em um P4210 ou P4310 altamente modificado durante um upgrade da versão 9.1 para a 9.2, o custo de maus hábitos de desenvolvimento torna-se imediatamente claro. Variáveis crípticas como evt_szName_WD01 ou Event Rules (ER)Linguagem de programação visual proprietária do JD Edwards usada para criar lógica de negócios em aplicações e relatórios. não documentadas transformam um retrofitProcesso de reaplicar customizações manuais em uma nova versão do software após uma atualização do sistema. padrão de poucas horas em um ciclo de depuração de vários dias. A ferramenta de merge visual falha em alinhar a lógica quando as variáveis customizadas carecem de contexto estrutural, levando a corrupções silenciosas de memória em tempo de execução ou interconexões de formulários quebradas.

Quando um grid customizado em uma aplicação como a P554210 leva mais de dez segundos para carregar 500 registros, as equipes de basis imediatamente culpam os índices do banco de dados ou o tamanho do heap da JVM do WebLogic. Na grande maioria das auditorias de performance realizadas no EnterpriseOne 9.2, a infraestrutura está perfeitamente bem; o gargalo são as Event Rules (ER) síncronas executadas no servidor JAS para cada linha. Alcançar tempos de resposta abaixo de um segundo exige parar de apontar o dedo para a infraestrutura e focar na otimização de performance de grid em APPL JD Edwards para grandes conjuntos de dados dentro do próprio motor de runtime do JDE.

Em uma customização padrão de pedidos de vendas P4210Aplicação padrão do JD Edwards para entrada e processamento de pedidos de vendas. com dezenas de linhas de grid, um loop ingênuo "Get Max Grid Rows" durante a validação pode facilmente adicionar quase um segundo de latência de UIUser Interface, ou Interface de Usuário, refere-se aos elementos visuais com os quais o operador interage. por transação. Os desenvolvedores costumam assumir que o runtime do EnterpriseOneA versão atual e baseada em web do software ERP JD Edwards da Oracle. otimiza esses loops internamente, mas ele realmente avalia cada célula sequencialmente, prejudicando o desempenho interativo nos servidores HTML. Este guia de exemplo de desenvolvimento APPLTermo técnico para uma aplicação interativa dentro do ambiente de desenvolvimento do JD Edwards. JD Edwards sobre validação de linha de grid mostra como focar apenas em linhas modificadas, reduzindo a sobrecarga de validação em mais de 80%.