SAP Cloud Platform(SCP) Integration and Modelling
Introduction: I was recently engaged in an SAP Cloud Platform(SCP) implementation project at a Media company. The primary goal of this project was to lay the foundation for SCP integration and reporting with 3rd party SaaS providers. In this blog, I will share my experiences with HANA modelling as well as integration of SCP, with On Premises BW and 3rd party SaaS provider.
SAP Cloud Platform Components used:
- SAP Cloud Platform
- Cloud Connector
- SAP Cloud Platform Integration(CPI)
- SAP HANA DB
External data sources to SCP:
- RESTful API ‘s from SaaS provider
- On Premises BW on HANA
- Business Objects WEBI On Premises(4.2)
- Analysis for Office
Architecture and Data Flow:
Data flow and primary activities:
How did we get 3rd party SaaS data into SCP?
Data from 3rd party SaaS company is pushed into SCP using CPI(Cloud Platform Integration). The data then gets updated into the HANA database tables via OData services initiated in the Integration Flow of CPI.
Key Notes: Pagination is handled in CPI. Not all fields in the API are delta capable therefore a weekly run is also initiated equivalent of a full load from the source.
How did we handle On-Premises BW on HANA data in SCP?
Connected to On-Premises BW on HANA via Cloud connector and created Virtual tables. The virtual tables are based on on-premises calculation views. Data is pulled into HANA views at the time of report execution. No on-premises data stored in SCP.
Following are some of the important aspects that should be considered while modelling in SCP HANA.
- Joins between SCP HANA database tables/views and Virtual tables based views need to be carefully designed. Particular attention should be paid to left outer joins. Left table in SCP HANA and the right being a calculation view based on premises virtual table. This was leading to performance issue as the all of the data from on-prem was first pulled into SCP HANA DB and then the join was going into effect, thereby significantly impacting performance. Solution was to re-design with inner joins where possible and used tables functions in views to call the calculation views(that are based on virtual tables).
- CTS+ has limitations in transporting Integration flows. We did an export/import of the integration flows.(Update – 12/07/2018 – Basis was able to configure and transport Integration flows as part of CTS+)
- WEBI reports prompts pop up slow, takes about 25-30 seconds to show up during WEBI report run time.
- Always call on premises views that return large dataset, with input parameters to limit the number of records being loaded into SCP HANA DB.
- Avoid Joins and use Union nodes instead where feasible for virtual data.
- Plan for SCP Authentication and Authorizations architecture in advance with Proof of concepts executed prior to launch.
Conclusion: SAP Cloud Platform has packed in a lot of features to help build enterprise grade applications and reporting possible. The components required will vary for based on the client needs. Careful study, understanding and expertise is needed to architect the solution and scale it. Integration of on premises data along with 3rd party feeds makes SAP Cloud Platform a good alternative to roll out new applications and reporting, without disrupting any existing enterprise systems.
Thanks for the blog post. Did you mean to provide a graphic of the architecture and data flow? It would be really helpful if we could get an insight into the actual architecture. Thanks.
Hi Shantanu, Thanks for your comment. I have updated with the Architecture Diagram.
Thank you for sharing the information it's great to see what people are doing out in the world. I notice you mentioned that APIs and API Management are in the picture but this was not included in the description. Were the APIs leveraged in your implementation, or this was for a separate use case?
API’s were not leveraged in the implementation. However API Management is part of the architecture and is planned to expose enterprise data. We had done a POC to ensure partner data can be consumed by partner companies via the API Management.