O que é o JDE Log Insights

Um log do JD Edwards EnterpriseOne pode ter milhões de linhas, e a resposta costuma estar em poucas delas. O JDE Log Insights lê esses arquivos e mostra por onde começar: agrupa os erros, mede funções de negócio (BSFN) e SQL, encontra pausas e desenha o que chamou o quê. ^[1]

É um único arquivo HTML, sem instalação nem conta.

Abrir o JDE Log Insights →

Como o app trata os seus dados

• Nada sai do seu computador. O arquivo bloqueia conexões de rede. Logs costumam trazer usuários, servidores e SQL, então isso importa.
• O log não fica guardado. Ao fechar a página, a análise some. O app só guarda idioma, tema e o limite de lentidão.

Os logs do JD Edwards

Cada arquivo responde a uma pergunta diferente. A documentação da Oracle separa assim: ^{[2] [3] [4]}

O número no nome é o ID do processo, então um servidor gera vários arquivos. Abra juntos os do mesmo processo: o app lê todos de uma vez e diz o que identificou em cada um.

Como obter os logs

O local do jde.log e do jdedebug.log vem de JobFile e DebugFile, na seção [DEBUG] do jde.ini. ^[3] O jdedebug só traz chamadas, SQL e tempos com a depuração ligada:

[DEBUG]
Output=FILE
LogErrors=1

1. Ligue a depuração na máquina certa. Para reproduzir o problema, isole um único kernel ou processo, para os logs não se misturarem. ^[7]
2. Reproduza o problema uma vez e copie os arquivos. Eles podem ser sobrescritos na sessão seguinte: a Oracle descreve os dois comportamentos, sobrescrever e acrescentar, conforme o servidor e a estação. ^{[3] [4]}
3. Volte Output ao valor anterior. O log cresce rápido e pesa no processo: um autor estima de 2% a 5% a mais de tempo. ^[7]

Logs de UBE ficam na fila de impressão (PrintQueue), e o nível de detalhe vem de UBEDebugLevel, na seção [UBE]. ^[3]

Roteiro: investigando o exemplo

Use os dados de exemplo: são fictícios, montados a partir de trechos públicos de log, e o resultado abaixo é o que você verá. O caso tem de tudo: uma conexão perdida com o banco, uma leitura enorme e um SQL lento.

1. Abra o exemplo e leia o primeiro insight

1. Abra o app e clique em Ver um exemplo.
2. Confira os totais do topo: 8.693 linhas, 62 ocorrências de erro em 7 tipos, 124 chamadas de BSFN e 123 comandos SQL.
3. Leia o primeiro cartão, marcado como Crítico: O banco de dados ficou fora de alcance. O ORA-03113 apareceu 22 vezes, de 12 de mar. 09:17:00 a 12 de mar. 09:17:42.

2. Abra o erro e veja a linha original

1. No primeiro cartão, clique em Ver os erros. A aba Erros abre já filtrada.
2. Clique na mensagem do ORA-03113. O detalhe traz o que a fonte diz sobre o erro e o link para ela.
3. Em Ocorrências de exemplo, clique em Ver no log para conferir o trecho original, com a linha marcada.

De volta aos insights, outro cartão diz que o JDB9900401 costuma ser consequência do ORA-03113. Foram 22 ocorrências, sempre até 1 segundo depois, na mesma thread. Por isso a investigação começa pelo ORA-03113.

3. Procure onde o tempo foi

1. Abra a aba BSFN. A tabela vem ordenada por Tempo próprio.
2. F4111EndDocument levou 9,13 s no total, e 7,41 s são tempo próprio dela. Logo, o tempo não está nas funções que ela chama.

4. Descubra o SQL responsável

1. Abra a aba SQL. O primeiro comando é uma leitura de F0005, sem WHERE, de cerca de 7,4 s.
2. Veja os outros dois sinais: uma leitura de F41021 trouxe 4.000 linhas, e o comando em F4101 rodou 120 vezes.

5. Veja o caminho no mapa

1. Abra a aba Fluxo e clique no bloco F41021.
2. O mapa destaca o caminho: P4116 chama F4111EndDocument, que chama AverageCostUpdate, que lê F41021. Agora você sabe qual tela leva a essa leitura.

6. Gere o relatório

1. Clique em Relatório e marque Ocultar usuários, servidores, IPs, caminhos e valores entre aspas.
2. Revise o texto e use Copiar ou Baixar .md.

Resultado: em poucos minutos você tem uma hipótese para cada problema. Conexão com o banco perdida às 09:17, com um erro que é consequência de outro; uma leitura sem filtro; e uma função chamada 120 vezes. Falta confirmar cada uma com o DBA e com quem conhece o código.

Como ler os insights

Os cartões são regras simples sobre os números do log, e estas são as condições exatas. Um sinal não é uma causa: ele diz onde olhar.

Abaixo dos cartões, dois gráficos mostram os erros e as linhas de log ao longo do tempo. Clique em uma barra de erro para ver só os erros daquele intervalo. Ver como tabela traz os mesmos números em tabela.

Erros

O app agrupa mensagens que só mudam nos valores, e o mesmo erro com números diferentes conta como um só. Filtre por Nível e Área, ou digite um trecho, como o nome de uma tabela.

• Fatal, Erro e Alerta vêm de códigos e palavras da mensagem, como ORA-00942, OCI0000178 e failed.
• O que a fonte diz: o app tem uma pequena base, só com textos da Oracle, cada um com o link da fonte. ^{[3] [4] [8]}
• Código fora da base: procure no My Oracle Support ou no aplicativo P92002, que traz as mensagens de erro do sistema. ^[4]

BSFN

O app junta cada chamada ao seu retorno, por thread, e calcula dois tempos:

• Tempo total: da chamada ao retorno, incluindo as funções chamadas por ela.
• Tempo próprio: o total menos o tempo das funções filhas. É onde você deve olhar primeiro. ^[7]
• Retorno ≠ 0: chamadas que retornaram valor diferente de 0. O app só conta; confira como quem chama trata esse retorno.

SQL

O app retira os valores, para juntar comandos iguais, e soma execuções, linhas lidas e tempo. Assim, valores de clientes não ficam guardados na tabela.

• Linhas lidas: conta as linhas "Fetched the record" depois de cada comando. Um estudo de caso de P4116 mostra esse padrão: 40 mil linhas lidas em uma única chamada de função. ^[6]
• Tempo aprox.: vai do comando até a última busca, então inclui o que a aplicação fez entre as buscas.
• Pista: um intervalo longo entre o comando e a primeira busca costuma apontar para o banco, mais do que para a lógica. ^[7]

Pausas

Pausa é o tempo sem novas linhas no mesmo processo e na mesma thread. A Oracle sugere o jdedebug justamente para ver o ponto em que a execução normal parou. ^[3] Cada linha da tabela mostra o que veio antes e depois.

Contexto

A aba Contexto responde "o que estava rodando?": arquivos lidos e o tipo de cada um, aplicações e relatórios, tabelas, processos e threads, e as chamadas de API mais frequentes.

Fluxo

A aba Fluxo desenha quem chama quem, somando todas as execuções: entrada, BSFN por nível, tabelas e erros em sequência. Em um jde.log puro, mostra processo → erro → erro seguinte.

• Quanto mais grossa a ligação, mais vezes ela ocorreu.
• ⏱ marca o que passou do limite de lentidão, e a linha tracejada, uma volta, como recursão.
• Ao clicar em um bloco, o caminho dele fica em destaque e Abrir detalhes leva ao detalhe.
• Em uma BSFN, Parâmetros mostra lado a lado a entrada e a saída de cada parâmetro, das linhas IN-> e OUT->, em até cinco chamadas: a primeira, a mais lenta e as que retornaram valor diferente de 0. ≠ marca o que mudou.
• Ver as ligações como tabela traz as mesmas ligações em texto, e Baixar SVG salva a imagem.

Conteúdo

A aba Conteúdo mostra o log inteiro, linha a linha, com uma cor e uma etiqueta para cada tipo de evento: erros, retornos diferentes de 0, BSFN, SQL, leitura de linhas, parâmetros, API e UBE. Use-a quando os resumos já disseram onde olhar e você quer ler o que aconteceu ao redor.

• Filtrar: clique em um tipo para ver só as linhas dele. Clicar em outro soma, e Mostrar tudo desfaz.
• Pausas: ⏸ marca a linha que veio depois de uma pausa acima do limite.
• Navegar: use a busca, Ir para a linha, Próximo erro ▶ e as setas. Em Ver no log, o botão Abrir em Conteúdo traz você para cá.
• Copiar: linhas com mais de 2.000 caracteres são cortadas na tela, e Copiar traz o texto inteiro.

Relatório e privacidade

Relatório gera um texto em Markdown com os insights e os principais números, para anexar a um chamado. Antes de enviar para alguém ou para uma IA, marque Ocultar usuários, servidores, IPs, caminhos e valores entre aspas.

Documentar, no menu do topo, junta numa página todas as abas, menos Conteúdo, sem os filtros da tela, e abre a janela de impressão do navegador. Escolha "Salvar como PDF" como destino para guardar a análise. Ao contrário do relatório, o PDF não oculta nada: os valores aparecem como estão no log.

Novo volta à tela inicial e tira a análise atual da memória, para você abrir outro log. Os arquivos no seu computador não mudam. Para guardar o resultado, use Documentar antes.

Um método para o log real

Com um problema real, esta ordem evita perder tempo:

1. Comece pelo jde.log. Se houver falha grave ou queda de conexão, resolva isso antes de medir desempenho.
2. Reproduza com depuração em um único processo, e abra o jdedebug.
3. Siga o tempo: BSFN por tempo próprio, depois SQL e Pausas.
4. Confirme na linha original com Ver no log e com quem conhece o código e o banco.
5. Corrija e meça de novo. Um autor sugere 10 ou mais execuções e usar a mediana, porque uma só engana. ^[7]

Para logs muito grandes ou análise oficial, a Oracle oferece o LogParse, no Performance Workbench do Server Manager, que gera resumo, CSV de BSFN e tabelas e pausas. ^[5] O JDE Log Insights é uma alternativa rápida, sem servidor, não um substituto.

Prompts de IA

Com os sinais em mãos, ainda falta interpretar: o que esse código quer dizer, qual erro veio primeiro, o que perguntar ao DBA. Uma IA ajuda a organizar hipóteses e a preparar a conversa. Ela também erra com segurança: inventa causas, cita notas de suporte que não existem e supõe como é a sua customização. Trate a saída como rascunho de um colega apressado. Para escrever prompts melhores, veja o tutorial de prompts.

Antes de colar: logs podem trazer usuários, servidores, SQL e valores de clientes. O app não envia nada para a rede, mas o serviço de IA recebe tudo o que você colar nele. Use Ocultar usuários, servidores, IPs, caminhos e valores entre aspas, revise o texto e siga a política da sua organização para uso de IA.

Troque os trechos entre colchetes e cole na ferramenta de IA que você usa. Os prompts seguem a ordem da investigação, mas cada um funciona sozinho.

1. Priorizar o que o relatório mostra

Em Relatório, marque Ocultar usuários, servidores, IPs, caminhos e valores entre aspas, use Copiar e cole o texto no fim do prompt.

Você é um analista experiente em JD Edwards EnterpriseOne.
Abaixo está o relatório de uma ferramenta que lê logs do sistema.

Contexto do problema: [o que o usuário viu, quando, em qual aplicação]

Com base só no relatório:
1. Liste de 3 a 5 hipóteses, da mais provável à menos provável.
2. Para cada uma, cite o número ou a linha do relatório que a sustenta e diga o que a derrubaria.
3. Diga o que devo olhar primeiro e quem na equipe pode confirmar.
4. Separe o que é fato no relatório do que é suposição sua.

Não invente códigos, tabelas, notas de suporte nem características do meu ambiente. Se faltar dado, diga qual.

Relatório:
[cole o relatório]

2. Explicar um erro

Abra o erro na aba Erros e use Ver no log para copiar a mensagem e as linhas ao redor, trocando dados sensíveis. Depois, compare a resposta com o que a Oracle diz sobre o código. ^[8]

Explique este erro de um log do JD Edwards EnterpriseOne para quem não é especialista.

Versão do sistema e banco: [ex.: Tools 9.2, Oracle, ou "não sei"]
O que estava sendo feito: [aplicação, UBE ou ação]

Mensagem e linhas ao redor:
[cole o trecho]

Responda:
1. O que a mensagem diz, em linguagem simples.
2. Causas possíveis, com o que confirma ou descarta cada uma.
3. Onde verificar e quem normalmente verifica.
4. Quais partes da sua resposta vêm de documentação e quais são dedução. Se não conhece o código, diga, em vez de adivinhar.

3. Separar causa de consequência

Na aba Erros, use Baixar CSV e cole a tabela. Antes de colar, troque usuários, servidores e valores, porque o CSV não oculta dados. O prompt pede que a IA diga o que abrir no log para confirmar cada ligação.

A tabela abaixo lista os erros agrupados de um log do JD Edwards EnterpriseOne, com contagem, primeira e última ocorrência.

Identifique:
1. Quais erros parecem a origem e quais parecem consequência, usando a ordem no tempo e o tipo de mensagem.
2. Erros que ocorreram no mesmo período e podem ter a mesma causa.
3. Por qual erro começar, e por quê.

A tabela não mostra a thread nem o texto completo. Diga o que eu preciso abrir no log para confirmar cada ligação. Não trate coincidência no tempo como prova.

Tabela:
[cole o CSV]

4. Entender onde a BSFN gasta tempo

Na aba BSFN, use Baixar CSV e cole a tabela. Em tempo de relógio, a diferença entre total e próprio indica onde descer. ^[7]

A tabela abaixo traz as funções de negócio (BSFN) medidas em um jdedebug do JD Edwards EnterpriseOne: chamadas, tempo total, tempo próprio, média, máximo e retornos diferentes de 0. Os tempos são de relógio, com o log ligado.

Cenário medido: [o que foi executado, e quantas vezes]
Tempo que o usuário percebeu: [ex.: 40 s]

1. Quais funções merecem atenção primeiro, e por quê.
2. Onde o tempo total é bem maior que o próprio, e o que isso indica.
3. Sinais de chamada repetida demais.
4. Que perguntas fazer a quem conhece o código.

Não diga o que uma função faz por dentro, a menos que eu informe. Se um nome sugerir algo, marque como suposição.

Tabela:
[cole o CSV]

5. Analisar um SQL

Abra o comando na aba SQL e use Copiar: o texto vem sem os valores. Acrescente as colunas da linha, como execuções e linhas lidas. ^[7]

Analise este SQL de um log do JD Edwards EnterpriseOne. Os valores foram retirados.

Comando:
[cole o comando]

Execuções: [número]
Linhas lidas: [número]
Tempo aproximado (inclui o que a aplicação fez entre as buscas): [tempo]
Banco: [ex.: Oracle, SQL Server]
Tamanho da tabela: [linhas, ou "não sei"]

Responda:
1. O que chama a atenção: repetição, volume, falta de filtro.
2. O que pedir ao DBA para confirmar, como plano de execução e índices existentes.
3. Duas ou três melhorias a avaliar na aplicação e no banco, com o risco de cada uma.

Não invente nomes de índices ou de colunas. Não recomende alterar tabelas padrão do JD Edwards sem dizer o impacto.

6. Interpretar uma pausa

Abra a pausa na aba Pausas e copie as linhas antes e depois, trocando dados sensíveis. A resposta deve dizer o que falta para decidir, não só dar um palpite.

Em um log do JD Edwards EnterpriseOne, houve uma pausa de [tempo] na mesma thread.

Última linha antes:
[cole]

Primeira linha depois:
[cole]

Como o log foi gerado: [ex.: usuário usando a tela, UBE, carga automática]

Liste o que pode explicar essa pausa, como trabalho sem registro, espera de banco ou rede, ou falta de atividade do usuário. Para cada explicação, diga o que observar para confirmar ou descartar. Se as linhas não permitem decidir, diga isso.

7. Planejar a próxima medição

Pede um plano curto para reproduzir e comparar, seguindo o método deste tutorial. Revise qualquer mudança no jde.ini com quem administra o servidor. ^{[3] [7]}

Quero medir um problema de desempenho no JD Edwards EnterpriseOne e comparar antes e depois de uma correção.

Problema: [o que está lento]
Ambiente disponível para teste: [ex.: homologação, um kernel isolado]
O que já sei: [cole os principais achados]

Monte um plano curto:
1. Como reproduzir o mesmo cenário, sempre igual.
2. Quais logs coletar e como isolar o processo, para eles não se misturarem.
3. Quantas execuções fazer e como comparar, usando a mediana.
4. O que pode distorcer a medida, como o próprio log, o cache e outros usuários.
5. Como desfazer as configurações de depuração ao terminar.

Marque o que precisa de confirmação do administrador do sistema. Se não tiver certeza do nome de um parâmetro, diga.

8. Escrever o chamado

Separa fatos de hipóteses, para o chamado não afirmar o que ninguém provou. Se a IA citar um documento de suporte, confira se ele existe.

Escreva um chamado para [DBA, desenvolvimento ou suporte] a partir do relatório abaixo.

O que aconteceu para o usuário: [descreva]
Impacto: [quem foi afetado, desde quando]
O que já foi tentado: [descreva]

Estrutura:
1. Resumo em duas frases.
2. Fatos observados, com horários e números do relatório.
3. Hipóteses, marcadas como hipóteses.
4. O que peço que seja verificado.
5. Anexos a enviar.

Não acrescente fatos, causas nem prazos. Mantenha as partes ocultas como estão.

Relatório:
[cole o relatório]

Como conferir a resposta

Erros comuns e limitações

Erros de leitura

• Concluir pela contagem. O erro mais frequente pode ser consequência de outro, mais raro.
• Confundir pausa com lentidão. Leia as linhas ao redor.
• Medir uma execução só. Tempos variam, e o log pesa.
• Abrir só o jde.log e procurar tempos. Quem registra chamadas e SQL é o jdedebug.

Limitações

• Só logs fictícios. O app foi testado com logs montados a partir de trechos públicos, nunca com um log de produção. Versões, idiomas e plataformas podem variar: ele avisa quando reconhece menos de 60% das linhas, e nesse caso só procura palavras de erro.
• Detecção por palavras. Pode marcar uma linha normal como erro, ou deixar passar um erro escrito de outro jeito.
• Sem ano. Os logs não trazem o ano, então só dia e hora aparecem.
• Arquivos compactados não são lidos: extraia o .zip antes.
• Tamanho: testamos até 501 MB, lidos em cerca de 10 s em um computador de mesa, com o Chromium. Outros equipamentos variam.
• Navegadores: Firefox, Safari e celulares reais não foram testados.

Revisão rápida

Tente responder antes de abrir cada pergunta.

Referências

1. Giovani Perotto Mesquita, “JDE Log Insights”, app em um único arquivo HTML, giovanipm.github.io/jde-log-insights.html.
2. Oracle, “jde.log”, JD Edwards EnterpriseOne Tools, documentação, consultado em 01/11/2026, docs.oracle.com. A página afirma que o jde.log fica sempre na raiz da unidade principal. A página [3] diz que o local vem de JobFile. Seguimos a [3], mais específica.
3. Oracle, “Troubleshooting the Enterprise Server”, documentação, consultado em 01/11/2026, docs.oracle.com. A página descreve o jde.log do servidor como sobrescrito a cada sessão e, em servidor Windows, como acrescentado ao final.
4. Oracle, “Troubleshooting the Workstation”, documentação, consultado em 01/11/2026, docs.oracle.com.
5. Oracle, “LogParse Output Files for the Enterprise Server”, documentação, consultado em 01/11/2026, docs.oracle.com.
6. Dong's Page, “Case Study: Slow Performance in P4116”, estudo de caso publicado em blog pessoal, consultado em 01/11/2026, sohigh99.github.io.
7. Vincenzo Caserta, “JD Edwards BSFN performance measurement with logs and timings”, artigo técnico; os 2% a 5% e as 10 execuções são recomendações do autor, não da Oracle, consultado em 01/11/2026, vincenzocaserta.it.
8. Oracle, “Oracle Database Error Help”, páginas das mensagens ORA citadas no app, consultado em 01/11/2026, docs.oracle.com/error-help/db.

What JDE Log Insights is

A JD Edwards EnterpriseOne log can have millions of lines, and the answer is usually in a few of them. JDE Log Insights reads these files and shows where to start: it groups errors, measures business functions (BSFN) and SQL, finds pauses and draws what called what. ^[1]

It is a single HTML file, with no installation or account.

Open JDE Log Insights →

How the app handles your data

• Nothing leaves your computer. The file blocks network connections. Logs often contain users, servers and SQL, so this matters.
• The log is not stored. When you close the page, the analysis is gone. The app only stores the language, the theme and the slowness limit.

The JD Edwards logs

Each file answers a different question. Oracle's documentation splits them like this: ^{[2] [3] [4]}

The number in the name is the process ID, so a server produces several files. Open those of the same process together: the app reads them all at once and says what it identified in each.

How to get the logs

The location of jde.log and jdedebug.log comes from JobFile and DebugFile, in the [DEBUG] section of jde.ini. ^[3] jdedebug only holds calls, SQL and timing with debugging on:

[DEBUG]
Output=FILE
LogErrors=1

1. Turn debugging on where it counts. To reproduce the problem, isolate a single kernel or process, so the logs do not mix. ^[7]
2. Reproduce the problem once and copy the files. They may be overwritten in the next session: Oracle describes both behaviors, overwrite and append, depending on the server and workstation. ^{[3] [4]}
3. Set Output back to its previous value. The log grows fast and weighs on the process: one author estimates 2% to 5% more time. ^[7]

UBE logs are in the print queue (PrintQueue), and the detail level comes from UBEDebugLevel, in the [UBE] section. ^[3]

Walkthrough: investigating the sample

Use the sample data: it is made up, built from public log excerpts, and the results below are what you will see. The case has it all: a lost database connection, a huge read and a slow SQL.

1. Open the sample and read the first insight

1. Open the app and click See a sample.
2. Check the totals at the top: 8,693 lines, 62 error occurrences across 7 types, 124 BSFN calls and 123 SQL statements.
3. Read the first card, marked Critical: The database was out of reach. ORA-03113 appeared 22 times, from Mar 12 09:17:00 to Mar 12 09:17:42.

2. Open the error and see the original line

1. On the first card, click See the errors. The Errors tab opens already filtered.
2. Click the ORA-03113 message. The detail has what the source says about the error, with a link to it.
3. Under Sample occurrences, click View in log to check the original passage, with the line marked.

Back on the insights, another card says JDB9900401 is usually a consequence of ORA-03113. There were 22 occurrences, always up to 1 second later, on the same thread. So the investigation starts with ORA-03113.

3. Find where the time went

1. Open the BSFN tab. The table comes sorted by Own time.
2. F4111EndDocument took 9.13 s in total, of which 7.41 s is its own time. So the time is not in the functions it calls.

4. Find the SQL responsible

1. Open the SQL tab. The first statement is a read of F0005, with no WHERE, of about 7.4 s.
2. See the other two signals: a read of F41021 returned 4,000 rows, and the statement on F4101 ran 120 times.

5. See the path on the map

1. Open the Flow tab and click the F41021 block.
2. The map highlights the path: P4116 calls F4111EndDocument, which calls AverageCostUpdate, which reads F41021. Now you know which screen leads to this read.

6. Create the report

1. Click Report and tick Hide users, servers, IPs, paths and quoted values.
2. Review the text and use Copy or Download .md.

Result: in a few minutes you have a hypothesis for each problem. Database connection lost at 09:17, with one error that is a consequence of another; a read with no filter; and a function called 120 times. It remains to confirm each with the DBA and with whoever knows the code.

How to read the insights

The cards are simple rules on the log's figures, and these are the exact conditions. A signal is not a cause: it says where to look.

Below the cards, two charts show errors and log lines over time. Click an error bar to see only that interval's errors. View as table has the same figures in a table.

Errors

The app groups messages that differ only in their values, so the same error with different numbers counts as one. Filter by Level and Area, or type a fragment, such as a table name.

• Fatal, Error and Warning come from codes and words in the message, such as ORA-00942, OCI0000178 and failed.
• What the source says: the app has a small base, only with Oracle's texts, each with a link to the source. ^{[3] [4] [8]}
• Code outside the base: look it up in My Oracle Support or in the P92002 application, which holds the system's error messages. ^[4]

BSFN

The app matches each call to its return, by thread, and computes two times:

• Total time: from call to return, including the functions it calls.
• Own time: the total minus the time of child functions. This is where to look first. ^[7]
• Return ≠ 0: calls that returned a value other than 0. The app only counts them; check how the caller handles this return.

SQL

The app removes values, to group identical statements, and adds up runs, rows read and time. This way, customer values are not kept in the table.

• Rows read: counts the "Fetched the record" lines after each statement. A P4116 case study shows this pattern: 40,000 rows read in a single function call. ^[6]
• Approx. time: runs from the statement to the last fetch, so it includes what the application did between fetches.
• Hint: a long interval between the statement and the first fetch tends to point to the database rather than the logic. ^[7]

Pauses

A pause is the time without new lines in the same process and thread. Oracle suggests jdedebug precisely to see the point where normal execution stopped. ^[3] Each table row shows what came before and after.

Context

The Context tab answers "what was running?": files read and the kind of each, applications and reports, tables, processes and threads, and the most frequent API calls.

Flow

The Flow tab draws who calls whom, adding up all runs: entry, BSFN by level, tables and errors in sequence. On a plain jde.log, it shows process → error → next error.

• The thicker the link, the more often it occurred.
• ⏱ marks what went over the slowness limit, and a dashed line, a loop back, such as recursion.
• When you click a block, its path is highlighted and Open details leads to the detail.
• On a BSFN, Parameters shows each parameter's input and output side by side, from the IN-> and OUT-> lines, in up to five calls: the first, the slowest and those that returned a value other than 0. ≠ marks what changed.
• View the links as a table has the same links as text, and Download SVG saves the image.

Content

The Content tab shows the whole log, line by line, with a color and a tag for each event type: errors, returns other than 0, BSFN, SQL, row fetches, parameters, API and UBE. Use it when the summaries have told you where to look and you want to read what happened around it.

• Filter: click a type to see only its lines. Clicking another adds it, and Show all undoes it.
• Pauses: ⏸ marks the line that came after a pause over the limit.
• Navigate: use the search, Go to line, Next error ▶ and the arrow keys. In View in log, the Open in Content button brings you here.
• Copy: lines over 2,000 characters are cut on screen, and Copy brings the full text.

Report and privacy

Report creates a Markdown text with the insights and the main figures, to attach to a ticket. Before sending it to someone or to an AI, tick Hide users, servers, IPs, paths and quoted values.

Document, in the top menu, puts every tab except Content on one page, without the on-screen filters, and opens the browser's print window. Choose "Save as PDF" as the destination to keep the analysis. Unlike the report, the PDF hides nothing: the values appear as they are in the log.

New goes back to the start screen and clears the current analysis from memory, so you can open another log. The files on your computer do not change. To keep the result, use Document first.

A method for a real log

With a real problem, this order avoids wasted time:

1. Start with jde.log. If there is a severe failure or a lost connection, solve that before measuring performance.
2. Reproduce with debugging in a single process, and open the jdedebug.
3. Follow the time: BSFN by own time, then SQL and Pauses.
4. Confirm on the original line with View in log and with whoever knows the code and the database.
5. Fix and measure again. One author suggests 10 or more runs and using the median, because a single run misleads. ^[7]

For very large logs or official analysis, Oracle offers LogParse, in the Server Manager Performance Workbench, which creates a summary, CSV files of BSFN and tables, and timing gaps. ^[5] JDE Log Insights is a quick alternative, with no server, not a replacement.

AI prompts

With the signals in hand, you still have to interpret them: what this code means, which error came first, what to ask the DBA. An AI helps organize hypotheses and prepare the conversation. It also makes confident mistakes: it invents causes, cites support notes that do not exist and assumes how your customization works. Treat its output as a draft from a colleague in a hurry. To write better prompts, see the prompt tutorial.

Before pasting: logs may hold users, servers, SQL and customer values. The app sends nothing over the network, but the AI service receives whatever you paste into it. Use Hide users, servers, IPs, paths and quoted values, review the text and follow your organization's AI policy.

Replace the parts in brackets and paste into the AI tool you use. The prompts follow the order of the investigation, but each one works on its own.

1. Prioritize what the report shows

In Report, tick Hide users, servers, IPs, paths and quoted values, use Copy and paste the text at the end of the prompt.

You are an analyst experienced in JD Edwards EnterpriseOne.
Below is the report from a tool that reads the system's logs.

Problem context: [what the user saw, when, in which application]

Based only on the report:
1. List 3 to 5 hypotheses, from most to least likely.
2. For each, cite the figure or line of the report that supports it and say what would rule it out.
3. Say what I should look at first and who on the team can confirm it.
4. Separate what is fact in the report from what is your assumption.

Do not invent codes, tables, support notes or features of my environment. If data is missing, say which.

Report:
[paste the report]

2. Explain an error

Open the error in the Errors tab and use View in log to copy the message and the surrounding lines, replacing sensitive data. Then compare the answer with what Oracle says about the code. ^[8]

Explain this error from a JD Edwards EnterpriseOne log to a non-specialist.

System and database version: [e.g. Tools 9.2, Oracle, or "I don't know"]
What was being done: [application, UBE or action]

Message and surrounding lines:
[paste the passage]

Answer:
1. What the message says, in plain language.
2. Possible causes, with what confirms or rules out each one.
3. Where to check and who usually checks it.
4. Which parts of your answer come from documentation and which are deduction. If you do not know the code, say so instead of guessing.

3. Separate cause from consequence

In the Errors tab, use Download CSV and paste the table. Before pasting, replace users, servers and values, because the CSV does not hide data. The prompt asks the AI to say what to open in the log to confirm each link.

The table below lists the grouped errors of a JD Edwards EnterpriseOne log, with count, first and last occurrence.

Identify:
1. Which errors seem to be the origin and which seem to be consequences, using the order in time and the type of message.
2. Errors that occurred in the same period and may share a cause.
3. Which error to start with, and why.

The table does not show the thread or the full text. Say what I need to open in the log to confirm each link. Do not treat coincidence in time as proof.

Table:
[paste the CSV]

4. Understand where a BSFN spends time

In the BSFN tab, use Download CSV and paste the table. In wall-clock time, the difference between total and own points to where to go down. ^[7]

The table below has the business functions (BSFN) measured in a JD Edwards EnterpriseOne jdedebug: calls, total time, own time, average, maximum and returns other than 0. Times are wall-clock, with logging on.

Measured scenario: [what was run, and how many times]
Time the user perceived: [e.g. 40 s]

1. Which functions deserve attention first, and why.
2. Where total time is much larger than own time, and what that indicates.
3. Signs of calls repeated too often.
4. What to ask whoever knows the code.

Do not say what a function does internally unless I tell you. If a name suggests something, mark it as an assumption.

Table:
[paste the CSV]

5. Analyze a SQL

Open the statement in the SQL tab and use Copy: the text comes without values. Add the row's columns, such as runs and rows read. ^[7]

Analyze this SQL from a JD Edwards EnterpriseOne log. Values were removed.

Statement:
[paste the statement]

Runs: [number]
Rows read: [number]
Approximate time (includes what the application did between fetches): [time]
Database: [e.g. Oracle, SQL Server]
Table size: [rows, or "I don't know"]

Answer:
1. What stands out: repetition, volume, missing filter.
2. What to ask the DBA to confirm, such as the execution plan and existing indexes.
3. Two or three improvements to evaluate in the application and the database, with the risk of each.

Do not invent index or column names. Do not recommend changing standard JD Edwards tables without stating the impact.

6. Interpret a pause

Open the pause in the Pauses tab and copy the lines before and after, replacing sensitive data. The answer should say what is missing to decide, not just guess.

In a JD Edwards EnterpriseOne log, there was a pause of [time] on the same thread.

Last line before:
[paste]

First line after:
[paste]

How the log was created: [e.g. user on the screen, UBE, automatic load]

List what could explain this pause, such as unlogged work, a database or network wait, or no user activity. For each explanation, say what to observe to confirm or rule it out. If the lines do not allow a decision, say so.

7. Plan the next measurement

Asks for a short plan to reproduce and compare, following this tutorial's method. Review any change to jde.ini with whoever runs the server. ^{[3] [7]}

I want to measure a performance problem in JD Edwards EnterpriseOne and compare before and after a fix.

Problem: [what is slow]
Environment available for testing: [e.g. QA, an isolated kernel]
What I already know: [paste the main findings]

Build a short plan:
1. How to reproduce the same scenario, always the same way.
2. Which logs to collect and how to isolate the process, so they do not mix.
3. How many runs to do and how to compare them, using the median.
4. What can distort the measurement, such as the log itself, the cache and other users.
5. How to undo the debug settings when finished.

Mark what needs confirmation from the system administrator. If you are not sure of a parameter name, say so.

8. Write the ticket

Separates facts from hypotheses, so the ticket does not state what nobody has proved. If the AI cites a support document, check that it exists.

Write a ticket for [DBA, development or support] from the report below.

What happened for the user: [describe]
Impact: [who was affected, since when]
What was already tried: [describe]

Structure:
1. Two-sentence summary.
2. Observed facts, with times and figures from the report.
3. Hypotheses, marked as hypotheses.
4. What I am asking to be checked.
5. Attachments to send.

Do not add facts, causes or deadlines. Keep the hidden parts as they are.

Report:
[paste the report]

How to check the answer

Common mistakes and limitations

Reading mistakes

• Concluding from the count. The most frequent error may be a consequence of a rarer one.
• Confusing a pause with slowness. Read the surrounding lines.
• Measuring a single run. Times vary, and the log weighs.
• Opening only jde.log and looking for times. jdedebug is the one that records calls and SQL.

Limitations

• Made-up logs only. The app was tested with logs built from public excerpts, never with a production log. Versions, languages and platforms may vary: it warns when it recognizes under 60% of the lines, and then only searches for error words.
• Detection by words. It may flag a normal line as an error, or miss an error worded differently.
• No year. Logs do not include the year, so only day and time appear.
• Compressed files are not read: extract the .zip first.
• Size: we tested up to 501 MB, read in about 10 s on a desktop computer, in Chromium. Other machines vary.
• Browsers: Firefox, Safari and real phones were not tested.

Quick review

Try to answer before opening each question.

References

1. Giovani Perotto Mesquita, “JDE Log Insights”, single-file HTML app, giovanipm.github.io/jde-log-insights.html.
2. Oracle, “jde.log”, JD Edwards EnterpriseOne Tools, documentation, accessed 1 November 2026, docs.oracle.com. This page says jde.log is always in the root of the primary drive. Page [3] says the location comes from JobFile. We follow [3], which is more specific.
3. Oracle, “Troubleshooting the Enterprise Server”, documentation, accessed 1 November 2026, docs.oracle.com. This page describes the server jde.log as overwritten each session and, on a Windows server, as appended.
4. Oracle, “Troubleshooting the Workstation”, documentation, accessed 1 November 2026, docs.oracle.com.
5. Oracle, “LogParse Output Files for the Enterprise Server”, documentation, accessed 1 November 2026, docs.oracle.com.
6. Dong's Page, “Case Study: Slow Performance in P4116”, case study on a personal blog, accessed 1 November 2026, sohigh99.github.io.
7. Vincenzo Caserta, “JD Edwards BSFN performance measurement with logs and timings”, technical article; the 2% to 5% and the 10 runs are the author's advice, not Oracle's, accessed 1 November 2026, vincenzocaserta.it.
8. Oracle, “Oracle Database Error Help”, pages of the ORA messages cited in the app, accessed 1 November 2026, docs.oracle.com/error-help/db.

Che cos'è JDE Log Insights

Un log di JD Edwards EnterpriseOne può avere milioni di righe, e la risposta di solito è in poche di esse. JDE Log Insights legge questi file e mostra da dove iniziare: raggruppa gli errori, misura le funzioni di business (BSFN) e gli SQL, trova le pause e disegna cosa ha chiamato cosa. ^[1]

È un unico file HTML, senza installazione né account.

Apri JDE Log Insights →

Come l'app tratta i tuoi dati

• Nulla esce dal tuo computer. Il file blocca le connessioni di rete. I log contengono spesso utenti, server e SQL, quindi è importante.
• Il log non viene conservato. Chiudendo la pagina, l'analisi sparisce. L'app conserva solo lingua, tema e limite di lentezza.

I log di JD Edwards

Ogni file risponde a una domanda diversa. La documentazione di Oracle li distingue così: ^{[2] [3] [4]}

Il numero nel nome è l'ID del processo, quindi un server genera più file. Apri insieme quelli dello stesso processo: l'app li legge tutti insieme e indica cosa ha identificato in ciascuno.

Come ottenere i log

La posizione di jde.log e jdedebug.log dipende da JobFile e DebugFile, nella sezione [DEBUG] di jde.ini. ^[3] jdedebug contiene chiamate, SQL e tempi solo con il debug attivo:

[DEBUG]
Output=FILE
LogErrors=1

1. Attiva il debug dove serve. Per riprodurre il problema, isola un solo kernel o processo, così i log non si mescolano. ^[7]
2. Riproduci il problema una volta e copia i file. Possono essere sovrascritti nella sessione seguente: Oracle descrive entrambi i comportamenti, sovrascrivere e accodare, secondo il server e la postazione. ^{[3] [4]}
3. Riporta Output al valore precedente. Il log cresce in fretta e pesa sul processo: un autore stima dal 2% al 5% di tempo in più. ^[7]

I log di UBE sono nella coda di stampa (PrintQueue), e il livello di dettaglio dipende da UBEDebugLevel, nella sezione [UBE]. ^[3]

Percorso: indagare sull'esempio

Usa i dati di esempio: sono fittizi, costruiti da estratti pubblici di log, e i risultati qui sotto sono quelli che vedrai. Il caso ha di tutto: una connessione persa con il database, una lettura enorme e un SQL lento.

1. Apri l'esempio e leggi il primo insight

1. Apri l'app e fai clic su Vedi un esempio.
2. Controlla i totali in alto: 8693 righe, 62 occorrenze di errore in 7 tipi, 124 chiamate BSFN e 123 istruzioni SQL.
3. Leggi la prima scheda, segnata come Critico: Il database non era raggiungibile. ORA-03113 è apparso 22 volte, da 12 mar 09:17:00 a 12 mar 09:17:42.

2. Apri l'errore e guarda la riga originale

1. Sulla prima scheda, fai clic su Vedi gli errori. La scheda Errori si apre già filtrata.
2. Fai clic sul messaggio di ORA-03113. Il dettaglio riporta cosa dice la fonte sull'errore, con il collegamento.
3. In Occorrenze di esempio, fai clic su Vedi nel log per controllare il brano originale, con la riga segnata.

Tornando agli insight, un'altra scheda dice che JDB9900401 è di solito una conseguenza di ORA-03113. Ci sono state 22 occorrenze, sempre entro 1 secondo, nello stesso thread. Per questo l'indagine parte da ORA-03113.

3. Cerca dove è finito il tempo

1. Apri la scheda BSFN. La tabella è ordinata per Tempo proprio.
2. F4111EndDocument ha impiegato 9,13 s in totale, di cui 7,41 s di tempo proprio. Quindi il tempo non è nelle funzioni che chiama.

4. Trova l'SQL responsabile

1. Apri la scheda SQL. La prima istruzione è una lettura di F0005, senza WHERE, di circa 7,4 s.
2. Guarda gli altri due segnali: una lettura di F41021 ha restituito 4000 righe, e l'istruzione su F4101 è stata eseguita 120 volte.

5. Guarda il percorso sulla mappa

1. Apri la scheda Flusso e fai clic sul blocco F41021.
2. La mappa evidenzia il percorso: P4116 chiama F4111EndDocument, che chiama AverageCostUpdate, che legge F41021. Ora sai quale schermata porta a questa lettura.

6. Crea il report

1. Fai clic su Report e seleziona Nascondi utenti, server, IP, percorsi e valori tra virgolette.
2. Rivedi il testo e usa Copia o Scarica .md.

Risultato: in pochi minuti hai un'ipotesi per ogni problema. Connessione al database persa alle 09:17, con un errore conseguenza di un altro; una lettura senza filtro; e una funzione chiamata 120 volte. Resta da confermare ciascuna con il DBA e con chi conosce il codice.

Come leggere gli insight

Le schede sono regole semplici sui numeri del log, e queste sono le condizioni esatte. Un segnale non è una causa: indica dove guardare.

Sotto le schede, due grafici mostrano errori e righe di log nel tempo. Fai clic su una barra di errore per vedere solo gli errori di quell'intervallo. Vedi come tabella riporta gli stessi numeri in tabella.

Errori

L'app raggruppa i messaggi che cambiano solo nei valori, quindi lo stesso errore con numeri diversi conta come uno solo. Filtra per Livello e Area, o digita una parte, come il nome di una tabella.

• Fatale, Errore e Avviso derivano da codici e parole del messaggio, come ORA-00942, OCI0000178 e failed.
• Cosa dice la fonte: l'app ha una piccola base, solo con testi di Oracle, ciascuno con il collegamento alla fonte. ^{[3] [4] [8]}
• Codice fuori dalla base: cercalo in My Oracle Support o nell'applicazione P92002, che contiene i messaggi di errore del sistema. ^[4]

BSFN

L'app abbina ogni chiamata al suo ritorno, per thread, e calcola due tempi:

• Tempo totale: dalla chiamata al ritorno, incluse le funzioni che chiama.
• Tempo proprio: il totale meno il tempo delle funzioni figlie. È qui che devi guardare prima. ^[7]
• Ritorno ≠ 0: chiamate che hanno restituito un valore diverso da 0. L'app le conta soltanto; verifica come il chiamante gestisce il ritorno.

SQL

L'app rimuove i valori, per unire le istruzioni uguali, e somma esecuzioni, righe lette e tempo. Così i valori dei clienti non restano nella tabella.

• Righe lette: conta le righe "Fetched the record" dopo ogni istruzione. Un caso di studio su P4116 mostra questo schema: 40.000 righe lette in una sola chiamata di funzione. ^[6]
• Tempo appross.: va dall'istruzione all'ultima lettura, quindi include ciò che l'applicazione ha fatto tra le letture.
• Indizio: un intervallo lungo tra l'istruzione e la prima lettura indica di solito il database più che la logica. ^[7]

Pause

La pausa è il tempo senza nuove righe nello stesso processo e thread. Oracle suggerisce jdedebug proprio per vedere il punto in cui l'esecuzione normale si è fermata. ^[3] Ogni riga della tabella mostra cosa è venuto prima e dopo.

Contesto

La scheda Contesto risponde a "cosa stava girando?": file letti e tipo di ciascuno, applicazioni e report, tabelle, processi e thread, e le chiamate API più frequenti.

Flusso

La scheda Flusso disegna chi chiama chi, sommando tutte le esecuzioni: ingresso, BSFN per livello, tabelle ed errori in sequenza. In un jde.log puro, mostra processo → errore → errore seguente.

• Più il collegamento è spesso, più volte si è verificato.
• ⏱ segna ciò che ha superato il limite di lentezza, e la linea tratteggiata, un ritorno, come la ricorsione.
• Facendo clic su un blocco, il suo percorso è evidenziato e Apri dettagli porta al dettaglio.
• Su una BSFN, Parametri mostra affiancati ingresso e uscita di ogni parametro, dalle righe IN-> e OUT->, in fino a cinque chiamate: la prima, la più lenta e quelle che hanno restituito un valore diverso da 0. ≠ segna ciò che è cambiato.
• Vedi i collegamenti come tabella riporta gli stessi collegamenti in testo, e Scarica SVG salva l'immagine.

Contenuto

La scheda Contenuto mostra l'intero log, riga per riga, con un colore e un'etichetta per ogni tipo di evento: errori, ritorni diversi da 0, BSFN, SQL, lettura di righe, parametri, API e UBE. Usala quando i riepiloghi ti hanno già detto dove guardare e vuoi leggere cosa è successo intorno.

• Filtrare: fai clic su un tipo per vedere solo le sue righe. Facendo clic su un altro si somma, e Mostra tutto annulla.
• Pause: ⏸ segna la riga venuta dopo una pausa oltre il limite.
• Navigare: usa la ricerca, Vai alla riga, Errore successivo ▶ e le frecce. In Vedi nel log, il pulsante Apri in Contenuto ti porta qui.
• Copiare: le righe oltre 2.000 caratteri sono tagliate sullo schermo, e Copia porta il testo intero.

Report e privacy

Report crea un testo in Markdown con gli insight e i numeri principali, da allegare a un ticket. Prima di inviarlo a qualcuno o a un'IA, seleziona Nascondi utenti, server, IP, percorsi e valori tra virgolette.

Documenta, nel menu in alto, riunisce in una pagina tutte le schede tranne Contenuto, senza i filtri dello schermo, e apre la finestra di stampa del browser. Scegli "Salva come PDF" come destinazione per conservare l'analisi. A differenza del report, il PDF non nasconde nulla: i valori appaiono come sono nel log.

Nuovo torna alla schermata iniziale e toglie l'analisi attuale dalla memoria, per aprire un altro log. I file sul tuo computer non cambiano. Per conservare il risultato, usa prima Documenta.

Un metodo per il log reale

Con un problema reale, quest'ordine evita perdite di tempo:

1. Inizia dal jde.log. Se c'è un guasto grave o una connessione persa, risolvili prima di misurare le prestazioni.
2. Riproduci con il debug in un solo processo, e apri il jdedebug.
3. Segui il tempo: BSFN per tempo proprio, poi SQL e Pause.
4. Conferma sulla riga originale con Vedi nel log e con chi conosce codice e database.
5. Correggi e misura di nuovo. Un autore suggerisce 10 o più esecuzioni e di usare la mediana, perché una sola inganna. ^[7]

Per log molto grandi o per l'analisi ufficiale, Oracle offre LogParse, nel Performance Workbench di Server Manager, che genera riepilogo, CSV di BSFN e tabelle, e pause. ^[5] JDE Log Insights è un'alternativa rapida, senza server, non un sostituto.

Prompt di IA

Con i segnali in mano, resta da interpretarli: cosa significa questo codice, quale errore è venuto prima, cosa chiedere al DBA. Un'IA aiuta a organizzare le ipotesi e a preparare la conversazione. Sbaglia anche con sicurezza: inventa cause, cita note di supporto che non esistono e suppone come sia la tua personalizzazione. Tratta il risultato come la bozza di un collega di fretta. Per scrivere prompt migliori, vedi il tutorial sui prompt.

Prima di incollare: i log possono contenere utenti, server, SQL e valori di clienti. L'app non invia nulla in rete, ma il servizio di IA riceve tutto ciò che incolli. Usa Nascondi utenti, server, IP, percorsi e valori tra virgolette, rivedi il testo e segui la politica della tua organizzazione sull'uso dell'IA.

Sostituisci le parti tra parentesi quadre e incolla nello strumento di IA che usi. I prompt seguono l'ordine dell'indagine, ma ciascuno funziona da solo.

1. Dare priorità a ciò che mostra il report

In Report, seleziona Nascondi utenti, server, IP, percorsi e valori tra virgolette, usa Copia e incolla il testo alla fine del prompt.

Sei un analista esperto di JD Edwards EnterpriseOne.
Qui sotto c'è il report di uno strumento che legge i log del sistema.

Contesto del problema: [cosa ha visto l'utente, quando, in quale applicazione]

Basandoti solo sul report:
1. Elenca da 3 a 5 ipotesi, dalla più alla meno probabile.
2. Per ciascuna, cita il numero o la riga del report che la sostiene e di' cosa la smentirebbe.
3. Di' cosa devo guardare prima e chi nel team può confermare.
4. Separa ciò che è un fatto nel report da ciò che è una tua supposizione.

Non inventare codici, tabelle, note di supporto né caratteristiche del mio ambiente. Se manca un dato, di' quale.

Report:
[incolla il report]

2. Spiegare un errore

Apri l'errore nella scheda Errori e usa Vedi nel log per copiare il messaggio e le righe intorno, sostituendo i dati sensibili. Poi confronta la risposta con ciò che dice Oracle sul codice. ^[8]

Spiega questo errore di un log di JD Edwards EnterpriseOne a chi non è specialista.

Versione del sistema e del database: [es.: Tools 9.2, Oracle, o "non lo so"]
Cosa si stava facendo: [applicazione, UBE o azione]

Messaggio e righe intorno:
[incolla il brano]

Rispondi:
1. Cosa dice il messaggio, in parole semplici.
2. Cause possibili, con ciò che conferma o esclude ciascuna.
3. Dove verificare e chi di solito verifica.
4. Quali parti della risposta vengono dalla documentazione e quali sono deduzioni. Se non conosci il codice, dillo invece di indovinare.

3. Separare causa e conseguenza

Nella scheda Errori, usa Scarica CSV e incolla la tabella. Prima di incollare, sostituisci utenti, server e valori, perché il CSV non nasconde i dati. Il prompt chiede all'IA di dire cosa aprire nel log per confermare ogni collegamento.

La tabella qui sotto elenca gli errori raggruppati di un log di JD Edwards EnterpriseOne, con conteggio, prima e ultima occorrenza.

Identifica:
1. Quali errori sembrano l'origine e quali conseguenze, usando l'ordine nel tempo e il tipo di messaggio.
2. Errori avvenuti nello stesso periodo che possono avere la stessa causa.
3. Da quale errore iniziare, e perché.

La tabella non mostra il thread né il testo completo. Di' cosa devo aprire nel log per confermare ogni collegamento. Non trattare la coincidenza nel tempo come una prova.

Tabella:
[incolla il CSV]

4. Capire dove una BSFN spende tempo

Nella scheda BSFN, usa Scarica CSV e incolla la tabella. In tempo reale, la differenza tra totale e proprio indica dove scendere. ^[7]

La tabella qui sotto riporta le funzioni di business (BSFN) misurate in un jdedebug di JD Edwards EnterpriseOne: chiamate, tempo totale, tempo proprio, media, massimo e ritorni diversi da 0. I tempi sono reali, con il log attivo.

Scenario misurato: [cosa è stato eseguito, e quante volte]
Tempo percepito dall'utente: [es.: 40 s]

1. Quali funzioni meritano attenzione prima, e perché.
2. Dove il tempo totale è molto maggiore di quello proprio, e cosa indica.
3. Segni di chiamate ripetute troppo.
4. Quali domande fare a chi conosce il codice.

Non dire cosa fa una funzione all'interno, a meno che io lo indichi. Se un nome suggerisce qualcosa, segnalo come supposizione.

Tabella:
[incolla il CSV]

5. Analizzare un SQL

Apri l'istruzione nella scheda SQL e usa Copia: il testo arriva senza i valori. Aggiungi le colonne della riga, come esecuzioni e righe lette. ^[7]

Analizza questo SQL di un log di JD Edwards EnterpriseOne. I valori sono stati rimossi.

Istruzione:
[incolla l'istruzione]

Esecuzioni: [numero]
Righe lette: [numero]
Tempo approssimato (include ciò che l'applicazione ha fatto tra le letture): [tempo]
Database: [es.: Oracle, SQL Server]
Dimensione della tabella: [righe, o "non lo so"]

Rispondi:
1. Cosa salta all'occhio: ripetizione, volume, filtro mancante.
2. Cosa chiedere al DBA di confermare, come il piano di esecuzione e gli indici esistenti.
3. Due o tre miglioramenti da valutare nell'applicazione e nel database, con il rischio di ciascuno.

Non inventare nomi di indici o colonne. Non raccomandare di modificare le tabelle standard di JD Edwards senza indicare l'impatto.

6. Interpretare una pausa

Apri la pausa nella scheda Pause e copia le righe prima e dopo, sostituendo i dati sensibili. La risposta deve dire cosa manca per decidere, non solo tirare a indovinare.

In un log di JD Edwards EnterpriseOne, c'è stata una pausa di [tempo] nello stesso thread.

Ultima riga prima:
[incolla]

Prima riga dopo:
[incolla]

Come è stato generato il log: [es.: utente sulla schermata, UBE, carico automatico]

Elenca cosa può spiegare questa pausa, come lavoro non registrato, attesa di database o rete, o inattività dell'utente. Per ogni spiegazione, di' cosa osservare per confermarla o escluderla. Se le righe non permettono di decidere, dillo.

7. Pianificare la prossima misura

Chiede un piano breve per riprodurre e confrontare, seguendo il metodo di questo tutorial. Rivedi ogni modifica a jde.ini con chi amministra il server. ^{[3] [7]}

Voglio misurare un problema di prestazioni in JD Edwards EnterpriseOne e confrontare prima e dopo una correzione.

Problema: [cosa è lento]
Ambiente disponibile per il test: [es.: collaudo, un kernel isolato]
Cosa so già: [incolla i risultati principali]

Prepara un piano breve:
1. Come riprodurre lo stesso scenario, sempre uguale.
2. Quali log raccogliere e come isolare il processo, perché non si mescolino.
3. Quante esecuzioni fare e come confrontarle, usando la mediana.
4. Cosa può falsare la misura, come il log stesso, la cache e altri utenti.
5. Come annullare le impostazioni di debug alla fine.

Segnala cosa richiede conferma dall'amministratore di sistema. Se non sei sicuro del nome di un parametro, dillo.

8. Scrivere il ticket

Separa fatti e ipotesi, perché il ticket non affermi ciò che nessuno ha provato. Se l'IA cita un documento di supporto, verifica che esista.

Scrivi un ticket per [DBA, sviluppo o supporto] a partire dal report qui sotto.

Cosa è successo per l'utente: [descrivi]
Impatto: [chi è stato colpito, da quando]
Cosa è già stato provato: [descrivi]

Struttura:
1. Riepilogo in due frasi.
2. Fatti osservati, con orari e numeri del report.
3. Ipotesi, segnate come ipotesi.
4. Cosa chiedo di verificare.
5. Allegati da inviare.

Non aggiungere fatti, cause né scadenze. Mantieni le parti nascoste così come sono.

Report:
[incolla il report]

Come controllare la risposta

Errori comuni e limiti

Errori di lettura

• Concludere dal conteggio. L'errore più frequente può essere conseguenza di uno più raro.
• Confondere pausa e lentezza. Leggi le righe intorno.
• Misurare una sola esecuzione. I tempi variano, e il log pesa.
• Aprire solo il jde.log e cercare i tempi. Chiamate e SQL sono registrati dal jdedebug.

Limiti

• Solo log fittizi. L'app è stata provata con log costruiti da estratti pubblici, mai con un log di produzione. Versioni, lingue e piattaforme possono variare: avvisa quando riconosce meno del 60% delle righe, e allora cerca solo parole di errore.
• Rilevamento per parole. Può segnalare una riga normale come errore, o non vedere un errore scritto in altro modo.
• Senza anno. I log non riportano l'anno, quindi appaiono solo giorno e ora.
• I file compressi non vengono letti: estrai prima lo .zip.
• Dimensione: abbiamo provato fino a 501 MB, letti in circa 10 s su un computer fisso, in Chromium. Altre macchine variano.
• Browser: Firefox, Safari e telefoni reali non sono stati provati.

Ripasso rapido

Prova a rispondere prima di aprire ogni domanda.

Riferimenti

1. Giovani Perotto Mesquita, “JDE Log Insights”, app in un unico file HTML, giovanipm.github.io/jde-log-insights.html.
2. Oracle, “jde.log”, JD Edwards EnterpriseOne Tools, documentazione, consultato il 01/11/2026, docs.oracle.com. Questa pagina afferma che jde.log è sempre nella radice dell'unità principale. La pagina [3] dice che la posizione dipende da JobFile. Seguiamo la [3], più specifica.
3. Oracle, “Troubleshooting the Enterprise Server”, documentazione, consultato il 01/11/2026, docs.oracle.com. Questa pagina descrive il jde.log del server come sovrascritto a ogni sessione e, su server Windows, come accodato.
4. Oracle, “Troubleshooting the Workstation”, documentazione, consultato il 01/11/2026, docs.oracle.com.
5. Oracle, “LogParse Output Files for the Enterprise Server”, documentazione, consultato il 01/11/2026, docs.oracle.com.
6. Dong's Page, “Case Study: Slow Performance in P4116”, caso di studio su un blog personale, consultato il 01/11/2026, sohigh99.github.io.
7. Vincenzo Caserta, “JD Edwards BSFN performance measurement with logs and timings”, articolo tecnico; il 2-5% e le 10 esecuzioni sono consigli dell'autore, non di Oracle, consultato il 01/11/2026, vincenzocaserta.it.
8. Oracle, “Oracle Database Error Help”, pagine dei messaggi ORA citati nell'app, consultato il 01/11/2026, docs.oracle.com/error-help/db.

Qué es JDE Log Insights

Un log de JD Edwards EnterpriseOne puede tener millones de líneas, y la respuesta suele estar en unas pocas. JDE Log Insights lee estos archivos y muestra por dónde empezar: agrupa los errores, mide las funciones de negocio (BSFN) y el SQL, encuentra pausas y dibuja qué llamó a qué. ^[1]

Es un único archivo HTML, sin instalación ni cuenta.

Abrir JDE Log Insights →

Cómo trata la aplicación tus datos

• Nada sale de tu ordenador. El archivo bloquea las conexiones de red. Los logs suelen traer usuarios, servidores y SQL, así que esto importa.
• El log no se guarda. Al cerrar la página, el análisis desaparece. La aplicación solo guarda el idioma, el tema y el límite de lentitud.

Los logs de JD Edwards

Cada archivo responde a una pregunta distinta. La documentación de Oracle los separa así: ^{[2] [3] [4]}

El número del nombre es el ID del proceso, así que un servidor genera varios archivos. Abre juntos los del mismo proceso: la aplicación los lee todos a la vez e indica qué identificó en cada uno.

Cómo obtener los logs

La ubicación de jde.log y jdedebug.log viene de JobFile y DebugFile, en la sección [DEBUG] de jde.ini. ^[3] jdedebug solo trae llamadas, SQL y tiempos con la depuración activa:

[DEBUG]
Output=FILE
LogErrors=1

1. Activa la depuración donde haga falta. Para reproducir el problema, aísla un solo kernel o proceso, para que los logs no se mezclen. ^[7]
2. Reproduce el problema una vez y copia los archivos. Pueden sobrescribirse en la sesión siguiente: Oracle describe los dos comportamientos, sobrescribir y añadir, según el servidor y la estación. ^{[3] [4]}
3. Vuelve Output al valor anterior. El log crece rápido y pesa en el proceso: un autor estima entre un 2% y un 5% más de tiempo. ^[7]

Los logs de UBE están en la cola de impresión (PrintQueue), y el nivel de detalle viene de UBEDebugLevel, en la sección [UBE]. ^[3]

Recorrido: investigar el ejemplo

Usa los datos de ejemplo: son ficticios, creados a partir de fragmentos públicos de log, y los resultados de abajo son los que verás. El caso lo tiene todo: una conexión perdida con la base de datos, una lectura enorme y un SQL lento.

1. Abre el ejemplo y lee el primer insight

1. Abre la aplicación y haz clic en Ver un ejemplo.
2. Mira los totales de arriba: 8693 líneas, 62 ocurrencias de error en 7 tipos, 124 llamadas de BSFN y 123 sentencias SQL.
3. Lee la primera tarjeta, marcada como Crítico: La base de datos quedó fuera de alcance. ORA-03113 apareció 22 veces, de 12 mar 09:17:00 a 12 mar 09:17:42.

2. Abre el error y mira la línea original

1. En la primera tarjeta, haz clic en Ver los errores. La pestaña Errores se abre ya filtrada.
2. Haz clic en el mensaje de ORA-03113. El detalle trae lo que dice la fuente sobre el error, con el enlace.
3. En Ocurrencias de ejemplo, haz clic en Ver en el log para comprobar el fragmento original, con la línea marcada.

De vuelta en los insights, otra tarjeta dice que JDB9900401 suele ser consecuencia de ORA-03113. Hubo 22 ocurrencias, siempre hasta 1 segundo después, en el mismo hilo. Por eso la investigación empieza por ORA-03113.

3. Busca dónde se fue el tiempo

1. Abre la pestaña BSFN. La tabla viene ordenada por Tiempo propio.
2. F4111EndDocument tardó 9,13 s en total, de los que 7,41 s son tiempo propio. Luego el tiempo no está en las funciones que llama.

4. Encuentra el SQL responsable

1. Abre la pestaña SQL. La primera sentencia es una lectura de F0005, sin WHERE, de cerca de 7,4 s.
2. Mira las otras dos señales: una lectura de F41021 trajo 4000 filas, y la sentencia en F4101 se ejecutó 120 veces.

5. Mira el camino en el mapa

1. Abre la pestaña Flujo y haz clic en el bloque F41021.
2. El mapa destaca el camino: P4116 llama a F4111EndDocument, que llama a AverageCostUpdate, que lee F41021. Ahora sabes qué pantalla lleva a esa lectura.

6. Genera el informe

1. Haz clic en Informe y marca Ocultar usuarios, servidores, IP, rutas y valores entre comillas.
2. Revisa el texto y usa Copiar o Descargar .md.

Resultado: en pocos minutos tienes una hipótesis para cada problema. Conexión con la base de datos perdida a las 09:17, con un error consecuencia de otro; una lectura sin filtro; y una función llamada 120 veces. Falta confirmar cada una con el DBA y con quien conoce el código.

Cómo leer los insights

Las tarjetas son reglas simples sobre las cifras del log, y estas son las condiciones exactas. Una señal no es una causa: indica dónde mirar.

Debajo de las tarjetas, dos gráficos muestran los errores y las líneas de log a lo largo del tiempo. Haz clic en una barra de error para ver solo los errores de ese intervalo. Ver como tabla trae las mismas cifras en una tabla.

Errores

La aplicación agrupa los mensajes que solo cambian en los valores, así que el mismo error con números distintos cuenta como uno. Filtra por Nivel y Área, o escribe un fragmento, como el nombre de una tabla.

• Fatal, Error y Alerta vienen de códigos y palabras del mensaje, como ORA-00942, OCI0000178 y failed.
• Qué dice la fuente: la aplicación tiene una pequeña base, solo con textos de Oracle, cada uno con el enlace a la fuente. ^{[3] [4] [8]}
• Código fuera de la base: búscalo en My Oracle Support o en la aplicación P92002, que contiene los mensajes de error del sistema. ^[4]

BSFN

La aplicación une cada llamada a su retorno, por hilo, y calcula dos tiempos:

• Tiempo total: de la llamada al retorno, incluidas las funciones que llama.
• Tiempo propio: el total menos el tiempo de las funciones hijas. Es donde debes mirar primero. ^[7]
• Retorno ≠ 0: llamadas que devolvieron un valor distinto de 0. La aplicación solo las cuenta; comprueba cómo trata ese retorno quien llama.

SQL

La aplicación quita los valores, para juntar sentencias iguales, y suma ejecuciones, filas leídas y tiempo. Así, los valores de clientes no quedan en la tabla.

• Filas leídas: cuenta las líneas "Fetched the record" tras cada sentencia. Un caso de estudio de P4116 muestra este patrón: 40.000 filas leídas en una sola llamada de función. ^[6]
• Tiempo aprox.: va de la sentencia a la última lectura, así que incluye lo que la aplicación hizo entre lecturas.
• Pista: un intervalo largo entre la sentencia y la primera lectura suele apuntar a la base de datos más que a la lógica. ^[7]

Pausas

Pausa es el tiempo sin líneas nuevas en el mismo proceso e hilo. Oracle sugiere jdedebug justamente para ver el punto en que la ejecución normal se detuvo. ^[3] Cada fila de la tabla muestra lo que vino antes y después.

Contexto

La pestaña Contexto responde a "¿qué se estaba ejecutando?": archivos leídos y el tipo de cada uno, aplicaciones e informes, tablas, procesos e hilos, y las llamadas de API más frecuentes.

Flujo

La pestaña Flujo dibuja quién llama a quién, sumando todas las ejecuciones: entrada, BSFN por nivel, tablas y errores en secuencia. En un jde.log puro, muestra proceso → error → error siguiente.

• Cuanto más grueso el enlace, más veces ocurrió.
• ⏱ marca lo que superó el límite de lentitud, y la línea discontinua, una vuelta, como la recursión.
• Al hacer clic en un bloque, su camino queda destacado y Abrir detalles lleva al detalle.
• En una BSFN, Parámetros muestra lado a lado la entrada y la salida de cada parámetro, de las líneas IN-> y OUT->, en hasta cinco llamadas: la primera, la más lenta y las que devolvieron un valor distinto de 0. ≠ marca lo que cambió.
• Ver los enlaces como tabla trae los mismos enlaces en texto, y Descargar SVG guarda la imagen.

Contenido

La pestaña Contenido muestra el log entero, línea a línea, con un color y una etiqueta para cada tipo de evento: errores, retornos distintos de 0, BSFN, SQL, lectura de filas, parámetros, API y UBE. Úsala cuando los resúmenes ya te han dicho dónde mirar y quieres leer lo que ocurrió alrededor.

• Filtrar: haz clic en un tipo para ver solo sus líneas. Hacer clic en otro suma, y Mostrar todo lo deshace.
• Pausas: ⏸ marca la línea que vino después de una pausa por encima del límite.
• Navegar: usa la búsqueda, Ir a la línea, Siguiente error ▶ y las flechas. En Ver en el log, el botón Abrir en Contenido te trae aquí.
• Copiar: las líneas de más de 2.000 caracteres se cortan en pantalla, y Copiar trae el texto completo.

Informe y privacidad

Informe genera un texto en Markdown con los insights y las cifras principales, para adjuntar a una incidencia. Antes de enviarlo a alguien o a una IA, marca Ocultar usuarios, servidores, IP, rutas y valores entre comillas.

Documentar, en el menú superior, reúne en una página todas las pestañas, menos Contenido, sin los filtros de la pantalla, y abre la ventana de impresión del navegador. Elige "Guardar como PDF" como destino para guardar el análisis. A diferencia del informe, el PDF no oculta nada: los valores aparecen tal como están en el log.

Nuevo vuelve a la pantalla inicial y quita el análisis actual de la memoria, para abrir otro log. Los archivos de tu equipo no cambian. Para guardar el resultado, usa antes Documentar.

Un método para el log real

Con un problema real, este orden evita perder tiempo:

1. Empieza por el jde.log. Si hay un fallo grave o una conexión perdida, resuélvelo antes de medir el rendimiento.
2. Reproduce con depuración en un solo proceso, y abre el jdedebug.
3. Sigue el tiempo: BSFN por tiempo propio, después SQL y Pausas.
4. Confirma en la línea original con Ver en el log y con quien conoce el código y la base de datos.
5. Corrige y mide de nuevo. Un autor sugiere 10 o más ejecuciones y usar la mediana, porque una sola engaña. ^[7]

Para logs muy grandes o análisis oficial, Oracle ofrece LogParse, en el Performance Workbench de Server Manager, que genera resumen, CSV de BSFN y tablas, y pausas. ^[5] JDE Log Insights es una alternativa rápida, sin servidor, no un sustituto.

Prompts de IA

Con las señales en la mano, aún falta interpretarlas: qué significa este código, qué error vino primero, qué preguntar al DBA. Una IA ayuda a organizar hipótesis y a preparar la conversación. También se equivoca con seguridad: inventa causas, cita notas de soporte que no existen y supone cómo es tu personalización. Trata el resultado como el borrador de un colega con prisa. Para escribir mejores prompts, mira el tutorial de prompts.

Antes de pegar: los logs pueden traer usuarios, servidores, SQL y valores de clientes. La aplicación no envía nada a la red, pero el servicio de IA recibe todo lo que pegues. Usa Ocultar usuarios, servidores, IP, rutas y valores entre comillas, revisa el texto y sigue la política de tu organización sobre el uso de IA.

Cambia las partes entre corchetes y pega en la herramienta de IA que uses. Los prompts siguen el orden de la investigación, pero cada uno funciona por sí solo.

1. Priorizar lo que muestra el informe

En Informe, marca Ocultar usuarios, servidores, IP, rutas y valores entre comillas, usa Copiar y pega el texto al final del prompt.

Eres un analista con experiencia en JD Edwards EnterpriseOne.
Abajo está el informe de una herramienta que lee los logs del sistema.

Contexto del problema: [qué vio el usuario, cuándo, en qué aplicación]

Basándote solo en el informe:
1. Enumera de 3 a 5 hipótesis, de la más a la menos probable.
2. Para cada una, cita la cifra o la línea del informe que la sostiene y di qué la descartaría.
3. Di qué debo mirar primero y quién del equipo puede confirmarlo.
4. Separa lo que es un hecho en el informe de lo que es una suposición tuya.

No inventes códigos, tablas, notas de soporte ni características de mi entorno. Si falta un dato, di cuál.

Informe:
[pega el informe]

2. Explicar un error

Abre el error en la pestaña Errores y usa Ver en el log para copiar el mensaje y las líneas de alrededor, cambiando los datos sensibles. Después, compara la respuesta con lo que dice Oracle sobre el código. ^[8]

Explica este error de un log de JD Edwards EnterpriseOne a quien no es especialista.

Versión del sistema y de la base de datos: [ej.: Tools 9.2, Oracle, o "no lo sé"]
Qué se estaba haciendo: [aplicación, UBE o acción]

Mensaje y líneas de alrededor:
[pega el fragmento]

Responde:
1. Qué dice el mensaje, en lenguaje sencillo.
2. Causas posibles, con lo que confirma o descarta cada una.
3. Dónde comprobar y quién suele comprobarlo.
4. Qué partes de tu respuesta vienen de documentación y cuáles son deducción. Si no conoces el código, dilo en lugar de adivinar.

3. Separar causa y consecuencia

En la pestaña Errores, usa Descargar CSV y pega la tabla. Antes de pegar, cambia usuarios, servidores y valores, porque el CSV no oculta datos. El prompt pide que la IA diga qué abrir en el log para confirmar cada enlace.

La tabla de abajo lista los errores agrupados de un log de JD Edwards EnterpriseOne, con recuento, primera y última ocurrencia.

Identifica:
1. Qué errores parecen el origen y cuáles parecen consecuencia, usando el orden en el tiempo y el tipo de mensaje.
2. Errores que ocurrieron en el mismo periodo y pueden tener la misma causa.
3. Por qué error empezar, y por qué.

La tabla no muestra el hilo ni el texto completo. Di qué debo abrir en el log para confirmar cada enlace. No trates la coincidencia en el tiempo como prueba.

Tabla:
[pega el CSV]

4. Entender dónde gasta tiempo una BSFN

En la pestaña BSFN, usa Descargar CSV y pega la tabla. En tiempo de reloj, la diferencia entre total y propio indica dónde bajar. ^[7]

La tabla de abajo trae las funciones de negocio (BSFN) medidas en un jdedebug de JD Edwards EnterpriseOne: llamadas, tiempo total, tiempo propio, media, máximo y retornos distintos de 0. Los tiempos son de reloj, con el log activo.

Escenario medido: [qué se ejecutó, y cuántas veces]
Tiempo que percibió el usuario: [ej.: 40 s]

1. Qué funciones merecen atención primero, y por qué.
2. Dónde el tiempo total es mucho mayor que el propio, y qué indica.
3. Señales de llamadas repetidas de más.
4. Qué preguntar a quien conoce el código.

No digas qué hace una función por dentro, a menos que yo lo indique. Si un nombre sugiere algo, márcalo como suposición.

Tabla:
[pega el CSV]

5. Analizar un SQL

Abre la sentencia en la pestaña SQL y usa Copiar: el texto viene sin los valores. Añade las columnas de la fila, como ejecuciones y filas leídas. ^[7]

Analiza este SQL de un log de JD Edwards EnterpriseOne. Los valores se quitaron.

Sentencia:
[pega la sentencia]

Ejecuciones: [número]
Filas leídas: [número]
Tiempo aproximado (incluye lo que la aplicación hizo entre lecturas): [tiempo]
Base de datos: [ej.: Oracle, SQL Server]
Tamaño de la tabla: [filas, o "no lo sé"]

Responde:
1. Qué llama la atención: repetición, volumen, falta de filtro.
2. Qué pedir al DBA que confirme, como el plan de ejecución y los índices existentes.
3. Dos o tres mejoras que evaluar en la aplicación y en la base de datos, con el riesgo de cada una.

No inventes nombres de índices ni de columnas. No recomiendes alterar tablas estándar de JD Edwards sin indicar el impacto.

6. Interpretar una pausa

Abre la pausa en la pestaña Pausas y copia las líneas antes y después, cambiando los datos sensibles. La respuesta debe decir qué falta para decidir, no solo adivinar.

En un log de JD Edwards EnterpriseOne, hubo una pausa de [tiempo] en el mismo hilo.

Última línea antes:
[pega]

Primera línea después:
[pega]

Cómo se generó el log: [ej.: usuario en la pantalla, UBE, carga automática]

Enumera lo que puede explicar esta pausa, como trabajo sin registro, espera de base de datos o red, o falta de actividad del usuario. Para cada explicación, di qué observar para confirmarla o descartarla. Si las líneas no permiten decidir, dilo.

7. Planificar la próxima medición

Pide un plan corto para reproducir y comparar, siguiendo el método de este tutorial. Revisa cualquier cambio en jde.ini con quien administra el servidor. ^{[3] [7]}

Quiero medir un problema de rendimiento en JD Edwards EnterpriseOne y comparar antes y después de una corrección.

Problema: [qué va lento]
Entorno disponible para pruebas: [ej.: pruebas, un kernel aislado]
Lo que ya sé: [pega los principales hallazgos]

Prepara un plan corto:
1. Cómo reproducir el mismo escenario, siempre igual.
2. Qué logs recoger y cómo aislar el proceso, para que no se mezclen.
3. Cuántas ejecuciones hacer y cómo compararlas, usando la mediana.
4. Qué puede distorsionar la medida, como el propio log, la caché y otros usuarios.
5. Cómo deshacer la configuración de depuración al terminar.

Marca lo que necesita confirmación del administrador del sistema. Si no estás seguro del nombre de un parámetro, dilo.

8. Escribir la incidencia

Separa hechos e hipótesis, para que la incidencia no afirme lo que nadie probó. Si la IA cita un documento de soporte, comprueba que exista.

Escribe una incidencia para [DBA, desarrollo o soporte] a partir del informe de abajo.

Qué ocurrió para el usuario: [describe]
Impacto: [a quién afectó, desde cuándo]
Qué se intentó ya: [describe]

Estructura:
1. Resumen en dos frases.
2. Hechos observados, con horas y cifras del informe.
3. Hipótesis, marcadas como hipótesis.
4. Qué pido que se compruebe.
5. Adjuntos que enviar.

No añadas hechos, causas ni plazos. Mantén las partes ocultas como están.

Informe:
[pega el informe]

Cómo comprobar la respuesta

Errores comunes y limitaciones

Errores de lectura

• Concluir por el recuento. El error más frecuente puede ser consecuencia de otro más raro.
• Confundir pausa con lentitud. Lee las líneas de alrededor.
• Medir una sola ejecución. Los tiempos varían, y el log pesa.
• Abrir solo el jde.log y buscar tiempos. Quien registra llamadas y SQL es el jdedebug.

Limitaciones

• Solo logs ficticios. La aplicación se probó con logs creados a partir de fragmentos públicos, nunca con un log de producción. Versiones, idiomas y plataformas pueden variar: avisa cuando reconoce menos del 60% de las líneas, y entonces solo busca palabras de error.
• Detección por palabras. Puede marcar una línea normal como error, o pasar por alto un error escrito de otra forma.
• Sin año. Los logs no traen el año, así que solo aparecen día y hora.
• Los archivos comprimidos no se leen: extrae el .zip antes.
• Tamaño: probamos hasta 501 MB, leídos en unos 10 s en un ordenador de sobremesa, en Chromium. Otros equipos varían.
• Navegadores: Firefox, Safari y móviles reales no se probaron.

Repaso rápido

Intenta responder antes de abrir cada pregunta.

Referencias

1. Giovani Perotto Mesquita, “JDE Log Insights”, aplicación en un único archivo HTML, giovanipm.github.io/jde-log-insights.html.
2. Oracle, “jde.log”, JD Edwards EnterpriseOne Tools, documentación, consultado el 01/11/2026, docs.oracle.com. Esta página afirma que jde.log está siempre en la raíz de la unidad principal. La página [3] dice que la ubicación viene de JobFile. Seguimos la [3], más específica.
3. Oracle, “Troubleshooting the Enterprise Server”, documentación, consultado el 01/11/2026, docs.oracle.com. Esta página describe el jde.log del servidor como sobrescrito en cada sesión y, en servidor Windows, como añadido al final.
4. Oracle, “Troubleshooting the Workstation”, documentación, consultado el 01/11/2026, docs.oracle.com.
5. Oracle, “LogParse Output Files for the Enterprise Server”, documentación, consultado el 01/11/2026, docs.oracle.com.
6. Dong's Page, “Case Study: Slow Performance in P4116”, caso de estudio en un blog personal, consultado el 01/11/2026, sohigh99.github.io.
7. Vincenzo Caserta, “JD Edwards BSFN performance measurement with logs and timings”, artículo técnico; el 2-5% y las 10 ejecuciones son consejos del autor, no de Oracle, consultado el 01/11/2026, vincenzocaserta.it.
8. Oracle, “Oracle Database Error Help”, páginas de los mensajes ORA citados en la aplicación, consultado el 01/11/2026, docs.oracle.com/error-help/db.