SAP CPI Adapter Types Comparison: SOAP, REST, IDoc, OData, and More

SAP Cloud Integration adapters define how an iFlow connects to a sender or receiver. The correct choice depends on the protocol exposed by the external system, the message format, authentication, delivery pattern, and operational requirements.

A useful design separates the transport protocol from the payload format and from message transformation. For example, REST commonly carries JSON, but it can also carry XML; SOAP uses XML envelopes; SFTP transfers files without providing an application API. Start with the endpoint contract rather than choosing an adapter because its name appears familiar.

For broader context, see the SAP integration, PI, PO, and CPI overview before mapping an existing landscape to Cloud Integration.

01How CPI adapters fit into an iFlow

An adapter sits at the edge of an iFlow. A sender adapter receives a message, while a receiver adapter sends a message to a target system. Processing steps between them can validate, route, enrich, map, convert, or otherwise transform the message.

The adapter usually controls connection details such as the endpoint address, transport security, authentication, timeout, proxy behavior, and protocol-specific options. The payload is handled by the adapter and subsequent iFlow steps, so adapter selection should be reviewed together with message mapping and error handling.

The SAP CPI iFlow basics guide provides the surrounding flow structure for the adapter decisions described here.

Sender system
    |
    v
Sender adapter -> validation/routing -> mapping/conversion -> Receiver adapter
                                                                  |
                                                                  v
                                                            Target system

02SAP CPI adapter comparison at a glance

The comparison is a starting point, not a substitute for the target system contract. A system may expose both an OData service and an IDoc interface for the same business object, with different delivery guarantees and monitoring responsibilities.

03SOAP and REST adapter selection

Choose SOAP when the provider publishes a WSDL, uses XML schemas as the formal contract, or relies on SOAP headers and fault messages. Confirm the operation name, namespace, SOAP version, authentication method, and whether the endpoint expects a SOAP action.

Choose REST when the provider documents HTTP resources and methods such as GET, POST, PUT, or DELETE. Confirm the URL structure, required headers, accepted content type, response codes, pagination model, rate limits, and token lifecycle. A REST adapter configuration is incomplete until the team understands how the API signals both success and failure.

For REST calls, test at least one successful response, one validation error, one authentication failure, and one throttling or temporary failure. Record the request method and relevant headers without exposing access tokens in logs.

04Using the IDoc adapter for SAP integration

The IDoc adapter is appropriate when an SAP system already provides a stable IDoc-based interface for the business process. The design normally depends on the message type, basic type or extension, partner profile, port, and processing direction.

For inbound processing into SAP, validate the receiving partner configuration and confirm how the SAP system creates and reports IDoc status records. For outbound processing, verify the sending partner configuration, trigger condition, and whether the IDoc is serialized or released as expected.

The SAP CPI IDoc integration basics guide covers the interface elements that must align between Cloud Integration and the SAP backend.

Treat IDoc status as part of the operational design. A technically delivered message can still produce an application-level error in the target SAP system, so monitoring should correlate the CPI message with the resulting IDoc number and status where the interface supports that correlation.

05OData and HTTP adapter differences

Use the OData adapter when the service follows OData conventions and the integration needs service-specific handling such as entity sets, navigation paths, query options, CSRF protection, or OData pagination. The adapter helps express an OData interaction, but it does not replace business validation or response handling in the iFlow.

Use the HTTP adapter for a generic HTTP endpoint whose contract does not require OData-specific behavior. Configure the method, URL, headers, authentication, and body according to the provider documentation. HTTP is often the right choice for a custom JSON API, webhook, or service with a non-OData resource model.

A practical decision rule is simple: the service contract determines the protocol adapter, while the payload schema determines the conversion and mapping steps that follow it.

06SFTP and file-based integration

Choose SFTP when the source or target exchanges files through a secure file server. Define the directory, file name pattern, polling interval, archive behavior, lock strategy, encoding, and error directory before activating the flow.

File integration needs explicit duplicate and partial-file protection. Coordinate how the producer signals file completion, use a stable naming convention, and ensure that processed files cannot be picked up repeatedly. For large files, review memory use, streaming options, splitting strategy, and downstream transaction limits.

A file name can carry business metadata, but the payload remains the authoritative source for business validation. Do not treat a successfully downloaded file as proof that the business transaction succeeded.

07How to choose an adapter

Use this sequence when a new interface is being designed:

1. Identify the endpoint contract published by the sender or receiver.
2. Select the protocol adapter that directly matches that contract.
3. Confirm the direction: sender, receiver, or both in separate flows.
4. Document authentication, certificates, network route, timeout, and retry behavior.
5. Define the payload format, character encoding, and schema validation rules.
6. Decide whether mapping, conversion, enrichment, or routing is required.
7. Define correlation identifiers and the monitoring fields operators need.
8. Test technical success, business rejection, authentication failure, timeout, duplicate delivery, and retry behavior.

The adapter should be selected before detailed mapping, but the decision should be validated against the complete end-to-end test. A protocol that looks suitable in isolation may be unsuitable when the provider requires synchronous responses, strict ordering, or a particular error contract.

08Authentication and connectivity checks

Record the authentication model separately from the adapter choice. Common patterns include basic authentication, client certificates, OAuth credentials, SSH keys for SFTP, and signed or encrypted B2B messages.

Store credentials and keys in the appropriate security artifacts and assign only the permissions needed by the interface. Confirm certificate validity, trust configuration, hostname matching, proxy routing, and firewall access before investigating payload mapping.

For a failed connection, check the evidence in this order:

1. The endpoint URL, host, and port.
2. DNS and network reachability from the integration runtime.
3. TLS trust and certificate validity.
4. Authentication artifact and target-system permissions.
5. Adapter-specific headers, method, action, or path.
6. Payload structure and content type.

This order separates transport failures from application failures and reduces unnecessary changes to the iFlow.

09Testing and troubleshooting adapter failures

Test the adapter independently where possible, then test the complete iFlow with a representative payload. Capture the message identifier, correlation identifier, endpoint, response status, and provider error reference while protecting credentials and personal data.

A useful troubleshooting split is:

The SAP CPI monitoring and error handling basics guide is useful when turning these checks into an operational procedure.

Retry only failures that are safe to retry. A network timeout may leave the target system uncertain about whether it processed the request, so idempotency keys, business document numbers, or duplicate checks may be required before automatic replay.

10Mapping and payload conversion

Adapters transport messages; they do not automatically make two business schemas equivalent. Use message mapping, content modifiers, converters, or scripting when the source and target structures differ.

Check namespaces carefully in XML messages, especially for SOAP and IDoc payloads. For JSON, confirm whether fields are mandatory, nullable, arrays, nested objects, or represented by provider-specific date and number formats.

The SAP CPI message mapping basics guide covers the transformation decisions that follow adapter configuration.

Keep sample payloads for the minimum valid message, a complete business message, and a deliberately invalid message. These samples make regression testing faster after changes to mappings, credentials, endpoint paths, or adapter parameters.

11Operational checklist before activation

Before activating an adapter-based iFlow, verify the following:

• The endpoint and direction match the approved interface contract.
• Authentication artifacts are present, valid, and limited to the required permissions.
• Certificates and keys have an owner and renewal process.
• Sender polling, schedules, or webhook behavior are documented.
• Timeouts, retries, and duplicate handling are explicit.
• Payload validation and mapping errors are visible to operators.
• Correlation identifiers connect CPI messages with target-system records.
• Sensitive headers, credentials, and payload fields are excluded from diagnostic output.
• A support procedure identifies the responsible system owner and escalation data.
• A rollback or deactivation procedure has been tested.

Treat adapter configuration as production code. Record changes, test them with representative data, and review operational alerts after activation rather than relying only on a successful deployment.

12Key points for adapter design

The best adapter is the one that matches the published endpoint contract and supports the required operational behavior. SOAP, REST, OData, IDoc, SFTP, HTTP, AS2, and Mail each solve different integration problems.

A reliable implementation combines the adapter with clear authentication, payload validation, mapping, monitoring, correlation, retry, and duplicate-handling rules. Troubleshooting becomes faster when transport, protocol, payload, and business-processing evidence are captured separately.