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.
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.
- 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.
- 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
- Things to consider when using a model involving multiple databases with a 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
- 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.
- 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.
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.
Security
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.
Managment
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
Operations
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.
Customization
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
- SAP Managed Tags:
3 Comments
