Em nossas auditorias de bases de código JDE 9.2Versão do software de gestão empresarial JD Edwards EnterpriseOne da Oracle. customizadas, rotineiramente descobrimos que uma parte significativa dos gargalos de desempenho em aplicações interativas customizadas — muitas vezes entre 30% e 50% — decorre de Form InterconnectsMecanismo que permite chamar uma aplicação a partir de outra, passando parâmetros entre elas. mal implementados. Os desenvolvedores frequentemente configuram um row exitBotão ou opção de menu que executa uma ação baseada na linha selecionada em uma tabela. no JDE APPL para abrir uma aplicação padrão relacionada como um simples mapeamento de apontar e clicar, mas chamar uma aplicação padrão pesada como o P4210 (Sales Order Entry) a partir de um grid customizado sem isolar o limite da transação pode levar a bloqueios de banco de dados órfãos nas tabelas F41021Tabela do banco de dados que armazena informações de disponibilidade de estoque por local. ou F4211.
Para evitar esses problemas de bloqueio e vazamentos de memória, você deve controlar precisamente como as variáveis GCGrid Column, variáveis que representam os dados contidos em uma linha específica da tabela na tela. são mapeadas para a estrutura FIForm Interconnect, conjunto de parâmetros definidos para receber ou enviar dados durante a chamada entre formulários. de destino. Este exemplo técnico demonstra como passar o contexto de um grid customizado com segurança, lidar com riscos de ponteiros nulos no evento Dialog Is Initialized do formulário de destino e garantir que a aplicação chamadora libere seu cursor de banco de dados imediatamente. A implementação desses mapeamentos precisos de Event Rules (ER)Linguagem de programação visual utilizada no JD Edwards para definir a lógica de negócio. elimina os bloqueios fantasma que frequentemente assolam as sessões multi-threaded do cliente HTML.
Anatomia de um Form Interconnect de Row Exit
Um ponto de falha comum no desenvolvimento customizado em FDAForm Design Aid, a ferramenta de desenvolvimento usada para criar e modificar telas no JD Edwards. é tratar um row exit como um clique de botão glorificado, em vez de uma transação consciente do contexto. Quando um usuário seleciona uma linha em um grid e clica em um row exit, o mecanismo de runtime executa as regras de evento subjacentes dentro do escopo dessa linha específica, utilizando variáveis Grid Column (GC). Se sua aplicação customizada tiver várias linhas selecionadas ou se o usuário clicar no exit sem uma seleção ativa, o runtime passará valores nulos ou lixo para o Form Interconnect (FI). Para evitar isso, você deve validar explicitamente se uma linha está selecionada verificando a variável de sistema SV Selected_Grid_Row antes de disparar a chamada.
A mecânica da transição depende inteiramente do mapeamento dessas variáveis GC para a Form Data Structure (DSTR)Definição de campos usada para passar dados entre objetos, como telas e funções de negócio. do formulário de destino. Quando você configura o Form Interconnect no FDA, a ferramenta expõe a estrutura de recebimento do formulário de destino, que atua como um contrato estrito entre as aplicações chamadora e receptora. Tipos de dados incompatíveis ou campos de chave não mapeados neste interconnect não dispararão um erro de compilador nas Event Rules, mas causarão falhas silenciosas em tempo de execução ou farão com que a aplicação de destino assuma um código de ação incorreto, como Add em vez de Update. Por exemplo, passar um número de documento math numericTipo de dado numérico proprietário do JD Edwards usado para cálculos e armazenamento de valores. em um parâmetro de string de caracteres falhará silenciosamente ao carregar a business viewUma seleção de campos de uma ou mais tabelas que serve de base para os dados em uma tela. do formulário de destino.
Aplicações padrão como P4210 (Sales Order Entry) ou P0911 (Journal Entry) exigem um conjunto completo de chaves primárias para ignorar suas telas iniciais de busca/navegação e carregar um registro diretamente no formulário de revisão. Para o P4210, isso significa mapear o Order Number (DOCO), Order Type (DCTO) e Order Company (KCOO) das colunas do seu grid customizado diretamente para os parâmetros FI correspondentes do formulário de destino, normalmente W4210A ou W4210B. Omitir até mesmo uma chave, como KCOO, força a aplicação de destino a entrar em um estado de consulta padrão ou exibir um erro "Record Not Found". Esse mapeamento direto ignora a latência típica de busca e seleção, economizando de 3 a 5 segundos por transação para os usuários e evitando consultas desnecessárias ao banco de dados.
Extraindo o Contexto da Linha Selecionada com Segurança no FDA
Eu reviso regularmente códigos FDA customizados onde os desenvolvedores capturam valores de variáveis Form Control (FC) ou Event Rules (ER) em vez de variáveis Grid Column (GC) durante a execução de um row exit. No evento Button Clicked de um Row Exit, o mecanismo de runtime aponta especificamente para a linha ativa do grid. Se você referenciar uma variável ER obsoleta, populada durante um loop anterior de 'Grid Rec is Fetched', você passará as chaves erradas — como um número de Address Book (AN8) ou Order Number (DOCO) antigo — para a aplicação de destino. Esse descompasso resulta em uma tela em branco ou, pior, em um usuário atualizando o registro de banco de dados errado.
Quando os usuários selecionam várias linhas — por exemplo, 5 ou 10 linhas em um grid de remessa customizado — a lógica padrão de linha única falha. Para processar essa seleção com segurança, você deve implementar um loop usando as funções de sistema Get Selected Grid Row Count e Get Next Selected Row. Inicialize um contador usando Get Selected Grid Row Count para determinar se há trabalho a ser feito e, em seguida, percorra cada índice usando Get Next Selected Row para buscar os valores GC específicos para aquele ponteiro de linha.
Antes de invocar o Form Interconnect dentro deste loop, realize uma verificação rigorosa de valores nulos em chaves GC críticas, como Company (CO) ou Document Type (DCTO). Passar uma chave não inicializada ou nula dispara uma consulta aberta em aplicações padrão como P4210 ou P4310, o que pode travar a sessão HTML do usuário ou degradar o desempenho do banco de dados no Enterprise ServerServidor central que processa a lógica de negócios e as regras de evento do JD Edwards.. Se o formulário de destino não suportar seleção múltipla, seu código deve interceptar o loop quando a contagem de linhas exceder 1, alertando o usuário com uma mensagem de erro padrão do JDE em vez de gerar várias janelas de aplicação separadas sequencialmente e travar a pilha de chamadas do navegador.
Exemplo de Código: Chamando P4210 a partir de APPL Customizada
No desenvolvimento 9.2, vincular um workbench customizado como o P554211 à aplicação padrão de Sales Order Entry (P4210) exige adesão estrita às regras de mapeamento do Form Design Aid (FDA) para evitar vazamentos de memória ou estados de thread corrompidos. Quando um usuário dispara o row exit, o runtime deve passar a chave exclusiva da linha selecionada do grid diretamente para a estrutura de dados do formulário de destino. Para o P4210, esse destino é normalmente o formulário W4210A, que espera uma composição precisa de três chaves para localizar o registro correto nas tabelas F4201 e F4211.
Dentro do evento "Row Exit & Changed - Instant" do seu row exit customizado, você deve mapear explicitamente os valores da Grid Column (GC) para as variáveis do Form Interconnect (FI) do W4210A. Deixar de mapear todos os três campos de chave — número do pedido, tipo do pedido e empresa do pedido — força o P4210 a inicializar um pedido em branco, uma fonte frequente de chamados no suporte. O mapeamento exato de Event Rules no FDA se parece com isto:
// Chamar Sales Order Entry (P4210) a partir de Row Exit Customizado
Call(App:P4210, Form:W4210A)
GC OrderNumber -> FI mnOrderNumber
GC OrderType -> FI szOrderType
GC OrderCompany -> FI szOrderCompany
"2" -> FI cVersionMode
"1" -> FI cActionCodeA escolha da flag de execução correta determina como o cliente HTML gerencia a pilha de threads. Se o seu P554211 precisar atualizar imediatamente seu grid com quantidades ou códigos de status atualizados quando o usuário retornar, você deve configurar o Form Interconnect para execução ModalModo de execução que bloqueia a tela de origem até que a janela chamada seja fechada.. Isso bloqueia a thread chamadora, garantindo que o usuário conclua seu trabalho no P4210 antes que o controle retorne à aplicação customizada, onde um evento Press Button(HC Find) pode atualizar o grid. Por outro lado, se o usuário precisar apenas do P4210 como uma janela de referência paralela para verificar detalhes da linha sem bloquear a thread do chamador, configure o interconnect como Não-Modal. Isso permite que o usuário arraste a janela do P4210 para um segundo monitor enquanto mantém o grid do P554211 ativo para entrada contínua de dados.
Armadilhas Comuns em Row Exits de Apps Padrão
Um descuido comum no Form Design Aid (FDA) ocorre quando um desenvolvedor passa uma variável em branco ou não inicializada para a estrutura de chave primária de um formulário de destino. Em aplicações padrão como P4101 ou P4210, receber uma chave em branco faz com que o mecanismo de runtime de destino assuma o modo 'Add' em vez do modo pretendido 'Update' ou 'Inquiry'. Para evitar isso, você deve verificar explicitamente as 'Form Properties' do formulário de destino para garantir que ele esteja configurado para aceitar o código de ação específico — como Change ou Inquiry — que sua aplicação customizada está passando. Se o formulário de destino não estiver configurado para permitir a ação recebida, o runtime falhará silenciosamente ou levará o usuário a uma tela de entrada incorreta.
Gerenciar os limites de transação entre formulários é crítico para evitar a contenção do banco de dados. Quando você dispara um interconnect modal, a aplicação chamada é executada dentro da thread do chamador e compartilha seu limite de transação. Se sua aplicação customizada já atualizou um registro na tabela Item Location (F41021) e então chama uma aplicação padrão como o P4112 de forma modal, a aplicação secundária pode tentar bloquear o mesmo registro F41021. Esse descompasso nos limites de transaction processingMecanismo que garante que um conjunto de operações no banco de dados seja concluído com sucesso ou totalmente revertido. resulta em um deadlockSituação em que dois ou mais processos ficam impedidos de continuar pois um espera pela liberação de um recurso bloqueado pelo outro. imediato no banco de dados, congelando a sessão do usuário até que o mecanismo do banco de dados expire por timeout.
Outro problema frequente ocorre quando os desenvolvedores processam linhas do grid sequencialmente dentro de um loop, mas não limpam as variáveis da estrutura do Form Interconnect antes da próxima iteração. Se uma linha subsequente tiver um valor em branco em um campo como Location (LOCN), a estrutura do Form Interconnect reterá o valor da linha anterior. Isso leva à passagem de dados obsoletos para a aplicação de destino, corrompendo o contexto da transação secundária. Limpar explicitamente as variáveis da estrutura de dados no início de cada iteração do loop é a única maneira confiável de garantir a integridade dos dados em caminhos de execução de várias linhas.
Depurando a Pilha do Row Exit Interconnect
Quando um row exit para uma aplicação padrão como o P4210 falha ao passar dados de chave silenciosamente, adivinhar qual variável é nula é um desperdício de tempo. Abra seu jdedebug.logArquivo de log técnico que registra detalhadamente todas as operações de banco de dados e lógica do JD Edwards. local e pesquise diretamente pela string "Form Interconnect" para isolar os parâmetros exatos da estrutura de dados que estão sendo passados em tempo de execução. Esse rastreamento de log expõe os valores precisos das estruturas de entrada e saída, permitindo verificar se os valores das colunas do grid realmente foram mapeados para a estrutura de dados do formulário de destino durante o evento de clique do botão.
Se os valores parecerem corretos no log, mas o formulário de destino ainda carregar em branco, a falha está ocorrendo durante a inicialização da aplicação de destino. Conecte seu depurador C local e coloque um breakpoint dentro do evento Dialog Is Initialized da aplicação padrão ou nas business functionsProgramas em C ou NER que executam processos de negócio específicos e reutilizáveis no sistema. C subjacentes, como a B4200310. Isso permite que você percorra a thread de execução e confirme se as variáveis internas da aplicação de destino estão sobrescrevendo os valores recebidos do form interconnect antes que o formulário seja renderizado.
Incompatibilidades de specsEspecificações técnicas que definem o comportamento e a aparência dos objetos no JD Edwards. entre ambientes frequentemente causam falhas silenciosas onde o row exit funciona no cliente de desenvolvimento, mas trava na web. Inspecione os arquivos e1root.log do servidor HTML; você encontrará avisos de "Form Structure Mismatch" se as especificações locais em seu cliente de desenvolvimento não estiverem alinhadas com os pacotes serializados implantados no servidor corporativo. Essa incompatibilidade normalmente acontece quando um desenvolvedor modifica uma estrutura de dados de formulário padrão ou adiciona parâmetros customizados sem recompilar e implantar os pacotes de cliente e servidor.
Quando o row exit é executado perfeitamente em sua máquina de desenvolvimento local, mas falha completamente ao lançar a aplicação padrão no cliente web HTML, verifique seus mapeamentos no Object Configuration Manager (OCM)Ferramenta que gerencia onde os objetos e dados devem ser processados ou acessados no ecossistema JDE.. Certifique-se de que os mapeamentos OCM para a aplicação de destino estejam ativos e apontados para a fonte de dados correta para o ambiente em que você está testando, como o DV920. Um mapeamento OCM mal configurado impedirá que o mecanismo de runtime da web resolva a chamada do form interconnect, deixando o usuário preso no grid de origem sem nenhum feedback visual.
Aprimorar a lógica de row exit no Form Design Aid é um passo fundamental para construir aplicações que sobrevivam à próxima atualização de Tools Release sem intervenção manual. Para líderes de TI corporativa que gerenciam um ecossistema JDE customizado, estabelecer esses padrões rigorosos de desenvolvimento é essencial para garantir a capacidade de atualização a longo prazo e a estabilidade do sistema.
