SAP Cloud Integration IDoc Receiver Handler

[aayushaggarwal]

Introduction

Integration is critical piece in any project and IDoc is standard interface used to integrate with ECC / S4 systems, therefore, appropriate IDoc Handling strategy is must to ensure smooth execution of business activities.

• In this blog post, we will discuss how to create IFlow in CPI to handle the multiple IDocs received from the source system.


• We will see the configurations required in SAP CPI. This will be useful in any project which will be handling multiple IDocs coming from source systems.

Problem Statement

In CPI, we normally use a single IFlow to receive all the IDocs from the Source system(unlike SAP PI where we develop separate interfaces for each IDoc), we achieve this in CPI with the help of Process Direct functionality, using which we can call other IFlows in same and different packages.

Figure (below) shows how such IFlow looks like…

Image Source: SAP BTP Trial Account

To achieve this we read the IDoc Control Data in the IFlow and use a router to route the messages based on the Message Type or (as shown above) the IDoc type of the incoming IDoc.

• But the downside of this approach is that whenever there is an addition of a new IDoc type, we must add a new condition, a new branch and a new receiver to this IFlow, basically we will have to edit and redeploy this IFlow, which proves to be a tedious task and highly not recommended in the live system where thousands of messages pass daily and making changes in the IFlow can affect the Business as Usual (BAU) activities. This may lead to multiple message failures, increase of the ticket counts and worse, loss of business or monetary loss for the client.

Solution Approach

The shortcoming of the above approach is that we need to make changes in the main IFlow to add or remove the IDoc Types.

Therefore, the solution should be such where we should not have to make changes in the main IFlow and we should be able to add or remove the IDoc types, which can be achieved using:

• Value Mapping,


• Groovy Scripting, and


• Dynamic Configuration

The IFlow will look like this:

Image Source: SAP BTP Trial Account

The idea behind this approach is to use Value mapping for configuration and whenever we want to add or remove any IDoc in the IFlow, it can be done by changing the Value mapping only rather than changing the complete IFlow.

Step by Step Logic

1. Create 4 new properties in the Content Modifier, MESTYP, DOCTYP, SENDER and LS, and read the values of IDoc Message Type, IDoc Type, Sender and Logical system from the IDoc Control Data(EDIDC) segment respectively using XPath,


2. We will take the IDoc control data as input of the Groovy,


3. The required information is the Source, Message Type, IDoc Type and the Logical system stored in the respective Exchange Property,


4. In the groovy script we will access the Value mapping and get the corresponding Process Direct address to the next IFlow as shown below,


5. Then we will write the address of the next IFlow in the Header PD_Address,

import java.util.HashMap;

import com.sap.it.api.ITApi.ValueMappingApi;

import com.sap.it.api.ITApiFactory;

import com.sap.it.api.mapping.ValueMappingApi;

import com.sap.gateway.ip.core.customdev.util.Message;



def Message processData(Message message) {

	// Get properties

	map = message.getProperties();

	String mestyp = map.get("MESTYP");

	String doctyp = map.get("DOCTYP");

	String sender = map.get("SENDER");

	String log_sys = map.get("LS");

	

	// Get ValueMapping API

	def api = ITApiFactory.getApi(ValueMappingApi.class, null);

	

	if (api == null) {

		throw new Exception("Could not retrieve ValueMappingAPI.");

	}

	

	// Get the value from value mapping

	String value = api.getMappedValue(sender, mestyp, log_sys, doctyp,"ProcessDirect" );



	if (value == null ) {

		throw new Exception("No values found in the Value Mapping for Keys: " + sender + " : " + mestyp + " : " + log_sys + " : " + doctyp);

	}

	

	//Set Process Direct Address as Header

        message.setHeader("PD_Address", value);	

	return message;

}

Later the header "PD_Address"can be dynamically called in the Process Direct using Apache Camel expression:

Image Source: SAP BTP Trial Account

The Value Mapping will look like this:

Image Source: SAP BTP Trial Account

Benefits

Using this approach, we get the following benefits:

Image Source: MS Powerpoint

Summary

IDoc receiving is one of many ways in which we can use this approach, with a slight change it can be used for IDoc sending also and even while sending/receiving other type of data to/from multiple senders/receivers. We can also add a Multicast functionality to it as well.

P.S.

This is my first ever blog post so please excuse my beginner mistakes. Also, this blog post wouldn't have been possible without the help and inputs of my former & new colleagues, family and friends. Thank you!

 

Thanks and Regards,

Aayush Aggarwal