Lesson 2 of 6
Integration flows
10 min
Listen to this lesson
An integration flow is a model of how one kind of message travels: who sends it, what happens to it, and who receives it. You build it in the web-based flow editor in the Design area, configure each element in its property sheet, then deploy it to the tenant runtime. The model looks like a BPMN diagram, and it reads like one: pools for the participants, an integration process with steps, and channels that connect them through adapters.
Anatomy of a flow
- SenderThe system that starts the exchange, for example Contoso's S/4HANA system CMQ sending an ORDERS IDoc.
- Sender channel and adapterThe protocol endpoint the tenant exposes, such as the IDoc adapter over SOAP, with its authentication setting.
- Integration processSteps in order: convert, enrich, map, route, call out, log.
- Receiver channel and adapterThe outbound protocol, such as SFTP or AS2 toward the partner, with the credential alias to use.
- ReceiverThe partner system, here Lakeside Components' order intake.
The integration process is where the steps go. Typical steps are the Content Modifier (set headers, exchange properties and the body), converters (JSON to XML and back, CSV to XML), mappings, Router, Splitter, Request Reply (call an external system and use its answer), Content Enricher, and Script steps in Groovy or JavaScript for logic the standard steps cannot express. SAP's integration flow design guidelines on the SAP Business Accelerator Hub show reference flows for each Enterprise Integration Pattern.
Adapters
Adapters translate between the outside world and the message inside the flow. Pick them from the system and protocol at each end, not from habit. For an S/4HANA Private Edition system the common choices are the IDoc adapter, the SOAP adapter for web services, and the OData or HTTP adapter for APIs. When the tenant calls a system that is on-premise or in a private network, it goes through Cloud Connector; when S/4HANA sends an IDoc to Cloud Integration, it calls the tenant over HTTPS directly.
| Adapter | Typical Contoso use | Style | What to configure carefully |
|---|---|---|---|
| IDoc | ORDERS out of S/4HANA, ORDRSP back in | Asynchronous | Endpoint address, authentication, IDoc number handling |
| OData / HTTP | Reading a business partner from S/4HANA during the flow | Synchronous | Proxy type on-premise, location ID, credential alias, timeout |
| SFTP | Dropping order files for a smaller supplier | Asynchronous, file based | Host key in known hosts, directory, file name pattern |
| AS2 | EDI with larger trading partners | Asynchronous with receipts | Partner certificates, MDN handling, signing and encryption |
| JMS | Decoupling receipt from processing inside the tenant | Asynchronous, queued | Queue name, retry interval, maximum retries |
| ProcessDirect | Calling another flow in the same tenant | Internal | Matching address on both flows |
Building the Lakeside order flow
- Create the flow in package
Contoso_P2P_Outboundand add the sender participant for S/4HANA with an IDoc sender channel. - Add a Content Modifier that copies the IDoc's purchase order number into a header such as
SAP_ApplicationID, so the monitor can be searched by business key. - Add the message mapping from the ORDERS IDoc structure to Lakeside's order format (lesson 3 covers it).
- Add a receiver participant for Lakeside and an SFTP receiver channel that writes one file per order.
- Externalize the host, directory and credential alias so each tenant can set its own values without editing the flow.
- Save, deploy, and check in Monitor that the deployment status is Deployed and the runtime status is Started.
Externalized parameters are the difference between a flow you can transport and a flow you have to edit in production. Anything that differs by tenant, such as hosts, directories, credential aliases and partner IDs, belongs in a parameter you set through Configure. The flow model itself then moves unchanged from the test tenant to the production tenant, which is also what auditors expect to see.
- DesignModel and saveFlow saved as a new version in the package in the test tenant.
- ConfigureSet parametersLakeside's test SFTP host and the test credential alias.
- DeployRuntime startedDeployment status Deployed, runtime status Started.
- TestOrder 4500002210 sentMessage completed and file found at Lakeside's test host.
- TransportProduction tenantSame flow version; only parameters set to production values.
What would you do?
Kenji hard-coded Lakeside's test SFTP host and directory into the receiver channel to save time. The flow is ready to move to production next week. What should Theo ask for before transport?
- A flow has a sender, sender channel, integration process, receiver channel and receiver.
- Choose adapters by the protocol at each end; the tenant reaches on-premise systems through Cloud Connector.
- Set a business key header so the monitor can be searched by order number.
- Externalize everything that differs by tenant, then transport the same flow version.
Check your understanding · not graded
Lesson check
1. Which step calls an external system and continues the flow with its response?
2. Why externalize parameters such as hosts and credential aliases?
3. Contoso's S/4HANA system is in a private network. How does the cloud tenant reach it?
4. What status pair confirms a flow deployed and is running?