One of the main differences between SAP Process Orchestration and SAP Cloud Integration is the way how strict or loose the Integration content is managed. The participants of an interface in PO are managed as Business Systems (maintained in the SLD) or Business Components for A2A connectivity or as Business Components with Parties for B2B/B2G connectivity. This is clearly visible in both configuration and runtime and allows a high degree of reuse.
In SAP Cloud Integration you have several places where you can maintain/see this information and there is no concept of reusability…
- Designtime: Metadata
- Designtime: Process Model (BPMN) -> later visible at runtime
- Connections (no maintenance): This is purely based on technical host/port connectivity (accessible via OData API, not shown here)
Best Practices
1. Always maintain the Sender and Receiver section when you create an iFlow. It is useful information to understand how the connectivity is done from a business perspective (Sender might be your SAP ECC, Receiver might be a Supplier). You can also maintain several senders and receivers and use spaces to make readability easier (see also the example above with a B2G scenario for Norway where the information level is very detailed).
2. Do not be lazy and change the default name of a Sender/Receiver in the Integration Flow Designer. It will not only help to understand the design better, but especially improve monitoring situations, as you will see the name of the Receiver (along with the channel name) in the MPL. Another advantage is that you can also search for those fields.
3. Enforce the Sender and/or Receiver to be written into the MPL. It is especially useful, when the adapter is not providing this information. It really depends on the adapters used. SOAP and XI manage this well, but others might not write this information into the MPL, but you can always enforce it (not only in error situations), by writing them into the header variable (in addition you can control if the Receiver is overwritten by receiver adapters- or not). Of course you can also externalize them to adjust the name based on the deployment environment:
Conclusion: Using the concept is optional, but it helps you to understand the iFlows better and also increase overall transparency for you integration layer, both from an architecture and operations perspective.
