Skip to Content

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:

  • AS2
  • LDAP
  • Mail
  • SuccessFactors
  • IDOC
  • SOAP
  • SAPRM

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:

  • JMS
  • Twitter
  • Facebook
  • ProcessDirect
  • SFTP

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.

References:

Troubleshooting Message Processing in the CPI Web Application

Cloud Integration – Setting the Log Level for Message Processing

Cloud Integration – Enabling Trace for Message Processing

Cloud Integration – System Log Download

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

    1. Markus Beier Post author

      Hi Daniel,

      thanks for the feedback and for making the video!

      The HTTP adapter does not support tracing so far. The decoration of the sender channel gives a hint on that as it carries an empty envelope icon instead of the filled one used for steps which were traced. The HTTP adapter does not modify the payload so what you see for the JSON to XML Converter step is exactly the payload as received by the adapter.
      However, only dedicated headers are propagated to the IFlow processing. All others are removed in the beginning of the processing to prevent unintended impact unless explicitly white-listed (cf. help on Allowed Header(s) configuration property).

      I’ll forward your feedback to the corresponding colleagues.

      Best regards,
      Markus

      (0) 

Leave a Reply