Foundations and integration contracts

What you should be able to explain

Integration Suite contains multiple integration capabilities. Cloud Integration designs and executes message-based flows; API Management governs API exposure. BTP provides the surrounding platform context. This dedicated track develops integration engineering beyond the existing BTP overview lessons.

Write the contract

In a fictional order interface, specify the sender, receiver, operation, schema, authentication method, business key and expected acknowledgement. Decide whether the sender waits for a final business result or only receives an acceptance response. A successful transport response is evidence about transport; it is not automatically proof that the receiver posted an order.

Design the processing boundary

A sender adapter receives the message. Processing steps validate and transform it. A receiver adapter calls the target. Exchange properties can carry internal processing context, while headers may affect adapter behavior or protocol communication. Confirm the exact adapter documentation before propagating a header. Keep secrets in the supported security material rather than script literals.

Worked investigation: the sender timed out

This is a fictional training case. The receiver committed order ORD-101, but its acknowledgement arrived after the sender timeout. A blind retry may create a duplicate. Use the business correlation key and receiver evidence to distinguish a failed delivery from a lost acknowledgement. A message-processing log is one evidence source; the final business object provides another. Neither a transport status nor a retry counter alone proves business completion.

Guided practice

Use a mock receiver and an explicit idempotency contract. Test a valid order, an invalid schema, a receiver rejection, a timeout before posting and a timeout after posting. For the last case, verify the receiver's business key before replay. The platform cannot guarantee exactly-once business effects across arbitrary remote systems merely because a queue or retry exists.

Recovery and operations

Set retry limits, distinguish retryable communication errors from invalid business data, and name the recovery owner. Configure retention and diagnostic logging to suit data sensitivity. Preserve a correlation identifier and sanitized failure summary rather than permanently recording full payloads. Re-test both the original failure and the successful path after changing the integration.

Check your understanding

An HTTP acceptance response has been returned but the downstream posting is pending. What can you claim? The receiving interface accepted the request according to its contract. Claim business success only when the relevant downstream evidence confirms it.

Scope and references

Capabilities, adapters, runtime options and entitlements differ by plan, region and release. JMS, events, APIs and hybrid runtime are separate design choices whose prerequisites must be checked.
[Official SAP Help: Cloud Integration](https://help.sap.com/docs/integration-suite/sap-integration-suite/ci?locale=en-US)
[Official Cloud Integration guide](https://help.sap.com/docs/cloud-integration)

---

Tutorial outcome

Define sender, receiver, schema, business key and acknowledgement semantics before drawing an iFlow. Transport acceptance and business completion are different facts. A timeout after a receiver commit creates an ambiguous outcome that a blind retry cannot safely resolve.

Prerequisites

Basic business-process knowledge; synthetic fixtures or an authorized sandbox.

Worked case — fictional

A synthetic create-order call times out after the mock receiver commits ORD101.

Step-by-step investigation

1. Contract

Write down the order key and the meaning of each acknowledgement before implementing retries.

Expected evidence: ORD101 is the stable business key.

2. Receive

Validate the synthetic message and preserve its correlation identifier through processing.

Expected evidence: Correlation C101 remains attached to ORD101.

3. Ambiguity

Simulate a receiver commit followed by a lost response and inspect receiver state.

Expected evidence: Sender timed out; ORD101 already exists.

4. Recover

Reconcile the receiver result before following the agreed replay procedure.

Expected evidence: Replay creates no second order.

Try it yourself

Reproduce the synthetic input from the example below in a local fixture or authorized sandbox. Follow each step, record the observed result, and explain any mismatch before continuing. Do not treat the expected evidence as a result observed in your SAP tenant.

Acceptance check

The exercise distinguishes accepted, posted and unknown outcomes without duplicate orders.

Common failure to avoid

Queueing and retries alone do not establish exactly-once business effects.

Self-check

A receiver timed out after a possible commit. What is the next safe evidence?

Expected reasoning: The receiver's business state for the agreed business key.

Edition and release scope

Check the linked SAP documentation for your product, runtime, region and enabled service plan. The worked case is a simulation; these steps were not executed in a customer SAP tenant.

SAP references

References checked 2026-10-30. SAP material supports the named concepts; the case, fixture and acceptance checks are original ERPClimb teaching material. No SAP tenant execution or certification is claimed.

[SAP Learning — Developing with SAP Integration Suite](https://learning.sap.com/learning-journeys/developing-with-sap-integration-suite) — Cloud Integration, API management and integration engineering

[SAP Help — Define Idempotent Process Call](https://help.sap.com/docs/cloud-integration/sap-cloud-integration/define-idempotent-process-call) — Successful subprocess recording and ambiguous receiver timeout limitations

A synthetic create-order call times out after the mock receiver commits ORD101.

Queueing and retries alone do not establish exactly-once business effects.

The exercise distinguishes accepted, posted and unknown outcomes without duplicate orders. Check the linked SAP documentation for your product, runtime, region and enabled service plan. The worked case is a simulation; these steps were not executed in a customer SAP tenant.

A receiver timed out after a possible commit. What is the next safe evidence? The receiver's business state for the agreed business key.