SAP MDG · COMMUNITY
How can I bring my own data provider into SAP MDG using SAP Cloud Integration?
SAP MDG uses a fixed Query/Read request and response format, while provider-specific transformation and API invocation happen in SAP Cloud Integration. The delivered CI content can be copied and adapted; usually only the request/response mappings and provider API call configuration need to change.
SAP MDG uses a fixed Query/Read request and response format, while provider-specific transformation and API invocation happen in SAP Cloud Integration. The delivered CI content can be copied and adapted; usually only the request/response mappings and provider API call configuration need to change.
This quick reference shows the standard SAP MDG processing model for bringing your own data provider. SAP MDG sends a fixed Query or Read structure to Cloud Integration; CI identifies the request type, routes it to the correct process, converts the payload into the external provider format, calls the provider API, and maps the result back to the fixed SAP response structure.
Process flow
- 1. SAP MDG sends a fixed SAP-defined Query or Read request to Cloud Integration.
- 2. Cloud Integration receives the request.
- 3. CI identifies whether the request is Query, Read, or invalid.
- 4. CI routes valid requests to the corresponding Query or Read integration process.
- 5. CI transforms the fixed SAP request into the external provider format.
- 6. CI calls the external provider API.
- 7. CI checks the provider response and handles errors.
- 8. CI transforms a successful provider response back into the fixed SAP response structure.
Use the SAP-delivered Cloud Integration implementation as the starting point; copy it into a customer-owned integration package.
Create the provider-specific integration package and keep the generic framework reusable.
Preserve the central integration process that inspects the inbound message and routes Query, Read, or invalid requests.
Keep provider-agnostic routing unchanged.
Preserve the standard SAP technical headers; do not modify the generic header fields except for SAP_Receiver.
Support logging, traceability, correlation, and monitoring.
Adapt the SAP-to-provider request mapping and provider-to-SAP response mapping.
Convert between fixed SAP structures and the provider-specific API format.
Configure the provider-specific API call and authentication such as API key, OAuth, or Basic Auth.
Connect CI to the external provider endpoint.
Use optional Mapping Extension for additional customer-defined Read mapping logic where needed.
Add an extra enhancement layer without changing the standard flow.
Referenced tables
| Object | Purpose |
|---|---|
Key Objects and Terms | Reference of the main integration concepts used in the BYODP framework. |
The remaining configuration, implementation details, and testing guidance continue from this answer more…
Related questions and keywords
Alternative questions
- How does Bring Your Own Data Provider work in SAP MDG?
- What is the architecture for a custom data provider?
- How does SAP MDG communicate with an external data provider?
Possible questions
- How do I start building a custom provider integration?
- Can I copy the SAP-delivered CI package?
- Which parts of the delivered integration should I change?
- What is the end-to-end implementation checklist for a BYODP scenario?
- How do Query and Read processing differ for an external data provider?