External Properties and their value in CPI development and change management

[MartyMcCormick]

When working with customers who are using SAP Cloud Platform Integration (CPI) for their integrations, I often come across questions on maintaining property values across Q and P systems. Often, I find iFlows that are being edited directly in production to set property values such as hostnames on SOAP/OData adapters, credential names, schedulers, etc. There are several downsides to this approach, namely you have to find all places to change the property and you have to change them after every time you transport the iFlow package since the values get overwritten. For example, if you have an iFlow with 10 calls to an S/4HANA Cloud system to fetch various data, you would be changing the hostnames and credentials 10 times every time you transported.

There are several great blogs that discuss externalization of parameters (for example: https://blogs.sap.com/2017/06/20/externalizing-parameters-using-sap-cloud-platform-integrations-web-...I often see externalization used in content modifier or adapters such as SFTP, SOAP and OData. However, the possibilities are endless in CPI.

Let's walk through a simple example in case you are new to CPI and not sure what I am referring to in the above text.

Let's say you have to make an OData call to post a Material Document goods movement.

This is the URL: https://my900999-api.s4hana.ondemand.com/sap/opu/odata/sap/API_MATERIAL_DOCUMENT_SRV

On your OData adapter, you can click on the Externalize link in the upper right

You provide ExternalizedParameters in {{ }} notation. Here, the recommendation is to use only the base URL. The reason being, if you have several calls to S/4HC as part of this iFlow then you only need to change the value on time in Configure step after transport. They all use S4HCURL and credential S4HCCred.

Note: You can also provide external parameters by just typing {{S4HCCred}} into the value field on the adapter itself and the values can be changed just by clicking on the grey text.

Anything specific like the OData endpoint can be entered as normal and not part of the external parameter.

Then when you transport this iFlow package, you just need to use Configure option to change these values.

You can see all parameters that were externalized including those set on content modifiers, adapters, etc. in this screen. If you have 12 receivers using the S/4HC URL, you only need to change it once.

Subsequent transports of the package to production do not overwrite these changed values allowing you to quickly transport changes from Q->P in CPI.

Possibilities are endless to use external parameters, especially on the first content modifier. Things like enabling extended logging properties, a specific user id, hostnames, etc. can all be set and configured via Configure option without editing the iFlow itself.

You can (and should) externalize items such as schedulers too. Thus, allowing you to change schedules of iFlows in Q and P or from one once to scheduled, etc.

Enter a name for the property, i.e. {{Scheduler}}

Now scheduler is configured via "Configure" option and not in the iFlow itself.

To summarize, externalizing parameters allows the CPI package to be transported and the iFlow parameters to be set via "Configure" option in design editor instead of editing the iFlow directly. This keeps change management consistent, reduces effort on transports while increasing flexibility of using different parameters across your landscape. Subsequent transports do not overwrite these values allowing for quick and efficient transports of packages.

Thanks,
Marty