LogAppDoc

|---------------------------------------------------------------------|
| ------------------------------------------------------------------- |
| Log de aplicação: Documentação técnica ||
| ------------------------------------------------------------------- |
|---------------------------------------------------------------------|
O ,Log de aplicação' é uma ferramenta utilizada para agrupar mensagens, gravar, ler e eliminar logs no
banco de dados, bem como para exibir logs. A documentação apresentada aqui está estruturada por
temas e constitui uma introdução por etapas à temática.
CONTEÚDO
Introdução..........................................................
Chamada mais simples................................................
Que dados podem ser agrupados? ...............................
Como podem as mensagens ser

agrupadas?........................................
Procurar e ler mensagens....................................
Exibição de log de sistema: Princípio de função .............................
Exibição de log de sistema: Módulo de função

BAL_DSP_LOG_DISPLAY.........
Exibição de log de sistema: Perfis de exibição em

standard..................
Exibição de log de sistema na

subtela..................................................
Exibição de log de sistema em um container de

controle..........................
Gravar e carregar logs........................................
Eliminar logs no banco de dados.....................................
Modificar logs.................................................
Arquivar logs...............................
Início de transação..................................................
Outros módulos de função..........................................
ANEXO
Síntese das rotinas callback........................................
Versão de impressão da documentação técnica..............................
|---------------------------------------------------------------------|
| Introdução |
|---------------------------------------------------------------------|
Em um programa de aplicação podem surgir situações durante o tempo de execução das quais o usuário
tem ter conhecimento. Estas são geralmente situações de erro, mas também pode ser vantajoso dar a
conhecer uma informação sobre uma operação efetuada corretamente (contudo, o usuário não deve
receber informações irrelevantes em excesso).
Não será feita a distinção exata entre exceção, erro, mensagem etc. Nesta conectividade, é importante
que haja uma situação, na qual surge uma determinada informação (na generalidade uma mensagem
T100 ou um texto da mensagem para uma exceção), que está sendo exibida imediata ou posteriormente
em um log. Esta informação é denominada por mensagem.
Estas mensagens não devem ser saídas individualmente (instruções ABAP MESSAGE, RAISE), mas
serão primeiramente agrupadas e representadas em conjunto em outro momento.
Esta quantidade de mensagens representa um log. Para um log existem geralmente informações básicas
de cabeçalho (de que tipo de log se trata, quem e como foi criado, etc.). Durante uma transação é
possível criar vários logs.
O log de aplicação oferece só uma infraestrutura bem estruturada, para agrupar mensagens, gravá-las no
banco de dados e representá-las como um log. Esta infra-estrutura e algumas convenções devem ser
explicadas aqui de forma resumida.
Núcleo técnico e capa simplificada

=====================================================
=================
O log de aplicação é composto basicamente por dois shells: um tipo de núcleo técnico de módulos de
função pequenos e flexíveis assim como um shell simplificado, que para determinados cenários, utiliza os
módulos de função do núcleo.
Exemplo:
No núcleo técnico existem módulos de função para efetuar a pesquisa no banco de dados
(BAL_DB_SEARCH), para carregar logs para a memória principal (BAL_DB_LOAD) e para a saída de
logs, que se encontram na memória principal (BAL_DSP_LOG_DISPLAY). Por sua vez, no shell
simplificado existe o módulo de função APPL_LOG_DISPLAY, que utiliza o shell nesta seqüência para
exibir logs no banco de dados.
É possível utilizar tanto os módulos de função do núcleo como da capa simplificada.
Os módulos de função da capa simplificada são principalmente módulos de função do log de aplicação
anterior (do release 3.0). Estes módulos de função (que começam por APPL_LOG_...) chamam
internamente os módulos de função do novo núcleo técnico (que começa por BAL_...).
Todos os grupos de funções devem ser encontrados no pacote SZAL, os grupos de funções da capa
simplificada começam por SLG..., os do núcleo técnico por SBAL.....
Se o log de aplicação anterior for utilizado, o usuário não tem de converter se não pretender fazê-lo.
Contudo, nem todas as funções do log de aplicação novo podem ser utilizadas na capa simplificada
anterior, só algumas características novas surgem também na capa anterior.
Exemplo:
O módulo de função (anterior) para a exibição de logs no banco de dados APPL_LOG_DISPLAY tem o
novo parâmetro de importação I_S_DISPLAY_PROFILE, que contém uma descrição, como os logs
devem ser editados (ver capítulo Exibição de log de sistema). Este parâmetro está sendo encaminhado
para o núcleo.
Convenções de nomes
=====================================================
=================
No novo log de aplicação, para os módulos de função são válidas as convenções de nomes seguintes:
Nome do módulo de função: começam por BAL para o log de aplicação base
Parâmetro de importação: começam por I_
Parâmetro de exportação: começam por E_
Parâmetro de modificação: começam por C_
Se os parâmetros de módulos de função forem uma estrutura, segue um S_, nas tabelas um T_.
Exemplo:
I_S_LOG_HEADER é um parâmetro importação de um módulo de função, que tem por base uma
estrutura DDIC.
São válidas convenções semelhantes para categorias DDIC: geralmente começam por BAL_, se se tratar
de um estrutura é seguida por um S_, nas categorias de tabela um T_.
|---------------------------------------------------------------------|
| Introdução |
|---------------------------------------------------------------------|
Em um programa de aplicação podem surgir situações durante o tempo de execução das quais o usuário
tem ter conhecimento. Estas são geralmente situações de erro, mas também pode ser vantajoso dar a
conhecer uma informação sobre uma operação efetuada corretamente (contudo, o usuário não deve
receber informações irrelevantes em excesso).
Não será feita a distinção exata entre exceção, erro, mensagem etc. Nesta conectividade, é importante
que haja uma situação, na qual surge uma determinada informação (na generalidade uma mensagem
T100 ou um texto da mensagem para uma exceção), que está sendo exibida imediata ou posteriormente
em um log. Esta informação é denominada por mensagem.
Estas mensagens não devem ser saídas individualmente (instruções ABAP MESSAGE, RAISE), mas
serão primeiramente agrupadas e representadas em conjunto em outro momento.
Esta quantidade de mensagens representa um log. Para um log existem geralmente informações básicas
de cabeçalho (de que tipo de log se trata, quem e como foi criado, etc.). Durante uma transação é
possível criar vários logs.
O log de aplicação oferece só uma infraestrutura bem estruturada, para agrupar mensagens, gravá-las no
banco de dados e representá-las como um log. Esta infra-estrutura e algumas convenções devem ser
explicadas aqui de forma resumida.
Núcleo técnico e capa simplificada
=====================================================
=================
O log de aplicação é composto basicamente por dois shells: um tipo de núcleo técnico de módulos de
função pequenos e flexíveis assim como um shell simplificado, que para determinados cenários, utiliza os
módulos de função do núcleo.
Exemplo:
No núcleo técnico existem módulos de função para efetuar a pesquisa no banco de dados
(BAL_DB_SEARCH), para carregar logs para a memória principal (BAL_DB_LOAD) e para a saída de
logs, que se encontram na memória principal (BAL_DSP_LOG_DISPLAY). Por sua vez, no shell
simplificado existe o módulo de função APPL_LOG_DISPLAY, que utiliza o shell nesta seqüência para
exibir logs no banco de dados.
É possível utilizar tanto os módulos de função do núcleo como da capa simplificada.
Os módulos de função da capa simplificada são principalmente módulos de função do log de aplicação
anterior (do release 3.0). Estes módulos de função (que começam por APPL_LOG_...) chamam
internamente os módulos de função do novo núcleo técnico (que começa por BAL_...).
Todos os grupos de funções devem ser encontrados no pacote SZAL, os grupos de funções da capa
simplificada começam por SLG..., os do núcleo técnico por SBAL.....
Se o log de aplicação anterior for utilizado, o usuário não tem de converter se não pretender fazê-lo.
Contudo, nem todas as funções do log de aplicação novo podem ser utilizadas na capa simplificada
anterior, só algumas características novas surgem também na capa anterior.
Exemplo:
O módulo de função (anterior) para a exibição de logs no banco de dados APPL_LOG_DISPLAY tem o
novo parâmetro de importação I_S_DISPLAY_PROFILE, que contém uma descrição, como os logs
devem ser editados (ver capítulo Exibição de log de sistema). Este parâmetro está sendo encaminhado
para o núcleo.
Convenções de nomes
=====================================================
=================
No novo log de aplicação, para os módulos de função são válidas as convenções de nomes seguintes:
Nome do módulo de função: começam por BAL para o log de aplicação base
Parâmetro de importação: começam por I_
Parâmetro de exportação: começam por E_
Parâmetro de modificação: começam por C_
Se os parâmetros de módulos de função forem uma estrutura, segue um S_, nas tabelas um T_.
Exemplo:
I_S_LOG_HEADER é um parâmetro importação de um módulo de função, que tem por base uma
estrutura DDIC.
São válidas convenções semelhantes para categorias DDIC: geralmente começam por BAL_, se se tratar
de um estrutura é seguida por um S_, nas categorias de tabela um T_.
|---------------------------------------------------------------------|
| Chamada simples |
|---------------------------------------------------------------------|
Síntese
=====================================================
=================
Neste local é descrito como agrupar do modo mais fácil mensagens e como representá-las
posteriormente como um log.
Módulos de função:
BAL_LOG_CREATE Criar log com dados de cabeçalho
BAL_LOG_MSG_ADD Anexar uma mensagem ao log
BAL_LOG_EXCEPTION_ADD Anexar exceção ao log
BAL_DSP_LOG_DISPLAY Exibir mensagens que se encontram na memória principal
Categorias:
BAL_S_LOG Contém os dados do cabeçalho do log
BAL_S_MSG Contém os dados de uma mensagem
BAL_S_EXC Contém os dados de uma exceção
BALLOGHNDL Handle de log
BALMSGHNDL Handle de mensagem
Programa de exemplo
O report SBAL_DEMO_01 simula a verificação de um vôo. É saído um log, do qual é possível ver o
resultado da verificação.
==>Executar SBAL_DEMO_01 ==>Coding SBAL_DEMO_01
O report SBAL_DEMO_07 simula, como o report SBAL_DEMO_01, a verificação de um vôo. Os erros
serão anexados ao log mediante as exceções.
Abrir um log
=====================================================
=================
É possível abrir um log no log de aplicação com o módulo de função BAL_LOG_CREATE. É possível
incluir neste módulo de função os dados de cabeçalho através do parâmetro de importação
I_S_LOG_HEADER. Este tem a estrutura BAL_S_LOG.
Ao chamar o módulo de função BAL_LOG_CREATE é obtido o chamado handle de log (LOG_HANDLE,

CHAR22).
O LOG_HANDLE é um chamado GUID (globally unique identifier), que identifica univocamente um log.
Com este handle é possível acessar este log, para por exemplo, modificar posteriormente os dados de
cabeçalho ( BAL_LOG_HDR_CHANGE) ou para anexar um mensagem ( BAL_LOG_MSG_ADD) ou um
texto de exceção ( BAL_LOG_EXCEPTION_ADD) ao log.
O LOG_HANDLE possui imediatamente o seu valor final, portanto, é ainda válido depois de gravar.
==>Nota:
Os logs na memória principal e também no banco de dados são referenciados no novo log de aplicação
pelo (LOG_HANDLE). Continua a existir o clássico LOGNUMBER, que ao gravar é atribuído pelo intervalo
consecutivo de numeração 01 do objeto do intervalo de numeração APPL_LOG. Muitas aplicações têm
nas suas estruturas uma referência a este LOGNUMBER, de modo que este continua a ser suportado.
Além disso, a apresentação externa é mais fácil o usuário compreender o LOGNUMBER do que o
LOG_HANDLE. Entre LOG_HANDLE e LOGNUMBER existe uma relação de 1:1.
Anexar mensagens ao log

=====================================================
=================
Funcionalidade
É anexada uma mensagem com o log identificado I_LOG_HANDLE ( Identificador de log).
Os dados de uma mensagem são predefinidos no módulo de função BAL_LOG_MSG_ADD através do

parâmetro de importaçção I_S_MSG (estrutura BAL_S_MSG).
Com E_S_MSG_HANDLE é obtido um Identificador de mensagem que identifica esta mensagem de

forma unívoca.
Estes dados são principalmente informações T100 (categoria de mensagem, área funcional, nº de
mensagem, as 4 variáveis de mensagem), mas também podem ser incluídas outras informações, tais
como dados específicos da aplicação (denominado por contexto) e também parâmetros para um texto
descritivo ampliado ou um rotina de retorno.
Ao chamar os módulos de função BAL_LOG_MSG_ADD, BAL_LOG_MSG_CUMULATE, etc. é obtido o

identificador de mensagem (E_S_MSG_HANDLE) .
O identificador de mensagem é composto pelo Identificador de protocolo do protocolo, ao qual pertence
a mensagem e um nº seqüêncial, ( MSGNUMBER ), que é atribuído internamente. Com este identificador
a mensagem é identificada de forma unívoca e é possível acessar uma mensagem com este identificador,
por exemplo, para modificá-la (BAL_LOG_MSG_CHANGE) ou lê-la (BAL_LOG_MSG_READ).
Anexar exceções ao log

=====================================================
=================
Funcionalidade
Um texto de exceção será anexado com o log indentificado com (I_LOG_HANDLE Handle de log).
A classe de exceção, a gravidade do erro, a classe do problema e o nível de detalhe são especificados
mediante o parâmetro IMPORTING I_S_EXC (estrutura BAL_S_EXC) ao módulo de função
BAL_LOG_EXCEPTION_ADD.
As informações de contexto para exceções e anexo acumulado de exceções não serão suportadas.
Com E_S_MSG_HANDLE obtém-se um Handle de mensagem que identifica univocamente esta

mensagem.
=> Nota: este módulo de função substitui o módulo de função BAL_LOG_EXC_ADD.
Exibir o log
=====================================================
=================
Com BAL_DSP_LOG_DISPLAY é possível exibir as mensagens agrupadas. Este módulo de função pode
ser chamdo sem parâmetros. Neste caso, são utilizadas todas as mensagens que se encontram na
memória principal e representadas segundo uma edição standard (esta edição standard também é
utilizada na transação SLG1).
==>Nota
A indicação do identificador de log nos módulos de função como BAL_LOG_MSG_ADD,
BAL_LOG_MSG_CUMULATE, BAL_LOG_MSG_ADD_FREE_TEXT, etc. é opcional.
Se não for indicado, é utilizado o log default. Este pode ser definido (para além de outros dados default)
com BAL_GLB_MSG_DEFAULTS_SET. Se não estiver definido nenhum log default, este é definido
automaticamente por BAL_LOG_CREATE (para mais informações ver aqui).
|--------------------------------------------------------------------------------------|
| Que dados podem se agrupados? |
|------------------------------------------------------------------------------------- |
Síntese
=====================================================
=================
O log de aplicação agrega mensagens e agrupa-as em logs. São expostos os dados que podem ser
agrupados pelo log de aplicação.
Módulos de função
BAL_LOG_EXCEPTION_ADD Anexar uma exceção ao log
Categorias
BAL_S_LOG Contém dados de cabeçalho do log
BAL_S_MSG Contém dados de uma mensagem
BAL_S_EXC Contém dados de uma exceção
BAL_S_CONT Contexto para mensagem/cabeçalho de log
BAL_S_PARM Parâmetros para mensagem/cabeçalho de log
Programa de exemplo
Report SBAL_DEMO_02 simula a verificação de um vôo. É saído um log, a partir do qual é possível ver
os resultados da verificação.
O cabeçalho de log
=====================================================
==================
Um log no log de aplicação é aberto com BAL_LOG_CREATE, sendo os dados de cabeçalho incluídos
na estrutura BAL_S_LOG. Os dados desta estrutura são apresentados conforme se segue:
• OBJECT, SUBOBJECT
O log de aplicação é utilizado pelas aplicações mais variadas. Para que uma aplicação possa encontrar
de forma eficiente os logs escritos pela mesma, cada log possui no cabçalho de log os atributos OBJECT
e SUBOBJECT.
Isto são "Siglas" normalizadas (CHAR20), que caracterizam a respetiva aplicação ou subaplicação e que
é possível instalar com a transação SLG0 (Exemplo: OBJECT = "FREIGHT_COSTS" (Custos de frete),
SUBOBJECT = "SETTLEMENT" (Faturamento)).
Esta indicação no cabeçalho do log é opcional durante o tempo de execução, mas na gravação (com o
módulo de função BAL_DB_SAVE) tem de existir OBJECT (e caso necessário, SUBOBJECT).
• EXTNUMBER
A identificação externa no cabeçalho de log (CHAR100) é uma identificação que pode ser
definida pela aplicação. Esta identificação caracteriza um log.
Esta pode, por exemplo, ser utilizada para estabelecer uma ligação entre um objeto de aplicação
e um log. Para esta finalidade, o nº de documento do objeto de aplicação é colocado na
identificação externa do log.
Também é possível, agrupar através de uma identificação externa vários logs em um log lógico
(a exibição de logs é válida para vários logs!).
No banco de dados existe um índice nos campos OBJECT/SUBOBJECT/EXTNUMBER, assim
na indicação destes campos é possível ler de forma eficiente um log do banco de dados
(nenhum "Full Table Scan").
• ALDATE, ALTIME, ALUSER , ALTCODE, ALPROG, ALMODE
Outros dados do cabeçalho de log proporcionam informações sobre o modo como foi criado o
log. Estas são a data, a hora e o usuário (ALDATE, ALTIME, ALUSER) assim com a transação
ou o programa com o qual foi gerado o log (ALTCODE, ALPROG). O modo de operação, no qual
foi gerado o log, também é gravado no ALMODE (portanto on-line, em background, etc.).
• ALCHDATE, ALCHTIME, ALCHUSER

Se um log já existente no banco de dados for modificado posteriormente, o usuário, a data e a
hora são gravados nos campos ALCHDATE, ALCHTIME e ALCHUSER .
• DATE_DEL, DEL_BEFORE
Um log tem uma data de vencimento (DATE_DEL), após a qual pode ser eliminado um código
(DEL_BEFORE), que proibe explicitamente a eliminação antes desta data. Para mais
informações relativas a este tema "Eliminação de logs", efetuar aqui um clique.
• ALSTATE
Um log também tem um status que descreve se um log está ou não concluído. Este código só
tem um caráter informativo e não é analisado.
• CONTEXT: CONTEXT-TABNAME, CONTEXT-VALUE

Informações de contexto relativas ao cabeçalho de log
• PARAMS: PARAMS-T_PAR, PARAMS-ALTEXT, PARAMS-CALLBACK

Parâmetros relativos ao cabeçalho de log
==>Nota 1
Ao ler um cabeçalho de log com BAL_LOG_HDR_READ são obtidas maiores informações, que não se
encontram em BAL_S_LOG, visto que não é possível indicar estes dados externamente. Isto são por
exemplo o LOGNUMBER interno, o número de mensagem, de mensagens A, E, W, I e S assim como a
classe de problemas mais alta que ocorreu.
==>Nota 2
No log de aplicação obsoleto, no tempo de execução, foi aberto um log pela indicação do referido objeto e
subobjeto de log de aplicação. Por conseguinte, foi identificado um log (no tempo de execução), devido à
indicação de OBJECT/SUBOBJECT. Isto teve como conseqüência, que para um OBJECT/SUBOBJECT
só pôde ser criado um log.
No novo log de aplicação já não existe esta restrição. Um log é identificado por um handle,
OBJECT/SUBOBJECT são apenas atributos de um log.
A mensagem
=====================================================
==================
Uma mensagem que possa ser agrupada com o módulo de função BAL_LOG_MSG_ADD, é
representada pela estrutura BAL_S_MSG. É possível utilizá-la em modalidades diferentes, que se
seguem:
• MSGTY, MSGID, MSGNO, MSGV1, MSGV2, MSGV3, MSGV4

Estes são os dados clássicos de uma mensagem T100.
Os campos tipo de mensagem ( MSGTY), área funcional MSGID), número de erro ( MSGNO)
têm de ser preenchidos, opcionalmente os campos para as quatro variáveis de mensagem
MSGV1 até MSGV4.
• PROBCLASS, DETLEVEL, ALSORT, TIME_STMP

Se trata de atributos para a mensagem T100, como a classe de problema ( PROBCLASS, por
exemplo "muito importante"), o nível de detalhamento ( DETLEVEL, valores de 1 a 9), critério de
ordenação ( ALSORT, a utilizar arbitrariamente) e o registro da hora ( TIME_STMP). Estes
campos podem ser utilizados na exibição do log de sistema (exceto TIME_STMP).
• MSG_COUNT
Se uma mensagem foi acumulada, este valor de acumulação é gravado em MSG_COUNT. Este
valor é aumentado com BAL_LOG_MSG_CUMULATE se forem anexadas mais mensagens a
esta.
• CONTEXT: CONTEXT-TABNAME, CONTEXT-VALUE

Informações de contexto para uma mensagem
• PARAMS: PARAMS-T_PAR, PARAMS-ALTEXT, PARAMS-CALLBACK

Parâmetro para uma mensagem
O contexto
=====================================================
==================
Uma mensagem ou um cabeçalho de log por vezes só tem efeito se forem incluídas algumas outras
informações.
Para tal, no log de aplicação é considerado o denominado contexto.
Exemplo:
A mensagem 'Para o cliente ABC o limite de crédito será excedido' tem efeito no diálogo, visto que o
usuário se encontra a processar um determinado documento. No entanto, no log também deveria ser
possível ver o número de documento. Esta informação pode se encontrada em variáveis de mensagem,
mas esta pode causar problemas no caso de informações de ambiente detalhadas (por exemplo número
da ordem, número de item, número de divisão, etc.).
Por isso, é possível incluir estas informações de contexto em uma mensagem (ou em um cabeçalho de
log) no log de aplicação. Para tal, tem de ser definida uma estrutura DDIC, que contenha as informações
de contexto pretendidas (comprimento máximo de 256 byte). No campo CONTEXT é entrado o nome da
estrutura DDIC em CONTEXT-TABNAME, porém, o conteúdo da estrutura emCONTEXT-VALUE. Os
dados do contexto podem ser exibidos posteriormente sem quaisquer problemas.
Exemplo:
====================================================================
DATA:
l_s_msg TYPE bal_s_msg,
l_s_my_context type my_ddic_structure.
* Mensagem 123(XY): 'Limite de crédito para cliente &1 excedido'.

l_s_msg-msgty = 'E'.
l_s_msg-msgid = 'XY'.
l_s_msg-msgno = '123'.
l_s_msg-msgv1 = 'ABC'.
* Anexar número de documento como contexto à mensagem:
l_s_my_context-document = '3000012345'.
l_s_msg-context-tabname = 'MY_DDIC_STRUCTURE'.
l_s_msg-context-value = l_s_my_context.
* Anexar mensagem ao log
CALL FUNCTION 'BAL_LOG_MSG_ADD'
EXPORTING
i_s_msg = l_s_msg
EXCEPTIONS
others = 1.
====================================================================
Observação
A linha
l_s_msg-context-value = l_s_my_context.
sob unicode origina um erro de sintaxe, se o contexto contiver campos que não sejam semelhantes a
caracteres (por exemplo INTEGER).
Recomenda-se utilizar apenas campos semelhantes a caracteres no contexto (também é possível uma
conversão posterior, as informações de contexto antigas no banco de dados serão automaticamente
convertidas durante a leitura).
Caso tenham de ser necessariamente utilizados campos não-semelhantes a caracteres no contexto, a
linha acima mencionada poderá ser substituída da seguinte forma:
FIELD-SYMBOLS:
<l_s_my_context> TYPE c.
ASSIGN l_s_my_context TO <l_s_my_context> CASTING.
l_s_msg-context-value = <l_s_my_context>.
Os parâmetros
=====================================================
==================
Para um cabeçalho de log e uma mensagem ainda é possível arquIvar no log de aplicação parâmetros.
Estas informações podem ser chamadas na exibição do log de sistema do log de aplicação, ao exibir o
detalhe para o cabeçalho de log ou para uma mensagem.
Estes parâmetros podem ser utilizados de dois modos diferentes:
• Como "Texto descritivo ampliado"

Por exemplo, se em uma mensagem T100 o texto descritivo não for suficiente, porque são
necessárias mais informações do que as 4 variáveis de mensagem, é possível indicar
adicionalmente no campo PARAMS-ALTEXT um 'Texto em diálogo' entrado com a transação
SE61. Este texto pode conter tantos caracteres de preenchimento como são incluídos na tabela
PARAMS-T_PAR.
Pode ser encontrado um exemplo na rotina FORM MSG_ADD_WITH_EXTENDED_LONGTEXT
no report SBAL_DEMO_02 .
• Como rotina callback

Através da indicação de uma rotina callback em PARAMS-CALLBACK, na tela detalhada é
acessada a rotina predefinida, na qual é possível exibir os detalhes próprios.
Uma rotina callback (rotina de retorno) pode ser efetuada em dois modos diferentes se for
utilizado o log de aplicação:
como rotina FORM ou como módulo de função
A definição de uma rotina callback inclui a indicação dos campos seguintes:
USEREXITT: Tipo de rotina (' ' = FORM, 'F' = módulo de função)
USEREXITP: Programa, no qual se encontra o usuário (só em FORM)
USEREXITF: Nome de rotina (nome de rotina FORM ou módulo defunção)
Um módulo de função tem de ser configurado como a rotina FORM (USING deve ser substituído
por IMPORTING). Além disso, manter impreterivelmente os mesmos nomes de parâmetro.
A exceção
=====================================================
==================
A exceção que pode ser agrupada pelo log de aplicação com o módulo de função
BAL_LOG_EXCEPTION_ADD, será representada pela estrutura BAL_S_EXC:
• EXCEPTION
Mediante o campo Exceção, é indicada também uma classe de exceção da qual deve ser inserido um
texto de exceção no log. Este campo tem de ser preenchido no log ao inserir uma exceção.
Ao ler os dados de exceção mediante BAL_LOG_EXCEPTION_READ, serão devolvidos os dados da

exceção mediante o parâmetro E_S_EXC com a estrutura BAL_S_EXCR .
• MSGTY
O campo Tipo de mensagem refere-se aos dados clássicos de uma mensagem T100 ( MSGTY). Além
disso, também devia ser preenchido para exceções.
• PROBCLASS, DETLEVEL, ALSORT, TIME_STMP
Trata-se de atributos para uma mensagem ou exceção, como a classe do problema ( PROBCLASS, por
exemplo "muito importante"), nível de detalhe ( DETLEVEL, valores de 1 a 9), critério de ordenação (
ALSORT, pode ser utilizado de forma arbitrária) e registro da hora ( TIME_STMP). Estes campos não
podem ser utilizados na exibição de log (com exceção TIME_STMP).
• MSG_COUNT Este atributo não será utilizado para exceções.
Não podem ser arquivadas informações de contexto ou parâmetros para uma exceção.
|---------------------------------------------------------------------|
| Como agrupar mensagens? |
|---------------------------------------------------------------------|
Síntese
=====================================================
=================
Aqui são expostos vários métodos, como agrupar mensagens do log de aplicação.
BAL_LOG_EXCEPTION_ADD Anexar uma exceção ao log
BAL_LOG_MSG_CUMULATE Anexar mensagem de forma acumulada ao log
BAL_LOG_MSG_REPLACE Substituir a última mensagem
BAL_GLB_MSG_CURRENT_HANDLE_GET Providenciar o handle de mensagens atual
BAL_LOG_MSG_DELETE Eliminar mensagem
BAL_LOG_EXCEPTION_DELETE Eliminar exceção
BAL_LOG_MSG_CHANGE Modificar mensagem
BAL_LOG_EXCEPTION_CHANGE Modificar exceção
BAL_GLB_MSG_DEFAULTS_GETChamar predefinições para dados de mensagem
BAL_GLB_MSG_DEFAULTS_SET Definir predefinições para dados de mensagem
Categorias
BAL_S_MDEF Predefinições para mensagens
Programa de exemplo
Report SBAL_DEMO_02 simula a verificação de um vôo. É saído um log, a partir do qual é possível ver
os resultados da verificação.
Anexar mensagem ao log

=====================================================
==================
Esta é a forma 'clássica' de colocar mensagens em um log. Uma mensagem é simplesmente anexada
com BAL_LOG_MSG_ADD ao log.
==>Nota
A indicação do identificador de log nos módulos de função como BAL_LOG_MSG_ADD,
BAL_LOG_MSG_CUMULATE, BAL_LOG_MSG_ADD_FREE_TEXT, etc. é opcional.
Se não for indicado, é utilizado o log default. Este pode ser definido (para além de outros dados default)
com BAL_GLB_MSG_DEFAULTS_SET. Se não estiver definido nenhum log default, este é definido
automaticamente por BAL_LOG_CREATE (para mais informações ver aqui).
Anexar mensagem de forma acumulada
=====================================================
==================
Funcionalidade
É anexada uma mensagem de forma acumulada ao log identificado com I_LOG_HANDLE ( identificador
de log).
Os dados de uma mensagem são indicados através do parâmetro IMPORTING I_S_MSG (estrutura
BAL_S_MSG).
Com E_S_MSG_HANDLE é devolvido um Identificador de mensagem, que identifica esta mensagem

de forma unívoca.
O que significa 'Acumular' ?

Determinadas mensagens são enviadas várias vezes na execução de um programa, sem que a sua
repetição proporcione outras informações. Para não sobrecarregar desnecessariamente a memória
principal, é possível acumular este tipo de mensagens com BAL_LOG_MSG_CUMULATE. Se for enviada
repetidamente uma mensagem destas, não é criada uma mensagem nova, mas o contador MSG_COUNT
é aumentado na mensagem anterior.
Se as mensagens forem iguais, pode ser indicado na interface do módulo de função. Os dados T100 têm
de ser idênticos. Também é possível definir, que outros dados têm de ser iguais:
• I_COMPARE_ATTRIBUTES = 'X'
Os outros atributos de mensagem (Classe de problema PROBCLASS, nível de
detalhamento DETLEVEL e campo de ordenação ALSORT) têm de ser iguais
• I_COMPARE_CONTEXT = 'X'
O contexto também tem de ser igual
• I_COMPARE_PARAMETERS = 'X'
Os parâmetros da mensagem também têm de ser iguais.
Para encontrar o mais rapidamente possível uma mensagem idêntica, no caso de acumulação, o log de
aplicação, durante o tempo de execução estrutura uma pequena tabela de índices que contém uma
assinatura unívoca de uma mensagem. Contudo, este índice só é estruturado se a acumulação for
utilizada.
Substituir a última mensagem

=====================================================
==================
Funcionalidade
A última mensagem colocada no log de aplicação é eliminada e substituída por uma mensagem nova.
Os dados da mensagem novos são indicados através do parâmetro IMPORTING I_S_MSG (estrutura
BAL_S_MSG). Com E_S_MSG_HANDLE é devolvido um Identificador demensagem , que identifica
univocamente a mensagem nova.
Em que log é colocada a mensagem nova?
• Se com I_LOG_HANDLE não for indicado nenhum Identificador de log, a mensagem é

colocada no mesmo log como a mensagem eliminada.
• Caso contrário a mensagem nova é colocada no log identificado com I_LOG_HANDLE.
• Se não exitir uma mensagem antiga e não estiver indicado nenhum log com I_LOG_HANDLE, a
mensagem é anexada ao log default (para mais informações ver aqui).
Para quê substituir a última mensagem?

Por vezes é pretendido substituir uma mensagem enviada por um programa externo para o log de
aplicação, por uma mensagem própria. Isso é possível efetuar com o módulo de função
BAL_LOG_MSG_REPLACE.
Exemplo
Para a programação é chamado um módulo de função genérico para calcular os horários para um vôo. Se
uma programação não tiver êxito, um módulo de função destes poderia sair uma mensagem
relativamente técnica: "Programação para operação 0006 falhou". Dado que as mensagens devem ser
sempre registradas em log no local da sua criação, este módulo escreve uma mensagem no log de
aplicação. Para o usuário seria muito mais útil a mensagem "Determinação de horários para o vôo de
Hamburgo para Nova Iorque falhou".
==>Nota
É possível chamar o identificador da última mensagem enviada com
BAL_GLB_MSG_CURRENT_HANDLE_GET. Isto pode ser utilizado, se por exemplo não for pretendido
sobregravar a última mensagem escrita, mas sim eliminá-la (com BAL_LOG_MSG_DELETE) ou
modificá-la ( BAL_LOG_MSG_CHANGE) .
Mensagem como texto livre

=====================================================
==================
Funcionalidade
É anexada uma mensagem de texto livre ao log identificado com I_LOG_HANDLE ( Identificador de
log).
O texto de mensagem é predefinido pelo parâmetro de IMPORTING I_TEXT (comprimento máximo de

200 caracteres) para o módulo de função BAL_LOG_MSG_ADD_FREE_TEXT.
A gravidade de erro (I_MSGTY) e (opcional) a classe de problema (I_PROBCLASS) também podem ser
predefinidas.
Com E_S_MSG_HANDLE é obtido um Identificador de mensagem que identifica esta mensagem de

forma unívoca.
Substituir predefinições para mensagens

=====================================================
==================
Algumas informações que seriam importantes para a compreensão de uma mensagem, nem são
conhecidas no local da criação de uma mensagem, mas eventualmente apenas a nível de programa.
Exemplo
Em uma rotina muito inferior é verificada a indicação do local de destino para um transporte com
caminhão. Neste local não é conhecido nem o número de transporte, nem o trajeto parcial, para o qual
isto é efetuado.
Para que as mensagens enviadas por esta rotina obtenham as informações de contexto corretas, é
possível predefini-las antes da chamada desta rotina (definir defaults).
Isto é efetuado com BAL_GLB_MSG_DEFAULTS_SET. Para este módulo de função é transferida a
categoria de dados BAL_S_MDEF, que para além do contexto, contém ainda outros dados (tais como
atributos de mensagem, parâmetros, o log default, etc.).
As predefinições atualmente válidas também podem ser providenciadas com
BAL_GLB_MSG_DEFAULTS_GET. Isto é sobretudo importante, se não for pretendido definir novamente
as predefinições completas mas apenas modificar um determinado aspecto (por exemplo, o número de
posição do contexto mas não o número de ordem).
• ==>Nota
É sempre recomendado, utilizar os módulos de função BAL_GLB_MSG_DEFAULTS_GET e
BAL_GLB_MSG_DEFAULTS_SET em combinação, visto que não é possível ter a certeza, que
predefinições estão atualmente definidas.
As predefinições atuam sobre os módulos de função seguintes:

BAL_LOG_MSG_ADD Anexar mensagem a um log
BAL_LOG_EXCEPTION_ADD Anexar exceção a um log
BAL_LOG_MSG_CUMULATE Mensagem acumulada
BAL_LOG_MSG_ADD_FREE_TEXT Anexar mensagem como texto livre
Mensagens com contexto complexo

=====================================================
==================
Às vezes é pretendido anexar informações mais complexas a uma mensagem (ou a um cabeçalho de
log), como é possível efetuar através do contexto ou parâmetros acima descritos.
Para tal, o log de aplicação coloca à disposição uma tabela do tipo INDX, que pode ser utilizada através
das instruções ABAP
EXPORT TO DATABASE e IMPORT FROM DATABASE.
O report SBAL_DEMO_06 exibe, como é possível gravar e ler contextos complexos. Isso é efetuado
conforme se segue:
• Agrupar mensagens:
Para um cabeçalho de log ou uma mensagem deve ser definida uma rotina CALLBACK (...-
PARAMS-CALLBACK-...)
Simultaneamente as informações de contexto complexas devem ser agrupadas em tabelas
internas do programa da chamada.
• Gravar logs:
Neste momento devem ser atualizadas as tabelas internas através de
EXPORT my_data TO DATABASE bal_indx(al) ID lognumber.
O nº de log interno LOGNUMBER é devolvido do módulo de função BAL_DB_SAVE.
• Exibição do log de sistema:

Se na exibição do log de sistema for selecionado o detalhe para uma mensagem ou um
cabeçalho de log, é acessada a rotina CALLBACK gravada no agrupamento.
Aqui, é possível efetuar uma leitura posterior dos dados e representá-los através de
EXPORT my_data FROM DATABASE bal_indx(al) ID lognumber.
O nº de log interno LOGNUMBER pode ser encontrado na tabela interna transferida para esta
rotina callback (sob PARAM = "%LOGNUMBER").
• Eliminação de logs.
Não há nada a fazer por parte da aplicação. Os dados também são eliminados automaticamente.
==>Nota
Informações de contexto complexas devem ser utilizadas com precaução. Podem ocorrer alguns
problemas. Se a estrutura (por exemplo, através de uma mudança de release) do contexto complexo
MY_DATA tiver sido modificada, provavelmente já não é possível ler os dados. Atualmente, não é
possível garantir que o contexto complexo também seja arquivado automaticamente, de for efetuada a
função de arquivo (ainda não existe atualmente!).
Anexar exceção ao log

=====================================================
==================
Funcionalidade
Um texto de exceção será anexado com o log indentificado com (I_LOG_HANDLE Handle de log).
A classe de exceção, a gravidade do erro, a classe do problema e o nível de detalhe são especificados
mediante o parâmetro IMPORTING I_S_EXC (estrutura BAL_S_EXC) ao módulo de função
BAL_LOG_EXCEPTION_ADD.
As informações de contexto para exceções e anexo acumulado de exceções não serão suportadas.
Com E_S_MSG_HANDLE obtém-se um Handle de mensagem que identifica univocamente esta

mensagem.
=> Nota: este módulo de função substitui o módulo de função BAL_LOG_EXC_ADD.
|---------------------------------------------------------------------|
| Procurar e ler mensagens |
|---------------------------------------------------------------------|
Síntese
=====================================================
=================
Aqui são expostos métodos diferentes, como é possível procurar e ler mensagens que se encontram na
memória principal (não no banco de dados!).
BAL_GLB_SEARCH_LOG Procurar logs na memória principal
BAL_GLB_SEARCH_MSG Procurar mensagens na memória principal
BAL_LOG_HDR_READ Ler cabeçalho de log e outros dados
BAL_LOG_MSG_READ Ler mensagem e outros dados
BAL_LOG_EXCEPTION_READ Ler exceção e outros dados
Categorias
BAL_S_LFIL Critérios de filtro para dados de cabeçalho de log
BAL_S_MFIL Critérios de filtro para dados de mensagem
BAL_T_CFIL Critérios de filtro para dados de contexto
BAL_T_LOGH Tabela com handle de log
BAL_T_MSGH Tabela com handle de mensagem
Programas de exemplo
O report SBAL_DEMO_03 cria vários logs na memória principal e procura em seguida por mensagens ou
logs, para ler alguns dados.
O report SBAL_DEMO_08 cria vários logs na memória principal e procura em seguida por exceções ou
logs, para ler alguns dados.
Procurar e ler logs na memória principal
=====================================================
==================
Se no programa de aplicação não estiver disponível nenhum identificador, para acessar um log no log de
aplicação, é possível chamá-lo através de BAL_GLB_SEARCH_LOG, ao procurar na memória principal
por logs.
Este módulo de função obtém como parâmetro de importação diferentes critérios de busca, que se
referem aos dados do cabeçalho de log:
• I_S_LOG_FILTER
Critérios de filtro relativos ao cabeçalho de log (estrutura BAL_S_LFIL)
• I_S_LOG_CONTEXT_FILTER
Critérios de filtro relativos aos dados de contexto do cabeçalho de log (categoria BAL_T_CFIL)
• I_T_LOG_HANDLE
Predefinição da quantidade de identificadores de log, na qual deve ser efetuada a pesquisa
(categoria BAL_T_LOGH)
Se estiverem especificados simultaneamente vários parâmetros, estes são sujeitos a uma operação "E"
lógica.
O resultado E_T_LOG_HANDLE é uma tabela com identificadores de log.
Com um identificador de log é possível ler os dados de cabeçalho de um log através de

BAL_LOG_HDR_READ. Para além, dos Dados de cabeçalho de log reais em E_S_LOG, este módulo
de função devolve outros dados tais como:
• E_EXISTS_ON_DB E_IS_MODIFIED
O log já existe no banco de dados ?
Caso afirmativo, foi modificado ?
• E_LOGNUMBER
O nº de log interno (se o log ainda não estiver gravado, existe aqui só um nº temporário, que
começa por '$')
• E_STATISTICS
Dados estatísticos do log (na totalidade 120 mensagens, 13 das quais são erros, 4 avisos, etc.)
• E_TXT_OBJECT, E_TXT_SUBOBJECT, E_TXT_ALMODE, etc.

Textos para diferentes campos do cabeçalho do log (por exemplo E_TXT_ALMODE = 'batch
input', se ALMODE = 'I')
Procurar e ler mensagens na memória principal

=====================================================
==================
Se no programa de aplicação não estiver disponível nenhum identificador para acessar uma mensagem
no log de aplicação, é possível providenciar este com BAL_GLB_SEARCH_MSG ao efetuar a pesquisa
na memória principal por logs.
Este módulo de função obtém como parâmetro de importação diferentes critérios de busca, que se
referem aos dados da mensagem e do cabeçalho de log correspondente:
• I_S_LOG_FILTER
Critérios de filtro relativos ao cabeçalho de log (estrutura BAL_S_LFIL)
• I_S_LOG_CONTEXT_FILTER
Critérios de filtro relativos aos dados de contexto do cabeçalho de log (categoria BAL_T_CFIL)
• I_T_LOG_HANDLE
Predefinição da quantidade de identificadores de log, na qual deve ser efetuada a pesquisa
(categoria BAL_T_LOGH)
• I_S_MSG_FILTER
Critérios de filtro relativos aos dados de mensagem (estrutura BAL_S_MFIL)
• I_S_MSG_CONTEXT_FILTER
Critérios de filtro relativos aos dados de contexto de uma mensagem (Categoria BAL_T_CFIL)
• I_T_MSG_HANDLE
Predefinição da quantidade de identificadores de mensagem na qual deve efetuada a pesquisa
(categoria BAL_T_MSGH)
Se estiverem especificados simultaneamente vários parâmetros, estes são sujeitos a uma operação "E"
lógica.
O resultado E_T_MSG_HANDLE é uma tabela com identificadores de mensagem. E_T_MSG_HANDLE
indica a quantidade dos identificadores de log, nos quais se encontram estas mensagens.
Ler mensagens
=====================================================
==================
Com um Identificador de mensagem é possível ler através de BAL_LOG_MSG_READ os dados
relativos a uma mensagem. Para além dos Dados de mensagem reais em E_S_MSG este módulo de
função devolve outros dados, tais como:
• E_EXISTS_ON_DB
Já existe a mensagem no banco de dados ?
• E_TXT_MSGTY, E_TXT_MSGID, etc.

Textos para campos diferentes da mensagem (por exemplo E_TXT_MSGTY = 'Fehler', se
MSGTY = 'E')
Ler exceções
=====================================================
==================
Com um Handle de mensagem é possível ler os dados para uma exceção mediante
BAL_LOG_EXCEPTION_READ. O módulo de função devolve os Dados de exceção em E_S_EXC .
Outros dados devolvidos são, por exemplo:
• E_EXISTS_ON_DB
A mensagem já existe no banco de dados?
• E_TXT_MSGTY, E_TXT_DETLEVEL, etc.

Textos relativos a vários campos da exceção (por exemplo, E_TXT_MSGTY = 'Erro', se MSGTY
= 'E')
Critérios de filtro para o cabeçalho de log

=====================================================
==================
Esta estrutura contém critérios de filtro, que fazem referência ao cabeçalho de log. É constituída
principalmente por RANGES para os campos diferentes do Cabeçalho de log como:
- LOG_HANDLE
- EXTNUMBER
- OBJECT
- SUBOBJECT
- ALDATE
- ALTIME
- ALPROG
- ALTCODE
- ALUSER
- ALMODE
- PROBCLASS
Além disso, também é possível efetuar a pesquisa pelo nº de log interno LOGNUMBER.
Se o usuário estiver interessado no registro da hora, deve ser utilizado DATE_TIME, que contém
- do 'momento de' (DATE_TIME-DATE_FROM DATE_TIME-TIME_FROM
- e do 'momento até' (DATE_TIME-DATE_TO DATE_TIME-TIME_TO).
==>Nota
Se forem especificados simultaneamente vários critérios, estes são sujeitos a uma operação "E".
• Exemplo
Efetuar pesquisa de todos os logs, que pertencem ao objeto 'BCT1', que têm o nº externo '12345'
ou '67890', e que foram criados esta manhã com a transação 'XY01'
================================================================
DADOS:
l_s_log_filter TYPE bal_s_lfil,
l_r_object TYPE bal_s_obj,
l_r_extnumber TYPE bal_s_extn,
l_r_altcode TYPE bal_s_tcde.
* Definir objeto
l_r_object-option = 'EQ'.
l_r_object-sign = 'I'.
l_r_object-low = 'BCT1'.
append l_r_object to l_s_log_filter-object.
* Definir nºs externos
l_r_extnumber-option = 'EQ'.
l_r_extnumber-sign = 'I'.
l_r_extnumber-low = '12345'.
append l_r_extnumber to l_s_log_filter-extnumber.
l_r_extnumber-low = '67890'.
append l_r_extnumber to l_s_log_filter-extnumber.
* Código de transação
l_r_altcode-option = 'EQ'.
l_r_altcode-sign = 'I'.
l_r_altcode-low = 'XY01'.
append l_r_altcode to l_s_log_filter-altcode.
* Intervalo de tempo
l_s_log_filter-date_time-date_from = sy-datum.
l_s_log_filter-date_time-time_from = '000000'.
l_s_log_filter-date_time-date_to = sy-datum.
l_s_log_filter-date_time-time_to = '120000'.
===============================================================
Critérios de filtro para a mensagem

=====================================================
==================
Esta estrutura contém critérios de filtro, que fazem referência à mensagem. É constituída principalmente
por RANGES para os diferentes campos da Mensagem como:
- MSGNUMBER Nº mensagem no log de aplicação
- MSGID Classe de mensagem (também área funcional)
- MSGNO Nº de mensagem em uma classe de mensagem
- MSGTY Categoria de mensagem
- DETLEVEL Nível de detalhamento
- PROBCLASS Classe de problema
Além disso, também é possível efetuar predefinições relativas à combinação da classe de mensagem e
ao nº de mensagem (campo MSGIDMSGNO ).
Para a pesquisa de exceções, é possível combinar critérios de filtro para os RANGES seguintes:
- EXCLS Nome da classe de exceção
- EXTXT Denominador para texto de exceção
- MSGTY Tipo de mensagem
- DETLEVEL Nível de detalhe
- PROBCLASS Classe do problema
==>Nota
Se forem especificados simultaneamente vários critérios, estes são sujeitos a uma operação "E".
• Exemplo
Efetuar pesquisa de todos os erros muito importantes e importantes
===================================================================
DADOS:
l_s_msg_filter TYPE bal_s_mfil,
l_r_msgty TYPE bal_s_msty,
l_r_probclass TYPE bal_s_prcl.
* Definir categoria de mensagem

l_r_msgty-option = 'EQ'.
l_r_msgty-sign = 'I'.
l_r_msgty-low = 'E'. "erro
append l_r_msgty to l_s_msg_filter-msgty.
* Definir classe do problema
l_r_probclass-option = 'EQ'.
l_r_probclass-sign = 'I'.
l_r_probclass-low = '1'. "mensagens muito importantes
append l_r_probclass to l_s_msg_filter-probclass.
l_r_probclass-low = '2'. "mensagens importantes
append l_r_probclass to l_s_msg_filter-probclass.
===============================================================
Critérios de filtro para o contexto

=====================================================
==================
Esta categoria contém os critérios de filtro, que se referem ao Contexto. Esta categoria é composta por
RANGES para os diferentes campos do contexto.
Estes critérios de filtro estão estruturados como uma tabela interna, tendo cada entrada a seguinte
estrutura:
- TABNAME Nome da estrutura DDIC do contexto
- FIELDNAME Campo ao qual se refere o RANGE seguinte
- T_RANGE Tabela range com SIGN, OPTION, LOW e HIGH
• Exemplo
São procuradas as companhias aéreas 'SF' e 'AB':
================================================
DADOS:
l_t_context_filter TYPE bal_t_cfil,
l_s_context_filter TYPE bal_s_cfil,
l_s_range TYPE bal_rfield.
* Definir campo
l_s_context_filter-tabname = 'BAL_S_EX01'.
l_s_context_filter-fieldname = 'CARRID'.
* Definir companhias aéreas
l_s_range-option = 'EQ'.
l_s_range-sign = 'I'.
l_s_range-low = 'SF'.
append l_s_range to l_s_context_filter-t_range.
l_s_range-low = 'AB'.
append l_s_range to l_s_context_filter-t_range.
* Anexar resultado à tabela de filtro
append l_s_context_filter to l_t_context_filter.
...
===============================================================
Tabelas com handle de log e de mensagem

=====================================================
==================
Tabela com Identificadores de protocolos.
==>Nota
É uma tabela ordenada. Por conseguinte, as entradas não devem ser efetuadas com APPEND mas com
INSERT ... INTO TABLE9 nesta tabela.
Tabela com Identificadores de mensagens.
==>Nota
É uma tabela ordenada. Por conseguinte, as entradas não devem ser APPEND mas com INSERT ...
INTO TABLE nesta tabela.
|---------------------------------------------------------------------|
| Exibição do log de sistema: Princípio de função |
|---------------------------------------------------------------------|
Que informaçõe podem principalmente ser representadas ?

=====================================================
=================
A quantidade de mensagens na memória principal pode ser imaginada como uma tabela extremamente
larga com uma série de campos (na memória os dados não são gravados assim). Os campos possíveis
nesta tabela são:
• A linha de mensagem (MSGTY, MSGID, MSGNO, MSGV1, etc.)
• Os atributos de mensagem (PROBCLASS, DETLEVEL, etc.)
• Os campos de todos os contextos de mensagem ocorridos
• Os textos de mensagem:
o A linha de mensagem editada
o Os textos descritivos para os campos ("Muito importante" para classe de problema 1,

etc.)
• Dados do cabeçalho de log, à qual pertence esta mensagem:
o Dados de cabeçalho de log (EXTNUMBER, USER, DATUM, etc.)
o Os campos de todos os contextos de cabeçalho de log ocorridos
o Os textos de cabeçalho de log (portanto, textos descritivos para os campos)
• Dados externos, por exemplo o texto breve para material, anexados pelo programa de chamada
através de uma rotina de retorno
Oa campos representáveis estão listados na estrutura BAL_S_SHOW. Esta estrutura não contém os
campos dos contextos assim como os dados externos, visto que estes a priori podem não ser conhecidos
ao log de aplicação.
Como é efetuada a edição ?

=====================================================
=================
Esta (enorme) quantidade de dados tem de ser apresentada de forma adequada ao usuário. Através da
predefinição de um perfil, é possível controlar a edição dos dados. Este perfil não é nenhuma variável de
exibição que o usuário final possa definir, mas uma categoria de dados complexa a definir pelo programa
de chamada (estrutura BAL_S_PROF), que é transferida para o módulo de saída
BAL_DSP_LOG_DISPLAY .
A representação tem por base algumas suposições básicas:
• As mensagens são representadas em forma de lista. Esta lista contém um subconjunto dos
campos representáveis. Este subconjunto pode ser indicado por um catálogo de campos
(idêntico ao visor de listas ABAP), que é parte do perfil de exibição BAL_S_PROF.
• Para cada mensagem podem ser chamados detalhes:
o Texto descritivo para a mensagem
o Texto descritivo ampliado ou rotina CALLBACK
o Informações técnicas para uma mensagem (categoria de mensagem, área funcional, nº

de mensagem etc.)
• A quantidade de mensagens pode ser analisada com recursos do visor de listas ABAP (Procurar)
ou restringida (Filtrar). Além disso, no cabeçalho de lista existe a possibilidade de restringir
rapidamente a quantidade de dados em relação à categoria de mensagem (A, E; W; I/S). Um
clique sobre um ícone correspondente oculta ou insere, por exemplo, as mensagens I e S.
• Visto que a lista de mensagens pode ser extremamente comprida e pouco clara, é possível
anexar à navegação uma árvore de hierarquia. Esta árvore funciona quase como um índice para
a quantidade de mensagens. Ao efetuar um clique em um nó ou de uma folha ou do botão
correspondente, é possível exibir as mensagens correspondentes a este capítulo na lista. A
estrutura desta árvore também pode ser predifinida através do perfil de exibição.
|---------------------------------------------------------------------|
| Exibição do log de sistema: módulo de função
BAL_DSP_LOG_DISPLAY |
|---------------------------------------------------------------------|
Síntese
=====================================================
=================
BAL_DSP_LOG_DISPLAY Exibir logs
Categorias
BAL_S_PROF Perfil de exibição
BAL_S_LFIL Critérios de filtro para dados cabeçalho de log
BAL_S_MFIL Critérios de filtro para dados de mensagem
BAL_T_CFIL Critérios de filtro para dados de contexto
BAL_T_LOGH Tabela com identificadores de log
BAL_T_MSGH Tabela co identificadores de mensagen
Módulo de função BAL_DSP_LOG_DISPLAY

=====================================================
=================
Funcionalidade
A exibição standard dos logs do log de aplicação que se encontram no banco de dados é efetuada
através da transação SLG1. Esta representa os logs de um modo predefinido.
Dependente da aplicação, a saída de log por vezes tem de se apresentar de um modo diferente e é
necessário, representar logs que não foram gravados.
Como condição é suposto que na memória principal se encontre uma quantidade de logs com mensagens
correspondentes, que existem ou devido ao atual agrupamento de mensagens ou devido ao
carregamento de logs do banco de dados ( BAL_DB_LOAD).
Os dados podem ser exibidos através da chamada do módulo de função BAL_DSP_LOG_DISPLAY.

Este funciona como um motor de exibição, que é notificado sobre:
• I_S_LOG_FILTER, ... I_T_MSG_HANDLE

O QUE deve ser representado (através de Critérios de filtro)
• I_S_DISPLAY_PROFILE
COMO os dados devem ser representados (através de um Perfil de exibição)
• I_AMODAL
Se a exibição deve ser executada em um modo novo.
==>Nota
Na exibição em um modo novo é perdido o controle do programa. Já não é possível, atualizar a exibição
do log de sistema.
No parâmetro Exporting E_S_EXIT_COMMAND são obtidas informações sobre o motivo do

encerramento da exibição do log de sistema.
Exemplo
O report SBAL_DEMO_04 exibe várias opções para realizar a exibição do log de sistema ( ==>Executar
==>Coding).
O QUE deve ser representado ?
=====================================================
=================
A quantidade de dados a representar pode ser determinada através da indicação dos parâmetros
IMPORTING:
• Critérios de filtro relativos ao log
o I_S_LOG_FILTER Critérios de filtro para cabeçalhos de
o logs
o I_S_LOG_CONTEXT_FILTER Critérios de filtro para Contexto do cabeçalho de log
o I_T_LOG_HANDLE Tabela com identificadores de
o logs
• Critérios de filtro relativos à mensagem
o I_S_MSG_FILTER Critérios de filtro para mensagens
o I_S_MSG_CONTEXT_FILTER Critérios de filtro para contexto de mensagem
o I_T_MSG_HANDLE Tabela com identificadores de
o mensagem
Os filtros são as categorias de dados que também são utilizadas na pesquisa de mesnagens e logs.
Se a indicação de filtros não for suficiente é possível especificar alternativamente através da quantidade
de identificadores de logs e mensagens, que foram agrupadas segundo critérios próprios.
• Se forem indicados vários parâmetros, estes são submetidos a uma operação "E" lógica,
portanto, só são exibidas as mensagens, que preenchem simultaneamente todas as condições.
• Se só forem indicados os critérios de filtro relativos ao log, são representadas todas as

mensagens existentes na memória principal, cujos cabeçalhos de log preenchem os critérios
indicados (deste modo é possível que também sejam exibidos logs "vazios", portanto, logs que
não têm mensagens).
• Se só existirem critérios relativos à mensagem, são representadas todas as mensagens

existentes na memória principal, que preenchem estes critérios.
• Se não forem indicados nenhuns destes parâmetros, são exibidas todas as mensagens
existentes na memória principal.
COMO devem ser representados os dados ?

=====================================================
=================
O perfil de exibição (estrutura BAL_S_PROF) indica como se deve apresentar a exibição do log de
sistema. Este é composto principalmente por catálogos de campos, que descrevem que campos devem
aparecer na lista e nos diferentes níveis de capítulo da árvore de navegação.
O log de aplicação disponibiliza perfis de exibição predefinidos que podem ser chamados através de
módulos de função (ver aqui).
Também é possível "estruturar" um perfil de exibição próprio. Se não for indicado nenhum perfil de
exibição, é selecionado o perfil de exibição standard da transação SLG1.
O perfil de exibição contém os seguintes campos (exceto MESS_FCAT todos os campos são opcionais):
• Parâmetros gerais
o LANGU
O idioma para a saída do log
o TITEL
Título da tela
o USE_GRID
Para a representação das mensagens deve ser utilizado ALV Grid Control e não o VLA
habitual (será ignorado se a representação utilizar sempre, em conformidade com o
standard, o Grid Control).
o NO_TOOLBAR 'X':
'X': a barra de ferramentas por cima de ALV Grid é suprimida (só é adequado de
USE_GRID = 'X').
Se a barra de ferramentas for influenciada de outra forma, ainda existe a opção de
inserir botões próprios (ver EXT_PUSH1, ..., EXT_PUSH4) ou de mofificar
completamente a barra de ferramentas (ver CLBK_TOOLB).
o START_COL, START_ROW, END_COL, END_ROW

Coordenadas, no caso de o log deva aparecer como caixa de diálogo.
o POP_ADJST
Se este parâmetro for definido para 'X', o sistema tenta ajustar a altura da caixa de
diálogo (caso o log seja exibido na caixa de diálogo) à quantidade de dados a exibir. As
indicações supracitadas são consideradas limitações máximas.
o NOT_EMPTY
Se este parâmetro for definido para 'X', são omitidas as subárvores na exibição, se
forem constituídas por apenas uma entrada e todos outros dados (indicados no
catálogo de campos) forem iniciais.
Exemplo:
Dado que para o documento 1000013 não existem mensagens dependentes do item, a
árvore aparece inicialmente conforme se segue (classificação por nº de documento e nº
de item):
Documento 1000012
-- Item 0010
-- Item 0020
Documento 1000013
-- Item 0000
Documento 1000014
-- Item 0010
Com o flag NOT_EMPTY = 'X' é omitida a entrada "Item 0000", porque todos os campos
por detrás desta entrada são iniciais (também todos os invisíveis).
o COLORS
Indica as cores nas quais devem ser exibidas as classes de problemas. Com COLORS-
PROBCLASS1 = "3" são destacadas a amarelo, por exemplo, todas as mensagens com
a classe de problema 3 (standard).
Parâmetro para a lista das mensagens
o MESS_FCAT
Catálogo de campos para a lista de mensagem (categoria de tabela BAL_T_FCAT da
estrutura BAL_S_FCAT).
É possível exibir entre outros, todos os campos da estrutura BAL_S_SHOW assim
como campos do contexto da mensagem ou do cabeçalho de log.
o MESS_SORT
Tabela com seqüência de ordenação das mensagens (categoria de tabela
BAL_T_SORT da estrutura BAL_S_SORT).
Contém nome de tabela e nome de campo, nº de seqüência ordenada e código paa
ordenação ascendente ou descrescente. Os campos mencionados têm de ter sido
mencionados anteriormente em MESS_FCAT.
o SHOW_ALL
"X": Indica, que as mensagens são imediatamente exibidas na lista e que não têm de
ser primeiro selecionadas na árvore.
o MESS_MARK
"X": As mensagens podem ser selecionadas via campo de seleção.
o CWIDTH_OPT
A largura de coluna na lista das mensagens deve ser otimizada.
o DISVARIANT
Estrutura DISVARIANT: Dados para o visor de listas para variantes de exibição (nome
de report, identificador etc.)
Ter em consideração: se no mesmo programa também forem exibidas outras listas VLA
(ou ALV Grid), preencher também o identificador para que as variantes de exibição para
as listas diferentes não sejam misturadas.
• Parâmetro para a árvore de navegação
o LEV1_FCAT, ..., LEV9_FCAT

Catálogos de campos para nível de capítulo 1 a 9 (categoria de tabela BAL_T_FCAT da
estrutura BAL_S_FCAT).
É possível exibir entre outros, todos os campos da estrutura BAL_S_SHOW
assim como campos do contexto da mensagem ou do cabeçalho de log.
o LEV1_SORT, ..., LEV9_SORT

Tabela com seqüência de ordenação dos níveis de capítulo (categoria de tabela
BAL_T_SORT da estrutura BAL_S_SORT).
o HEAD_TEXT, HEAD_SIZE
CHAR/INTEGER: Conteúdo e largura do título da coluna por cima da árvore
o ROOT_TEXT
CHAR: Texto do nó raiz (só deve ser utilizado em casos excecionais. O nó raiz não
deve ser um título, este pertence a HEAD_TEXT).
o TREE_SIZE
INTEGER Tamanho do controle de árvore (em CHARACTER). Esta indicação de
tamanho é apenas uma indicação aproximada devido à fonte proporcional!
o TREE_ONTOP
"X": O controle de árvore é exibido por cima da lista de mensagens
o TREE_ADJST
"X": Caso a árvore se encontre por cima das mensagens (portanto, se for
TREE_ONTOP = 'X'), é tentado ajustar a altura da árvore ao número das linhas a
representar. TREE_SIZE é a altura máxima da árvore.
o EXP_LEVEL
1,.., 9 Indica, até que nível de árvore deve ser expandido.
o BYDETLEVEL
"X": Árvore de navegação deve ser estruturada segundo o campo DETLEVEL das
mensagens.
o TREE_NOMSG
"X": A árvore não contém dados das mensagens. A árvore é estruturada
exclusivamente de dados do cabeçalho de log.
• Rotinas de retorno
As rotinas de retorno são definidas através da estrutura DDIC BAL_S_CLBK.
o CLBK_READ
Leitura posterior de dados externos para a exibição (por exemplo, texto breve de
material)
(Para mais informações ver aqui).
o CLBK_UCOM
Execução de comandos do próprio usuário
o CLBK_UCBF
Se for chamado ANTES da execução de um comando próprio do usuário
o CLBK_UCAF
Se for chamado DEPOIS da execução de um comando próprio do usuário
o CLBK_PBO
PBO da exibição (por exemplo, para definir um status próprio)
o CLBK_TOOLB
Modificação da barra de ferramentas através do ALV Grid
(USE_GRID = 'X' é condição !)
• Botões próprios
o EXT_PUSH1, ..., EXT_PUSH4

Com estes componentes é possível colocar botões próprios no menu, sem ter de ser
definido um status GUI próprio. Para PAI, ao premir um destes botões, é acionado o
comando de usuário "%EXT_PUSH1", ... "%EXT_PUSH4", ao qual é possível reagir na
respetiva rotina callback. A definição de um botão é composta pelos seguintes
elementos:
EXT_PUSH1-ACTIVE = "X": Botão está ativo
EXT_PUSH1-DEF-TEXT Indica o texto do botão
EXT_PUSH1-DEF-ICON_ID Ícone do botão
EXT_PUSH1-DEF-ICON_TEXT Texto ao lado do ícone
EXT_PUSH1-DEF-QUICKINFO texto de informação rápida
EXT_PUSH1-DEF-PATH Código de seleção direta
EXT_PUSH1-POSITION item, no qual deve
aparecer o botão
' ': na barra de ferramentas de comando
'3': na barra de ferramentas por cima da lista de
mensagens, à esquerda (só em USE_GRID = 'X')
'4': na barra de ferramentas por cima da lista de
mensagens, à direita (só em USE_GRID = 'X')
O catálogo de campos BAL_T_FCAT
=====================================================
=================
Com o catálogo de campos BAL_T_FCAT são definidos, na exibição do log de sistema do log de
aplicação, os campos que devem se encontrar na lista de mensagens ou nos níveis diferentes da árvore
de navegação.
Uma entrada no catálogo de campos (estrutura BAL_S_FCAT) tem as seguintes informações:
• REF_TABLE, REF_FIELD
Nome de campo de tabela do campo a representar (por exemplo, BAL_S_SHOW-PROBCLASS).
Entre outros, é possível representar todos os campos da estrutura BAL_S_SHOW assim como
os campos do contexto da mensagem ou do cabeçalho do log.
Estes dois campos são obrigatórios, todos os outros são opcionais.
• COL_POS
Posição na qual deve surgir este campo.
Ter em consideração: o log de aplicação anexa implicitamente como primeira coluna o ícone
para a gravidade do erro. Esta coluna é fixa, pelo que aparece em todas as saídas (valor de
reconhecimento mais alto). Por conseguinte, os perfis standard entregues começam com a
coluna 2 (por exemplo, para o campo T_MSG, texto da mensagem). Os ícones para o texto
descritivo e o detalhe para a mensagem são anexados automaticamente.
Se, por exemplo, for pretendido modificar um perfil standard e inserir uma coluna antes do texto
da mensagem (portanto, na posição 2), as posições de coluna dos outros campos têm de ser
aumentadas em 1.
• OUTPUTLEN
Comprimento de saída
• PONTO ATIVO
• 'X': campo é um campo ativo (só é possível na lista das mensagens).
• COLTXT_ADD, COL_SEP
Normalmente, em cada nível de capítulo da árvore de navegação só devem ser representados
poucos campos (ideal seria apenas um), para não evadir o usuário com informações
desnecessárias. Podem existir 9 níveis, pelo que não é possível ter o nome de um campo como
título de coluna na árvore de navegação. Em vez de tal, é possível o nome de campo anteceder
o conteúdo de campo.
Exemplo: ‘Classe de problema: 1’ em vez de apenas ‘1’.
Isto só é possível através da definição do código COLTXT_ADD para ‘X’ no catálogo de campos.
Se for solicitado, é possível colocar ainda um separador (por exemplo, dois pontos) entre o
denominador de campo e o valor (COL_SEP = ‘:’).
• COLTEXT, COLDDICTXT, CLTXT_LEN

O texto situado à frente de um campo (ou por cima de uma coluna), pode ser indicado no
COLTEXT. Normalmente é retirado do DDIC, em COLDDICTXT é possível indicar objetivamente
o que deve ser utilizado (COLDDICTXT = "L", "M", "S", "R" indica, se deve ser utilizado o
denominador de campo comprido, médio ou curto ou o título). CLTXT_LEN indica o
comprimento.
• IS_TREECOL
No nível 1 é possível posicionar campos com um título de coluna. Neste caso o campo
IS_TREECOL deve ser definido para ‘X’. Estes aparecem na árvore de controle junto da árvore
correspondente.
• IS_EXTERN
Alguns campos não se encontram em uma mensagem ou no seu contexto, mas resultam
implicitamente deles. Por exemplo, se existir o nº de material no contexto, é possível derivar daí
o texto breve do material. Isto é possível efetuar na rotina de retorno BAL_CALLBACK_READ.
Nesta rotina são tratados todos os campos que no catálogo de campos têm o código
IS_EXTERN = "X".
• NO_OUT
Alguns campos têm apenas um caráter técnico e não devem ser exibidos (por exemplo,
LOG_HANDLE). Neste caso deve ser definido o código NO_OUT.
• TECH 'X': campo é um campo técnico e não ocorre no catálogo de seleção de campos.
O catálogo de ordenação BAL_T_SORT

=====================================================
=================
Com o catálogo de ordenação BAL_T_SORT é definido na exibição do log de sistema do log de
aplicação, em que seqüência ordenada devem ser ordenadas as mensagens ou as entradas na árvore de
navegação.
Uma entrada no catálogo de ordenação (estrutura BAL_S_SORT) tem as seguintes informações:
• REF_TABLE, REF_FIELD
Nome de campo de tabela do campo a representar (por exemplo BAL_S_SHOW-PROBCLASS)
==>Nota
Este campo TEM de ser mencionado no catálogo de campos para as mensagens ou os níveis de
capítulos!
• SPOS
Seqüência de ordenação
• UP, DOWN
Direção de ordenação para cima ou para baixo
|---------------------------------------------------------------------|
| Exibição de log de sistema: Perfis de exibição no standard
|
|---------------------------------------------------------------------|
Síntese
=====================================================
=================
Aos módulos de exibição do log de aplicação é transferido, entre outros, um chamado Perfil de exibição,
que descreve como o log deve ser representado.
O log de aplicação fornece perfis de exibição predefinidos diferentes, que podem ser chamados através
dos módulos de função (e -- se for pretendido -- também modificados).
BAL_DSP_PROFILE_STANDARD_GET Perfil standard (SLG1) para muitos logs
BAL_DSP_PROFILE_SINGLE_LOG_GET Perfil standard (SLG1) para um log
BAL_DSP_PROFILE_NO_TREE_GET Representação sem árvore (tela inteira)
BAL_DSP_PROFILE_POPUP_GET Representação sem árvore (popup)
BAL_DSP_PROFILE_DETLEVEL_GET Hierarquia segundo DETLEVEL das mensagens
Programa de exemplo
Report SBAL_DEMO_04 exibe possibilidades diferentes como é possível realizar uma exibição do log de
sistema
Perfil standard (SLG1) para muitos logs
=====================================================
=================
Funcionalidade
BAL_DSP_PROFILE_STANDARD_GET devolve o Perfil deexibição, que é utilizado na transação de
exibição standard do log de aplicação ( SLG1), para exibir muitos logs de uma só vez.
Nesta edição é possível encontrar na árvore de navegação no nível de capítulo 1, o cabeçalho de log com
os seus dados, no nível 2 a classificação é efetuada segundo a classe de problema. A lista de mensagens
inclui principlamente o texto de mensagem.
A mensagem primeiro não é exibida. Só depois de o usuário selecionar um log (ou um subconjunto
deste), é que são exibidas as mensagens.
Exemplo
Report SBAL_DEMO_04_STANDARD ( ==>Executar ==>Coding)
Perfil Standard (SLG1) para um log

=====================================================
=================
Funcionalidade
BAL_DSP_PROFILE_SINGLE_LOG_GET devolve um Perfil de exibição, que é utilizado na transação de
exibição standard do log de aplicação ( SLG1), se for exibido apenas um log.
Nesta edição é possível encontrar na árvore de navegação no nível de capítulo 1, o cabeçalho de log com
os seus dados, no nível 2 a classificação é efetuada segundo a classe de problema. A lista de mensagens
inclui principlamente o texto de mensagem.
A representação foi otimizada em relação à apresentação de um único log:

- a classificação segundo a classe de problema já está expandida
- a lista de mensagens é completamente exibida
Exemplo
Report SBAL_DEMO_04_SINGLE_LOG ( ==>Executar ==>Coding)
Representação sem árvore (tela inteira)

=====================================================
=================
Funcionalidade
BAL_DSP_PROFILE_NO_TREE_GET devolve um Perfil de exibição, que representa as mensagens
como uma lista simples em uma tela completa.
Na lista de mensagens é possível ver principalmente o texto de mensagem.
Nesta edição não existe nenhuma árvore de navegação, para navegar pelas mensagens.
Exemplo
Report SBAL_DEMO_04_NO_TREE ( ==>Executar ==>Coding)
Representação sem árvore (popup)

=====================================================
=================
Funcionalidade
BAL_DSP_PROFILE_POPUP_GET devolve um Perfil de exibição, que representa as mensagens em
um popup em forma de lista.
Da lista de mensagens consta sobretudo o texto da mensagem.
Nesta edição não existe qualquer árvore de navegação, que permita navegar pelas diferentes
mensagens.
Exemplo
Report SBAL_DEMO_04_POPUP ( ==>Executar ==>Coding)
Hierarquia segundo o campo DETLEVEL das mensagens

=====================================================
=================
Funcionalidade
BAL_DSP_PROFILE_DETLEVEL_GET devolve um Perfil deexibição que estrutura a árvore de
navegação a partir dos textos de mensagem.
É obtido o nível na árvore a partir do campo DETLEVEL, que pode ser predefinido ba estrutura
BAL_S_MSGAo criar uma mensagem (por exemplo, com o módulo de função BAL_LOG_MSG_ADD).
Exemplo
m log contém os seguintes dados:
Categoria DETLEVEL texto de mensagem

S 1 Faturamento companhia aérea SAP Flights
S 2 Vôo 007 de Hamburgo para Toronto
S 3 Fatura 17003115 criada com êxito
E 3 Fatura 17003117 está incorreta
E 4 Cliente 1234 no documento 17003117: dados de endereço
incompletos.
...
É obtida a seguinte representação:

Faturamento Companhia aérea SAP Flights
| Vôo 007 de Hamburgo para Toronto
| Fatura 17003115 criada com êxito
| Fatura 17003117 está incorreta
| Cliente 1234 no documento 17003117: Dados de
endereço...
....
Na árvore, a gravidade de erro é transferido de forma ascendente, isto é se a mensagem "Cliente 1234 no
documento 17003117: Dados de endereço incompletos." for um erro (ícone vermelho), isto é transferido
automaticamente para os níveis superiores.
Ver também o report SBAL_DEMO_04_DETLEVEL ( ==>Executar ==>Coding)
|---------------------------------------------------------------------|
| Exibição do log de sistema na subtela |
|---------------------------------------------------------------------|
Funcionalidade
A exibição do log de sistema do log de aplicação também pode ser instalada como subtela.
Exemplo
O report SBAL_DEMO_04_SUBSCREEN exibe, como é possível efetuar a inclusão da exibição do log de
sistema na subtela
( ==>Executar ==>Coding).
Módulos de função relacionados

BAL_DSP_OUTPUT_INIT Inicialização da saída
BAL_DSP_OUTPUT_SET_DATA Definição da quantidade de dados aexibir
BAL_DSP_OUTPUT_FREE Encerrar saída
Procedimento
• Definir área de subtela na própria tela
Por exemplo, em um registro (se nome da área de subtela for MY_SUBSCREEN).
Para PBO tem de ser efetuada a chamada
CALL SUBSCREEN MY_SUBSCREEN INCLUDING 'SAPLSBAL_DISPLAY' '0101'.
Para PAI apenas:
CALL SUBSCREEN MY_SUBSCREEN.
• Antes da chamada da tela ou apenas uma vez para PBO

Inicialização da exibição através do módulo de função BAL_DSP_OUTPUT_INIT. Este módulo
de função obtém como parâmetro IMPORTING basicamente apenas o Perfil de exibição, que
controla como devem ser representados os dados.
o ==>ATENÇÃO
Neste perfil de exibição tem de estar definido USE_GRID = 'X'! Esta opção nem sempre
é definida pelos módulos de função standard BAL_DSP_PROFILE_... !
• Após a chamada de BAL_DSP_OUTPUT_INIT

Chamada do módulo de função BAL_DSP_OUTPUT_SET_DATA. Este módulo de função indica
que dados devem ser representados.
Este módulo de função pode ser chamado várias vezes, se por exemplo, entretanto a quantidade
de dados a exibir tenha sido modificada.
É configurado de modo semelhante ao módulo de função BAL_DSP_LOG_DISPLAY, pelo que
contém Critérios de filtro, que determinam que dados, que se encontram na memória principal,
devem ser exibidos.
• Encerramento da exibição
Chamada do módulo de função BAL_DSP_OUTPUT_FREE. Através desta chamada são
desativados os controles e os recursos novamente liberados.
==>Nota
Os módulos de função BAL_DSP_OUTPUT_INIT e BAL_DSP_OUTPUT_FREE têm de formar sempre um
par, porque através do primeiro é aumentada a pilha do log de aplicação em 1 e através do segundo é
reduzido novamente em 1.
Esta lógica permite que na exibição do log de sistema seja possível ramificar para a exibição de um outro
log (por exmeplo, em uma caixa de diálogo).
|---------------------------------------------------------------------|
| Gravar e carregar logs |
|---------------------------------------------------------------------|
Síntese
=====================================================
==================
Logs que foram acumulados na memória principal, também podem ser gravados no banco de dados.
Logs gravados podem ser carregados novamente para a memória principal e serem modificados ou
exibidos.
BAL_DB_SAVE Gravar logs no banco de dados
BAL_DB_SAVE_PREPARE Preparar gravação
BAL_DB_SEARCH Procurar logs no banco de dados
BAL_DB_LOAD Carregar logs do banco de dados
BAL_LOG_REFRESH Retirar log da memória principal
BAL_GLB_MEMORY_REFRESH Reinicializar memória global (parcialmente)
Exemplo
Report SBAL_DEMO_05 ( ==>Executar ==>Coding) simula um processamento de faturamento para
todos os vôos efetuados em uma determinada data. Existe a opção entre três entradas de menu:
• Efetuar faturamento apenas de forma "simulativa".

Os "documentos" são agrupados na memória principal e têm apenas nºs temporários. O log
também contém nºs temporários.
• Executar faturamento "real".

No banco de dados é gravado um log. Contudo, antes os nºs de documentos temporários são
substituídos por nºs "finais" no log.
• Exibir logs.
Gravar logs
=====================================================
==================
Funcionalidade
É possível gravar logs na memória principal com o módulo de função BAL_DB_SAVE. É possível arquivar
todos os dados da memória principal no banco de dados (Parâmetro importing I_SAVE_ALL = 'X'), mas
também pode ser especificado um subconjunto através da indicação de uma quantidade de
identificadores de log (Parâmetro importing I_T_LOG_HANDLE).
Esta tabela de identificadores de log pode ser obtida através da chamada do módulo de função
BAL_GLB_SEARCH_LOG, que na memória principal efetua a pesquisa de logs segundo determinados
critérios de filtro.
Ao gravar logs é atribuído um nº de log interno (campo LOGNUMBER). Contudo, durante o tempo de
execução este campo está apenas preenchido com um valor temporário (por exemplo $00001).
Por conseguinte, o módulo de função BAL_DB_SAVE devolve uma tabela (Parâmetro exporting
E_NEW_LOGNUMBERS), que compara o LOG_HANDLE, o nº externo EXTNUMBER, o LOGNUMBER
temporário e o LOGNUMBER final. Assim, depois de gravar é possível determinar o nº que foi atribuído a
um log.
A gravação também é possível em IN UPDATE TASK (Parâmetro importing I_IN_UPDATE_TASK = 'X').
Além disso, é possível gravar logs em um outro mandante (parâmetro I_CLIENT). Se I_CLIENT não for
indicado, a gravação é efetuada no mandante atual.
Notas
Depois da gravação de logs, estes continuam na memória principal. O seu estado é como se tivessem
acabado de ter sido carregados do banco de dados. Se for pretendido retirar logs já gravados na memória
principal, utilizar o módulo de função BAL_LOG_REFRESH (para um log ) ou
BAL_GLB_MEMORY_REFRESH (para vários ou todos os logs).
Por motivos de compatibilidade, o campo LOGNUMBER continua visível para o programa de chamada.
Tem a desvantagem de durante o tempo de execução ter apenas um valor temporário e só se tornar um
valor final ao gravar. Assim, todas as tabelas de aplicação, que através do LOGNUMBER indicam um log,
têm de ser atualizadas na gravação.
Ao utilizar o campo LOG_HANDLE, isto é desnecessário. Na criação de um log, o LOG_HANDLE possui

imediatamente o seu valor final (com BAL_LOG_CREATE) .
Preparação da gravação
=====================================================
==================
Funcionalidade
Às vezes nas Mensagens do log de aplicação, pode acontecer que as variáveis de mensagem ou os
Contextos contenham dados que ainda não têm os seus valores finais.
Um exemplo típico são nºs de documentos. Ao criar um documento, inicialmente é atribuído um nº

temporário (por exemplo ‘$0001’). Só quando o documento for gravado, é utilizado um nº final do intervalo
consecutivo de numeração.
Se tenham sido criadas mensagens para um documento destes, é possível, por exemplo as variáveis de
mensagem conterem nºs temporários. Na gravação estes valores temporários devem ser substituídos por
valores finais (portanto, por exemplo $0001 por 0000123456), caso contrário o log não tem valor.
Uma substituição deste tipo pode ser executada pelo módulo de função BAL_DB_SAVE_PREPARE.
Para o módulo de função são transferidos modelos de substituição (categoria de tabela BAL_T_RPLV),
que descrevem por exemplo, que as variáveis de mensagem com o conteúdo anterior ‘$0001’ (campo
OLD_VALUE) devem ser substituídas pelo valor novo ‘12345’ (campo NEW_VALUE). E ‘$0002’ por
‘67890’ etc.
Para informações de contexto também é possível definir substituições (categoria de tabela

BAL_T_RPLC). Por exemplo, em todos os contextos, que tenham a estrutura DDIC ‘MY_STRUC’
(TABNAME), substituir os dados no campo ‘VBELN’ (FIELDNAME), nomeadamente ‘$0001’
(OLD_VALUE) por ‘12345’ (NEW_VALUE), etc.
Com I_REPLACE_IN_ALL_LOGS = 'X' é indicado que a substituição deve ser efetuada em todos os log
que se encontram na memória principal. Contudo, se se pretender efetuar uma substituição em apenas
determinados logs, é possível definir I_REPLACE_IN_ALL_LOGS = ' ' e indicar os identificadores de log
pretendidos I_T_REPLACE_IN_THESE_LOGS.
• ==>Nota
Na generalidade, a substituição das variáveis de mensagem é uma operação insegura, porque
não se tem a certeza se por exemplo, o conteúdo da variável de mensagem MSGV1 em uma
determinada mensagem continha um nº de ordem. Poderia também se tratar de um nº
temporário (casualmente igual) de um documento completamente diferente, que foi gerado em
background e para o qual também foram entradas mensagens.
Para evitar esta ambiguidade, é possível especificar a origem de uma variável de mensagem ao
enviar uma mensagem. Isto é efetuado através de indicações nos campos MSGV1_SRC, ...,
MSGV4_SRC na estrutura BAL_S_MSG. Ao substituir as variáveis de mensagem com
BAL_DB_SAVE_PREPARE é possível fazer referência a estes indicadores (campo
MSGV_SRC).
Procurar logs no banco de dados

=====================================================
==================
Funcionalidade
Se no banco de dados estiverem gravados logs, estes têm de ser possíveis encontrar novamente. Isto
pode ser efetuado através do módulo de função BAL_DB_SEARCH.
Para este são transferidos critérios de filtro para o cabeçalho de log (estrutura BAL_S_LFIL) e é
devolvida uma tabela de cabeçalhos de logs (estrutura BALHDR), que correspondem aos critérios.
Esta tabela pode ser transferida para o módulo BAL_DB_LOAD BAL_DB_LOAD, que carrega estes logs
para a memória principal.
• ==>Nota
Ao estruturar a estrutura de filtro BAL_S_LFIL deve ser tomado em consideração, de não
provocar nenhum FULL TABLE SCAN. Através da indicação dos seguintes campos ou
combinações de campos, é possível encontrar um log sem FULL TABLE SCAN.:
- LOGNUMBER (é o índice primário da tabela do cabeçalho de log)
- LOG_HANDLE (existe um índice)
- OBJECT/SUBOBJECT/EXTNUMBER (existe um índice)
Se for pretendido acessar eficientemente um log a partir de qualquer objeto de aplicação, este
tem de ter gravado nas suas estruturas ou LOGNUMBER ou LOG_HANDLE, ou o campo
EXTNUMBER deve ser preenchido com uma chave unívoca, que é obtida a partir dos dados do
objeto de aplicação (por exemplo, o nº de documento). Juntamente com a indicação de
OBJECT/SUBOBJECT (portanto, a aplicação que escreveu o log), o acesso é unívoco.
Além disso, é possível indicar na estrutura de filtro outros critérios, tais como as restrições de
tempo ou a transação, com a qual foi criado o log.
• ==>Nota A pesquisa também pode ser efetuada em outro mandante. Este pode ser incluído em
I_CLIENT. O módulo de função BAL_DB_LOAD considera automaticamente o mandante
indicado em E_T_LOG_HEADER. Se I_CLIENT não for indicado, é utilizado o mandante atual.
Carregar logs do banco de dados

=====================================================
==================
Funcionalidade
É possível carregar logs do banco de dados com o módulo de função BAL_DB_LOAD.
A indicação dos logs que devem ser carregados na memória principal, pode ser efetuada de diversas
formas (em alternativa):
• I_T_LOG_HANDLE
Uma tabela com identificadores de log
• I_T_LOGNUMBER
Uma tabela com nºs de log internos
• I_T_LOG_HEADER
Uma tabela com cabeçalhos de log (código de retorno de módulo de função BAL_DB_SEARCH)
Como resultado da operação de carregamento, é possível retirar uma tabela com identificadores de log
(parâmetro de exportação E_T_LOG_HANDLE) ou identificadores de mensagem (parâmetro de
exportação E_T_MSG_HANDLE).
Este módulo funciona de modo de intermandantes:
• No caso de indicação de I_T_LOG_HANDLE também são efetuadas eliminações em todos os

mandantes (isto não é crítico, dado que o identificador de log é unívoco a nível mundial)
• No caso de indicação de I_T_LOGNUMBER é considerado o mandante especificado no

parâmetro I_CLIENT. Caso contrário, é utilizado o mandante atual.
• No caso de indicação de I_T_HEADER é considerado o mandante indicado no campo de tabela

MANDANT (é preenchido automaticamente pelo módulo de função BAL_DB_SEARCH).
Outros parâmetros:
Com o parâmetro de importação I_DO_NOT_LOAD_MESSAGES, é possível indicar que primeiro só
sejam carregados os cabeçalhos de log para a memória principal. Ver Leitura conforme as
necessidades das mensagens de um log.
Com o parâmetro de importação I_EXCEPTION_IF_ALREADY_LOADED = 'X', é possível propor que a
exceção LOG_ALREADY_LOADED seja acionada, caso um dos logs a carregar já esteja na memória
principal. Neste caso, não é carregado um único log.
I_EXCEPTION_IF_ALREADY_LOADED = ' ' (default) leva a que um log a carregar seja ignorado, caso
este já esteja em uma memória principal. No entanto, todos os logs ainda não carregados são carregados
corretamente.
Nota
No entanto, se for pretendido carregar o status do banco de dados, também é possível utilizar o módulo
de função BAL_DB_RELOAD. Eventualmente, este elimina primeiro um log da memória principal para
depois o carregar.
Leitura de mensagens de um log segundo as necessidades

=====================================================
==================
Com o parâmetro I_DO_NOT_LOAD_MESSAGES = "X" é possível controlar no módulo de função
BAL_DB_LOAD, que primeiramente só devem ser carregados os cabeçalhos de log para a memória
principal.
As mensagens de um log só são carregadas para a memória principal no caso de determinados eventos:
• se as mensagens forem acessadas durante a leitura (por exemplo, para a exibição do log de
sistema ou com o módulo de função BAL_LOG_MSG_READ)
• se o log for acessado durante a modificação (por exemplo, no caso de modificação dos dados de
cabeçalho com o módulo de função BAL_LOG_HDER_CHANGE ou ao anexar mensagens com
BAL_LOG_MSG_ADD)
• se for chamado o módulo de função BAL_DB_RELOAD para este log.
Se forem recarregadas as mensagens de um log, mas apenas uma vez. As mensagens não são
recarregadas individualmente. Por isso, um log está se encontra apenas com o cabeçalho de log ou
completo na memória principal.
A indicação I_DO_NOT_LOAD_MESSAGES = "X" não tem qualquer efeito, se tiver sido definida uma
estatística com o módulo de função BAL_STATISTICS_GLB_SET ou BAL_STATISTICS_LOG_SET (uma
estatística no log de aplicação é uma análise, que em um determinado momento fornece informações
sobre os erros, avisos etc. que existem relativamente a um critério indicado, por exemplo "3 erros para
material ABC").
Visto que esta estatística tem por base os dados de mensagem, as mensagens, neste caso, têm de ser
sempre lidas.
A indicação I_DO_NOT_LOAD_MESSAGES = "X" é muito útil se apenas interessarem os dados do

cabeçalho do log.
Esta característica também pode ser utilizada na exibição de logs:
Se o perfil de exibição para a exibição do log de sistemas estiver estruturado de modo a que na árvore só
sejam necessários os dados do cabeçalho de log, é suficiente ler só os cabeçalhos de log para a memória
principal. Se na árvore for selecionadao um log, as mensagens do log são automaticamente lidas
posteriormente para a exibição.
Contudo, não é possível o módulo de função BAL_DSP_LOG_DISPLAY reconhecer automaticamente se

na árvore só se encontram dados do cabeçalho de log. Isto é devido ao fato de na árvore também
poderem ser utilizadas informações de contexto. Contudo, estas podem estar anexadas tanto a uma
mensagem como ao cabeçalho de log. Por este motivo, no perfil de exibição I_S_DISPLAY_PROFILE
(estrutura BAL_S_PROF) tem de ser explicitamente indicado, que a árvore não contém dados de
mensagem. Isto é efetuado através da indicação I_S_DISPLAY_PROFILE-TREE_NOMSG = ‘X‘.
• ==>Nota
De resto
I_DO_NOT_LOAD_MESSAGES = ‘X‘
e a opção de perfil de exibição
I_S_DISPLAY_PROFILE-TREE_NOMSG = ‘X‘
só fazem sentido, se no perfil de exibição estiver
I_S_DISPLAY_PROFILE-SHOW_ALL = ‘ ‘
caso contrário, as mensagens seriam exibidas imediatamente.
|---------------------------------------------------------------------|
| Eliminar logs no banco de dados |
|---------------------------------------------------------------------|
Síntese
=====================================================
==================
Para que não ocorra um estouro nas tabelas do banco de dados do log de aplicação, os logs também têm
de ser eliminados. Isto pode ser efetuado de dois modos:
• Com a transação standard SLG2 eliminar logs. Esta transação segue uma determinada lógica na
eliminação de logs, que será referida mais abaixo.
• Com os módulos de função do log de aplicação, que são chamados pela aplicação (por exemplo,
ao eliminar um objeto de aplicação ou em uma transação de aplicação)
BAL_DB_DELETE Elimina logs no banco de dados
Transação SLG2: Eliminação de logs

=====================================================
==================
Esta transação é um report, em cuja tela de seleção é possível indicar que logs devem ser eliminados. É
possível executar este report on-line (Programa -> Executar (F8)) ou por exemplo, também em
background (Programa ->Executar em background (F9)). Por fim, também pode ser planejado um job
regular.
• Opções
o Determinar apenas número

O report não lê dados do banco de dados, mas só determina, quantos logs são
possíveis eliminar. Isto é muito rápido e é a opção default.
o Gerar lista
Os logs não são eliminados, mas só aparece uma lista dos logs que são possíveis
eliminar. O usuário pode selecionar os logs que pretende eliminar.
Se existirem mais de 100 logs elimináveis, apenas são exibidos os primeiros 100, os
100 seguintes caso sejam solicitados, etc.
o Eliminar imediatamente
Todos os logs elimináveis são imediatamente eliminados no banco de dados
(aconselhável em batch).
• Condições de seleção
A quantidade dos logs a eliminar pode ser predefinida pelas condições de seleção. É possível
indicar o objeto/subobjeto do log de aplicação, o nº externo, o nº de log, a classe de problema
assim como a data/hora da criação.
• Data de vencimento
No entanto, nem todos os logs, que preenchem as condições de seleção supracitadas, são
elimináveis.
Um log só pode ser eliminado depois de vencido.
Isto significa: a data de vencimento do log foi atingida ou excedida. A data de vencimento é
predefinida na criação de um log com o módulo de função BAL_LOG_CREATE nos dados do
cabeçalho do log (estrutura BAL_S_LOG) pelo campo ALDATE_DEL.
Contudo, este campo ALDATE_DEL só é preenchido em relativamente poucos casos. Por
standard, o log de aplicação define a mesma para 31.12.2098. Por conseguinte, estes logs
jamais seriam eliminados e permanceceriam permanentemente no sistema.
Por este motivo, o report tem na rúbrica "Data de vencimento" as seguintes opções:
o Eliminar apenas logs, cuja data de vencimento foi realmente atingida

Esta é a opção standard, que no entanto, não elimina os logs nos quais não foi indicada
a data de vencimento.
o Também logs, nos quais é permitida a eliminação antes do vencimento

Esta opção proporciona que também sejam eliminados os logs, nos quais a data de
vencimento ainda não foi atingida, mas que nos quais o código DEL_BEFORE é inicial.
DEL_BEFORE tal como ALDATE_DEL pode ser incluído ao abrir um log. Por standard,
é inicial, isto é, "Eliminação antes do vencimento" é permitida.
Portanto, na eliminação de logs o usuário pode proceder em duas etapas:
• Na primeira etapa tenta eliminar apenas os logs realmente vencidos.
• Se a etapa1 não for efetiva porque alguns logs são difíceis e continuam a permanecer no
sistema, o usuário pode tentar eliminar também aqueles nos quais é permitida a eliminação
antes do vencimento. Nesta etapa o usuário tem também a possibilidade de restringir
objetivamente em objetos/subobjetos.
Para o programador da aplicação existem possibilidades diferentes para selecionar, tal como a data de
vencimento ALDATE_DEL o o código DEL_BEFORE, quando o módulo de função BAL_LOG_CREATE
for chamado. Alguns exemplos:
• O log deve ser eliminado o mais rapidamente possível

ALDATE_DEL = sy-datum.
DEL_BEFORE = space.
É possível eliminar o log no dia de criação.
• O log deve ser eliminável em 100 dias, não antes

ALDATE_DEL = sy-datum + 100.
DEL_BEFORE = "X".
O tempo de permanência de 100 dias tem de ser indicado pela aplicação. Atualmente, o log de
aplicação não tem nenhum customizing, no qual possam ser definidos os tempos de
permanência (por exemplo, em função do objeto/subobjeto do log de aplicação).
• Manter o log o máximo de tempo possível

ALDATE_DEL = "20981231". (ou inicial)
DEL_BEFORE = space.
Deste modo, o log permanece no sistema, se a transação de eliminação SLG2 for executada
com a opção standard "Só logs realmente vencidos". Só quando a opção "Também logs, nos
quais é permitida a eliminação antes do vencimento" for selecionada, é eliminado o log.
• O log não pode ser eliminado de modo algum pela transação standard
ALDATE_DEL = "20981231". (ou inicial)
DEL_BEFORE = "X".
Um log destes tem de ser explicitamente eliminado pela aplicação (ver capítulo seguinte).
==>Nota
Antes do release 4.6A não existia a transação SLG2. Nestes releases a eliminação de logs era efetuada
pelo report RSSLG200. Este report não estava configurado e eliminava todos os logs que estavam
realmente vencidos. Com RSSLG210 era possível planejar este report como um job.
Se era pretendido eliminar logs, nos quais a eliminação era permitida antes da data de vencimento, tinha
de ser utilizado o report RSSLGK90, que também continha condições de seleção relativas ao
objeto/subobjeto do log de aplicação, etc.
Eliminação de logs através de módulos de função

=====================================================
==================
Funcionalidade
Para eliminar logs a partir da aplicação, está à disposição o módulo de função BAL_DB_DELETE.
Os logs a eliminar podem ser transferidos de três formas

diferentes para o módulo de função (só em alternativa):
• I_T_LOG_HANDLE: tabela com identificadores de log.

Esta indicação é sobretudo adequada se o LOG_HANDLE tiver sido armazenado na própria
aplicação.
• I_T_LOGNUMBER: Tabela com nºs de log.

É possível utilizar esta tabela se, em vez do LOG_HANDLE, for utilizado o nº de log
LOGNUMBER (talvez ainda de releases anteriores) como referência ao log na tabela de
aplicação.
• I_T_LOGS_TO_DELETE: tabela com cabeçalhos de log.

Esta tabela é o código de retorno do módulo de função BAL_DB_SEARCH. Este módulo de
função é utilizado caso não exista qualquer referência ao log na tabela de aplicação, sendo, em
vez disso, criada a ligação através do campo EXTNUMBER no cabeçalho de log. Neste caso,
indicar o log de aplicação objeto/subobjeto e o nº externo no filtro para BAL_DB_SERACH.
BAL_DB_DELETE funciona de modo de intermandantes:
• No caso de indicação de I_T_LOG_HANDLE também são eliminados logs em outros mandantes

(isto não é crítico, porque o identificador de log é unívoco)
• No caso de indicação de I_T_LOGNUMBER as eliminações são efetuados no mandante

I_CLIENT. Se I_CLIENT não for indicado, as eliminações são efetuadas no mandante atual
• No caso de indicação de I_T_LOG_HEADER é considerado o mandante indicado no campo

MANDANT (é preenchido automatiamente pelo módulo de função BAL_DB_SEARCH).
Outros parâmetros:
O parâmetro I_IN_UPDATE_TASK no módulo de função BAL_DB_DELETE, indica se a eliminação na
tarefa de atualização deve ser executada.
O parâmetro I_WITH_COMMIT_WORK indica se o módulo de função BAL_DB_DELETE deve acionar um

COMMIT WORK. Isto é uma vantagem se o objetivo for eliminar muitos logs com muitos dados.
Normalmente, existe no banco de dados limitações relativas ao segmento rollback ou ao número dos
bloqueios de banco de dados para entradas em tabela a eliminar. De modo a não exceder estes limites,
BAL_DB_DELETE trabalha por blocos, se I_WITH_COMMIT_WORK = "X" .
Notas:
O módulo de função BAL_DB_DELETE não executa verificações se um log pode ser eliminado (data de
expiração, etc.). É necessário que estas verificações sejam efetuadas na aplicação.
Existem vários cenários na eliminação de logs a partir da aplicação:
• O log tem de ser eliminado, porque o objeto, que indica para o log, é eliminado.
Neste caso, é possível transferir diretamente ao módulo de eliminação o LOG_HANDLE,
LOGNUMBER, etc.
• Verificar primeiro se o log é eliminável.

Os dados de cabeçalho de log mais importantes podem ser lidos diretamente com
BAL_DB_SEARCH. É possível verificar a tabela E_T_LOG_HEADER e transferir os logs
elimináveis para BAL_DB_DELETE.
• Os dados de BAL_DB_SEARCH não são suficientes para a verificação.

Este procedimento é um pouco mais demorado e deve constituir uma exceção:
o O log é carregado com BAL_DB_LOAD para a memória principal (com a opção

I_DO_NOT_LOAD_MESSAGES = "X" só são carregados todos os dados de cabeçalho
do log).
o Com BAL_LOG_HDR_READ é possível ler e verificar os dados do cabeçalho do log, e

determinar os logs elimináveis.
o Os logs carregados são retirados com BAL_LOG_REFRESH da memória principal ...
o ... e os logs elimináveis são eliminados com BAL_DB_DELETE no banco de dados.
==>Nota
Antes do release 46A não existia o módulo de função BAL_DB_DELETE. Em vez deste, existiam os
módulos de função APPL_LOG_DELETE e APPL_LOG_DELETE_WITH_LOGNUMBER.
Estes módulos de função também eliminavam logs, contudo, apenas aqueles vencidos ou nos quais era
permitida a eliminação antes do vencimento.
==>Nota
Ao eliminar logs também é acessada uma rotina de retorno, na qual é possível eliminar tabelas próprias,
que foram anexadas a um log (Para mais informações ver aqui).
|---------------------------------------------------------------------|
| Modificar logs |
|---------------------------------------------------------------------|
Síntese
=====================================================
==================
Com o log de aplicação não só é possível criar logs como também modificá-los. Esta opção não existe
apenas para os logs novos criados na memória principal durante o tempo de execução, mas também para
logs já gravados no banco de dados. Para tal, estão à disposição alguns módulos de função, que se
seguem.
BAL_DB_ENQUEUE Bloquear log
BAL_DB_LOAD Carregar log(s)
BAL_DB_SAVE Gravar log(s)
BAL_DB_DEQUEUE Desbloquear log
BAL_LOG_MSG_CHANGE Modificar mensagem
BAL_LOG_MSG_DELETE Eliminar mensagem
BAL_LOG_EXCEPTION_CHANGE Modificar exceção
BAL_LOG_EXCEPTION_DELETE Eliminar exceção
BAL_LOG_HDR_CHANGE Modificar cabeçalho de log
BAL_LOG_DELETE Eliminar log (também no BD ao gravar)
BAL_LOG_REFRESH Retirar log da memória principal
Bloquear e desbloquear logs

=====================================================
==================
Se for pretendido modificar um log já gravado, este tem de ser carregado com o módulo de função
BAL_DB_LOAD na memória principal e, depois das modificações, gravado novamente com
BAL_DB_SAVE.
Para que um log não seja modificado simultaneamente por dois programas, o log deve ser bloqueado
antes de carregá-lo com BAL_DB_ENQUEUE. Isto é efetuado sob a indicação do Handle de log
I_LOG_HANDLE.
Ao bloquear é possível incluir adicionalmente o denominado parâmetro SCOPE, que controla quando é
anulado automaticamente um bloqueio (ver Conceito de bloqueio SAP).
Após a gravação, é possível desbloquear novamente um log com BAL_DB_DEQUEUE.
Modificar logs
=====================================================
==================
Existem as seguintes opções para modificar logs:
• Modificar mensagem com BAL_LOG_MSG_CHANGE

Sob indicação do Handle de mensagem I_S_MSG_HANDLE é possível modificar
completamente os Dados de mensagem (I_S_MSG).
• Eliminar mensagem com BAL_LOG_MSG_DELETE

A mensagem é eliminada com o Handle de mensagem I_S_MSG_HANDLE.
• Modificar exceção com BAL_LOG_EXCEPTION_CHANGE

Sob a indicação do Handle de mensagem I_S_MSG_HANDLE é possível modificar
completamente os dados de exceção (I_S_EXC).
• Eliminar exceção com BAL_LOG_EXCEPTION_DELETE

A exceção pode ser eliminada com o Handle de mensagem I_S_MSG_HANDLE
• Modificar os dados do cabeçalho de log com BAL_LOG_HDR_CHANGE

Sob a indicação do Handle de log I_LOG_HANDLE é possível modificar completamente os
dados de cabeçalho de log (I_S_LOG).
• Eliminar completamente o log com BAL_LOG_DELETE

O log que se encontra na memória principal com o Handle de log I_LOG_HANDLE é eliminado
na memória principal e ao gravar com BAL_DB_SAVE também seria eliminado no banco de
dados.
==>Nota
Se for pretendido eliminar apenas logs no banco de dados, sem carregá-los previa e adicionalmente para
a memória principal, deve ser utilizado o módulo de função BAL_DB_DELETE.
==>Nota
Se for pretendido eliminar apenas um log da memória principal, sem que na gravação também seja
eliminado fisicamente do banco de dados, deve ser utilizado o módulo de função BAL_LOG_REFRESH.
Este também pode ser utilizado, por exemplo, se um log tiver sido gravado com BAL_DB_SAVE e se for
pretendido limpá-lo posteriormente da memória principal.
|---------------------------------------------------------------------|
| Início da transação |
|---------------------------------------------------------------------|
Síntese
=====================================================
==================
Os módulos de função de aplicação são chamados frequentemente nos mais diversos contextos:
• Diálogo
• Processamento em massa
• Processamento na entrada EDI
• ...
Dependente deste ambiente, as mensagens são tratadas de formas diferentes.
• No diálogo uma mensagem deve ser saída imediatamente.
• No processamento em massa, as mensagens devem ser primeiro reunidas, para no final serem
saídas como log.
• Também são possíveis formas mistas: No caso de modificação de 100 itens da ordem nem
diálogo, não deve ser saída uma mensagem para cada item, mas no final deve aparecer uma
caixa de diálogo com as mensagens.
• Pode acontecer que o programa de chamada de um módulo de função pretenda decidir como
devem ser tratadas as mensagens que surgem: as mensagens do módulo de função chamado
não devem ser reunidas, visto que são demasiado técnicas. Ou devem apenas ser reunidas as
mensagens importantes.
O ideal é não indicar a um módulo de função chamado, como tratar as suas mensagens. Este envia as
mensagens que surgem para o log de aplicação e o PROGRAMA DE CHAMADA decide como tratá-las
(por exemplo, sair diretamente ou reunir).
Por conseguinte, é possível configurar no início da transação o log de aplicação. Esta configuração
também pode ser protegida para que não seja substituída durante a execução do programa.
BAL_GLB_CONFIG_SET Definir configuração
BAL_GLB_CONFIG_GET Ler configuração
BAL_GLB_AUTHORIZATION_GET Conceder autorização
BAL_GLB_AUTHORIZATION_RESET Devolver autorização
BAL_GLB_MEMORY_REFRESH Inicializar memória (parcialmente)
BAL_MSG_DISPLAY_ABAP Sair mensagem como ABAP-MESSAGE
Categorias
BAL_S_CONF Dados de configuração
BALAUTH Autorização
Definir e ler configuração
=====================================================
==================
O log de aplicação pode ser configurado no início da transação com o módulo de função
BAL_GLB_CONFIG_SET.
Para tal, o parâmetro de importação I_S_CONFIGURATION é transferido para o módulo de função que
tem a estrutura BAL_S_CONF.
As configurações definidas podem ser novamente chamadas com BAL_GLB_CONFIG_GET.
BAL_S_CONF descreve que as mensagens enviadas para o log de aplicação devem realmente ser
agrupadas (componente COLLECT) e que as mensagens devem ser saídas imediatamente no momento
da criação (componente DISPLAY):
• COLLECT-INACTIVE
COLLECT-INACTIVE = 'X' desativa completamente o agrupamento de mensagens.
COLLECT-INACTIVE = ' ' ativa novamente o agrupamento
• COLLECT-MSG_FILTER, COLLECT-CON_FILTER
Determina, que as mensagens devem ser reunidas pelo log de aplicação. Estes critérios de filtro
são referentes aos Dados de mensagem, podendo a filtragem relativa aos atributos de
mensagem ser efetuada com COLLECT-MSG_FILTER ou com COLLECT-CON_FILTER em
relação ao contexto da mensagem.
A indicação destes filtros não tem efeito se estiver definido COLLECT-INACTIVE = 'X'.
• DISPLAY-INACTIVE
DISPLAY-INACTIVE = 'X' serve para que não sejam exibidas nenhumas mensagens, se forem
enviadas para o log de aplicação.
DISPLAY-INACTIVE = ' ' serve para que as mensagens com a rotina de retorno DISPLAY-
CALLBACK indicada sejam exibidas. Se DISPLAY-CALLBACK não estiver preenchido,
DISPLAY-INACTIVE = ' ' não tem qualquer efeito.
• DISPLAY-MSG_FILTER, DISPLAY-CON_FILTER
Aqui são indicadas, tal como para o agrupamento, que mensagens devem ser exibidas (se for
DISPLAY-INACTIVE = ' ' e tiver sido indicada uma rotina de retorno).
• DISPLAY-CALLBACK
Isto é uma Rotina de retorno, que deve exibir uma mensagem. Esta apenas é acessada se for
DISPLAY-INACTIVE = ' ' e se uma mensagem for adequada para o filtro indicado (para mais
informações relativas à rotina de retorno ver aqui). Esta rotina apenas pode ser utilizada para
mensagens T100, mas não para exeções.
Exemplo 1
O programa principal chama BAL_GLB_CONFIG_SET, para providenciar que apenas sejam agrupadas
mensagens de erro e advertências do log de aplicação. Todas os outros tipos de mensagens devem ser
ignorados.
Exemplo 2
Além disso, é pretendido que todas as mensagens de erro muito importantes sejam exibidas
imediatamente na criação, nomeadamente como ABAP-MESSAGE (isto não deve ser confundido com a
saída de log normal, que por exemplo, poderia ser efetuada no final da transação!).
No standard atualmente só é entregue uma rotina de visualização (módulo de função

BAL_DSP_MSG_DISPLAY_ABAP). Isto poderia, por exemplo, ser utilizado, se for chamado um módulo
de verificação tanto no processamento em background como também no diálogo. No processamento em
background é configurado que devem ser agrupadas todas as mensagens, em contrapartida, no diálogo
não é efetuado nenhum agrupamento, mas sim saído diretamente. Em PAI de uma tela surge, por
exemplo, a mensagem de erro correspondente.
Em releases posteriores, seria possível efetuar outras rotinas de saída, por exemplo, para executar
também uma lista de mensagens em uma janela não-modal.
==>Nota
A performance do log de aplicação pode ser muito prejudicada através da indicação de filtros complexos,
visto que em cada envio de uma mensagem tem de ser verificado, se esta mensagem deve ser agrupada
ou exibida. Por isso, os filtros devem ser o mais simples possível.
Por este motivo, esta característica não deve ser utilizada para representar controles definidos pelo
cliente (denominadas mensagens de erro controláveis: em função de determinados critérios, o cliente
pode definir no customizing, se uma mensagem deve ser agrupada, e se assim for, com que tipo de
mensagem). Este tipo de solicitações conduz a filtros complexos.
==>Nota
Para a verificação se uma mensagem é agrupada ou exibida, são utilizados os dados de mensagem que
são obtidos ao tomar em consideração as Predefinições para as mensagens.
A configuração atua sobre os módulos de função seguintes:

BAL_LOG_MSG_ADD Anexar mensagem a um log
BAL_LOG_EXCEPTION_ADD Anexar exceção ao log
BAL_LOG_MSG_CUMULATE Anexar mensagem acumulada
BAL_LOG_MSG_ADD_FREE_TEXT Anexar mensagem como texto livre
Autorização
=====================================================
==================
Normalmente as funções críticas com a configuração (módulo de função BAL_GLB_CONFIG_SET) e a
inicialização (módulo de função BAL_GLB_MEMORY_REFRESH) só devem ser executadas pelo
programa principal. As rotinas inferiores não devem executar estas atividades globais.
Por vezes surgem problemas, porque uma rotina inferior chama o módulo de inicialização, por exemplo,
porque esta rotina originalmente não foi concebida para uma chamada neste contexto.
É possível evitar este tipo de efeitos com o conceito de autorização:

O programa principal (portanto, aquele que obtem primeiro o controle do programa), pode obter uma
autorização no início com o módulo de função BAL_GLB_AUTHORIZATION_GET. Este módulo de
função devolve emE_AUTHORIZATION uma chave unívoca.
As funções críticas supracitadas só podem ser executadas com a indicação da chave

I_AUTHORIZATION. Se I_AUTHORIZATION não for incluído ou se tiver o valor incorreto, a ação é
recusada (por exemplo, inicializar a memória). BAL_GLB_AUTHORIZATION_GET também não é
executável, portanto, não é possível chamar uma segunda chave.
Existe a possibilidade devolver novamente a sua chave com BAL_GLB_AUTHORIZATION_RESET (por

sua vez, isto também só pode ser efetuado sob indicação da chave).
Em seguida, é possível chamar novamente todos módulos de função sem autorização.
Os módulos de função seguintes têm uma autorização:

BAL_GLB_AUTHORIZATION_GET
BAL_GLB_AUTHORIZATION_RESET
BAL_GLB_CONFIG_SET
BAL_GLB_MEMORY_REFRESH
BAL_GLB_MSG_DEFAULTS_SET
BAL_STATISTICS_GLB_SET
==>Nota
Se for pretendido retirar apenas os dados de um único log, utilizar o módulo de função
BAL_LOG_REFRESH. Este não está protegido por uma autorização, visto que só tem efeito sobre um
único log e não sobre toda a memória do grupo de funções.
==>Nota
Na programação tem de ser tomado em conta que determinadas ações podem ser recusadas. Não se
deve confiar no êxito da ação.
• ==>Exemplo
É muito comum, inicializar a memória, chamar uma função e em seguida verificar no log se
ocorreram erros. O processamento de exceções (portanto, as execções na execução
doprograma) é transferido para a ferramenta do log, que no entanto, não é a sua finalidade!
Um procedimento destes deve ser evitado, porque é possível controlar de fora que mensagens
são agrupadas pelo log de aplicação e se a memória é reinicializada. Ao fim ao cabo, não existe
o controle sobre as mensagens que efetivamente se encontram no log.
|---------------------------------------------------------------------|
| Outros módulos de função |
|---------------------------------------------------------------------|
Síntese
=====================================================
=================
Seguem-se outros módulos de função, que até à data não foram referidos.
Trabalhar em toda a área roll

=====================================================
=================
BAL_GLB_MEMORY_EXPORT coloca a memória do grupo de funções na memória ABAP.
Estes dados podem ser chamados novamente com BAL_GLB_MEMORY_IMPORT. Se já existirem logs,
os logs importados são anexados aos existentes.
Verificações de dados e verificações de existência

=====================================================
=================
Dados que entram no log de aplicação são submetidos a determinadas verificações. Assim, o objeto do
log de aplicação indicado no cabeçalho de log tem de existir realmente. Se em uma mensagem for
incluído um contexto, também tem de ser indicado o nome da estrutura DDIC correspondente.
Estas verificações estão agrupadas em BAL_LOG_HDR_CHECK e em BAL_LOG_MSG_CHECK. As

verificações são exeutadas automaticamente ao criar uma mensagem e um log, mas por motivos de
encapsulamento estão abertas (para o caso de o usuário pretender, por exemplo, utilizar estas
verificações no próprio coletor de mensagens).
Com os módulos de função BAL_LOG_EXIST e BAL_LOG_MSG_EXIST é possível verificar (com a

indicação de um identificador de log ou de mensagem), se ainda se encontra na memória principal um log
ou uma mensagem.
Ver e verificar objeto de log de aplicação e subobjeto

=====================================================
=================
Se em um cabeçalho de log for indicado um objeto ou um subobjeto, o log de aplicação verifica se estas
indicações existem ou se são adequadas.
Estas funções estão encapsuladas e arquivadas e estão disponíveis para o acesso externo:
BAL_OBJECT_SELECT lê um registro da tabela de objetos do log de aplicação
BAL_SUBOBJECT_SELECT lê um registro da tabela dos subobjetos
BAL_OBJECT_SUBOBJECT verifica, se o objeto e o subobjeto existem e se a combinação é permitida.
Exibição do log de sistema: Telas detalhadas

=====================================================
=================
Na exibição do log de sistema é possível consultar para uma mensagem e para o cabeçalho de log,
detalhes diferentes. Estes detalhes estão encapsulados com os módulos de função e é possível chamá-
los independentemente da exibição do log. Como parâmetros de importação são necessários o
identificador de log ou de mensagem e o idioma.
• Telas detalhadas da mensagem:
o BAL_DSP_MSG_LONGTEXT:
É exibido o texto descritivo de uma mensagem.
o BAL_DSP_MSG_PARAMETERS
Saída do texto descritivo ampliado ou chamada de uma rotina CALLBACK (com base
nos dados em BAL_S_MSG-PARAMS)
o BAL_DSP_MSG_TECHNICAL_DATA
Saída dos dados técnicos de um mensagem, como área funcional, nº de erro, etc.
• Telas detalhadas para o cabeçalho de log:
o BAL_DSP_LOG_PARAMETERS
Saída do texto descritivo ampliado ou chamada de uma rotina CALLBACK (com base
nos dados em BAL_S_LOG-PARAMS)
o BAL_DSP_LOG_TECHNICAL_DATA
Saída de todos os dados de cabeçalho de log
==>Nota
Os módulos de função indicados saiem os dados tal como na ajuda F1. Isto é, na respetiva opção do
usuário (Ajuda->Opções) é possível efetuar a exibição do texto descritivo, do texto descritivo ampliado,
etc. de forma amodal.
|---------------------------------------------------------------------|
| Síntese das rotinas callback |
|---------------------------------------------------------------------|
Síntese
=====================================================
=================
A representação seguinte proporciona uma síntese sobre as rotinas de retorno existentes no log de
aplicação. São listadas as seguintes informações:
• Finalidade e momento
O que é feito na rotina de retorno e em que momento é acessada?
• Definição
Como é definida esta rotina de retorno?
• Configuração
Como tem de ser configurada
o ==>Nota
Uma rotina callback (rotina de retorno) pode ser efetuada em dois modos diferentes se
for utilizado o log de aplicação:
como rotina FORM ou como módulo de função
A definição de uma rotina callback inclui a indicação dos campos seguintes:
USEREXITT: Tipo de rotina (' ' = FORM, 'F' = módulo de função)
USEREXITP: Programa, no qual se encontra o usuário (só em FORM)
USEREXITF: Nome de rotina (nome de rotina FORM ou módulo defunção)
Um módulo de função tem de ser configurado como a rotina FORM (USING deve ser
substituído por IMPORTING). Além disso, manter impreterivelmente os mesmos nomes
de parâmetro.
Programa exemplo
Como exemplo e modelo funciona o report SBAL_CALLBACK.
==>Executar SBAL_CALLBACK ==>Coding SBAL_CALLBACK
BAL_CALLBACK_DISPLAY
=====================================================
=================
Finalidade e momento
É possível determinar como deve ser visualizada uma mensagem no momento da criação.
Por exemplo, todas as mensagens (ou apenas uma parte) surgem em uma janela amodal, de modo que o
usuário é constantemente informado sobre a evolução do programa (esta solução ainda não está
disponível).
Definição
No parâmetro I_S_CONFIGURATION do módulo de função BAL_GLB_CONFIG_SET no campo
I_S_CONFIGURATION-DISPLAY-CALLBACK.
Configuração
FORM bal_callback_display
USING
i_s_msg TYPE bal_s_msg.
...
ENDFORM.
Programa de exemplo
Como exemplo e modelo serve o report SBAL_CALLBACK.
A tela de seleção deste report permite, por exemplo, selecionar BAL_CALLBACK_DISPLAY. O depurador
é lançado, aquando
- da definição da rotina de retorno
- do processamento da rotina de retorno
Também é possível procurar pela cadeia "BAL_CALLBACK_DISPLAY" no Código do report.
BAL_CALLBACK_DETAIL_LOG
=====================================================
=================
Nesta rotina de retorno podem ser representados detalhes próprios para um cabeçalho de protocolo.
Estes são chamados se na exibição do log de sistema o cursor tiver sido posicionado sobre uma linha de
cabeçalho de log e se tiver sido premido o botão 'Detalhe'.
Definição
A rotina de retorno é definida por cabeçalho do log no momento da criação de um log com
BAL_LOG_CREATE. Na estrutura de transferência I_S_LOG (estrutura BAL_S_LOG) tem de ser
definido o campo I_S_LOG-PARAMS-CALLBACK .
Configuração
FORM bal_callback_detail_log
TABLES
i_t_params STRUCTURE spar.
...
ENDFORM.
A tabela interna I_t_params contém como campos:

PARAM (CHAR10) Nome do parâmetro
VALUE (CHAR75) Conteúdo do parâmetro.
I_t_params contém os parâmetros, que foram criados em BAL_S_LOG-PARAMS-T_PAR para um log.
Adicionalmente, ainda é incluído na tabela sob o nome '%LOGNUMBER' o nº de log.
Caso estas informações forem insuficientes, é possível chamar através do módulo de função
BAL_DSP_USER_COMMAND_DATA_GET os dados que descrevem os objetos atualmente
selecionados na exibição do log de sistema.
Nos dados também pode ser encontrado por exemplo, o identificador do log atual
(E_S_USER_COMMAND_DATA-TREE_LOGH).
Com esta indicação é possível providenciar outros dados para o log (por exemplo, com o módulo de
função BAL_LOG_HDR_READ ).
Programa de exemplo
A tela de seleção deste report permite, por exemplo, selecionar BAL_CALLBACK_DETAIL_LOG. O
depurador é lançado, aquando
Também é possível procurar pela cadeia "BAL_CALLBACK_DETAIL_LOG" no Código do report.
BAL_CALLBACK_DETAIL_MSG
=====================================================
=================
Nesta rotina de retorno é possível representar detalhes próprios para uma mensagem. Estes são
chamados se na exibição do log de sistema o cursor tiver sido definido sobre uma linha de log e tiver sido
premido o botão ‘Detalhes’. Como ‘Abreviatura’ também é possível clicar diretamente sobre o ícone de
detalhes ao lado da mensagem.
Definição
A rotina de retorno é definida por mensagemno momento do envio de uma mensagem, por exemplo com
BAL_LOG_MSG_ADD. Definir com o parâmetro Importing I_S_MSG (estrutura BAL_S_MSG) o campo
I_S_MSG-PARAMS-CALLBACK.
Configuração
FORM bal_callback_detail_msg
TABLES
i_t_params STRUCTURE spar.
...
ENDFORM.
A tabela interna I_t_params contém como campos:

PARAM (CHAR10) Nome do parâmetro
VALUE (CHAR75) Conteúdo do parâmetro.

I_t_params contém os parâmetros que foram criados em BAL_S_MSG-PARAMS-T_PAR para uma
mensagem (por exemplo, através de BAL_LOG_MSG_ADD).
Adicionalmente, ainda é incluído na tabela sob o nome '%LOGNUMBER' o nº de log assim como as
quatro variáveis de mensagem (sob 'V1' a 'V4').
Caso estas informações forem insuficientes, é possível chamar através do módulo de função
BAL_DSP_USER_COMMAND_DATA_GET os dados que descrevem os objetos atualmente
selecionados na exibição do log de sistema.
Nos dados também pode ser encontrado por exemplo, o identificador do

(E_S_USER_COMMAND_DATA-LIST_MSGH).
Com esta indicação é possível providenciar outros dados para o log (por exemplo, com o módulo de
função BAL_LOG_MSG_READ).
Programa de exemplo
A tela de seleção deste report permite, por exemplo, selecionar BAL_CALLBACK_DETAIL_MSG. O
depurador é lançado, aquando
Também é possível procurar pela cadeia "BAL_CALLBACK_DETAIL_MSG" no Código do report.
BAL_CALLBACK_READ
=====================================================
=================
Nesta rotina de retorno é possível efetuar uma leitura posterior dos dados para a exibição do log de
sistema, por exemplo, o texto breve para material. A rotina é chamada para cada mensagem e para cada
campo, que foram definidos no catálogo de campos como externos. Para evitar problemas de
performance, ler impreteterivelmente os dados armazenados em buffer. Não é possível efetuar um
prefetch ou processar a tabela dos dados a ler posteriormente de uma só vez, visto que estes dados são
estruturados de forma dinâmica.
Definição
Na exibição do log de sistema (por exemplo, chamado com BAL_DSP_LOG_DISPLAY) o perfil de
exibição I_S_DISPLAY_PROFILE é imcluído (estrutura BAL_S_PROF). A rotina de retorno é definida no
campo I_S_DISPLAY_PROFILE-CLBK_READ. Esta rotina é chamada para todos os campos que nos
Catálogos de campos LEV1_FCAT, ..., LEV9_FCAT ou MESS_FCAT têm o atributo IS_EXTERN = ‘X’ .
Configuração
FORM bal_callback_read
USING
i_s_info TYPE bal_s_cbrd
CHANGING
c_display_data TYPE bal_s_show
c_context_header TYPE bal_s_cont
c_context_message TYPE bal_s_cont
c_field TYPE any.
...
ENDFORM.
A estrutura i_s_info indica para que campo foi chamada a rotina callback
(REF_TABLE e REF_FIELD). O conteúdo do campo deve ser colocado em c_field.
Para preencher c_field são necessários os outros dados de mensagem (por

exemplo, o nº de material, se for pretendido determinar o texto breve do
material).
Estes dados podem ser encontrados em c_display_data (contém dados
representáveis da mensagem e do cabeçalho de log correspondente),
c_context_header (contexto para o cabeçalho de log) e c_context_message
(contexto para a mensagem).
==>Nota
Esta rotina CALLBACK é chamada em dois momentos diferentes. O momento que se apresenta, é
notificado através do campo I_S_INFO-IS_MESSAGE:
1. I_S_INFO-IS_MESSAGE = ' ' ==> Chamada na estrutura da árvore
2. I_S_INFO-IS_MESSAGE = 'X' ==> Chamada na estrutura da lista de mensagens
Ambas as operações são (normalmente) separadas temporalmente: A árvore é imediatamente
estruturada, quando surgir a exibição do log de sistema, contudo a lista de mensagens só quando o
usuário tiver selecionado na árvore um subconjunto de mensagens.
Esta situação é utilizada para a otimização de performance: Só são preenchidos os campos na estrutura
c_display_data, que são necessários neste momento.
• ==>Exemplo
Quando a árvore for estruturada é necessário determinar o texto de mensagem. Isto levaria
muito tempo. O texto de mensagem só é determinado quando o usuário tiver, por exemplo,
selecionado 100 mensagens (de um total de talvés 1.000 mensagens) da árvore.
Isto tem efeitos sobre os dados na estrutura c_display_data:

_S_INFO-IS_MESSAGE = ' '
Ao chamar para a árvore só estão preenchidos de certeza aqueles campos em c_display_data, que são
mencionados nos catálogos de campos LEV1_FCAT a LEV9_FCAT.
I_S_INFO-IS_MESSAGE = 'X'
Ao chamar para a lista só estão preenchidos de certeza aqueles campos em c_display_data, que são
mencionados em MESS_FCAT.
Esta situação deve ser tomada em consideração se for utilizada esta rotina callback.
Programa de exemplo
A tela de seleção deste report permite, por exemplo, selecionar BAL_CALLBACK_READ. O depurador é
lançado, aquando
Também é possível procurar pela cadeia "BAL_CALLBACK_READ" no Código do report.
BAL_CALLBACK_PBO
=====================================================
=================
Nesta rotina é possível definir um menu próprio para a exibição do log de sistema. Deste modo podem ser
integrados na exibição do log de sistema outros elementos específicos da aplicação. Esta rotina é
chamada para PBO da exibição do log do sistema.
Definição
No Anzeigeprofil, campo CLBK_PBO.
Configuração
FORM bal_callback_pbo
USING
i_t_extab TYPE slis_t_extab.
...
ENDFORM.
I_t_extab contém os códigos de função não ativos. Esta tabela tem de ser impreterivelmente incluída, se
for pretendido incluir nesta rotina o menu próprio:
SET PF-STATUS 'MY_STATUS' EXCLUDING i_t_extab.
==>Nota
Se for pretendido definir um menu próprio, normalmente é copiado e modificado o menu do log de
aplicação. Contudo, isto tem a desvantagem de não ser possível efetuar futuras modificações no menu
standard do log de aplicação.
Se se pretender ter apenas alguns botões na exibição do log de sistema, é recomendado utilizar no Perfil
de exibição os componentes EXT_PUSH1 a EXT_PUSH4.
Programa de exemplo
A tela de seleção deste report permite, por exemplo, selecionar BAL_CALLBACK_PBO. O depurador é
lançado, aquando
Também é possível procurar pela cadeia "BAL_CALLBACK_PBO" no Código do report.
BAL_CALLBACK_TOOLBAR
=====================================================
=================
Se para a exibição for utilizado ALV Grid Control
(parâmetro USE_GRID = 'X' no perfil de exibição), é possível modificar nesta rotina a barra de
ferramentas por cima do ALV Grid.
Deste modo, é possível integrar outros elementos específicos da aplicação na exibição do log de sistema.
Esta rotina é chamada se:
• for gerada a barra de ferramentas
• na barra de ferramentas for premido um botão, atrás do qual se encontra um subponto.
Definição
No Perfil de exibição, campo CLBK_TOOLB.
Configuração
FORM bal_callback_toolbar
USING
c_s_toolbar_info TYPE bal_s_tbi
* se a barra de ferramentas estiver preenchida, é possível modificá-la:

IF NOT c_t_toolbar_info-toolbar IS INITIAL.
* anexar um botão simples
CLEAR l_s_toolbar.
l_s_toolbar-butn_type = 0. "botão normal
l_s_toolbar-function = 'MY_BUTTON'.
l_s_toolbar-icon = icon_ws_rail.
l_s_toolbar-quickinfo = 'Botão novo'(nbt).
INSERT l_s_toolbar INTO c_t_toolbar_info-toolbar->mt_toolbar
INDEX 2.
* anexar um botão com submenu
CLEAR l_s_toolbar.
l_s_toolbar-butn_type = 1. "botão com submenu
l_s_toolbar-function = 'MY_MENU'.
l_s_toolbar-icon = icon_ws_ship.
l_s_toolbar-quickinfo = 'Menu novo'(nmn).
INSERT l_s_toolbar INTO c_t_toolbar_info-toolbar->mt_toolbar
INDEX 3.
ENDIF.
* se o menu estiver preenchido é possível anexar entradas ao submenu:

IF NOT c_t_toolbar_info-menu IS INITIAL.
IF c_t_toolbar_info-ucomm = 'MY_MENU'.
CALL METHOD c_t_toolbar_info-menu-> add_function
EXPORTING fcode = 'MY_SUBMENU_1'
text = text-ms1.
CALL METHOD c_t_toolbar_info-menu->add_function
EXPORTING fcode = 'MY_SUBMENU_2'
text = text-ms2.
ENDIF.
ENDIF.
ENDFORM.
BAL_CALLBACK_UCOMM, BAL_CALLBACK_BEFORE_UCOMM,
BAL_CALLBACK_AFTER_UCOMM
=====================================================
=================
o BAL_CALLBACK_UCOMM é chamado, se para PAI for acionado um comando que não corresponda
ao log de aplicação.
o BAL_CALLBACK_BEFORE_UCOMM é acessado para os comandos supracitados e adicionalmente
para alungs comandos standard, antes da execução do comando.
o BAL_CALLBACK_AFTER_UCOMM: mas após a execução.
Nos seguintes comandos standard são executados ..._BEFORE_... e ..._AFTER_... :

o %LONGTEXT Texto descritivo
o %DETAIL Detalhes para mensagem/cabeçalho de log
o %TECHDET Detalhes técnicos para mensagem/cabeçalho de log
o &IC1 Clique duplo na mensagem ou elemento na árvore
o %EXT_PUSH1 Botão definido externamente 1
Definição
o BAL_CALLBACK_UCOMM: No Perfil de exibição, campo CLBK_UCOM
o BAL_CALLBACK_BEFORE_UCOMM: No perfil de exibição, campo
CLBK_UCBF
o BAL_CALLBACK_AFTER_UCOMM: No perfil de exibição, campo
CLBK_UCAF
Configuração
FORM bal_callback_ucomm
CHANGING
c_s_user_command_data TYPE bal_s_cbuc.
...
ENDFORM.
Programa de exemplo
A tela de seleção deste report permite, por exemplo, selecionar BAL_CALLBACK_UCOMM. O depurador
é lançado, aquando
Também é possível procurar pela cadeia "BAL_CALLBACK_UCOMM" no Código do report.
Idêntico para os outros dois CALLBACKs.
Os dados nas rotinas callback

=====================================================
=================
BAL_S_CBUC serve para a configuração de rotinas callback, que são acessadas na exibição do log de
sistema do log de aplicação quando for premida uma tecla na exibição do log de sistema.
A estrutura contém informações sobre o status de exibição atual (o que foi selecionado, onde se encontra
o cursor etc.).
Além disso, esta estrutura também contém alguns campos, que podem ser modificados na rotina callback
(Atualizar a exibição ou encerrar?)
Informações detalhadas dos campos:

• Campos gerais
o UCOMM
Código de função acionado
• Campos modificáveis na rotina callback
o UCOMM_EXEC
'X': O comando foi processado com êxito.
' ': O comando não foi processado.
UCOMM_EXEC pode ser utilizado, se BAL_CALLBACK_CBBF for utilizado e se for
pretendido reagir a um comando standard e não executar o standard.
CALLBACK_AFTER_UCOMM é sempre acessado independentemente do fato de um
comando ter sido processado ou não.
o EXIT
Exibição do log de sistema deve ser encerrada.
o REFRESH
A exibição do log de sistema deve ser completamente reestruturada.
Isto pode ser útil se as mensagens básicas na memória principal foram modificadas (por
exemplo através de BAL_LOG_MSG_CHANGE) ou eliminadas
(BAL_LOG_MSG_DELETE).
A reestruturação exibe precisamente as mensagens que na chamada inicial
correspondem aos critérios de filtro indicados (por exemplo todas as mensagens de um
log => mensagens novas também são exibidas).
Se o usuário pretender exibir uma outra quantidade de mensagens (por exemplo um
outro log), é possível utilizar o módulo de função BAL_DSP_OUTPUT_SET_DATA
(neste caso não deve ser definido o código REFRESH, caso contrário a exibição é
reestruturada duas vezes).
Mas atenção: na reestruturação são determinados de novo todos os dados (por
exemplo, os textos de mensagem). Pelo que no caso de quantidades de mensagem
grandes, esta opção deve ser utilizada com cuidado, visto que a reestruturação demora
tanto tempo como a primeira exibição.
o MARKS_DEL
Devem ser eliminadas as marcações de mensagem. Este código só é importante, se no
perfil de exibição tiver sido selecionada a opção de marcar várias mensagens
(I_S_DISPLAY_PROFILE-MESS_MARK = 'X').
o MSGTY, MSGID, MSGNO, MSGV1, MSGV2, MSGV3, MSGV4

Mensagem que deve ser saída. Isto pode ser importante, se por exemplo, o usuário
deve ser notificado que para esta função tem de ser marcada uma mensagem.
Uma mensagem (por exemplo: 'Marcar uma mensagem') normalmente, não é saída
diretamente no log de aplicação em uma rotina de processamento, mas colocada na
estrutura c_s_user_command_data, porque podem existir outras rotinas de
processamento, que pretendam substituir esta mensagem.
• Informações relativas à árvore de navegação
o TREE_CLICK
Foi efetuado um clique duplo na árvore.
o TREE_LEVEL
Nível da árvore que foi marcado
o TREE_TABLE, TREE_FIELD, TREE_VALUE

Nome de tabela, nome de campo e conteúdo do campo que foi marcado (caso a
marcação seja apenas referente a um campo)
o TREE_SELF
Tabelas com nomes de campo e contéudos, que foram marcadas (caso a marcação
seja referente a vários campos, por exemplo 'Usuário/Data/Hora').
o TREE_LOGH
Identificador do log que foi marcado na árvore (caso a marcação represente exatamente
um log). Isto é, por exemplo, o caso se na exibição do log de sistema
standard (transação SLG1) for marcado um log no nível superior da árvore.
o TREE_MSGH
Identificador da mensagem que foi marcada na árvore.
Este campo só é preenchido se na árvore forem representadas mensagens.
(Isto é o caso se a exibição começar por I_S_DISPLAY_PROFILE-BYDETLEVEL = 'X',
portanto, por exemplo com o perfil standard do módulo de função
BAL_DSP_PROFILE_DETLEVEL_GET).
• Informações relativas às lista de mensagens
o LIST_MSGH
Mensagem marcada na lista (através do posicionamento do cursor)
o LIST_TMSGH
Quantidade de mensagens marcadas.
Este campo só é preenchido, se no perfil de exibição tiver sido selecionada a opção de
marcar várias mensagens (I_S_DISPLAY_PROFILE-MESS_MARK = 'X').
o LIST_TABLE, LIST_FIELD, LIST_VALUE

Nome de tabela, nome do campo e conteúdo do campo, que foi marcado na exibição.
• Campos internos
o LIST_SEL, LIST_COL, LIST_ROW, LIST_TABIX, TREE_NODE, TREE_ITEM,

LIST_REFR
CALLBACK_DB_DELETE
=====================================================
=================
Esta rotina é acessada, se forem eliminados logs no banco de dados.
Assim, também é possível eliminar dados que foram criados para o log em tabelas de banco de dados
próprias (por exemplo, tabelas de índices).
Definição
A definição é ligeiramente diferente do habitual: a rotina de retorno só pode ser definida como módulo de
função.
Este módulo de função tem de seguir uma determinada convenção de nomes:
Se ABC for o nome do objeto do log de aplicação, definido na transação SLG0, é acessado o módulo de
função BAL_DBDEL_ABC, se for eliminado um log no banco de dados, que tem no cabeçalho de log o
objeto ABC. O subobjeto não é tomado em consideração.
Configuração
FUNCTION BAL_DBDEL_...
*"----------------------------------------------------------------
*"*"Interface local:
*" IMPORTING
*" REFERENCE(I_T_LOGS_TO_DELETE) TYPE BALHDR_T
*" REFERENCE(I_IN_UPDATE_TASK) TYPE BOOLEAN
*"----------------------------------------------------------------
...
ENDFUNCTION.
I_T_LOGS_TO_DELETE é a tabela dos cabeçalhos de log a eliminar

I_IN_UPDATE_TASK = 'X' indica, que a eliminação deve ser efetuada na tarefa de atualização

LogAppDoc

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

LogAppDoc

Caricato da

Copyright:

Formati disponibili

|---------------------------------------------------------------------|

Chamada mais simples................................................

Que dados podem ser agrupados? ...............................

Como podem as mensagens ser

Procurar e ler mensagens....................................

Exibição de log de sistema: Princípio de função .............................

Exibição de log de sistema: Módulo de função

Exibição de log de sistema: Perfis de exibição em

Exibição de log de sistema na

Exibição de log de sistema em um container de

Gravar e carregar logs........................................

Eliminar logs no banco de dados.....................................

Outros módulos de função..........................................

Versão de impressão da documentação técnica..............................

Núcleo técnico e capa simplificada

É possível utilizar tanto os módulos de função do núcleo como da capa simplificada.

É possível utilizar tanto os módulos de função do núcleo como da capa simplificada.

Ao chamar o módulo de função BAL_LOG_CREATE é obtido o chamado handle de log (LOG_HANDLE,

Anexar mensagens ao log

Os dados de uma mensagem são predefinidos no módulo de função BAL_LOG_MSG_ADD através do

Com E_S_MSG_HANDLE é obtido um Identificador de mensagem que identifica esta mensagem de

Ao chamar os módulos de função BAL_LOG_MSG_ADD, BAL_LOG_MSG_CUMULATE, etc. é obtido o

Anexar exceções ao log

Com E_S_MSG_HANDLE obtém-se um Handle de mensagem que identifica univocamente esta

=> Nota: este módulo de função substitui o módulo de função BAL_LOG_EXC_ADD.

• ALCHDATE, ALCHTIME, ALCHUSER

• CONTEXT: CONTEXT-TABNAME, CONTEXT-VALUE

• PARAMS: PARAMS-T_PAR, PARAMS-ALTEXT, PARAMS-CALLBACK

• MSGTY, MSGID, MSGNO, MSGV1, MSGV2, MSGV3, MSGV4

• PROBCLASS, DETLEVEL, ALSORT, TIME_STMP

• CONTEXT: CONTEXT-TABNAME, CONTEXT-VALUE

• PARAMS: PARAMS-T_PAR, PARAMS-ALTEXT, PARAMS-CALLBACK

* Mensagem 123(XY): 'Limite de crédito para cliente &1 excedido'.

• Como "Texto descritivo ampliado"

• Como rotina callback

Ao ler os dados de exceção mediante BAL_LOG_EXCEPTION_READ, serão devolvidos os dados da

• MSG_COUNT Este atributo não será utilizado para exceções.

Anexar mensagem ao log

Com E_S_MSG_HANDLE é devolvido um Identificador de mensagem, que identifica esta mensagem

O que significa 'Acumular' ?

Substituir a última mensagem

Em que log é colocada a mensagem nova?

• Se com I_LOG_HANDLE não for indicado nenhum Identificador de log, a mensagem é

Para quê substituir a última mensagem?

Mensagem como texto livre

O texto de mensagem é predefinido pelo parâmetro de IMPORTING I_TEXT (comprimento máximo de

Com E_S_MSG_HANDLE é obtido um Identificador de mensagem que identifica esta mensagem de

Substituir predefinições para mensagens

As predefinições atuam sobre os módulos de função seguintes:

Mensagens com contexto complexo

• Exibição do log de sistema:

Anexar exceção ao log

Com E_S_MSG_HANDLE obtém-se um Handle de mensagem que identifica univocamente esta

=> Nota: este módulo de função substitui o módulo de função BAL_LOG_EXC_ADD.

Com um identificador de log é possível ler os dados de cabeçalho de um log através de

• E_TXT_OBJECT, E_TXT_SUBOBJECT, E_TXT_ALMODE, etc.

Procurar e ler mensagens na memória principal

• E_TXT_MSGTY, E_TXT_MSGID, etc.

• E_TXT_MSGTY, E_TXT_DETLEVEL, etc.

Critérios de filtro para o cabeçalho de log

Critérios de filtro para a mensagem

* Definir categoria de mensagem

Critérios de filtro para o contexto