Desenvolvimento no JD Edwards EnterpriseOne: UBE, BSFN em C e NER, e customização que não quebra a atualização

Este guia é para gestores de TI e desenvolvedores que mantêm ou evoluem o JD Edwards EnterpriseOne e precisam decidir como construir cada objeto. Ao final, o leitor sabe quando usar um UBE, uma business function em C ou em NER, como customizar sem perder a capacidade de aplicar atualizações e o que conferir antes de levar um objeto para produção.

O que é um UBE e quando usar

O UBE (Universal Batch Engine) é o objeto do EnterpriseOne para relatórios e processamento em lote, construído no Report Design Aid (RDA). É a escolha certa quando o trabalho percorre muitos registros sem interação do usuário: atualizações em massa, cargas, conferências e documentos impressos.

Cada UBE roda por meio de versões. A versão guarda a seleção de dados, a sequência de dados e os valores das opções de processamento, o que permite que um mesmo objeto atenda cenários diferentes sem duplicar código.

Para documentos com layout elaborado, como notas, pedidos e boletos, o caminho é o BI Publisher integrado ao EnterpriseOne. O UBE gera a saída em XML, o modelo é registrado no repositório de objetos (P95600) e uma definição de relatório (P95620) associa o UBE ao modelo. A própria Oracle orienta não usar o BI Publisher para relatórios simples de erro nem para UBEs de atualização que não produzem saída.

Business Functions: C ou NER

Business functions (BSFNs) encapsulam regras de negócio reutilizáveis por aplicações, UBEs e outras funções. Existem dois tipos: NER (Named Event Rules), escritas na linguagem de event rules do próprio EnterpriseOne, e BSFN em C, escritas diretamente em linguagem C com as APIs do sistema. Na compilação, a NER também é convertida em código C, e as duas são construídas pelo Business Function Builder.

Critérios técnicos de escolha

• Comece por NER. A documentação da Oracle recomenda NER sempre que possível. Ela é independente de plataforma e mais fácil de ler e manter.
• Use C quando a NER não alcança. Cache em memória (jdeCache), manipulação de estruturas complexas, controle fino de ponteiros e de transações, mensagens de erro em lote e chamadas a APIs que as event rules não expõem pedem C.
• Desempenho. Em rotinas que processam grandes volumes, uma função em C com cache e acesso a tabelas bem planejado costuma reduzir leituras repetidas ao banco. Para lógica de validação e cálculo comum, a diferença tende a ser pequena, e a NER vence pela manutenção.
• Manutenção. Código em C exige padrões rígidos de alocação e liberação de memória, tratamento de erros e documentação no cabeçalho.

Aplicações interativas e eventos

As aplicações interativas são construídas no Form Design Aid (FDA) e se comportam por meio de event rules ligadas a eventos de formulário, de grade e de controle. Antes de alterar uma aplicação, vale conferir se a necessidade cabe em uma versão, em uma opção de processamento ou em uma personalização sem código.

• Customizar a aplicação padrão faz sentido quando a mudança é pequena e precisa valer exatamente onde o usuário já trabalha, como uma validação extra em um campo. O custo é o retrofit a cada atualização que traga nova versão daquele objeto.
• Criar uma aplicação nova, no intervalo de sistemas reservado ao cliente, é o caminho quando surgem formulários, fluxos ou dados próprios. A Oracle orienta criar formulários personalizados em uma aplicação customizada, em vez de adicioná-los às aplicações existentes.

Em ambos os casos, regra de negócio relevante deve ficar em business function, e não espalhada nos eventos da tela. Assim a mesma regra serve à aplicação, ao UBE e a integrações.

Customizar sem quebrar a atualização

A capacidade de aplicar ESUs e novas tools releases sem retrabalho depende de decisões tomadas no primeiro dia de desenvolvimento.

• Faixa de sistemas 55 a 59. Objetos novos (tabelas, aplicações, UBEs, funções, itens de dicionário) usam os códigos de sistema 55 a 59, que a Oracle reserva para o cliente. Objetos nessa faixa não são sobrepostos por objetos novos entregues em atualizações.
• Clonar em vez de alterar. Quando um objeto padrão precisa mudar de forma substancial, copie para um nome na faixa do cliente (por exemplo, R5542565 a partir de R42565) e mantenha o original intacto.
• Tabelas tag em vez de colunas novas. Em vez de acrescentar colunas a uma tabela padrão, crie uma tabela complementar na faixa 55 a 59, ligada pela mesma chave.
• OMW e projetos. Todo objeto nasce e se move dentro de um projeto do Object Management Workbench, com transições de status configuradas para refletir desenvolvimento, teste e produção. O projeto padrão de cada usuário não promove objetos; o trabalho precisa estar em um projeto próprio.
• Documentação. Registre o motivo da mudança, o objeto de origem quando houver cópia e as dependências. É isso que torna o retrofit previsível.
• Impacto de ESUs e tools releases. Antes de aplicar uma ESU, levante quais objetos dela também foram customizados. As ferramentas de comparação (ER Compare e as opções de merge) e o retrofit ajudam a levar a customização para a versão nova do objeto. Uma tools release altera o runtime e também pede reteste.
• Testes de regressão. Mantenha um roteiro de testes por objeto customizado e execute-o depois de cada ESU ou tools release.

Integrações com outros sistemas

O EnterpriseOne tem um modelo próprio de interoperabilidade baseado em tabelas de interface, chamadas tabelas Z, cujo nome segue a tabela de aplicação com o sufixo Z1 (por exemplo, F4211Z1).

• Entrada: o sistema externo grava na tabela Z; um processo em lote valida os registros, atualiza as tabelas de aplicação com os válidos e sinaliza os inválidos para correção e nova execução. O dado bruto não toca as tabelas de produção antes de passar pela validação.
• Saída: com o tipo de transação configurado nas opções de processamento, o sistema grava uma cópia da transação na tabela Z, e um UBE customizado lê e formata o dado para o destino.

Quando não existe tabela Z para o caso, a integração pode ser construída com tabelas de interface próprias na faixa do cliente e UBEs de carga que chamam as business functions mestras do sistema, em vez de gravar direto nas tabelas. Assim valem as mesmas validações da tela.

Desempenho de relatórios e rotinas

• Índices. A seleção e a sequência de dados devem coincidir com um índice da tabela. Quando nenhum atende, crie o índice no Table Design Aid e gere-o no banco, avaliando o custo sobre as gravações.
• Seleção de dados. Filtre o máximo possível na seção principal, no banco, e não em event rules linha a linha. Use business views com apenas as colunas necessárias.
• Leituras repetidas. Evite buscar o mesmo registro mestre a cada linha processada; ordene os dados para aproveitar quebras de nível ou use cache em uma função em C.
• Processamento em lote. Rotinas pesadas devem rodar no servidor, fora do horário de pico, e ser divididas por versões com seleções distintas quando o volume permitir paralelismo.

Checklist antes de levar um objeto para produção

• O objeto está na faixa 55 a 59, com nome e descrição que indicam a origem e a finalidade.
• Todos os objetos do projeto foram devolvidos ao servidor (check in) e o projeto está no status de teste.
• Dependências (estruturas de dados, business views, itens de dicionário, UDCs, versões) estão no mesmo projeto.
• Funções em C liberam toda a memória alocada e tratam os códigos de retorno.
• O UBE foi executado com o volume real de dados em teste, e o tempo foi registrado.
• O roteiro de regressão dos objetos relacionados foi executado e aprovado.
• O pacote foi construído e implantado primeiro no ambiente de teste.

Perguntas frequentes

Qual a diferença entre um UBE e uma versão?

O UBE é o programa em lote; a versão é uma configuração de execução dele, com seleção de dados, sequência e opções de processamento próprias. Um único UBE pode ter várias versões.

Quando escrever uma business function em C em vez de NER?

Quando a lógica precisa de cache em memória, de APIs que as event rules não oferecem ou de controle fino sobre estruturas e desempenho. Para validações e cálculos comuns, a NER é a recomendação e simplifica a manutenção.

Por que usar os códigos de sistema 55 a 59?

Porque a Oracle reserva essa faixa para objetos do cliente. Objetos nela não são sobrepostos por objetos novos entregues em ESUs e atualizações, o que reduz o retrabalho.

É melhor alterar a aplicação padrão ou criar uma nova?

Alterações pequenas e pontuais podem ficar na aplicação padrão, aceitando o retrofit nas atualizações. Formulários, fluxos e dados próprios devem ficar em uma aplicação nova na faixa do cliente.

O que são as tabelas Z?

São tabelas de interface do EnterpriseOne, com sufixo Z1, usadas para receber e enviar transações de e para outros sistemas, com validação em lote antes de o dado chegar às tabelas de aplicação.

Como reduzir o tempo de um relatório lento?

Alinhe seleção e sequência de dados a um índice, filtre no banco em vez de linha a linha, evite leituras repetidas do mesmo registro e rode o processamento no servidor.

Desenvolvimento JD Edwards com a Uai Hub

A Uai Hub desenvolve no JD Edwards EnterpriseOne desde 2011: UBEs, business functions em C e NER, aplicações interativas, integrações e ajustes de desempenho, sempre dentro do padrão do sistema e com os objetos controlados no OMW. Veja como funciona em desenvolvimento JD Edwards ou fale com a gente.