Often, integration developers receive requirements wherein a sending system prefers to send a bulk piece of data, instead of individual messages to the S/4 HANA cloud system. While it may be simpler to work with smaller chunks of data, such requirements are often not avoidable. This may be due to many factors, some of them being – inability of the legacy (sending) system to adapt, performance considerations, network bandwidth or sometimes just for the sake of simplicity.
SAP S/4 HANA Cloud Platform Integration offers some simple tools (Splitters) to handle such large messages and break them down into multiple single messages which make processing easier. There are multiple types of such splitters available in SAP Cloud Platform Integration and we will have a look at some of the capabilities of these splitters in this blog.
The scenario: Incoming message is a large composite message and in order to be processed through SAP Cloud Platform Integration, needs to be split into individual messages for further processing.
The available options: SAP CPI offers multiple types of splitters to split a composite message into smaller ones. Some of these are explained below.
While working with I-Flows in the SAP Cloud Platform Integration, splitters are available in the “Message Routing” tool. For the sake of simplicity of demonstration, we will use a content modifier in the I-flow and populate it with a composite message. Then we will use different splitters to get multiple simple messages out of this large message.
Add a content modifier to the I-flow. We will populate the message body later while testing.
The “splitter” option under the “Message Routing” flow step offers multiple types of splitters:
1) Iterating Splitter
2) IDoc Splitter
3) General Splitter
4) PKCS#7/CMS Splitter
In this blog, we will see the use of the Iterating and General Splitters.
Add a general splitter to the I-flow after the Content Modifier flow step.
In the processing tab of the General Splitter, you can specify properties of the splitter in terms of how it must process the large message. You may choose to split the message with a line break (new line) or through a specific path which might be absolute or relative (Xpath expression).
For this example, we will use the line break option. This means that end of line in a composite message is treated as the end of message and a new line basically starts a new message. Each line will therefore be treated as a single message for processing.
The “Grouping” parameter offers to group a number of messages at a time. The default is 1 (even if left blank). But another number here means that many messages will be taken for processing at a time.
Other options like “Streaming”, “Parallel Processing” and “Stop on Exception” are self-explanatory and should be selected as appropriate.
For the sake of tracking the message (payload) within the i-flow, I have introduced some groovy script code. This code basically downloads the current payload as a text file attachment. The code of the groovy script is attached herewith:
Groovy Script – Original Message
import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
def Message processData(Message message) {
def map = message.getProperties();
def body = message.getBody(java.lang.String) as String;
def messageLog = messageLogFactory.getMessageLog(message);
if (messageLog != null) {
messageLog.addAttachmentAsString("Payload:", body, "text/xml");
}
return message;
}
Groovy Script – Split message
import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
def Message processData(Message message) {
def map = message.getProperties();
def body = message.getBody(java.lang.String) as String;
def messageLog = messageLogFactory.getMessageLog(message);
if (messageLog != null) {
messageLog.addAttachmentAsString("Payload post Split:", body, "text/xml");
}
return message;
}
Now, put a sample message body in the content modifier that we inserted earlier in the I-flow. This will help us test the General splitter that we just used.
Note that a start timer was also put to have this executed as soon as this is deployed. In real time scenarios, there may be a need to receive a message from a sender or pick up a file through FTP. This is not covered as part of this blog though.
Now save and deploy your i-flow. It should produce the result as follows:
Note that because of the groovy scripts, there are attachments of output produced. The “Payload” attachment has the original payload (complete message). The other attachments have single rows – one each for each row of the message, showing that the splitter took one row at a time. Do also note that the header row was preserved in each of the individual message.
Below are the screenshots of each of the attachments generated.
Message 6
Message 5
Message 4
Message 3
Message 2
Message 1
Now, try changing the “Grouping” parameter to a different value and observe the result. Here, we change it to 3.
Save and Deploy the I-flow again. It produces the following result.
It may be noted that changing the grouping value to 3 means 3 rows were grouped together from the main message. This helps to cover scenarios where there may be a need to group multiple records from within a large set of records.
We will now see the use of an iterating splitter. For starters, we will simply replace the General splitter of the i-flow with an iterating splitter. We will keep the same properties that we used in the general splitter.
Save and Deploy the i-flow. The output will be as below:
As may be noted, in this case, the header row is not preserved in the output attachments. This shows a notable difference that an iterating splitter does not preserve the encapsulating elements of the message payload. This is one basic difference between a general and an iterating splitter.
In addition, the iterating splitter presents a few more options in comparison to the general splitter. Take a note of them in the screenshot below:
The iterating splitter supports an additional expression type “Token” in addition to the Line break and the Xpath options. An Xpath expression can be used to specify either a relative or an absolute path of a message. The Token option can be used to specify an xml node.
Let us now change the expression type of our iterating splitter to an xml token and test the same i-flow. To do so, we will also have to change the message body in the content modifier to be in xml format. Please refer to the screenshots below:
Content modifier
The message body was as below:
<Orders>
<Order>Order1</Order>
<Item>Item1</Item>
<Material>Material1</Material>
<qty>10</qty>
<uom>PC</uom>
</Orders>
<Orders>
<Order>Order2</Order>
<Item>Item2</Item>
<Material>Material2</Material>
<qty>20</qty>
<uom>PC</uom>
</Orders>
<Orders>
<Order>Order3</Order>
<Item>Item3</Item>
<Material>Material3</Material>
<qty>30</qty>
<uom>PC</uom>
</Orders>
Iterating splitter
Note that the “token” expression type was used and the relevant node of the xml payload was specified in the Token.
Save and Deploy the i-flow. The following output was produced.
As you may have noted, the payload was split into three messages, with the specified node in the “Token” parameter of the iterating splitter.
The above examples show simple use of general and Iterating splitters in CPI I-flows. You can use them in real-time scenarios, wherein each of the split messages can be further used to capture data and (for example) used in posting into SAP S/4HANA cloud through a whitelisted API. It is also possible you can manipulate the data using string manipulations or map it using message mapping for the desired format which might be required by a receiving system.
Hope this blog helps in understanding the use of these easy-to-use splitters.
- SAP Managed Tags:
2 Comments
