1) SAP CPI is based on Apache Camel framework
Frst thing good to know is SAP CPI is based on Apache Camel integration framework. I mentioned good to know because it is not need to understand full usage of Camel, but it will make a lot sense when you see many “Camel” keyword during SAP CPI development, and know where to look for answers. For example, Camel’s simple expression, date, file language expression.
2) Content Modifier to add/change/delete some data
This is simple but important step in CPI that used frequently. Original Camel exchanges and Camel concept can refer this SAP Press blog. The key takeaways for practical CPI usage are:
a) Pipeline concept that CPI pass message contain headers, properties and body from one CPI step to next step connected by arrow. Multiple CPI steps can be chained together sequentially/parallelly.
b) Content Modifier able to add/change/delete headers, properties and body (also number range & variables).
c) Generally, header store smaller size data that might need send to receiver(s)a. E.g. as HTTP headers.
d) Generally, property store larger size data and data need to store in earlier step of iflow and need retrieve back at later step.
e) Body is main payload that can send to receiver(s).
3) Request-Reply to make some calls and Adapter for Connectivity
Request-Reply simply mean make some request call to receiver and get reply/response back. Suggest to first learn these 3 adapter types: HTTP, OData, SOAP because majority of use-case especially those cloud-based API believed fall under these 3 adapter types.
4) Routing Concept mean where and how should my messages flow to?
Routing is common usage in integration, suggest to first learn these 3 routing patterns:
Router step to send message to different routes based on condition, process using different logic and optionally back to single main route.
Multicast step to send the same message to multiple routes to process differently, and optionally gather back results from all different routes.
Splitter step to tackle challenge of splitting large payload to smaller one then only process. Should understand different between General and Iterating Splitter, and learn how to split by XPath, Line Break and Token.
5) Converter to convert body from one format to another
Should learn the usage of standard converter JSON To XML, XML to JSON, CSV to XML, XML to CSV, because these are common payload format hence common requirement.
6) Looping concept in CPI
If you come from imperative/procedural programming background (e.g. Java, ABAP, C#), you might wondering how to looping in SAP CPI? What are the equivalent CPI ways to do for loop/while loop since all these CPI steps is drag-and-drop only without coding? The answer is using CPI “Looping Process Call” with condition to exit loop. You should also aware the concept of OData V2 vs V4 looping and leverage build-in looping feature of OData adapter.
7) Filter/Sorting concept in CPI
Filter concept mean only take necessary data required, either source system only send required data, or use CPI filter step to retain only required data. For filter step you will need fair good knowledge of XPath to filter effectively. Alternatively, can use message mapping for filtering or use groovy mapping to do advanced complex filtering.
For sorting, there are no build-in ready step by CPI to do sorting. Will have to resort to custom solution, either XSLT, message mapping (not recommended due to need apply sorting to all fields) or groovy mapping.
😎 Enrich/Lookup concept in CPI
There will be cases you might need get different payloads from multiple sources or multiple calls, then only enrich the main payload with data from lookup payload. You should understand default capability and limitation of Content-Enricher step, and good to know ways to do advanced data enrichment using groovy mapping, since message mapping(multi-mapping) that involved multiple messages normally will be relatively much complex to develop and maintain.
9) Integration flow design concept in CPI
Personally, I classify the CPI iflow design to 2 major considerations:
First is performance consideration. You should aware different iflow design although might still achieve the result, but sacrificed performance and might become unbearable slow and error prone. General advice is to reduce number of calls required and eliminate unnecessary calls. Avoid using unnecessary large payload but split to reasonable smaller payloads.
Second is iFlow design that easy to understand, develop and maintain. For example, concept of modular design, divide and conquer technique to sub-divide different group of CPI steps into local integration process, make use of processDirect adapter for reusable logic. The iflow designed should be relatively easy to understand. If you from programming background then know that Spaghetti code is messy not maintainable, so the same apply to CPI iflow design, should easy to see where it start, how it flow (left to right, top to bottom) and where it end.One example of badly design iflow is use only one main process that have too many different CPI steps, multiple receivers and arrows that connecting horizontal, vertical, diagonal in every direction, then essential become Spaghetti flow.
10) Groovy Scripting capable to tackle complex mapping (and many things else)
Since Groovy is general purpose programming language so it is very flexible and powerful, basically you can use Groovy script to do a lot of tasks (not only mapping) as long as you able code the solution in Groovy language, and supported in CPI environment. For example use groovy mapping to so source-target fields mapping between these data format: Xml, Json, CSV, IDOC, Odata Batch. Using Groovy scripting is extensible because able to import Java Jar libraries that contain the feature you needed. Example CSV processing Jar library.
11) Message Mapping (Graphical Mapping) and Queue and Context concept
If you need to support existing message mapping from standard pre-packaged content iflow, or need to migrate SAP PI/PO message mapping to SAP CPI, then there is no other choice but need to understand those tricky mapping queue and context handling using node functions. It will be difficult to work on complex message mapping without good understanding on message mapping queue and context concept.
12) XSLT powerful in XML transformation but come with steep learning curve
SAP CPI XSLT processor support XSLT 3.0 specification, the key takeaway is with XSLT 3.0 it is even feature-rich to do advanced xml transformation. For me I still not able to tune my thinking into XSLT way and not skilled in XSLT. If you have the time, determination and brain-power to learn and think in XSLT, it will be a great skillset to acquire.
13) Persistence/Variable/Data Store mean CPI keep data for later usage
For normal integration flow processing, all header, properties and body temporarily hold in CPI during runtime will not able to retrieve them back again after iFlow processing end. This persistence/variable/Data store concept is asking CPI to ‘remember’ by storing in SAP CPI. Generally, global/local variable is for storing single value, while Data Store is to store list of value/payloads under same data store name.
14) Exception handling concept in CPI
When error happened in CPI message processing, we can either do nothing then let it failed in CPI in red error, or add exception sub-process. Ideally should at least able to get back the error message and error stack trace, then see how to handle errors, e.g. send alert email, store error message in SFTP server or design advanced re-processing mechanism using data store.
15) Security concept in CPI
First security concept is authentication. Should aware different authentication supported by SAP CPI. For example username/password, OAuth2 token or client-certificate based authentication. Second concept is authorization mean what access granted example developer role don't have admin access to manage CPI tenant setting or security artifact. Other security concept is message level encryption(encrypt and decrypt) and signature (sign and verify) that commonly used in file-based transfer like in SFTP, but some also apply encryption in API-based HTTP calls.
16) Explore and learn other adapter types based on need and interest
For example: Explore SFTP adapter if need work with files sending/polling, with external partners example Banks’ files. JDBC adapter if need connect and use SQL and stored procedure to interact with database tables. SuccessFactors adapter if need query or post data to SuccessFactors API (either SOAP or OData). You get the idea, hence no need to list all CPI adapter type here.
