SAP MDG · UTILITIES
How does Bring Your Own Data Provider work in SAP MDG?
SAP MDG uses a fixed Query/Read structure and delegates provider-specific transformation and API calls to SAP Cloud Integration. Copy the SAP-delivered CI content, keep the generic routing and header handling unchanged, and adapt only the provider mappings, API call, authentication, and error handling.
SAP MDG uses a fixed Query/Read structure and delegates provider-specific transformation and API calls to SAP Cloud Integration. Copy the SAP-delivered CI content, keep the generic routing and header handling unchanged, and adapt only the provider mappings, API call, authentication, and error handling.
SAP MDG uses a provider-agnostic pattern: fixed SAP Query/Read structures go to Cloud Integration, which handles request identification, routing, provider-specific mapping, API invocation, and standardized response mapping back to SAP. The SAP-delivered CI implementation can be copied and adapted, while the generic flow stays unchanged
Process flow
- Copy the SAP-delivered Cloud Integration implementation into a customer-owned package.
- Preserve the generic request identification and routing logic.
- Preserve the Query and Read sub-process structure.
- Initialize the standard SAP technical headers; only adapt `SAP_Receiver` if needed.
- Adapt the SAP-to-provider request mapping.
- Configure the external provider API call and authentication.
- Adapt the provider-to-SAP response mapping.
- Implement provider-specific error checks and unified error handling.
Cloud Integration package copy and adaptation
Use the SAP-delivered CI content as the starting point and adapt only provider-specific logic.
Cloud Integration central routing
Identify Query, Read, or invalid requests and route to the appropriate sub-process.
Cloud Integration mapping and API call configuration
Transform the fixed SAP request/response structures to and from the external provider format.
Cloud Integration standard SAP header handling
Initialize and preserve SAP_* headers for logging, traceability, correlation, and monitoring; do not modify them except `SAP_Receiver`.
Referenced tables
| Object | Purpose |
|---|---|
SAP_* headers | Standard technical headers used for logging, traceability, correlation, and monitoring. |
CamelHttpQuery | Carries query parameters such as `sap-language` for extraction in CI. |
SAPLanguage | Message property used to store the extracted language value. |
The remaining configuration, implementation details, and testing guidance continue from this answer more…
Related questions and keywords
Alternative questions
- What is the architecture for a custom data provider?
- How does SAP MDG communicate with an external data provider?
- Where is provider-specific logic implemented?」「Why is Cloud Integration required?」「Can multiple external data providers be used?」「Does SAP MDG require custom code for each provider
Possible questions
- How do I implement a custom provider integration in SAP Cloud Integration?
- Which parts of the SAP-delivered CI content should I copy and which parts should I change?
- How do Query and Read requests flow through Cloud Integration?
- How do I handle provider-specific request and response mapping?
- How should SAP_* headers be handled in the provider flow?
- How do I add provider-specific API authentication and error handling?