Ao construir aplicações interativas no JDE (APPL)Aplicações interativas do JD Edwards usadas para criar interfaces de usuário e lógica de negócio., implementar um exemplo seguro de insert e update em tabelas customizadas a partir de um formulário é fundamental para a integridade dos dados. Confiar apenas no processamento automático de formulários padrão do EnterpriseOneA versão atual e baseada em web do software ERP da JD Edwards. para tabelas customizadas — normalmente tabelas com prefixo 55, como a F550101 — muitas vezes traz problemas. Em cerca de 75% a 85% dos cenários complexos de desenvolvimento customizado, os auto-commits padrão do Fix/InspectUm tipo de formulário no JDE projetado para visualizar ou editar um único registro de banco de dados. ignoram regras de validação multi-tabelas ou falham em manter a integridade transacional. Para evitar registros órfãos e bloqueios de banco de dados, os desenvolvedores devem ignorar o mapeamento automático e assumir o controle manual da fase de gravação no banco de dados.

Este guia descreve um padrão de gravação transacional testado em produção usando Table I/OOperações de entrada e saída que permitem ler ou gravar dados diretamente nas tabelas do banco de dados. explícito via Event Rules (ER)Linguagem de programação visual do JD Edwards usada para definir a lógica de negócio em aplicações.. Ao desativar o processamento automático de tabelas nas propriedades do Form Design Aid (FDA)Ferramenta de desenvolvimento do JD Edwards usada para criar e projetar interfaces de usuário. e gerenciar os limites da transação manualmente por meio das funções de sistema Start Transaction e Commit Transaction, você elimina o risco de commits parciais. Analisaremos a lógica exata de ER necessária para detectar o modo do formulário, validar campos de entrada contra Master Business Functions (MBFs)Módulos de lógica centralizada que validam dados e garantem a integridade ao processar transações complexas. padrão como a B0100016 e executar gravações SQL seguras.

Projetando o Formulário e Mapeando Colunas Customizadas

Em mais de duas décadas auditando código JDE customizado, vi dezenas de falhas em produção causadas por uma simples incompatibilidade entre as variáveis de Form Control (FC)Elementos de interface, como campos de entrada e botões, em um formulário JDE. e seus itens de Data Dictionary (DD)Repositório central que define as características técnicas e regras de cada campo de dados no sistema. subjacentes. Ao projetar um formulário Fix/Inspect para interagir com uma tabela customizada como a F550101, alinhar essas variáveis com precisão é inegociável. Se você mapear um FC de string de 10 caracteres para um item de DD de 30 caracteres, ou houver incompatibilidade de precisão numérica, o EnterpriseOne compilará, mas truncará os dados ou falhará silenciosamente em tempo de execução. Os formulários Fix/Inspect fornecem a tela ideal para atualizações transacionais de registro único, separando a camada de UI do mapeamento do banco de dados.

Confiar nos commits automáticos de banco de dados do JDE pode levar a gravações parciais se a lógica de negócio customizada falhar no meio da transação. Se um usuário atualiza um campo customizado em um formulário vinculado a uma Business ViewUma seleção de campos de tabelas que serve como ponte entre o banco de dados e a aplicação. padrão, o runtime engine tenta processar a atualização automaticamente. Se as validações subsequentes ou atualizações em tabelas secundárias falharem, você acabará com registros órfãos na F550101. O Table I/O manual dá aos desenvolvedores controle absoluto sobre quando e como os dados são gravados na tabela customizada F550101. Ao ignorar o mapeamento automático padrão do engine e gerenciar o Table I/O no evento "OK - Button Clicked", você desacopla a interface do usuário do ciclo de commit do banco de dados.

Para executar isso com segurança, crie seu formulário Fix/Inspect sem associá-lo diretamente a uma Business View na F550101. Coloque variáveis FC não mapeadas diretamente na tela do formulário, garantindo que cada controle use exatamente o item de DD definido na tabela de destino. Esse desacoplamento evita que o runtime engine do Form Design Aid dispare gravações implícitas no banco de dados, permitindo que você coordene explicitamente a validação e as instruções de Table I/O customizadas dentro de suas Event Rules.

Implementando Validação Rigorosa Antes da Gravação no Banco de Dados

Disparar gravações no banco de dados sem validação absoluta garante a corrupção de dados em tabelas 55 customizadas logo na primeira semana de go-live. Você deve executar 100% da sua lógica de validação no evento 'OK - Button Clicked', especificamente antes de qualquer chamada de Table I/O ou business function. Se a validação falhar aqui, você pode interromper de forma limpa o engine de event rules antes que ele chegue ao evento 'OK - Post Button Clicked', onde o insert ou update físico real no banco de dados é confirmado.

Para interromper a execução imediatamente, use a função de sistema Set Action Error no botão OK, ou direcione entradas específicas usando Set Control Error. Isso força o cliente HTML a renderizar um banner de erro vermelho nativo, impedindo que o runtime engine prosiga para a fase de commit no banco de dados. Por exemplo, se um usuário tentar salvar um registro com uma chave primária vazia, a verificação de um valor em branco ou zero em seus Form Controls (FC) obrigatórios deve disparar essa função de sistema instantaneamente, evitando a inserção de uma chave primária nula em sua tabela customizada.

Além de simples verificações de nulos, você deve validar a integridade relacional contra as tabelas principais do JDE. Para uma tabela customizada que contém um campo de Address NumberNúmero único de identificação usado no JD Edwards para entidades como clientes, fornecedores e funcionários., seu código deve realizar um fetch-single contra a tabela F0101 usando o valor inserido. Se o registro na F0101 não existir, ou se o Search Type (AT1) for inválido para o seu contexto de negócio, dispare um código de erro de DD customizado como 0002 (Address Number Invalid) para bloquear a transação. Essa verificação simples elimina os registros órfãos que rotineiramente limpo de tabelas customizadas legadas durante migrações do 9.1 para o 9.2.

Detectando o Modo do Formulário para Insert ou Update

Confiar cegamente no comportamento automático do FDA em um formulário Fix/Inspect muitas vezes falha quando as chaves são passadas dinamicamente via Form Interconnects. Na lógica padrão do JDE, a variável de sistema SV Form_Mode alterna automaticamente entre ADD_MODE (valor 'A') e COPY_MODE ou UPDATE_MODE (valor 'C') com base no preenchimento das chaves primárias durante a inicialização. Avaliar essa variável de sistema durante o evento 'Post Dialog Is Initialized' é sua primeira linha de defesa para determinar programaticamente se o usuário está adicionando um novo registro ou modificando um existente.

Para evitar a corrupção do banco de dados, execute imediatamente uma operação de Fetch Single contra a chave primária da sua tabela customizada no evento 'Post Dialog Is Initialized'. Se o fetch for bem-sucedido (onde a variável de sistema SV CO_File_IO_Status for igual a CO_SUCCESS), armazene esse estado operacional em uma variável de formulário customizada, como evt_cIsUpdateMode_EV01 definida como '1'. Essa verificação explícita substitui quaisquer estados de formulário ambíguos causados por mapeamento customizado e fornece uma flag persistente e altamente confiável para direcionar o desvio condicional quando o usuário clica no botão OK.

O uso de uma variável de estado dedicada, em vez de confiar apenas nas suposições do runtime engine, evita que o formulário execute um insert em um registro existente. Em ambientes multiusuário, essa salvaguarda simples elimina completamente as violações de chave primária — como o ORA-00001Código de erro do banco de dados Oracle que indica uma tentativa de inserir um valor duplicado em uma chave única. do Oracle ou o Erro 2627 do SQL Server — que normalmente representam uma parte significativa das falhas em aplicações customizadas, em nossa experiência cerca de três quartos dessas falhas, durante a entrada de dados paralela. Ao ramificar a lógica do clique do botão OK com base em evt_cIsUpdateMode_EV01, você garante que o runtime execute um Insert limpo ou uma instrução Update direcionada, mantendo intacta a integridade da sua tabela customizada.

Escrevendo as Instruções de Table I/O para Insert e Update

Colocar operações de gravação no banco de dados no evento errado é um erro comum que leva a registros órfãos. Você deve executar suas instruções explícitas de Table I/O Insert ou Update dentro do evento 'OK - Post Button Clicked', garantindo que o runtime engine já tenha executado todas as regras de validação de nível de campo e de formulário no 'OK - Button Clicked' sem erros. Se a validação falhar, o runtime interrompe o processamento antes de chegar ao 'Post Button Clicked', evitando que dados inválidos cheguem à sua tabela customizada F550101.

No assistente de mapeamento de Table I/O, você deve mapear cada chave primária e coluna que não seja chave explicitamente para um controle de formulário, uma coluna de grade ou uma variável designada. Deixar colunas não mapeadas em uma instrução de insert não as define como nulas ou em branco por padrão; em vez disso, o middlewareSoftware que atua como ponte entre a aplicação e o banco de dados, gerenciando a comunicação. muitas vezes grava valores de memória lixo ou ponteiros não inicializados no banco de dados. Para a F550101, mapeie explicitamente as chaves primárias — como Address Number (AN8) e Line Number (LNID) — junto com cada flag customizada e campo de descrição para manter a integridade dos dados.

Padronize sua trilha de auditoria de banco de dados preenchendo os cinco campos críticos de auditoria para cada gravação. Mapeie o User ID (USER) para o valor de sistema SL UserID, o Program ID (PID) para SL programId e o Work Station ID (MKEY) para SL MachineKey. Para os campos Date Updated (UPMJ) e Time of Day (UPMT), atribua SL DateToday e uma utilidade de sistema para formatar a hora, garantindo que sua trilha de auditoria na F550101 corresponda às tabelas padrão da Oracle, como a F0101.

Muitos desenvolvedores legados ainda chamam Business Functions complexas e genéricas para executar gravações básicas em uma única tabela, o que adiciona overhead desnecessário. As instruções nativas de Table I/O fornecem Event Rules (ER) mais claras e autodocumentadas que qualquer desenvolvedor pode depurar durante um upgrade do 9.1 para o 9.2. Confiar em instruções nativas em vez de BSFNs customizadas em C reduz a pegada de objetos customizados, tornando os futuros upgrades de Tools Release mais limpos.

Habilitando Processamento de Transações e Rollbacks

Falhar ao vincular gravações pai-filho em uma única unidade lógica de trabalho é como as tabelas customizadas acabam com registros de detalhes órfãos. No Form Design Aid (FDA), você deve habilitar explicitamente a propriedade 'Transaction ProcessingMecanismo que agrupa operações de banco de dados para garantir que todas sejam concluídas com sucesso ou todas sejam revertidas.' na caixa de diálogo Form Properties. Essa única caixa de seleção instrui o runtime engine a agrupar todas as operações subsequentes de banco de dados dentro da thread de execução do formulário em uma única unidade de commit vinculada, evitando gravações parciais em tabelas como F550101 e F550102 se ocorrer uma falha de rede ou violação de restrição de banco de dados no meio do processo.

Ao gerenciar essas gravações pai-filho manualmente via Table I/O dentro das event rules do botão OK, você não pode confiar no comportamento padrão de auto-commit. Você deve chamar a função de sistema Begin Transaction antes de executar o primeiro insert na tabela de cabeçalho (F550101). Isso abre o limite da transação no banco de dados, garantindo que os inserts subsequentes na tabela de detalhes (F550102) rodem no mesmo handle de conexão. Uma vez que todos os registros sejam processados com sucesso, você chama a função de sistema Commit Transaction para finalizar as gravações no banco de dados.

Confiar que o banco de dados lidará com erros silenciosamente é uma receita para dados corrompidos. Imediatamente após cada instrução de Table I/O, você deve avaliar a variável de sistema SV File_IO_Status. Se essa variável retornar qualquer valor diferente de CO_SUCCESS — como um erro de chave duplicada ou um timeout de banco de dados — você deve executar imediatamente a função de sistema Rollback TransactionComando que cancela todas as alterações feitas no banco de dados desde o início da transação atual.. Isso reverte toda a unidade de trabalho para o estado pré-transação, evitando um cenário onde um registro de cabeçalho é confirmado sem suas linhas de detalhe correspondentes, e permite que você defina graciosamente um erro de engine no formulário.

Depurando Table I/O e Instruções SQL no jdedebug.log

Quando um formulário customizado falha ao salvar silenciosamente, o jdedebug.logArquivo de log técnico do JD Edwards que registra a execução de Event Rules e comandos SQL detalhados. local é sua única fonte da verdade. Desenvolvedores muitas vezes perdem horas analisando Event Rules quando deveriam analisar as instruções SQL brutas geradas pelo middleware de banco de dados JDBCamada de software do JDE que gerencia a tradução de comandos do sistema para a linguagem específica do banco de dados.. Abrir arquivos de log grandes, muitas vezes com dezenas de megabytes, e pesquisar pelo nome da sua tabela customizada (ex: F550101) revela imediatamente se o runtime está construindo uma instrução INSERT ou UPDATE malformada.

Um ponto de falha comum é uma violação de restrição de unicidade, manifestando-se como um erro ORA-00001 em bancos de dados Oracle ou Erro 2627 no SQL Server. Se o seu formulário depende de um next number que saiu de sincronia, o log mostrará os valores de chave duplicados que fazem com que o banco de dados rejeite a transação. Recomendo configurar Output=FILE e Debug=TRUE na seção [DEBUG] do seu jde.ini local para capturar a instrução SQL que precede a falha.

Para rastrear como esses valores inválidos chegaram ao table I/O, execute o Event Rules DebuggerFerramenta que permite aos desenvolvedores percorrer o código linha por linha para identificar erros de lógica. (ActiveEra) para percorrer seus desvios de validação. Colocar breakpoints no evento "Button Clicked" do botão OK permite inspecionar os valores em tempo de execução das variáveis de Form Control (FC) antes da chamada ao banco de dados. Isso evita a gravação de valores em branco ou não inicializados em chaves primárias.

Finalmente, inspecione o log para verificar se o campo de auditoria de última hora de atualização (UPMT) está sendo gravado no formato HHMMSS correto. O JDE espera um formato numérico estrito de 6 dígitos, como 143025. Se suas Event Rules passarem uma string truncada, o middleware rejeitará a gravação ou gravará 0, corrompendo a trilha de auditoria da sua aplicação.

Executar Table I/O seguro dentro do Form Design Aid é um requisito básico para qualquer ambiente 9.2.x. Se o seu parque de código customizado contém mais de 200 objetos, avaliar esses limites transacionais durante os upgrades é crítico para evitar a corrupção do banco de dados pós-go-live.

Se você está planejando um upgrade de JDE ou precisa auditar seu portfólio de aplicações customizadas para segurança transacional, entre em contato com nossa equipe de arquitetura de ERP enterprise para agendar uma revisão técnica de código.