We deliver standard CPI content for C4C integration with various products like SAP ECC, SAP CRM, SAP Marketing, Employee Central etc. But in most cases some enhancements are needed at the mapping level to pass additional information between systems, which are not part of standard content, but specific to customer implementations. In such cases the standard integration flow content needs to be edited, to make the required customer specific enhancements. The problem with editing an iFlow is two fold.

• • For the edited iFlow it is no longer possible to get future patches and enhacements

• • In case of a patch for a known bug is released, then all the customer specific enhancements have to be redone, which is both time consuming and error prone. In most cases it requires help of expert consulting.

With the introduction of ProcessDirect adapter, in SAP Cloud Platform Integration (CPI), now we are in a position to provide exit points in our integration flow artifacts which will enable customers to do enhancements on top of SAP delivered content without modifying the standard iFlow and thus customer will always get notified about all future patches and enhancements for those artifacts.

The same modelling is also possible with HTTP/SOAP adapter instead of ProcessDirect adapter but this will increase latency and network overhead as any call to another iFlow even inside the same tenant is treated as an external call and is routed via load balancer along with a need for authentication and authorization for each call.

In this blog we will discuss about the concept, of how extension is supported in SAP delivered content using modelling technique and use of process direct adapter. In a subsequent blog we will see how to implement the exit points.

Note: There can be various ways of modelling an iFlow to support extensions, this blog focuses on how this has been achieved for C4C integration content.

Refer to the official SAP help documentation for more information about Integration Flow Extension.

Understanding iFlow extensions

Extension is required in one of the following cases

1. 1. Source and target structure is enhanced

1. 1. Only the target structure is enhanced and mapped from existing elements in the source structure.

In the former case we need a pre-exit step where the extended source structure is mapped to standard SAP structure and a post exit step is needed where the output of the standard mapping and the extended source structure is mapped to extended target structure

Let’s try to understand this with an example

A typical iFlow in C4C content looks like below (without extension support)

Here we receive an IDOC from SAP ERP system, then map it to a target structure which is based on a C4C WebService and send the output to the target system (in this case SAP Cloud for Customer)

For simplicity we will refer SAP delivered structure as Standard Structure and customer enhanced structure as Extended Structure.

Example of Standard Structure : ORDERS.OREDERS05

Example of Extended Structure: ORDERS.OREDERS05.ZEXTENSION or ZORDERS.ZOREDERS05 (This purely depends if IDOC extended is using BDFG or WE30)

For the extension scenario we will only focus on the mapping as this contains the source and target structure.

Source Structure (Standard) ->Mapping->Target Structure (Standard)

In case of extension we get an extended source structure from source system, which needs to be mapped to an extended target structure

Source Structure Extended -> Mapping-> Target Structure Extended

In order to support extension the iFlow has to remodeled in such a way that the original mapping is never changed. This is achieved using the following steps.

1. 1. The Extended source message enters the iFlow (Main iFlow or Consumer iFlow) using the communication channel

1. 1. The original payload (Extended source structure) is stored, to be used later in the main iFlow and a pre-exit step is called using ProcessDirect adapter.

1. 1. In the pre-exit step (a separate iFlow/Producer iFlow), extended source structure is mapped to standard source structure (1:1 mapping) and the mapping output (standard source structure) is passed back to the main iFlow (consumer iFlow).

1. 1. In the main iFlow, the standard mapping is executed (expects input as the standard structure), which will produce the standard target message which then along with the original payload (extended source structure, which was previously stored in the main iFlow) is passed to a post-exit step using another ProcessDirect adapter inform of a multi message (having 2 messages in a single structure).

1. 1. In the post-exit step first the standard target message is mapped to the extended target message and then extension fields from source structure are mapped to the extension fields on the target structure (n:1 mapping) and the output is passed back to the main iFlow.

1. 1. Finally the extended target structure is sent to the target system.

To summarize,  mappings executed in different iFlow are listed below

• • Extended Source Structure->Standard Source Structure (Pre-Exit)

• • Standard Source Structure->Standard Target Structure (Main iFlow)

• • Standard Target Structure+Extended Source Structure -> Extended Target Structure (Post-Exit)

Note: From 1908 release pre-exits are no longer needed for IDOC to SOAP scenarios. So, one needs to just implement the one exit to map the extension fields. With this approach the no of calls inside the CPI tenant can be reduced significantly for high volume scenarios.

The main iFlow with pre and post exits to support extensions is modeled as below

1. 1. In the Content Modifier step the Original Payload is stored in to a exchange property which is later passed to the post-exit iFlow.

1. 1. The first Process Call is the pre-exit step

1. 1. The second process call is the post-exit step

1. 1. The filter step is used to filter the the target structure to be passed to the target system (this is needed to remove the mulitmap message root elements, created by n:1 mapping in the post-exit mapping).

Note: The router is used to check if exit steps are required to be called for this iFlow based on an external parameter which is set to false by default.

In the pre-exit process call step, a call is made to pre-exit iFlow using the ProcessDirect adapter.

In the post-exit process call step, the mapping output of the standard mapping is merged with the original payload from the source system using a content modifier, and a call is made to post exit iFlow using ProcessDirect adapter.

The pre-exit step is required only in case the source structure is enhanced, a typical example is extended IDOC (Here the IDOC root node is different from what we support in standard content). In case the source structure is service based then pre-exit is not required as the root node is not changed as a result the standard mapping can be executed as is. The extension fields get added to the same service (example: extension elements added to C4C service interfaces via KUT).

In the standard content both pre-exit and post-exit points will be provided only for scenarios where IDOC is the source structure. For all other scenarios only post-exit point will be supported.

Conclusion

In this blog we looked at how extensions are enabled for standard iFlow using modelling techniques and ProcessDirect adapter. In the next blog we will talk about how to implement the pre-exits and post-exits with a sample scenario. In addition we will talk about scope and timelines for this feature to be made available in the standard CPI content packages for C4C integration.