Sub-Logs

[NeumannJoerg]

The API is currently enforcing the One-Log-Approach.
This is nice for analyzing issues, as all relevant messages will be in one log.

It is not so nice anymore, when you want to analyze the behavior of a reusable component, that would create its own logs, which are then "abducted" by the calling applications, as they are opening logs of their own.

A compromise that works for both scenarios would be nice.

Idea:

• Every call to /USI/CL_BAL_FACTORY=>/USI/IF_BAL_FACTORY->CREATE_NEW_LOGGER should create a new logger instance
• If the calling application already opened a log, then both logs should be "linked"
  • A trace-message should be created in the main-log and in the sub-log
  • The trace-messages should have a new data container (Type: Navigation; Target: The other log)
  • Top-Down-Navigation (Parent to child) in SLG1 should work WITHOUT authority checks - if a log was created in the context of an application and somebody is allowed to see the main log, the sub-logs should also be visible. Otherwise support might become impossible, which would render the entire API useless.
  • Bottom-Up-Navigation MUST have an authoritiy check in place. An authorization for a low-level-component could otherwise grant access to logs of various applications and potentially sensitive data.
• Sub-Logs have to inherit their configuration (e.g. retention times) from their respective parent log. Otherwise sub-logs might be deleted before the parent, which would violate the One-Log-Approach.

Some points still need some clarification:

• How to deal with sub-logs of reusable components, if the component does not close them?
  • Saving a parent log should always save and destroy child logs
  • The token passed by the parent log has to be valid for the sub-logs too
  • Creation of sub-logs should be optional (Add flag in /USI/BAL_LV_LOBJ?)