Quando um batch customizado que processa 50.000 registros sofre uma exceção de memória não tratada ou um lock no banco de dados no registro 38.000, um log de auditoria ingênuo transforma uma recuperação simples em um desastre operacional. Inserir instruções Insert ou Update brutas no evento Do Section sem limites explícitos de transação garante erros de chave duplicada (JDB error 0002) ou linhas de auditoria órfãs em tabelas customizadas como a F550911A no momento em que a operação reinicia o trabalho.

Implementar um exemplo confiável de Table I/OOperações de leitura e gravação diretamente em tabelas de banco de dados no JD Edwards. em UBEUniversal Batch Engine, o motor de execução de relatórios e rotinas em lote no JD Edwards. do JDE para atualizar uma tabela de auditoria customizada com segurança exige uma lógica de Event RulesLinguagem de programação baseada em eventos do JD Edwards. estritamente idempotentePropriedade de uma operação que produz o mesmo resultado mesmo se executada múltiplas vezes., consultas defensivas de chave e um alinhamento deliberado com os limites de controle de transação (commitment controlRecurso do JDE que garante a integridade de gravações transacionais no banco de dados.) do EnterpriseOne. Se uma execução de batch abortada exigir que um desenvolvedor execute uma limpeza manual via SQL antes que o UBE possa ser reexecutado, a arquitetura de Table I/O é fundamentalmente falha.

Projetando Tabelas de Auditoria Customizadas para Reexecução de UBEs

A maioria das falhas de auditoria em batch remonta a um design de chave primária falho, e não a Event Rules incorretas. Se você construir a tabela de auditoria customizada F550911A usando um Unique Key ID (UKIDIdentificador numérico sequencial gerado automaticamente pelo JD Edwards.) substituto obtido via X00022, a operação gerará linhas de auditoria duplicadas sempre que um job noturno falhar no meio de uma execução de 500.000 registros e for reiniciado. O banco de dados atribui novos números de sequência na segunda passagem, fragmentando o rastreamento histórico e distorcendo relatórios de conciliação.

Impor uma chave natural composta que inclua Número do Documento (DOCO), Tipo de Documento (DCTO), Companhia do Documento (KCO), Número da Linha (LNID) e Data de Atualização (UPMJ) proporciona idempotênciaCapacidade de reprocessar dados sem gerar duplicidades ou inconsistências no sistema. estrutural diretamente na camada de banco de dados. Quando uma reexecução processa uma transação já tratada, o UBE encontra uma colisão de chave existente em vez de gravar linhas fantasmas na contabilidade. Essa arquitetura permite que a lógica do batch redirecione a execução de forma limpa para um fluxo de atualização ou registre um desvio benigno sem rastreamento de estado externo.

Ao contrário das aplicações interativas no Form Design Aid (FDAFerramenta gráfica de desenvolvimento de telas e aplicações interativas do JDE.), onde o mecanismo de execução preenche as colunas de auditoria automaticamente, o Table I/O em Event Rules exige o mapeamento explícito para cada operação de gravação. Você deve mapear manualmente SL UserId (USER), SL ProgramId (PID), SL MachineKey (JOBN), SL DateToday (UPMJ) e SL TimeOfDay (TDAY) no buffer de Table I/O. Deixar esses campos sem mapear grava metadados em branco ou preenchidos com zeros no banco de dados corporativo, invalidando imediatamente as auditorias de conformidade.

A seleção do índice dita diretamente a granularidade de bloqueio (lock) e o throughput ao iterar sobre conjuntos de dados de alto volume. Se a sequência do índice primário não corresponder exatamente aos critérios de chave nas suas chamadas de atualização por Table I/O, o gerenciador do banco de dados escala de locks finos por linha para locks amplos por página ou tabela. Alinhar a definição do índice de Table I/O com precisão à chave composta natural elimina a concorrência por locks e previne deadlocksBloqueios mútuos entre dois ou mais processos que tentam acessar as mesmas tabelas simultaneamente. com jobs batch concorrentes.

Posicionamento de Table IO: Lógica no Do Section vs End Section

Executar um Fetch Single, Insert ou Update explícito de Table I/O diretamente no evento Do Section executa um ciclo distinto de cursor de banco de dados para cada iteração da business view principal. Em um batch de 100.000 linhas — típico do processamento noturno de pedidos de vendas ou conciliações de estoque —, isso se traduz em 100.000 idas e voltas (round-trips) individuais ao banco de dados pela rede. A menos que os requisitos de conformidade exijam estritamente o log de auditoria transacional registro a registro, essa escolha de design degrada o throughput do batch, estendendo facilmente uma execução de UBE de 4 minutos para mais de 45 minutos.

Você pode reduzir as idas e voltas ao banco de dados em mais da metade acionando o Table I/O condicionalmente, em vez de executá-lo a cada ciclo de registro. Avalie sinalizadores de status — como o status do pedido LTTR ou o flag de processo EDI EDSP — e emita gravações de auditoria apenas quando ocorrerem alterações de estado. Crucialmente, mantenha o Table I/O completamente fora do evento After Record is Fetched. O JDE processa esse evento antes de avaliar os critérios de filtro do nível da seção ou a lógica Suppress Section Write do engine. Gravar registros de auditoria no After Record is Fetched garante que sua tabela de auditoria registrará linhas que o engine de relatório acabará descartando.

Descarregar métricas agregadas e estados finais de execução pertence estritamente ao evento End Section. Esse evento dispara uma única vez após o término do loop principal de processamento em todo o conjunto de dados sem erros não tratados. Use o End Section para gravar contagens resumidas do batch, valores financeiros totais e timestamps finais de execução na sua tabela de auditoria customizada. Restringir as gravações de resumo ao End Section mantém os locks de banco de dados no meio do processo fora do loop principal, garantindo que seu registro final de auditoria reflita com precisão o ciclo de execução concluído.

Estruturando Condições de Gravação para Prevenir Registros Duplicados

Executar um Insert cego por Table I/O em uma tabela de auditoria customizada garante uma falha não tratada no momento em que um job batch é executado sobre dados existentes. O runtime do JDE intercepta a violação de restrição de unicidade no banco de dados subjacente durante o JDB_InsertTable, grava um erro no jde.log e falha a execução do batch. Em jobs de alto volume que processam 50.000 registros, uma única chave duplicada no registro 49.999 transforma uma execução de 40 minutos em um job abortado que deixa as tabelas de destino fora de sincronia com o seu log de auditoria.

Eliminar esse modo de falha requer um padrão defensivo explícito de busca (fetch) antes de emitir chamadas de gravação. Nas suas Event Rules, passe a chave primária completa — tipicamente campos como DOCO, DCTO, KCOO e um número de linha ou sequência — em um Fetch Single de Table I/O direcionado diretamente ao índice primário. Essa operação consulta o estado da tabela sem bloquear a linha e preenche imediatamente a variável de sistema SV File_IO_Status para orientar a lógica de execução.

Avalie SV File_IO_Status imediatamente após o fetch. Quando o status for avaliado como CO SUCCESS, a linha de auditoria já existe de uma etapa anterior ou de uma execução abortada. Direcione sua lógica em ER para executar um Update por Table I/O mapeado estritamente sobre os campos exatos da chave primária, atualizando os timestamps de auditoria, contadores de tentativas ou valores de payload.

Quando SV File_IO_Status for avaliado como CO RECORD_NOT_FOUND, redirecione a execução para um Insert por Table I/O. Preencha o buffer de inserção com variáveis de Event Rule limpas e explicitamente inicializadas, em vez de variáveis de relatório não atribuídas que carregam memória residual de iterações anteriores da seção. Estruturar as condições de gravação por meio dessa sequência determinística mantém o Table I/O confiável, protege a integridade dos índices do banco de dados e garante que o UBE possa ser reexecutado sem lançar erros SQL de chave duplicada.

Gerenciando a Segurança de Transações e o Controle de Transação (Commitment Control)

O Table I/O padrão em Event Rules é executado no modo auto-commitModo de operação em que gravações no banco são confirmadas imediatamente sem rollback global. por padrão, de forma completamente independente do limite de transação subjacente da seção do UBE. Se você emitir um Insert ou Update em uma tabela de auditoria customizada F554111A dentro do evento Do Section enquanto gera registros contábeis padrão na F0911, essas operações serão executadas em handles de conexão separados. Um deadlock no banco de dados, cancelamento do batch ou erro de host em tempo de execução no registro 450 disparará um rollbackOperação de reversão que cancela alterações pendentes no banco de dados após um erro. do engine na business view principal da F0911, enquanto sua tabela customizada F554111A reterá registros de auditoria sujos e órfãos das linhas 1 a 449.

Para sincronizar essas operações sem escrever código C, habilite a propriedade Include in Transaction na caixa de diálogo Section Properties do UBE. Essa configuração força todas as instruções nativas de Table I/O em Event Rules executadas dentro dessa seção a entrarem no escopo de transação gerenciado pelo driver da business view principal. Quando um erro de processamento ou encerramento no nível do host dispara um rollback do batch, o engine JDB realiza o rollback das suas linhas de auditoria customizadas junto com as modificações nas tabelas padrão do JDE, preservando a consistência absoluta de estado em todas as tabelas envolvidas.

O processamento declarativo de transações no nível da seção falha quando a tabela de auditoria customizada reside em uma fonte de dados (data source) de banco de dados separada — como um banco de dados de analytics corporativo distinto ou um schema de segurança dedicado definido no Object Configuration Manager (OCMComponente do JDE que define a localização física e o mapeamento de tabelas e objetos no sistema.). O middleware JDB não consegue listar automaticamente handles de banco de dados de múltiplas fontes de dados em um único escopo de transação no nível da seção. Resolver isso exige ignorar o Table I/O nativo em ER e chamar funções de negócios em C (business functions) que utilizam JDB_BeginTransaction, JDB_CommitUser e JDB_RollbackUser para coordenar explicitamente os commits entre limites de conexão de banco de dados distintos. Passar handles de transação explícitos (HUSER e HREQUEST) garante que mesmo as gravações de auditoria em diferentes fontes de dados façam rollback de forma limpa durante falhas em processamentos batch de alto volume.

Tratando Abortos de Batch e Limites de Reinício Idempotentes

Quando um job batch falha no meio do processamento de 50.000 registros, a limpeza manual via SQL é um risco operacional que o desenvolvimento deve eliminar desde o projeto. Você deve tratar a ressubmissão diretamente em Event Rules usando o padrão de reinício nativo dos UBEs principais do JDE, como o R09801. Projete suas Processing OptionsTela de parâmetros configuráveis que alteram a forma de execução do programa sem alterar o código. para fornecer aos operadores um modo de reexecução explícito — permitindo que eles escolham entre reprocessar registros não commitados, tratar apenas erros ou forçar uma sobrescrita no nível de execução. Sem um modo de processamento claro definido no modelo de processing options, os operadores inevitavelmente criarão entradas duplicadas ou pularão registros que falharam durante a recuperação.

A idempotência exige uma coluna de status dedicada na sua tabela de auditoria F55, como o EDSP (Processed Code) ou um flag EV01 atualizado para 'P' após o commit bem-sucedido. No evento Initialize Section, o código driver deve inspecionar a tabela de auditoria para estabelecer a marca d'água (high-water mark) dos registros commitados antes do início do loop principal. Validar esse status em relação às linhas contábeis de origem na F0911 ou F4711 garante que a reexecução de um UBE abortado pule as transações já processadas sem gerar violações de chave primária.

Limpar registros parciais ou corrompidos de uma execução abortada requer restrições precisas de Table I/O. Nunca emita uma instrução Delete sem restrições contra a tabela F55. Limite o escopo do Delete por Table I/O estritamente usando uma chave composta correspondente ao Número do Job (SV JobNumber), Data de Execução (SV DateUpdated) e ID do Usuário (SV UserId). Isso isola e remove apenas os registros órfãos gravados durante a execução com falha, mantendo os dados históricos de auditoria completamente intocados.

Em ambientes corporativos, a vasta maioria dos abortos de batch decorre de timeouts temporários de rede ou falhas de alocação de memória no Enterprise Server. Construir sua lógica de auditoria na F55 em torno da detecção de marca d'água (high-water mark) e de Table I/O com escopo definido por job garante que a ressubmissão do UBE resulte exatamente no mesmo estado, quer leve uma ou três tentativas.

Implementação em Event Rules: Table IO Seguro Passo a Passo

Depender de conexões implícitas do engine do JDE para gravações de auditoria customizadas é um risco latente em produção. No evento Initialize Section, emita uma instrução Open de Table I/O explícita atribuindo sua tabela de auditoria customizada (por exemplo, F55411A) a um table handle dedicado (hUserTableHandle). Abrir o handle explicitamente durante a inicialização da seção garante que o overhead de conexão com o banco de dados ocorra exatamente uma vez por execução do UBE, em vez de abrir e fechar implicitamente para cada linha individual em um batch de 100.000 registros.

Dentro do evento Do Section, limpe todas as variáveis de relatório e valores de data structure mapeados para a tabela de auditoria antes de executar operações de leitura ou gravação. A falha em limpar variáveis como RV szErrorMessage ou RV mnAuditAmount causa o clássico vazamento de buffer de memória (memory buffer bleed), onde o estado do valor do registro 499 persiste silenciosamente no registro 500 se a 500ª linha retornar um campo de banco de dados nulo. Execute um Fetch Single de Table I/O usando seu table handle aberto, passando os componentes da chave primária (como BC szOrderKey e BC idDocumentType).

Avalie imediatamente o Valor de Sistema SV File_IO_Status após a chamada de fetch. Se SV File_IO_Status for igual a CO SUCCESS, direcione a lógica para o Update por Table I/O mapeado para a chave primária; se retornar CO ERROR (indicando ausência do registro), desvie diretamente para o Insert por Table I/O. Envolva ambos os fluxos com uma verificação condicional no SV File_IO_Status após a operação de gravação, escrevendo qualquer flag de falha em uma variável de relatório para saída de diagnóstico, de modo que a execução do batch termine com total visibilidade operacional em vez de falhar silenciosamente.

Por fim, passe para o evento End Section para executar um Close explícito por Table I/O usando hUserTableHandle. Deixar table handles abertos força o engine do enterprise server a manter cursores de banco de dados abertos até que o processo do UBE termine. Em jobs batch grandes que processam 50.000 registros em múltiplas subseções, handles não fechados rotineiramente esgotam os limites de cursores do banco de dados (como o Oracle OPEN_CURSORS = 300), lançando erros ORA-01000 no meio da execução e encerrando o job.

Estruturar suas Event Rules em torno de table handles explícitos, verificações defensivas de chave e limites de transação sincronizados garante que seus jobs batch sejam executados de forma confiável e se recuperem de forma limpa de abortos no meio do processo, sem a necessidade de intervenção manual.