Last Update: 2. May 2024
This is a checklist you should consider when creating an integration flow on Cloud Integration (being part of SAP Integration Suite or just SAP Cloud Integration). We already have a best practice document how to maximize the value of technical Interface Documentation, however this is a clear list of actions to perform…
What is the goal of this? Better READABILITY, STRUCTURE, TRANSPARENCY, MONITORING and thus higher QUALITY with more efficient OPERATIONS.
Before creating the artifact, here are some basic recommendations for a better operations experience:
- use a dispatcher iflow where applicable (e.g. iDocs/SOAP messages from SAP systems) for better reuse and modularization (readability).
- use one iflow for each receiver (if you have a distribution to more than one system) for better monitoring and transparency. Decouple them (if applicable by JMS queues and not only via ProcessDirect).
- use one iflow for each sender (if possible check if you can use a dispatcher – see 1.) for better monitoring and transparency.
- use local integration processes or separate integration flows for better reuse and modularization (readability). Also avoid putting too much logic (elements) into one integration process.
Metadata
- Name: <Your Company Prefix> <Area> <Object> – <Sender> to <Receiver>
- Area: A company-wide business area or domain like Finance, Procurement, Sales, Manufacturing
- Object: The exchanged document / business object which is transferred
- Example: “ACME Sales QuotationCreate – Hubspot to SAP_S4HANA”
- ID: Same as name, but shortened in a package notation
- Example: “acme.sales.quotation.create.hubspot.saps4hana”
- Description (will be shown in the package overview)
- Example: “Create quotes from Hubspot into SAP S/4HANA Sales from Webhook quote.created”
- Sender / Receiver (in a readable format, can be multiple if applicable)
- Example: “Hubspot”, “SAP S/4HANA”
You can also change some of the metadata later (Except for the ID. In case you need to change you can copy the iflow and enter the ID as the name and then later rename the Name):
Integration Flow Designer (BPMN)
- Description: Enter a meaningful process description explaining what happens within this Integration Flow (mentioning technical process steps)
- Add an Application ID (to identify each message if applicable)
- Add a Message Type (to identify the interface/object transferred – this is done by default in the dispatcher flows)
- Add Custom Headers (to identify a message and assign it to a business context if applicable, e.g. SalesOrganization/CustomerGroup for Orders )
- Log the payload (message body) where applicable
- Rename Participants (for each Sender & Receiver)
- Rename Integration Process (at least if you have more than one)
- Remove the Label from Events, Multicast and Join elements to improve readability
- Ask a question for each Router (ending with a ?) and provide clear answers (e.g. yes, no, ok, true) for each option (outgoing arrow)
- Rename the following objects by putting a short, meaningful text
- Content Modifier
- Filter
- Splitter (Generic, Iterative, …)
- Mapping (XSLT, Message Mapping, …)
- Groovy Script, JavaScript
- Local Integration Process
- Exception Subprocess
- Calls (Request-Reply, Enrich, …)
- Consider using alternative User Roles for inbound authentication
Those recommendations can be configured according to your needs and automatically checked by our Quality Checks as part of our Interface Documentation.
Your Configuration:
Quality Check results:
If all checks are successful, you will get an empty list with a success message (our goal):
