Learnings from “SAP HANA Live Analytics for ERP” and “SAP HANA OA” deployment
In this blog, I have discussed my learnings and experience which I gained while deploying SAP HANA Live reports for ERP (HANA Live) and SAP HANA Operational Analytics (OA). My learnings are purely technical and therefore it may not be relevant to Business people. Also, this deployment was executed to demonstrate standard content to Business so that they can perform gap analysis based on their requirements. I have tried to break down my learnings into highlights.
What? Do I have an approach?
During this project, my goal was to get my head around both RDS’s and come up with best configuration approach. Well, I am good (yes, I said “good”) when it comes to detail level but I have little experience with building approach. So, my team mate and content lead Craig Cauchi, who is very experienced BI personality and owner of Forefront Analytics played his part by creating an approach.
With this approach, we decided to deploy each solution one after another i.e.. First, deploy and run HANA Live RDS and then follow same steps/plan for deploying HANA OA RDS. For each solution, there were back-end and front-end components. So, we followed following method:
Data source – deploy and activate tables, HANA data models and universes irrespective of function (i.e. FI, CO etc)
Reports – pickup one function (i.e. FI for start) and then deploy and configure report for that function. Test the reports. Fix any issue and test again. Repeat this process for each function.
With above approach it was easy to tick the completion status and troubleshoot any emerging issue. Also, as we implemented each function module we were able to present the standard reports to respective users. Please note for configuration I used available RDS documentation.
Which did I like most?
Obviously, the content. However, I found the HANA data models were more helpful. There were 1025 HANA data models with HANA live RDS covering most of the business scenarios. As a developer I found it really useful as I can use reuse views or copy query views and enhance them. If needed, I can fulfill new requirements in short time period.
What did I hate most?
Rapid deployment means out-of-the-box based on best practices. However, it wasn’t the case for HANA OA RDS. This RDS was last changed in 2013 (as per SMP) and since then there had been changes to BI and HANA platform. These RDSs needed to be tested against new releases of platform. We have BI 4.1 SP5 platform. We ended up in situation where we were not able to import BI content for OA RDS. For troubleshooting we created BI 4.1 SP1 instance in cloud (long story so dont ask me) and then imported the package. Later, we export each report type to lcmbiar file and import this file to our platform to find which component is failing. After three days of effort (including setup in cloud) we found that crystal reports are failing to import. Just for note there was no restrictions/limitations mentioned in RDS requirements. In OA RDS, some universe has derived tables (even though it is not needed) and others doesn’t (they simply use column view/table). In some universes there are no field names in semantic format and it is using column names. SAP best practices for HANA says that we should not use select * statement but some universes based on HANA Live uses select * in derived table statement. It was time consuming job and reflected bad development practice.
What will I suggest?
Update of these RDSs overwrite all the changes that we make in existing package. This is mainly for HANA platform side. On BI platform side, we can copy the content and then edit it. Now, there should be an update mechanism for HANA where it keep our changes or at least warn us about loosing changes during update. Documentation suggest to copy them to customer folder/package and then change it. Well, that’s another way but with previous experience I can say it takes more than a week to perform such task for just one package. In our case, I had to find and copy all the dependent objects and then update the references in each model. Later, I had to update BI objects as well. So It was time consuming job. Therefore, what’s the benefit of out-of-box solution.
I also noticed that there is update to HANA RDS models but BOBJ layer is untouched. Universes are still mapped to old field and suddenly it becomes the customer responsibility to fix/update it. So, each type of content should be updated accordingly. There should be proper testing of each layer whenever there is change or update. Specifically, BI RDS should be tested for new releases of BI platform. The BI content should be aligned with SAP BI Client tool strategy. For example if dashboard designer is going to be deprecated then all dashboards should be replaced with SAP Design Studio applications.
Performance is another thing that need to be considered. There should be benchmark and recommended technical requirements or filter for each HANA models, universes and reports. Some HANA Live data models could not be executed as they consumed lot of memory and eventually crashed. We could not figure out how much memory need to be allocated or what changes could make it better. We shouldn’t be spending time on performance analysis if it is out-of-box solution.
My overall experience with these RDSs have been really good. It was a journey full of learnings and RDS’s defined scope really helped to achieve the Business need. However, there were surprises that I had to handle with development perspective. I agree (to some extent) that these solutions are based on Business’s best practices but technically it is missing best practice.
“Opinions expressed are solely my own and do not express the views or opinions of my employer.”