Lessons learned in implementing SAC with SAP HANA Cloud data source

[leojmfrancia]

"Every path is the right path. Everything could've been anything else. And it would have just as much meaning." - Mr. Nobody

The great thing about a growth mindset is that it encourages us to learn from our mistakes and be better. While deep analysis of approaches is important, recalibrating when facing issues is equally so.

I am a technical consultant working on NetWeaver, Data, Analytics, and AI/ML topics. I have recently implemented SAP Analytics Cloud (SAC) with SAP HANA Cloud as a data source and would like to share some of the watch-outs and lessons learned. Some of these may not be not new to the majority of the community but I thought it may be worth highlighting them in one post.

This blog entry might be useful to you if:

• You are starting or are in the middle of a new SAC implementation


• You are having second thoughts about architectural decisions


• Or you just want to see how others are approaching their implementations

This blog does not contain how-tos. Now, onto the lessons learned.

1. Standardize SAC story documentation

While this may sound basic, it helps a lot when you start having multiple stories and metrics to create. A sample template can be seen below where the metrics, system, object, measure, aggregation, custom calculations, filters, etc. can be found. This can be useful when different business units or departments have different interpretations of how a metric is calculated during the early stages of the implementation and you need to get consensus! This can also be useful when you need to rebuild the report (see section 5).

Doing this exercise consistently early in the project allowed us to identify whether a Data Warehouse solution (such as SAP Data Warehouse Cloud) was required or if in-built transformations in SAC are sufficient for us. In our case, the in-built SAC transformations were sufficient.

Standardizing documentation of reports can help with reviewing and rebuilding

2. Identify the data extraction approach

Like many aspects of implementations, finding the correct data extraction approach has the well-trodden answer of "it depends." The three main factors to consider among others are functional, data privacy, and volume as described in detail here.

In our case, since only periodic reporting is required and there are no data privacy constraints (both SAC and SAP HANA Cloud components are in SAP SaaS solutions), we opted for OData approach. The SAP HANA Cloud T-Shirt size procured in our implementation was not aimed to handle live connections as well.

3. Project tables fully as read-only (first)

In the early stages of a reporting project, one can expect iterative discussions on fields and metrics to be implemented. It was useful to project the tables completely (albeit read-only) to be consumed by SAC. This reduced the iterations in both SAC and SAP HANA Cloud levels. The unnecessary fields can be excluded from the projection at a later stage to keep data in your stories tailored. Be mindful when removing fields/columns - see section 5.

Tables projected completely as read-only

4. Build transformations in SAC or Data Warehouse level

Keeping transformations in SAC or Data Warehouse level keeps the core clean. Yes - that is a common phrase mentioned these days and it is great that plenty of work has been done to expound on the topic, such as this great blog from sudip.ghosh4. The context in this blog is slightly different, we are getting data from SAP HANA Cloud, but the same principle applies - keep the database clean and perform the transformations outside it for your reports/stories.

5. Take caution when removing fields in CDS projections or SAC Data Models

When removing columns/fields in CDS projections or SAC data models, you will likely end up rebuilding the SAC stories that have dependencies on said projections or data models. This can be challenging especially if you have complex reports and custom calculations in your SAC story; hence, it is recommended to document your stories and calculations well (see section 1).

You may end up rebuilding your stories if you remove fields in your data model - document your stories well!

6. Understand the budget for building the SAC landscape

The lifecycle management best practice document states that you need at least two SAP Analytics Cloud tenants in your landscape. Discuss this early with your stakeholders in case there will be budget concerns, e.g. you may end up having budget restrictions to have only one tenant!

Wrapping up

It is rare to see two scenarios be exactly the same and some pointers here may be contradictory to your experience. It becomes important to understand the business requirement, constraints, and expected volume so you can design your reporting solution. I would appreciate it if you can share your experiences in the comments.

To stay up to date with more tips, techniques, and product information, you can follow the SAP Analytics Cloud topic page.

Do follow my profile, leojmfrancia, for upcoming posts on Data Science, AI, and ML.

 

Invariably stochastically yours,

Leo