Like most middlewares, we associate SAP CI (a.k.a. SAP Cloud Integration = formerly CPI) with ETL operations- Extract, Transform  and Load data. This gives the perception that data only passes through SAP CI and no data is stored on it. While in most cases this may be true, there can be certain situations in which we want to persist some data on SAP CI as well.

For example, we may wish to store Last Successful run Date of a particular IFlow (integration flow). This could be required because we use this date in another IFlow, or another execution of the same IFlow, like fetching data based on this date. Some may argue that we can just look into the tenant’s Message Processing logs for finding the last execution date, right? And if that’s the case, why do we even need to store this data? But it’s not necessary that every execution is a successful one and thus, the Last Successful Run Date cannot be fetched directly from Message Processing logs.

As another example, let’s say that there are multiple paths of execution within an IFlow, and the path taken is decided on the basis of input data.

We wish to store the timestamp only when Path 1 is taken last. For Path 2 and Path 3, we do not require to store this information. Looking at Message Logs will not be of much help to us anymore. In such cases (and many more), we need some mechanism for persisting data on CI.

Thankfully, SAP CI already provides features for persisting data. Under Operations view of your CI tenant, you will find a section titled “Manage Stores”. This houses the various data persistence options provided by SAP CI. Let’s have a look at them one by one.

Variables

Let us come back to the scenario we had described earlier: we wish to store last successful run date of a particular IFlow. For this purpose, we can use a variable.

Creation of a variable

In our IFlow, we have to include a ‘Write Variables’ shape to do this. Using simple camel expression as shown below, we can store values in variables. Please note that we did not need to create a Variable by going into Operations view first.

As we had discussed earlier, we may wish to store this value only for a particular path of execution among many. In that case, we can place this shape in only that path.

Reading Variable value

To read the values stored in variables, all we need to do is reference the variables as shown below. This can be done in Message Exchange Properties as well.

Inspecting Variables in Operations View

To look at the value of this variable, go to ‘Variables’ under Manage Stores in Operation view. You can identify the variable using its name and the ID of the integration flow it belongs to. We can read this variable in the same IFlow and write back another value. This is because the scope of this variable is limited to that particular IFlow.

This is what Manage Variables screen looks like. You can see a list of all the variables under this tenant along with their visibility, name of the integration flow they’re associated with (in case of Local variables), associated Dates and available options.

Scope/Visibility of Variables

Variables have Local scope by default. This means that they are visible and accessible to only one IFlow.

But what if we wanted to read this value, or possibly even modify this value from another IFlow? In that case, we will have to use a Global variable. Like the name suggests, the scope of this variable is not confined to just one IFlow. This variable can be read and modified by iFLow.

When can something like this be useful? As an example, suppose the value written by one IFlow is to be used by another for its processing.

Since Global variables are not limited to one IFlow, when we look at these variables under Manage Stores, they have no value mentioned for IFlow Ids.

Can we have multiple variables of the same name?

Another thing to note is that you can have multiple local variables of the same name. This is possible because they can be differentiated by their IFlow Ids. But this is not possible for Global variables.

Can we have Local Variables by the same name as a Global Variable?

Yes, we can have multiple local variables of the same name. This name can be the same as a Global Variable.

When we read a variable value, we specify whether we wish to get the value of a local or a global variable. So there is no issue in having duplicate names.

What happens we try to reference variables that do not exist?

If we try to reference a variable that does not exist/provide an incorrect name. No value is extracted and the header/property is effectively set to null.

Alternatively, we can specify Default Values to be used in such cases when we reference variables. If the variable does not exist, this will  be used as a replacement and treated as a String object.

Deleting a variable

Variables can be deleted from ‘Manage Variable’ screen under Operations view of your CI tenant by clicking on the delete icon on the right side of the variable tile.

Retain Period of a variable

The period for which the value of a variable is stored is 400 days from Last Modification date of that variable.

Number Ranges

Now we are going to hop on to the next topic: Number Ranges. We already know it’s a mode of data persistence, but what exactly does it do and what makes it different?

Number ranges act as sequences which can be used for marking messages, among other applications. Suppose that in a particular integration scenario, all messages to the destination system must have a unique sequence number. This is where a number range can be of use.

Creating Number Ranges

Before use, Number ranges have to be created by specifying the following:

• Name: Give a unique name that will be used to reference this Number Range.
• Description: Not mandatory, but generally a good practice to include this information to avoid any confusion in the future.
• Minimum value: A non negative integer value with maximum 14 characters. Cannot enter string/characters here.
• Minimum value: A non negative integer value with maximum 14 characters. Cannot enter string/characters here.
• Field Length: The length of the sequence number returned by this number range.
• Rotate: If the maximum value is reached, the first value is picked as the next number in sequence.

Using Number Ranges

Number ranges can be used by referencing them in Message Headers/Exchange properties.

Number ranges can be used as per requirement. If they are to be used only under certain conditions and not in every execution, they can be referenced within the path matching those conditions to avoid unnecessary wastage of numbers in sequence. This can be done with the use of Routers, for example.

Can the same number range be referenced in multiple IFlows?

Yes, but remember that whenever they are referenced during an execution, the value is incremented by 1. If you are using the same number range for multiple integration flows, it can lead to confusion over apparently skipped values. Moreover, if the destination systems are expecting a continuous sequence, it will be problematic to use the same number range in multiple integration Flows.

Can the same number range be referenced at multiple places in the same IFlow?

Yes, this can be done as well. But we can expect skipped values as a result. For example, if a number range is referenced twice during an execution, the value of that number range will be incremented by 2. Keeping this in consideration, the same number range be referenced multiple times and even used to create increments/steps of n instead of just 1.

Can the next value of a number range be changed?

We can manually set the next value of a number range to some specific value. Although this is not usually encouraged, under some rare circumstances this may be warranted. This can be achieved by Editing the Number range under Operations view->Number Ranges.

What happens we try to reference a Number Range that does not exist?

If we try to reference a number range that does not exist/provide an incorrect name, an exception is raised of the format:

com.sap.it.rt.adapter.http.api.exception.HttpResponseException: An internal server error occured: Error while fetching next value for number range: NumberRangeName.

This is quite different to what happens in case of missing variables which simply returned null values.

Deleting a Number Range

Number Ranges can be deleted by clicking on Undeploy Button on ‘Manage Number Ranges’ screen under Operations View of your CI tenant.

Retain Period of a Number Range

Number ranges do not have a fixed retain period. They are retained until undeployed.

Using Variables instead of number ranges

If you think about it, variables can be used to replace number ranges. In an integration flow, we can set Message Headers/Properties to get value from variables (and set default value in case of its absence). After use, the value can be increased/decreased as per requirements and this value can be written back to the variable.

Pros:

• Can decrease values as well instead of just increasing. As an example, we can implement a countdown using this logic.
• Can implement our own logic for more complex scenario. Example: we can both increase and decrease values based on certain conditions.
• We can restrict usage of a sequence implemented with the use of Local Variables. This way, only a particular IFlow will have access to one sequence.
• We can change the sequence values as and when required using some logic implemented in our IFlow.
• We can assign default values to be used in absence of the specified variable.

Cons:

• The onus of incrementing/decrementing values is on the CI developer. Developer will have to take care of all possibilities to ensure that the correct sequence is followed.
• We cannot set the value of variables manually as we could with Number Ranges.

Whether this should be done or not is debatable and is best left to the discretion of the reader. In this Blog post, we learned about two modes of data persistence in SAP Cloud Integration and the differences between them. This is all the information one needs to begin working with variables and Number Ranges in SAP Cloud Integration. In the next post, we are going to discuss the third mode of data persistence – Data Stores, and some more interesting scenarios.