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 contents, which is held in a CHAR255 container.
The context is a DDIC structure with the name 'MY_STRUC', which contains the fields CARRID, CONNID and FLDATE:
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'
i_s_msg = l_s_msg
OTHERS = 0.
The statementl_s_msg-context-value = l_context. causes problems in unicode systems if the DDIC structure contains fields that are non character-like (for example, the fields CONNID as INTEGER).
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:
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.
If solution 1 cannot be applied and non character-like fields have to be used, you can proceed as follows:
<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.