Why extending iflows is always the way to go

If you are familiar with SAP Cloud Platform Integration (CPI), you know that SAP delivers a ton of out-of-the-box integration scenario’s.

This makes life easy. You download the package, configure the iflow, manage some certificates and authentications, you deploy it and you are good to go. This process is usually well described in the integration guide.

Implementing customer-specific logic

But what if you require some specific processing, or what if you have additional (usually custom) fields you want to interface? In that case you have 2 options:

1. You change the standard iflow.
2. You implement an extension.

Changing the standard iflow might seem tempting. It’s brilliantly easy (you click edit and you change whatever you like), where implementing an extension is a little bit more complex. There is a blog-trilogy available (here, here and here) on how to implement an extension. The fact that the blogpost is divided into three parts already indicates the complexity.

Yet extending the standard iflow is worth the effort rather than changing the standard because of the following reasons:

1. SAP delivers thousands of standard iflows. Do you really think they are all first-time right? Regular updates and fixes can be expected.
2. Iflows are the glue between 2 systems. If either of the systems change, the glue should change.

Extending is future-proof

Basically, what you do when you change the standard iflow, is you freeze the iflow definition. Future versions can not automatically be applied anymore. If you miss updates, you will miss fixes as well as developments on the iflow delivered by SAP.

Let’s assume a simplified situation where we have an iflow with 2 fields.

At a later moment in time, SAP will develop and deploy a new version of the iflow, in most cases because either the sender or receiver has changed. In this example, a new field has been added to the object.

If you had previously decided to change the standard iflow, you will be stuck with our version 1.0, where the mapping of the new field is not maintained.

In order to prevent this, SAP (and myself in this case) advise strongly not to change the standard iflow, but to implement an extension (as described in the forementioned trilogy).

In our case, when implementing, it would look like this:

And after SAP has deployed their version 1.1, it will look like this:

Simply put, despite the update of the standard iflow, our custom logic remains and does not interfere with the standard. The new mapping now automatically works.

Need help configuring your iflow extensions, feel free to ask :-).