It is our goal to continuously improve simulating and troubleshooting message processing in Cloud Integration. With the release of version 2.36 a new log level is introduced which collects message content in addition to the message processing log. This blog describes how this feature can be utilized and the relation to existing log levels which are described in detail in Setting the log level for message processing.
While developing or testing an integration scenario, the message processing log provides information about the status and the steps executed on a configurable level of detail. In scenarios where the message itself gets transformed during processing it can be extremely useful to monitor the message content at different stages as well.
The new log level Trace, like any other log level, can be set for a specific integration flow in the "Log Configuration" section of the "Manage Integration Content" view of the Web-based Monitor (see Product Documentation for details).
In the "Monitor Message Processing" view of the Web-based Monitor the log level used when writing the log is visible in both the overview list and the details view which allows selecting the desired log from multiple ones for the same integration flow.
However, there are some notable differences between Trace and the other log levels.
Due to these reasons the message content is not written to the message processing log but stored separately, allowing a different access level and lifecycle.
When tracing is enabled the message processing log will be written at the highest possible detail level (same as for log level Debug) and the message content gets collected and stored. After expiry of trace during an execution of an integration flow the collection of message content is stopped but the message processing log will still be written on the most detailed level. For subsequent executions, the log level falls back to the one which was set for the integration flow prior to Trace.
The time of Trace expiration as well as the previous log level is displayed in “Manage Integration Content” details.
It is worth noting that the log level to be used is determined once at each start of processing a message. This can be useful in retry scenarios where the message processing log consists of multiple parts, one for each try. By changing the log level while such an integration flow is in Retry status, log parts can have a different level of detail and even messages can be traced regardless of the log level which was active when the integration flow was started.
For the time being the message content persisted while tracing can be viewed with the Integration Operations Feature in Eclipse only (see View Trace). Future increments will provide a similar feature in Web-based Monitor as well.
SAP recommends to use tracing in non-productive environments only.
I hope you find this new feature useful. Please feel free to comment on this blog in case you have questions or feedback.
While developing or testing an integration scenario, the message processing log provides information about the status and the steps executed on a configurable level of detail. In scenarios where the message itself gets transformed during processing it can be extremely useful to monitor the message content at different stages as well.
The new log level Trace, like any other log level, can be set for a specific integration flow in the "Log Configuration" section of the "Manage Integration Content" view of the Web-based Monitor (see Product Documentation for details).
Figure 1: Setting the Log Level for an Integration Flow
In the "Monitor Message Processing" view of the Web-based Monitor the log level used when writing the log is visible in both the overview list and the details view which allows selecting the desired log from multiple ones for the same integration flow.
Figure 2: Selecting a Message Processing Log
However, there are some notable differences between Trace and the other log levels.
- Messages may contain sensitive data. Thus, access to message content is restricted to users having Business Expert role.
- Messages may contain a large amount of data. To prevent exhaustion of resources tracing expires after some time, typically 10 minutes and the message content collected during this period is retained for typically 1 hour only.
Due to these reasons the message content is not written to the message processing log but stored separately, allowing a different access level and lifecycle.
When tracing is enabled the message processing log will be written at the highest possible detail level (same as for log level Debug) and the message content gets collected and stored. After expiry of trace during an execution of an integration flow the collection of message content is stopped but the message processing log will still be written on the most detailed level. For subsequent executions, the log level falls back to the one which was set for the integration flow prior to Trace.
The time of Trace expiration as well as the previous log level is displayed in “Manage Integration Content” details.
Figure 3: Getting Trace expiry information
It is worth noting that the log level to be used is determined once at each start of processing a message. This can be useful in retry scenarios where the message processing log consists of multiple parts, one for each try. By changing the log level while such an integration flow is in Retry status, log parts can have a different level of detail and even messages can be traced regardless of the log level which was active when the integration flow was started.
For the time being the message content persisted while tracing can be viewed with the Integration Operations Feature in Eclipse only (see View Trace). Future increments will provide a similar feature in Web-based Monitor as well.
SAP recommends to use tracing in non-productive environments only.
I hope you find this new feature useful. Please feel free to comment on this blog in case you have questions or feedback.
- SAP Managed Tags:
9 Comments
