Skip to Content

Best practice on mixed data sources (S/4HANA Cloud and SCP)


We're working on a S/4HANA Cloud implementation project and currently facing one particular problem that would love to have some external input.

For this particular development we have to build an UI5 app to display Sales Documents and MRP data, showing what is planned for a Sales Order Item's material.

On S/4HANA Cloud the CDS for Sales Documents (I_SalesDocument/Item) is released for custom use, but not MRP data (SupplyDemandItems), as can be checked here CDS Views for Material Requirements Planning. Nevertheless, we do have access to MRP data using the whitelisted API Material Planning Data - Read.

The challenge now becomes on how and where we combine those two different OData services (assume that SO's CDS will be exposed as OData Service). Straightforward solution would be fetching them on UI, but that will for sure have an impact on performance.

Second option would be do the merge/manipulation on SCP using APM and expose that as base service for the UI. Data volume transferred will be the same between S/4HC and SCP but we would take advantage between data centers connection speed. On SCP data would be aggregated and UI would consume only what it needs.

Did you ever face the same issue and what was the overall solution? Again, would love to hear any input on this matter.

Thanks folks

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

1 Answer

  • Best Answer
    May 22 at 02:14 PM


    in one of our applications, we have a similar issue where we needed to integrate over multiple data sources. Here, we did this on the backend side with parallel requests to the relevant systems and then used some specific merger logic to combine the data from all sources.

    So in that regard, we have made good experience with this approach as it gives us good flexibility to transparently merge the data sources under a unified, business-oriented API that was then exposed to the UI.

    Also, it allowed us to transparently cache data from slower backends and ensure availability of our service even in case of a downstream system issue. In this case, we can still provide a partial response with a degradation indicator.

    Hope this helps!


    Add comment
    10|10000 characters needed characters exceeded