Skip to Content

How SAP runs HANA Analytics in Business Objects Explorer for several thousand users

Through the SAP Runs SAP program, Global IT has become SAP’s first and best customer by deploying innovations at an early stage, often before ramp up. The objective is to share our experiences with SAP’s customers and also to provide feedback to the development and product teams. In this post I would like to walk you through our experiences and the resulting concept to provide HANA analytics to several thousand users. Our journey was and is supported by several colleagues inside and outside Global IT who deserve credit. Please also note that my post explains how we in Global IT deployed the solution in our specific system environment with our internal end users requirements. It does not necessarily represent SAP’s official recommendations.

In 2011, SAP Global IT started with creating analytics scenarios using a side-by- side SAP HANA instance. With “side-by-side” I refer to the non-disruptive architecture where we extract data from a Business Suite system and build analytical data models for end user consumption in Business Objects. For data replication we use SLT which is trigger-based and ensures that each update in the source system is replicated immediately to SAP HANA. 


One of our very popular scenarios is the ‘Salespipeline on HANA’ project where we provide sales executives real-time analytics on opportunity data. We have chosen Business Objects Explorer as the front end as it provides desktop and mobile access, allows flexible data exploration, and shines with attractive visualization. Initially, our target user group was SAP’s top executives. The mobile presentation and the timeliness of the data contributed to the successful adoption. Executives could identify Opportunities at risk with this information now at their fingertips, and could make immediate calls to customers and the next management levels. The result: The next management levels wanted it too!


In order to roll out the solution to the next management levels, we were required to come up with a better authorization concept that also restricts access to the area of responsibility for each manager. In SAP HANA, you can restrict access to a view on data level with Analytical Privileges.  When designing an Analytical Privilege, you can choose any attribute of a view, and define filter values the user should be allowed to access. We could have, for example, created an Analytical Privilege for each Sales Organization and assigned the respective Analytical Privilege based on the data each user should be allowed to see. Instead, we decided that a user should have the same level of access to opportunities in HANA Analytics as in the data source SAP CRM. We developed an ABAP report that generates a table with user ID and Sales Organization as keys based on the user roles and profiles in SAP CRM. This table can be replicated in real-time using SLT into from SAP CRM to SAP HANA. In our data model we created an inner join between the authorization data and our data foundation.  In the Analytical Privilege we restrict on user ID instead of Sales Organization and hence only had to create and assign one single Analytical Privilege per user. We have two advantages to this design:

  1. It’s consistent and easily understood by end users because the access in HANA matches the access they already have in SAP CRM.
  2. It also simplifies the provisioning because we only need one Analytical Privilege for each end user, which is easily determined.

In the beginning we used an anonymous communications user between HANA and Business Objects Enterprise with the advantage that only one user was required in HANA. For the Analytical Privileges to take effect, HANA needs to ‘know’ which user accesses the Infospace in Business Objects. To refer to the actual end user in HANA, the HANA user credentials need to be maintained in the user settings in Business Objects Enterprise. The solution was a small Java program using the HANA SDK which we called ‘HANA Business Objects Authorizations’ tool – in short HBA tool (As you know, we love 3-letter acronyms at SAP!). It is placed on the Business Objects Enterprise server and executes the following steps:

  • Select all users that are assigned to an authorization group in Business Objects Enterprise,
  • Create these users in HANA,
  • Maintain the HANA credentials in Business Objects Enterprise for each user, and
  • Create and assigns an Analytical Privilege for this user according to a template.

As a result, we can provision HANA analytics to thousands of users without manual user maintenance effort. A new feature in SPS05 allows generating one Analytical Privilege for all users which determines the system user at runtime.  This limits the runtime for model activations and further simplifies the concept.

The project team is also working with the SAP Identity Management development team to add the connector functionality so that SAP IDM customers will be able to utilize the HBA functionality use case through IDM.

You must be Logged on to comment or reply to a post.
  • Hi Dirk,

    Nice blog! Would it be possible for you to share 'HBA' tool? I'm working on a similar use case where Design Studio is used instead Explorer on top of SAP HANA.

    With kind regards,

    Martijn van Foeken | Intenzz

  • Hi Dirk,

    It would be great to see the design you've outlined above released as a 'cookbook' on SCN.

    The managers I've spoken to about this solution have been very positive in their feedback. Well done!