Debuggando Apex - Debug Logs
- Jônatas Lima de Medeiros
- 10 de out. de 2023
- 4 min de leitura
Atualizado: 11 de out. de 2023
Introdução
Nessa pequena série de posts iremos abordar as formas de debugar seu código, a iniciar por "Debug Logs"
Existem diversas formas de encontrar erros na execução do nosso código, uma delas sendo escrevendo classes de teste, que não só é uma boa prática, como também uma necessidade para que possamos dar deploy do nosso código para ambientes de homologação e produção. Isso posto, todo desenvolvedor já passou pela infeliz experiência de ter um código totalmente ou majoritariamente coberto e ainda assim um bug escapar. Nós gostamos de acreditar que as classes de teste e que a aprovação do QA nos garante um código o mais perto do perfeito, mas também sabemos que o usuário sempre pode encontrar algo que ninguém jamais imaginaria. O que fazer então?
Debug Logs
Os logs de debug são ferramentas extremamente poderosas, que nos mostram passo a passo o que aconteceu, desde a chamada da nossa classe até onde o erro foi causado e qual o erro resultante disso. Os debug logs podem conter informações sobre:
Alterações no banco de dados
Chamadas HTTP
Erros no Apex
Recursos utilizados pelo Apex
Processos automatizados como:
Workflow
Processos de Aprovação
Regras de Validação
Flows
Segue aqui um código bastante simples que será utilizado para esse exemplo:
public with sharing class CalcularMedia {
public static void calcularMedia(Id studentId) {
List<AggregateResult> result = [SELECT AVG(Grade__c) avgGrade
FROM Grade__c
WHERE Student__c = :studentId
AND Name LIKE 'Unit%'];
if (!result.isEmpty()) {
Decimal average = (Decimal)result[0].get('avgGrade');
System.debug('Média: ' + average);
} else {
System.debug('Nenhum resultado encontrado para o cálculo da média.');
}
}
}
Para uma breve explicação de como utilizar, o caminho para gerar um Debug Log é:
Setup -> Debug Logs
Ao clicar em "New" podemos escolher o que será debugado e o nível de depuração. Você pode criar novos níveis.
Eles podem tanto ser vistos na plataforma quanto baixados.
Como podem ver, o nosso debug aparece após a execução do código.
Os mais experientes podem então falar do problema que é o System.debug() em ambientes produtivos, correndo o risco de vazar informações. Então segue aqui um snippet de código muito utilizado na empresa que trabalho para que possamos ter os debugs em nossos ambientes de sandbox sem correr esse risco
public static Boolean isSandbox(){
Boolean isSandbox = [SELECT IsSandbox
FROM Organization
LIMIT 1].IsSandbox;
return isSandbox;
}
Limites
Os Debug Logs tem os seguintes limites:
Cada log deve ter 20MB ou menos. Logs maiores terão seus tamanhos reduzidos removendo linhas como System.debug(), a se iniciar pelas mais antigas. Essas linhas podem ser removidas de qualquer parte do arquivo, não apenas do inicio.
System Debugs são mantidos por 24 horas. Monitoring Debugs são mantidos por sete dias.
Caso sejam gerados mais de 1.000MB de logs em uma janela de 15 minutos, a trace flag será desativada. A Salesforce envia um email para os usuários que modificaram a trace flag mais recentemente informando que a mesma pode ser ativa novamente em 15 minutos. Por essa razão é interessante evitar ativação de trace flags para classes muito utilizadas.
Quando a org atinge 1.000MB de logs, se torna impossível a adição ou edição de trace flags. Para a adição ou edição será então necessário deletar logs.
Seções
O tipo e quantidade de informações em um log depende dos filtros atribuídos a ele no entanto, o formato é sempre o mesmo.
Header
O Header (cabeçalho) contém as seguintes informações
Versão da API da transação
Categoria e nível usado para gerar o log.
Sendo:
Categoria | Nível |
Apex Code | Finest |
Apex Profiling | Info |
Callout | Info |
Database | Info |
NBA | Info |
System | Debug |
Validation | Info |
Visualforce | Info |
Wave | Info |
Workflow | Info |
ATENÇÃO
Se "Apex Code" for Finest, o debug irá incluir detalhes de atribuição de variáveis. Certifique-se de que não existem dados sensíveis sendo utilizados.
Execution Units
Uma Execution Units (unidade de execução) nada mais é do que uma transação. Ela contém todas as ocorrências dentro da transação. Elas são delimitadas por "EXECUTION_STARTED" e "EXECUTION_FINISHED"
Code Units
Uma Code Unit (Unidade de código) é uma Unit of Work(unidade de trabalho) discreta, como uma trigger ou um método webservice. Segue uma lista com algumas Code Units, mas note que ela não é completa.
Triggers
Workflow invocations and time-based workflow
Validation rules
Approval processes
Apex lead convert
@future method invocations
Web service invocations
executeAnonymous calls
Visualforce property accesses on Apex controllers
Visualforce actions on Apex controllers
Execution of the batch Apex start and finish methods, and each execution of the execute method
Execution of the Apex System.Schedule execute method
Incoming email handling
Linhas
Dentro das Code Units as linhas tem uma Timestamp e um Event Identifier que são separados por um pipe (|).
Timestamp: Horário que um evento ocorreu. O horário é o mesmo do usuário e segue o formato de horas:minutos:segundos:milisegundos. O valor entre parênteses representa o tempo em nano segundos desde o inicio da requisição. Esse último valor não aparece quando vemos um log pelo Developer Console, mas pode ser visto ao ir na aba "Logs", clicar com o botão direito no log desejado e clicar em "Open Raw Log". Event Identifier: Representa o evento que criou aquele registro no log.
Outros dados
O log contém também as seguintes informações:
Uso de Recursos | Utilização de recursos da plataforma são mostrados aqui |
Uso Cumulativo | Ao fim de cada transação temos esse log que contém informações acerca de invocações DML, queries pesadas e afins. |
Encerramento
Espero que esse post tenha te ajudado a entender um pouco melhor dessa ferramenta muitas vezes deixada de lado por sua interface não muito amigável. Nos próximos posts seguiremos a documentação com debug logs no Developer Console, Debug de chamadas de API e Ordem de Precedência dos logs.
Até a Próxima!
Comments