Persist Step in SAP Integration Suite CI

In integration scenarios, ensuring message traceability and data retention is crucial for auditing, compliance, and troubleshooting. SAP Cloud Integration (CI/CPI) of SAP Integration Suite BTP offers the Persist step as a tool to store messages at specific points within an integration flow.

The Persist step allows you to retain messages during processing, enabling access for later analysis. This feature proves essential when businesses need to prove which messages were received or sent at a specific time. While the Persist step doesn’t affect message processing, it plays a critical role in building reliable, traceable, and auditable integration solutions.

In this article, we’ll explore how the Persist step works, its use cases, data storage mechanics, and how to access stored messages in SAP CI (CPI).

What is the Use of Persist Step?

Auditing and Compliance

The Persist step in SAP Integration Suite CI (CPI) ensures message traceability by storing messages at key points within an integration flow. This creates an audit trail, making it easier to prove which data was sent or received at a specific time. Businesses can meet legal and regulatory compliance requirements by retaining messages for auditing purposes. Additionally, having a record of historical messages helps organizations demonstrate transparency during compliance checks and security assessments. This makes the Persist step essential for industries with strict regulatory frameworks such as finance, healthcare, and logistics.

Monitoring and Analysis

The Persist step in SAP CI (CPI) plays a crucial role in troubleshooting and error analysis by providing a way to track messages for root cause investigation when flows fail to function as expected. Persisted messages offer a snapshot of the exact payloads and metadata, allowing teams to conduct detailed debugging and pinpoint issues. Additionally, the ability to store messages provides operational transparency and improves monitoring of integration flows. By retaining these messages, teams can gain valuable insights into message processing, ensuring smoother operations and quicker resolutions for issues that arise. Persisted messages also enable teams to reprocess or simulate message flows, further supporting error resolution and operational continuity.

Unlike other data storage options in SAP Integration Suite like Data Stores, Variables, Queues, etc, persist messages are NOT meant to access during runtime. They are meant to access post-processing!

How the Persist Step Works

Typically, we place a Persist step after the Message Start Event to store the message when first received from the sender. They log the message again before or after the Send, Message End Event, or Request-Reply step to capture the message being sent to the receiver. This approach ensures that both incoming and outgoing messages are recorded, meeting auditing and compliance requirements.

However, you can use persist steps before or after any step in your integration flow as per your requirement.

Once the Persist step is executed, the stored message remains in the Message Store until it is accessed through the Cloud Integration OData API. Note that the message store has a disk space limit of 32 GB per tenant, so it’s important to manage storage effectively to avoid exceeding this limit.

How Data Is Stored

When the Persist step is used in SAP CI, the data (messages) is stored in the Message Store, which is a logical storage location within the SAP Cloud Platform Integration environment.

  1. Logical Storage Location:
    • The Message Store acts as the storage container for persisted messages. This store is specifically designed to hold the messages that are captured by the Persist step at designated points within an integration flow.
  2. Physical Storage Location:
    • The data is physically stored in the tenant database, which is shared with the Data Store in the SAP CI environment. This means that the data for messages is stored securely within the infrastructure of your SAP tenant.

However, there is a storage limit of 32 GB per tenant for all data in the Message Store, which includes persisted messages. It’s important to monitor storage usage to avoid hitting this limit, as exceeding it could impact the performance or availability of message storage.

How to Access Data Stored from a Persisit Step

Accessing persisted data in SAP CI requires the use of the Cloud Integration OData APIs, as there is no direct user interface option for retrieving messages from the Message Store. Here’s how you can access the stored messages:

Read Message Processing Log (MPL)

You can access Message Store Entries under Message Processing Log instance using the following URL endpoint.

https://<Cloud Integration host>/api/v1/MessageProcessingLogs('<Message ID>')/MessageStoreEntries

Example: https://mytenant.tmn.hci.eu1.hana.ondemand.com/api/v1/MessageProcessingLogs('ABCD-1234-EFG')/MessageStoreEntries

You can find the API documentation of MessageProcessingLogs here.

Read Message Store Entries

You can read individual persist messages (Message Store Entry) of a certain message ID as follows;

Each Persisited Message or Message Store Entry has a unique GUID (MessageStoreEntryId). Using this GUID, you can access the properties and messages stored as follows.

https://<Cloud Integration host>/api/v1/MessageStoreEntries('{MessageStoreEntryId}')

To access the message content of the persist message use the following URL;

https://<Cloud Integration host>/api/v1/MessageStoreEntries('{MessageStoreEntryId}')$value

You can find the MessageStore API documentation here.


Example Integration Flow with Two Persist Steps

I will create an integration flow that consumes invoice data from an API and enriches the data with product information.

Let’s imagine that ultimately, the invoices received are processed, and there is an IT auditing requirement to log the inbound message before data enrichment and the outbound message after data enrichment for future auditing purposes.

Here is the message before enrichment, we get the invoices from the Northwind OData service. At this point, we only have the Product ID.

Input Message of the first Persist Step

Then we have the message enriched with Product information such as ProductName, CatafgoryID, UnitProice, etc. The respective product data is fetched from the Northwind OData API linking the <ProductID> element from entity Invoices and Products.

Input Message of the Second Persist Step

Sample iFlow with Two Persist Steps

iFlow

Here first step is to get Invoices from OData API, then we persist the invoices XML. That is the first message milestone we want to persist or save to the tenant database.

Then we enrich the invoice information with respective product information by calling the Northwind OData API. After the invoice XML message has been enriched with product information, we persist the message again. This time the persisited message should have invoice information with additional product information.

Configuring Options of Persist Steps

Each persist step can be given a name so you can identify the message you are saving.

Persist Step 1 – Invoice List Before Data Enrichment

Configuration of the First Persisit Step

Since the first Persist Step saves the message before the data enrichment, I will call it “PersisitPreEnrich.” This will help me identify the stage of the message processing and at what point of the integration flow the message persisted—kind of like a milestone.

Persist Step 2 – Message After Data Enrichment

Configuration of the Second Persisit Step

Similarly, the next persistence is after data is enriched. Therefore, I will name the Step ID as “PersisitPostEnrich”. These names will come in handy when you want to read the stored messages from Persist step.

If you have sensitive data, you can also enable the option “Encrypt Stored Message” to save the message encrypted. When you are reading the data, you will have to decrypt the message.

Test the iFlow and Persist the Messages

Here is the Message ID of the instance. We will need the Message ID to filter the messages persisted for this instance of the interface run.

Message ID of the iFlow Runtime Instance

How to Access the Peristed Messages

As we talked about, there is no graphical option provided by SAP Integration Suite to view or access saved messages. You have to make use of the standard OData APIs provided by SAP Cloud Integration (CI) to access the messages.

To read the messages stored, we have to read the “MessageStore” entries. Since we already have the MessageID of the instance, we can find what are all the MessageStore entries under the Message Processing Log (MPL) using the following OData endpoint.

https://<Cloud Integration Host>/api/v1/MessageProcessingLogs('<Message ID>')/MessageStoreEntries
Access MessageStoreEntries of Message Processing Log

Here you will notice that we have two messages persisted. One with step ID “PersisitPreEnrich” and the other one with “PersisitPostEnrich”, the same names we defined as the StepID of persisting steps in the iFlow.

Also, notice there is a unique ID for each MessageStore entry a Message GUID. Using this Message GUID, you can read individual Message Store entries in the following URL endpoint.

https://<Cloud Integration host>/api/v1/MessageStoreEntries('{MessageStoreEntryId}')
MessageStore Entry of Second Persisit Step
MessageStore Entry of First Persisit Step

View the Message Content

Now to check the actual message content of each MessageStore entry or in other words the payload that was saved by each Persisit step ad “$value” to the end of the URL.

/MessageStoreEntries('{MessageStoreEntryId}')/$value

Message of Persisit Step ID – PersisitPreEnrich

Message Body of First Message Store Entry

Message of Persisit Step ID – PersisitPostEnrich

Message Body of Second Message Store Entry

Limitations and Workarounds when Using Persist Step

Persist Step in SAP Cloud Integration only writes successfully processed messages to the Message Store. If a message processing fails, it is not stored by default.

The workaround is to catch exceptions in a local subprocess and end the message processing in an Escalating End Event instead of an Error End Event.

Summary of Persisit Step in SAP Integration Suite CI (CPI)

The Persist step in SAP Cloud Integration (CI) enhances message traceability, auditing, and troubleshooting in integration scenarios. It stores messages at key points within an integration flow, enabling businesses to meet compliance requirements, conduct root cause analysis, and improve operational monitoring.

SAP CI securely stores persisted messages in the tenant’s Message Store, allowing access through OData APIs since no graphical interface exists. By strategically placing Persist steps in an integration flow, businesses create detailed audit trails, ensure data transparency, and support error resolution through stored message snapshots.

However, the Persist step stores messages only when processing succeeds.

This capability helps industries with strict regulatory demands build traceable and compliant integration solutions, making SAP CI a reliable platform for enterprise integration needs.

I hope you learned something new. To become confident in all the features of SAP Cloud Integration feature of SAP Integration Suite, join my online course.

Encode Message Payload to Base64 on CPI!

How to use Base64 message encoder in SAP Integration Suite.

Subscribe for more

My First Interface on CPI!

Learn how to develop your first iFlow on SAP Integration Suite within 7 minutes!

Subscribe for more

Leave a Reply

Your email address will not be published. Required fields are marked *