Monitoring in SAP Cloud Integration

Published by Rhein-Ruhr-Informatik on

In this blog post, we would like to explain how we monitor your processes in SAP Cloud Integration. It is one of the most important topics for those especially concerns about security in middleware.

Cloud Integration allows us to make changes over the messages, like mappings, or converting from one structure to another. Cloud Integration is not only powerful for data manipulation, but also offers strong monitoring features. In addition to Debug or Trace modes like any development IDE, it also allows us to monitor the necessary information without debugging.

For each service we can set Log Level to 5 different modes.

None: No information about processes even if they are successful or failed.

Info: Default mode to see if the process is successful or failed.

Error: Shows message only if the process is failed.

Debug: Shows the process steps without any information of messages.

Trace: Shows every information of messages, headers, bodies in every steps.

Default log configuration is set as Info. Which allows us to see status of every process, like completed, abandoned, canceled, failed, etc. This mode doesn’t allow us to see the message body, message headers, basically what is passing through over CPI. It is important to protect data for security reasons and to reduce memory consumption.

But if the process fails, how can we find out the issue?
Trace mode is useful when the same message can be received again. Before receiving messages, this mode should be activated. In trace mode, both the message body and headers can be viewed at each step.

The process that gets an error is displayed. In this mode, it is much easier and faster to identify the step where the error occurs.

However, CI allows us to stay in trace mode for only 10 minutes, then it returns automatically to the previous mode (info, error, or none). Additionally, the message can no longer be accessed after 1 hour. During development, this mode is often used. However, in production, after the process fails, we cannot re-trigger the same process. It is also not recommended to reveal the full message in production due to security reasons.

In that case, how can we indicate which message gets an error without exposing the entire message? Here’s what SAP offers:

There are some pre-built properties for monitoring and filtering messages. This feature is very helpful for understanding specific messages’ status and filtering the messages in monitoring screen. We can customize those Properties according to needs. In this example, Application Message ID is set from Order Id, and the type of Order is set as Application Message Type. If this order gets an error, we can directly point out the order number without revealing the whole message.

Bestellnummer festgelegt, und der Bestelltyp wird als „Application Message Type“ bestimmt. Wenn diese Bestellung einen Fehler enthält, können wir die Bestellnummer direkt herausfinden, ohne die gesamte Nachricht offenzulegen.

If those pre-build properties are not enough, or just need to add more customized properties, we can also add custom monitoring headers. These custom headers are not considered as actual headers. They are not sent to the receiver system. They are used only for monitoring purposes as internal.

We can also filter the messages according to monitoring properties and custom headers. For example, we have 7 messages in Completed status with the Message Type: Initial Order

But we have only 1 message with the order number 1000000.

By default, we cannot view the content of a message at any point during the process. However, in some cases, we may need to see the message body, especially when it’s in a failed status. To do this, we can create an attachment for monitoring purposes. Attachments can be in any text format, and they are customizable, allowing us to add information that helps identify the error. Additionally, attachments can be set up to be included only in error cases.

Most common usage cases:
– Seeing the whole body at the important points. – Like before mapping, after mapping
– In error case, the whole message body at the error point.

Logs stored in the middleware cannot be kept for long periods.

Trace can accept messages for up to 10 min, and these messages are only visible for 1 hours.

Debug can accept messages for up to 1 day.

All process logs are deleted after 1 month.

In Conclusion:

SAP provides a faster, more precise, and more secure middleware environment with Cloud Integration.

By default, Cloud Integration interface does not show any messages or headers to users. This is important for both security reasons and memory management.

However, in some cases, the failed message needs to be detected without using trace or debug mode, especially in a production environment. To achieve this, in info mode, necessary fields can be set as custom properties and attachments to identify which message has failed.

Cloud Integration stores logs maximum for 1 month. This 1-month period is intended for working with errors, detecting issues, and solving problems.

Categories: BlogSAP

en_USEnglish