Application Log and Unicode

Use

It is possible to attach a context to a message or log header in the application log. This context consists of the name of a (flat) DDIC structure and its content that is kept in a CHAR255 container.

DATA:
l_s_msg TYPE bal_s_msg,
l_context TYPE MY_STRUC.

* fill message type, id and message variables
....

* define context information
l_context-carrid = 'ABC'.
l_context-connid = 15.
l_context-fldate = sy-datum.
l_s_msg-context-tabname = 'MY_STRUC'.
l_s_msg-context-value = l_context.

* add this message to log 
CALL FUNCTION 'BAL_LOG_MSG_ADD'
EXPORTING
i_s_msg = l_s_msg
EXCEPTIONS
OTHERS = 0.

In principle, it could have been possible to completely convert this container mechanic for unicode conversion (for example, by introducing REF TO DATA as a reference to any context information). However, since most applications only operate with character-like contexts, a conversion of that kind was rejected. Instead, the following two options are available:

Only use character-like fields in the DDIC structure. This procedure is recommended.

Note

This option can then be used, for example, if INTEGERs are used in the context. It is possible to convert relatively easily to NUMC. Coding can normally remain unchanged because moving an integer into an NUMC field automatically converts it.

Furthermore, logs written in old releases can still be read. The old context data is automatically converted into the new structure when it is read.
Work with ASSIGN .. CASTING..

Note

If solution 1 cannot be applied and non character-like fields have to be used, you can proceed as follows:

The statement l_s_msg-context-value = l_context. can be replaced by:
```
FIELD-SYMBOLS:
<l_context> TYPE c.
ASSIGN l_context TO <l_context> CASTING.
l_s_msg-context-value = <l_context>.
               
```

Context data is still read/interpreted correctly in the application log.