SAP Integration Best Practices
Integration flows are long-lived assets. An iFlow built today might process millions of messages over the next five years, maintained by developers who were not part of the original team, modified to handle business requirements nobody anticipated at build time. Best practices are not rules invented arbitrarily — they are distilled lessons from years of integration projects that failed in predictable ways. Applying them saves the teams that come after you from repeating the same mistakes.
Design Best Practices
One Scenario Per iFlow
Each iFlow handles exactly one integration scenario: one source, one business process, one primary receiver. Resist the temptation to build a "universal" iFlow that handles multiple scenarios through complex routing. Universal iFlows become unmaintainable. When the scenario changes, developers cannot determine which part of the iFlow to modify without risk of breaking other scenarios sharing the same logic.
WRONG: One iFlow handles sales orders AND invoices AND customer master CORRECT: iFlow 1: Sales Order Integration (Shopify → SAP SD) iFlow 2: Invoice Processing (EDI → SAP FI) iFlow 3: Customer Master Sync (Salesforce → SAP SD)
Name Everything Meaningfully
iFlow names, adapter channel names, mapping names, and script names should immediately communicate their purpose. A developer reading your iFlow six months after you built it should understand each step without reading its configuration.
BAD NAMES: GOOD NAMES: iFlow: "Integration1" iFlow: "Shopify_SalesOrder_to_SAP_SD" Channel: "Sender1" Channel: "HTTP_Shopify_Webhook_Receiver" Mapping: "Mapping" Mapping: "Map_Shopify_Order_to_ORDERS05" Script: "Script2" Script: "Validate_OrderAmount_NotZero"
Externalize All Environment-Specific Values
Never hard-code system URLs, hostnames, port numbers, credential aliases, or any value that differs between development, QA, and production. Use Externalized Parameters in every iFlow. This single practice prevents the most common deployment mistake in SAP integration.
HARD-CODED (bad):
Receiver URL: https://s4hana-prod.corp.com:44300/sap/opu/...
EXTERNALIZED (correct):
Receiver URL: {{s4hana_host}}/sap/opu/...
Parameter s4hana_host configured per environment:
DEV: https://s4hana-dev.corp.com:44300
QA: https://s4hana-qa.corp.com:44300
PROD: https://s4hana-prod.corp.com:44300
Error Handling Best Practices
Every iFlow Has an Exception Sub-Process
No exceptions. Every production iFlow must include an Exception Sub-Process that at minimum logs the error, preserves the failed payload in a Data Store, and sends an alert notification. An iFlow without error handling is a black box that silently loses data when problems occur.
Classify Errors Before Responding
Detect whether a failure is technical (worth retrying) or business (needs data correction) before choosing a response. Retrying a business error wastes resources and delays detection of the real problem — bad data at the source.
Never Lose a Message
A message that cannot be processed must be stored somewhere accessible for later reprocessing. Use CPI Data Stores as the holding area for failed messages. Include all original data, the full error details, and the timestamp in the stored entry. The operations team must always be able to find and reprocess any failed message.
Security Best Practices
Principle of Least Privilege
Service accounts used by CPI to connect to SAP systems should have only the minimum permissions required. A CPI iFlow that reads sales orders does not need write access to financial posting. A supplier portal integration does not need access to HR data. Configure one service account per integration scenario with precisely scoped authorizations.
Rotate Credentials on Schedule
Set a calendar reminder to rotate all service account passwords and API keys at least every 90 days, or immediately upon any security incident. Store all credentials in CPI Security Material, never in iFlow properties or Externalized Parameters.
Log Access but Not Sensitive Data
Logs should record that a payment was processed but not the payment card number. Logs should record which customer made an order but not their personal identification details. Define which fields are sensitive before building, and strip them from logs explicitly.
Performance Best Practices
Process Asynchronously When Possible
Synchronous integrations hold connections open while processing occurs. Under load, this ties up connection pools. Whenever the caller does not immediately need the result, process asynchronously: accept the message into a queue, return a 202 Accepted response immediately, and process from the queue in the background.
Use Batch Processing for High Volumes
Calling a BAPI 10,000 times individually takes far longer than building one batch message with all 10,000 records and calling the batch-capable API once. S/4HANA OData supports $batch requests. IDOC bulk posting supports multiple IDocs in one transmission. Use batch capabilities for high-volume scenarios.
Cache Reference Data
If your iFlow looks up the same reference data repeatedly — for example, looking up a currency code table on every message — cache the result in a CPI Data Store after the first lookup. Subsequent lookups read from the cache (milliseconds) instead of calling SAP (hundreds of milliseconds). Refresh the cache daily or on a schedule matching how often the reference data changes.
Governance Best Practices
Document Every Interface
Maintain an interface inventory — a spreadsheet or wiki page listing every integration flow with its source system, target system, message type, trigger mechanism, frequency, owner, and last tested date. When something breaks, this document tells you exactly what is affected. When a system decommissions, it tells you which integrations to retire.
Manage Changes Through Transport
Never edit production iFlows directly. Always make changes in development, test in QA, and promote to production through a controlled transport process. Use Git or CPI's built-in version history to track what changed, when, and by whom.
Define and Test Service Level Agreements
For every integration, define what the business expects: maximum processing latency, maximum acceptable failure rate, recovery time objective if the integration goes down. Test whether your design meets these SLAs under load before going live. Monitor SLA compliance continuously in production.
Operations Best Practices
Treat Integration Failures as Incidents
A failed integration that blocks a business process is an incident, not just a technical error. Use the same incident management process for integration failures as for system outages. Assign severity levels, communicate status to affected stakeholders, and conduct root cause analysis after resolution.
Run Health Checks
Deploy health check iFlows that verify all connected systems are reachable and responding within acceptable time limits. Run them every five minutes. Alert when any system becomes unreachable — before business messages fail against it.
Review Performance Trends Monthly
Look at processing time trends across all iFlows monthly. A gradual increase in processing time often signals a growing problem — increasing data volumes, database growth in SAP, or network degradation — before it reaches a critical point. Catching trends early allows planned remediation instead of emergency response.
The Integration Developer Mindset
The best integration developers think beyond making data flow from A to B. They design for the failure case, the edge case, the case where everything goes wrong at 2 AM with nobody watching. They write code that their successor can maintain without a meeting. They monitor what they build and take responsibility for its reliability. They treat integration as a core business function — because when integration fails, business stops.
This mindset, combined with the technical skills built throughout this course, is what separates an integration developer who keeps systems running smoothly from one who creates fragile pipes that require constant attention. Build thoughtfully, monitor proactively, and always design for failure.