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

[MortenWittrock]

Hi Aayush

Congratulations on your first blog post 🙂 Very nice - keep up the good work!

Regards,

Morten

[former_member749377]

Congratulations on your first blog post.Great work 👍

[aayushaggarwal]

Thanks a lot Morten.

[aayushaggarwal]

Thank you Varsha!

[ShaikAzmathulla]

Congratulations Aayush . Great Blog . Keep Going ..

[ArielBravo]

Nicely explained. Kudos!

I had a similar idea a few years ago:

https://blogs.sap.com/2018/07/06/idoc-dispatching-use-case-for-processdirect-adapter/

Bests,

Ariel

[former_member683598]

Firstly, thanks for this post. I had the same question on deciding the approach. Link to my question:

https://answers.sap.com/questions/13395862/s4hana-rfc-destinations-for-idoc-communication-wit.html

Unlike, PI where we can maintain Value mapping table directly in Production (in case of any new additions), in CPI we will have to modify the value mapping table and deploy that - correct?

[aayushaggarwal]

Thanks Ariel, your blog is also very nice

[aayushaggarwal]

Thanks Anuj for your comment.

Yes, in CPI for every change you would need to deploy the Value mapping.

Regarding your question, we generally follow, one Generic RFC Destination for CPI approach, to avoid error messages queuing up, use Exception Sub-process in your IFlow to handle the errors, this will help you avoid any deadlocks.

 

[aayushaggarwal]

Thanks Azmathulla!

[former_member732211]

Thanks again Aayush. If the expected volume of IDOCs is huge, and they would come at the same time from SAP (not batched), can using one Dispatcher iFlow  create a Bottleneck?

[aayushaggarwal]

CPI has the capability to handle high volume of data, and worker nodes will handle the message received whether it is in one Dispatcher iFlow or multiple iFlows.

[former_member683598]

This helps, thank you 😊 

[babruvahana]

Hi aayushaggarwal ,

Congrats on your first blog.

We are using this approach quite a long. But, recently we are facing error with the below log though we have maintained the value mappings correctly.

Error Log:

*********

com.sap.esb.camel.error.handler.ErrorEventException: Error Event Exception
org.apache.camel.component.directvm.DirectVmConsumerNotAvailableException: No consumers available on endpoint: {Value from Value Mapping}. Exchange[]

********

• Is there any restriction on load of IDocs being sent to CPI?
• In case of errors, we always get the same error like internal error occurred with a suggestion to use CPI tenant URL mentioned in the RFC. We can't track the actually errors if a receiving system rejects the IDocs.

Any Idea how do we over come such errors.

Regards,

Pavan

[aayushaggarwal]

Hi Pavan,

Thanks for your comment!

The main cause of this issue is related with a mandatory IFlow that has not been deployed.

Kindly check for which Process Direct Address you are getting this error and check the respective IFlow to which the Process Direct is pointing to.

Also, in case of errors, you can see the details in the Overview tab of the Cloud Integration tenant.

Regards,

Aayush Aggarwal

[babruvahana]

Hi Aauysh,

Thanks for your response.

We are using this approach from long time, someone from our team had used a duplicate values in the value mapping. Hence the error. As this happened in Dev tenant we were good.

I was talking about the errors captured by IDocs in S/4 system in case of failures. Not in CPI. IDocs will always fail with the same error instead of having the actual error in S/4 system

Regards,

Pavan

[SyambabuAllu]

Hi Aayush,

Great blog.Thanks for sharing.

Thank you,

Syam

[former_member732211]

Hi Pavan,

Would tou be able to share how many iFlows are being referenced by this Common IDOC iFlow? And roughly how many messages processed by this iFlow daily?

-Anuj

[former_member226]

Superb Aayush... It's a really cool tip to access Value Mapping content via Groovy. It will definitely help.

Thanks for the hint.

[lalmao]

Hi Aauysh,

We are following your blog but we got the following error:

javax.script.ScriptException: java.lang.Exception: java.lang.Exception: No values found in the Value Mapping for Keys: null : null : null : null@ line 26 in script1.groovy, cause: java.lang.Exception: No values found in the Value Mapping for Keys: null : null : null : null

We created the Value mapping but we don't where is refering in the groovy script. Should we create another property for the VM?

Thanks,

Millie

 

[aayushaggarwal]

Hi Leomilde,

Really glad to know that you are trying this approach.

Reading the error, it seems like the property values (sender, mestyp, log_sys, doctyp) are empty.

I suggest you to debug your IFlow in the Trace mode.

Regards,

Aayush

[lalmao]

It is working now. Thanks Aayush for your post that helped me a lot.

[philippeaddor]

Hi Aayush,

Nice post, but in my opinion, no VM and Groovy Script is necessary. See my comment in the similar post here:

https://blogs.sap.com/2018/07/06/idoc-dispatching-use-case-for-processdirect-adapter/comment-page-1/...

Philippe