SAP CPI Antipatterns: what to avoid

Dear All,

Hope of all of you had a great 2019 and eagerly looking forward to the nice things 2020 is going to bring for us. For me, 2019 has been an eventful year, with new roles, new places, new challenges and a lot of learning.

There has been so many wonderful blogs about SAP CPI, written by people like Eng Swee Yeoh, Vadim Klimov, Morten Wittrock and many more technology enthusiasts who always find time to blog. Inspired by some of those blogs and my recent experience in CPI, I wanted to share my thoughts as well.

In this blog, I would like to list out few of such things. Please note this is not the complete list. But I believe these are the minimum things we should keep in mind when develop enterprise grade applications.

(Note: all the views expressed in this blog are my personal opinions. Please feel free to correct me if you believe, something can be better)

Re usability

When we code (irrespective of language, one thing we should look for is code re-usability). Imagine, same piece of code is written in 100 different places / files in your project. If we found a bug, then we need to update all those files, which can lead to further errors and is always a difficult task. Instead, write the common logic in one place and re-use whenever possible.

Instead of repeating all the steps in your main flow, try to create a separate iFlow and do one single process direct call from your main flow. This would help in maintaining the actual logic to do something (in this case, uploading the files) separate and easy configure.

Looks are also important

After a long day at work, when you get back home, how would you like to see your house? Clean and Tidy or everything scattered everywhere?

Fortunately, along with the strong and reliable run time capabilities, SAP CPI also has a user-friendly design time. When you design an iFlow, kindly give the artifacts a name, what they do. Please do not leave them as “Content Modifier-1”, “Route-201234”. Such things wont help anyone, including us when we try to get back to the flow after few days or months.

Have a look at this flow. All the receivers are named as Receiver-<number>

Looking at this below sub process, can we make out what this flow is doing?

Does your main flow really have to be this big? Can we not make use of sub-processes?

Can we give better names?

Externalization

One of the powerful features of SAP CPI, is the ability to externalize the important values (which can change when we move the flow from one landscape to other, or which needs to be changed before deployment, without changing the flow). As a minimum, make sure we externalize the receiving /sending system details. Any logging parameters, credentials etc.

As you can see in this below screenshot, neither the server URL, nor the credentials (and authentication method) are externalized. What if, our QA / PROD system has to connect to different URL and use a different authentication method?

Please, name your script files / message mappings / XSDs / any other resources properly. Every project we do using any of the SAP technologies are enterprise grade. Think about your client or your own employer, bad naming conventions puts all of us in a bad position.

Remove any unused External parameters. Its easy to clean while developing rather than after UAT Sign-Off or Go-Live.

Security Artifacts

Do not use your own credentials (like Srinivas-Mail-Credentials), you may forget to change it later and this could end up in production (take example of credentials for sending error emails and the flow never failed in DEV / QA)

Clean up any unnecessary security artifacts. Please note, we don’t have a “Where used” feature (yet) in CPI. So, if we don’t clean up our junk, it would extremely difficult for someone else to clean up your junk.

Be kind

We all know that CPI is a cloud offering, still be kind and think twice before you design an external call. Check if you can filter your data while querying. Avoid making Select * calls and then do an enrichment. We all love to use exchange properties to store intermediate data. However, if the payload we are storing in exchange properties too big, try to clean them up as soon as you have processed instead of waiting for CPI to clean them for you. Do not store sensitive data in headers, remember headers will be forwarded to the receiving systems.

Be thoughtful

Specially when using splitter. Understand the requirement properly. Out of a bunch of records, what should happen if the first or nth message fails? Do we need to process the rest or abort the whole transaction?

Avoid using data store where possible. Avoid unnecessary logging, avoid logging sensitive data (like employee / customer details). When processing the data, try to use SAP Application header, this helps in identifying message easily.

Groovy Script

We all love using groovy. However, when you are using groovy consider minimum coding standards. Avoid writing methods with 1000s of lines of code. Try to modularise your code, provide minimum comments, indentation and beautify your code. Avoid hard coding, check if you can make use of external properties or value maps. Avoid reading the message body as a String, instead use a reader.

Process Direct:

If we are making internal calls (one flow in CPI to other flow in CPI), try to make use of Process direct adapter, rather than using SOAP / HTTP adapter. More on Process direct adapter can be found here,

https://help.sap.com/viewer/368c481cd6954bdfa5d0435479fd4eaf/Cloud/en-US/74457187451f431298355fbbf807d086.html?q=process%20direct

Hope these things will help us deliver better integration flows using SAP CPI. Please let me know your thoughts.

Finally,

Wish you all a very happy new year.