Skip to Content
Author's profile photo Christina Obry

Best Practices for BI 4.x Shared Service Deployments

In this blog post I will describe some best practices with regards to Data Storage and Schema, Security, Managment, Operations and Customization for shared services deployments. A shared service deployment is characteristic by multiple business units accessing the same BI platform, sharing the software as well as physical hardware, yet being isolated from each other. The principals of share service deployments are the same as for multitenancy deployments; in this blog I use the terms interchangeably.

best practices.png

Data Storage and Schema

The BI Platform enables different deployment models, which can be exemplified in three common models. Of course mixed models or variations are possible, but to simplify I focus on these 3.

  1. Separate database with distinct semantic layer
    • In this deployment model, each business unit’s data is stored in a separate database, and the schemas of the business unit may have variations that call for different universes among business units. Often the database schemas and the universes are customizations or extensions of a generic model.
    • Things to consider when using a model involving multiple databases with a distinct semantic layer:
      • This model has strong data isolation, as in the model involving multiple databases with a shared semantic layer.
      • The data security model is simplest among the three models.
      • This model offers more flexibility in database and universe design.
      • The operation and maintenance cost is the highest among the three models.
      • This model has the least sharing of resources and is typically the most costly.
      • It is challenging to support aggregated metrics for peer comparisons.
        Shared DB.png
  2. Separate database with shared semantic layer
    • In this deployment model, each business unit’s data is stored in a separate database and, because the schema of each business unit’s database is virtually the same, a single universe can be shared among the business units
      • Things to consider when using a model involving multiple databases with a shared semantic layer:
        • This model has stronger data isolation than the shared-database model and may sometimes be required for regulatory reasons.
        • The database design and security model may be simpler than the shared-database model.
        • Operation and maintenance of BI content in the SAP BusinessObjects BI platform is still simple, similar to that of the shared-database model.
        • This model shares fewer resources than the shared-database model and is typically more costly.
        • With this model, it is more difficult to support aggregated metrics for peer comparisons
          seperate db.png
  3. Shared database and semantic layer
    • In this deployment model, data for all business units is stored in a single database. Semantic layers built on top of the database are shared among the business unit
    • Things to consider when using the shared-database model:
      • This model maximizes sharing of resources and typically has the best economy of scale.
      • Operation and maintenance of BI content in the SAP BusinessObjects BI platform is simpler.
      • Database security can be more complicated than other models.
      • Variation of data structure among tenants is limited.
      • With this model, it is easy to support aggregated metrics for peer comparison.

When you are considering data security and data access is the most important consideration in the design of a shares service deployment. The technique to achieve user-level data filtering is also influenced by the deployment model.

For the shared database and semantic layer deployment models, one can use the following 2 options:

  • Universe restriction for row access:
    In this approach, data filtering is achieved by using universe row-access restriction.  The list of users or user groups and their corresponding row access restriction are defined inside the universe.
    unv restiction.png
  • Useridentity pass-through for database server side filtering
    In the SAP BusinessObjects BI platform, database-level security can be achieved by using the enable database credentials feature of the user management function in the SAP BusinessObjects BI platform (aka DBUSER and DBPASS variables). This feature associates a database user name–password pair with each user account in the platform. When the universe connection is set to use the authentication mode Use BusinessObjects credential mapping, it will take the DBUSER and DBPASS values from the user information and pass them to the database at runtime

For the separate database with shared semantic layer, one can use the following 2 options:

  • Table switching by universe restriction
    Here you put data for different business units into different tables. Inside the universe, access restriction of type “alternative table” can be applied to users or user groups, ensuring that the business unit’s specific table issued at runtime in place of a generic table. While this approach has stronger data isolation than the row-access restriction technique, it requires more maintenance overhead on both the database side and the universe side.
  • Connection switching by universe restriction:
    In this approach, you create one universe connection object for each business unit. Within the universe, apply an access restriction of type Connection to the user group for the business unit and select the corresponding connection object for the access restriction. 
    connection switch.png

Alternatively you can create a dynamic query via Universe variable on custom attribute. This feature was added in the BI 4.0 SP4 release. It provides the capability to define some attributes in the CMC that will be attached to each individual user. These attributes are then exposed in the Semantic Layer and can be used to filter business unit’s specific data. A more detailed overview can be found in the User Attribute Mapping in BI4 – in depth blog.


Next I’ll go into best practices regarding managing security for multiple tenants.

It is advisable that business units each have their own user groups in the SAP BI platform. This will help simplify the authorization management in the shared SAP BI platform and will make applying it to the semantic layer more effective and easier to manage. For BI content management, the same advice applies: each business unit should have its own public folder for storing its BI documents.

Create Authorization controlled by Access Control List (ACL) for your business units. The access control setting specifies who can carry out operation on specific content. While powerful access control technology in the SAP BI platform allows many variations and complexity, the security setting can be simplified and easily managed if user group and folder structures are adopted.


When it comes to managing different business units, you may want to consider having a standard structure for each business unit in order to lower administration cost. If business units in a shares service deployment have structural similarity, such as same folder structure, same user group structure, similar reports and so on, then you can save administrating cost when onboarding a new business unit. For this you can take advantage of the Tenant Provisioning Tool to automate on-boarding process. This feature was introduced in BI 4.0 SP4. The tool focuses on business units onboarding and BI
contents management. Its goal is to reduce manual work by enable automation without lot of low level programming allowing, hence saving time and making the onboarding process less prone to human mistake. More information can be found in Overview of SAP BI 4.x Multitenancy Management Tool

An additional feature in the BI4.1 release is that business units which were onboarded via the onboarding command line tool are now visible in a new Multitenancy tab in the CMC. In this tab you the ability to change business unit’s properties such as name, concurrent user limit and associated user
groups. The concurrent user limit ensures service availability by limiting the number of concurrent users that a business unit can logon at a given time. Once
the business unit’s limit has been reached no further users of this business unit will be able to log on until another business unit’s user has logged out.

Once business units were onboarded using the above Onboarding tool, you can use the tenant auditing feature, which was introduced in BI 4.1. It allows to measure the usage of the system by the users of each business unit (for example, for billing purposes). For this feature enable and configure auditing events that you are interested it. Then in order to determine which auditing event is generated by which business unit/tenant use 2 new lookup tables in the auditing database: ADS_TENANT and ADS_USER


Administration effort of a shared service environment may be very large and may exceed the resources of a single administrator. A system administrator who wants to focus only on high-priority tasks can create delegated administrators and assign a subsets of management tasks to them (for example, the administration of a department or tenant content in case of BI platform as part of a SaaS application). Delegated administrators perform a limited set of tasks and have fewer rights on objects in the system. To improve user experience and workflow, a system administrator may hide any of the CMC tabs that a delegated administrator (or a principal) is not expected to use. Additional information can be found at Delegated administration in SAP BI 4.0 SP4


The hot backup feature, which was introduced in BI 4.0 SP4, allows you to back up your Business Intelligence platform system while continuing to allow users to use the system normally, this is important in a shared service deployment as service availability is crucial.

Using LCM you can archive and restore a subset of the BOE content, which can be used to archive a particular business unit’s data.

Additionally you can use system monitoring to ensure system health and to take proactive action. You can create custom defined condition and alerting for each business unit or create custom probe to check specific BI content or operation.



With different business units accessing the system there is often a need to customize the BI platform per business unit. Starting with 4.0 you can customize the landing page of BI launch pad by creating a custom BI workspace, an administrator can customize the homepage for a particular business unit’s user group or can also set the landing page to a particular business unit’s folder. For more information on this please see Tutorial: How to customize BI launch pad home page

Assigned Tags

      Comments are closed.
      Author's profile photo Former Member
      Former Member

      Very Clear !!! Keep Sharing..

      Author's profile photo Former Member
      Former Member


      This nice post.  we have similar kind of setup in BO3.1 (now migrating to 4.1) which is connection switching mechanism. however we are facing below issues.


      1. We have different DB schema which is connected in single universe which has more than 700 tables (ERP Backend - Oracle)

      2. We used group - connection restriction option from the universe to restrict the particular connection to particular group.

      3. Now we have the issue is like some business unit users want to access more than one DB, means they wants to belong more than one group.

      4. We have used SDK and customized the login page, and for each user we have created enterprise account with segment code, for example gkkkk is ad account, gkkkk_10, gkkkk_30, gkkkk_70 etc are the enterprise accounts

      5. while login a drop down list will come for their corresponding permission, for above example drop down will show 10, 30, 70.

      6. If they select 70 then internally it will use gkkkk_70 account credentials and will point to the corresponding unv connection.

      7. This is working perfectly.

      8. Problem is some users have access to more then 200 segments so for that particular account alone it will create 200+ enterprise accounts.

      9. in this case already we reached more than 60K users in the environment.

      10. Now we are searching some other good option to come out the current approach.

      Any suggestions?

      Author's profile photo Christina Obry
      Christina Obry
      Blog Post Author


      I have moved to new responsibilities within SAP a year ago. I am blocking new comments to this thread, please post questions to the BI Platform forum to allow the community to help further.