A new visualization for Message Processing Logs in the Web Application was released with version 2.38 as a first increment. With version 2.39, we worked on improving this feature to enhance the usability and increase the available information. In the following, I will provide some detail on those improvements.
The affected areas are:
- Record and display trace data for adapters
- Display the Name and Type of the respective Model Step directly in the step list
- Show the traversal path the message processing has taken in the model
- Improved correlation of message processing to the corresponding System Logs
Record and display trace data also for adapters
In some cases, it might happen that messages are not sent out or received as expected. Those cases were hard to troubleshoot with the tracing feature in case one wanted to check the exact payload as it was transmitted by the sender. The SOAP adapter for instances removes the SOAP specific tags from the transmitted payload when a message is received and only forwards the body for processing. For SOAP based adapters, the received and sent message payloads could already be recorded, however, this was not integrated with the regular tracing; for other adapters, this was not available at all.
With version 2.39, this is now part of the regular tracing feature and it has been extended to more adapters. Message content traced by adapters can be accessed like any other trace data. The payloads are recorded if the log level is set to Trace. Data is recorded before the message is transformed upon reception or after it has been transformed directly before sending. The point at which the trace data was recorded is shown in the section title on the step details page.
The following example depicts an step recorded for a SOAP sender adapter capturing the initially received payload together with its headers:
The following adapters support tracing of sent and received messages:
The goal is to extend this to other adapters as well, however tracing payloads and headers for adapters provides only valuable information for troubleshooting if the payload is actually transformed by the adapter or there are specific headers only provided by the adapter.
The following adapters are not transforming the body nor do they set specific headers, so it is not planned to enable tracing for them:
Note that already deployed Integration Flows containing IDOC, SOAP, and SAPRM adapters have to be redeployed once to enable the trace feature.
Display of Model Step Name and Type in step list
In the first increment of the new log visualization, there was already the option to mark an entry in the list of steps in order to have the respective step in the Integration Flow model highlighted. In order to improve the correlation of steps in the list with the model at a glance, now also the name and type of the Model Step belonging to a certain executed step is displayed directly in the list.
Note that you can specify the name of many integration flow step types in the Integration Flow Designer. If available, this can be done on the General tab of the respective step’s properties.
Show the traversal path the message processing has taken in the model
With the first increment, we also provided a visual indication of the path the message processing has taken in the Integration Flow model. This so-called message traversal path was only available, if the message was processed with log level Trace. The traversal path is marked by decorating the corresponding link with a icon or a icon, if the following step raised an error. This feature has now been extended to log levels Info and Debug. In order to have a visual distinction between steps for which trace data is available and steps for which only the processing information was captured, inverted icons are displayed if there is no trace data available: if the step was processed successfully and if the processing resulted in an error.
When you display a Message Processing Log which was recorded with log level Trace, you might encounter mix cases with respect to the traversal path decoration as some adapters are not supporting the recording of trace data. The link representing the channel would then be displayed with a icon, while other steps would be decorated with the icon.
Correlating message processing with System Logs
System Log Files can be accessed via the respective tile in the Access Logs section. These log files can be used to retrieve more information in case the processing of a message failed with an exception and you assume more context information to be available as part of the system logs. It can be however, that your tenant consists of multiple message processing nodes. In that case, it was cumbersome to find the log which actually might contain additional information for one specific message as there was no indication on which node the message was actually processed.
In order to improve that, we now show the so-called Process ID as part of the Logs section on the message detail view.
This ID can then be used to filter the available system logs as it is part of the system log’s filename.
I hope, you can benefit from the enhancements presented in this blog post. In case of questions or feedback please feel free to comment on this blog.