Tips for Configurations with Log Contexts
In a Read Access Logging configuration for Dynpro and Web Dynpro channels, you might need to use a log context to make sure that your log can be interpreted correctly. The log context is the UI element that other UI elements within the logging session depend on. When read access is being logged and the field that is defined as the log context changes on the user interface, all other fields are deleted from memory before the next log entry is created. Whether or not you need a log context depends on the user interface of your application. The graphic below shows a screen sequence taken from a simple HR application and the accompanying table gives recommendations on how to configure Read Access Logging for this screen sequence with the help of the log context.
Log contexts are based on single applications or programs, like configurations. Log contexts cannot be applied across several configurations or applications/programs.
For Dynpro, single transactions can contain more than one program, which may not be apparent to you when you create a recording. In this case too, log contexts cannot be spread over multiple programs used in the transaction.
The graphic below shows a sequence of three screens. On Screen 1, the user enters an employee number. Screen 2 displays the social security number and religion of the employee. Screen 3 displays the salary of the employee.
The table below shows how to configure the screen sequence depicted in the graphic above. Note that the field Employee Number is a different field on the three screens; on the first screen, it is an input field and on the second and third field, it is an output field like the other fields that cannot be edited.
|
Screen Number |
UI Element |
Recommended Logging Type |
Comment |
|---|---|---|---|
|
Screen 1 |
Employee No |
No logging necessary |
Only outputs are logged in Web Dynpro. As this is an input field, the value of the field is not logged. Therefore, this UI element does not need to be configured for logging. (On the next screen, however, the Employee No field can be logged.) |
|
Screen 2 |
Employee No |
Log with value and define as log context |
The employee number that has been entered on Screen 1 is repeated here. As this is an output field, we recommend logging it. Also, the other fields on Screen 2 depend on the employee number, so we recommend defining it as the log context. In the log, the field that is the log context is marked for easy identification. |
|
Screen 2 |
Social Security No |
Log without value (for example, legal regulations may prohibit logging social security numbers) |
The social security number of this employee is displayed within the same log entry as the log context. If you configure to log it without the value, only the fact that the field was accessed is logged, but not the value. |
|
Screen 2 |
Religion |
Log with value |
The religion of this employee is displayed within the same log entry. If you configure to log it with value, the religion is displayed in the log. |
|
Screen 3 |
Employee No |
No logging necessary |
As you have specified the Employee No from Screen 2 as the log context, you do not need to log this field. Note that even if the employee number was not repeated on each screen, the log context would still be logged as part the log entry of these screens. |
|
Screen 3 |
Salary |
Log with value |
As it is the only field that is configured on this screen, the salary of this employee will be displayed with the log context from Screen 2 in one log entry. |
Result
When a user clicks through this screen sequence when it is configured as described above, two log entries are created, one for Screen 2 and one for Screen 3. On Screen 1, no output field exists that can be logged. On Screen 3, the employee number does not have to be logged as the employee number field from screen 2 is the log context and is thus automatically logged during a screen sequence even if it is not displayed on subsequent screens.