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
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:
Some points still need some clarification: