Secret recipes in SAP Business Objects

Data & Analytics

October 28, 2014

Security is very important in the day-to-day life. Industries like Banking, capital market, etc., can’t be live without Security. Business requirement to secure all the critical data based on the user’s role in the Organization. In the traditional way, the Security implementation rules and userid’s were maintained in a security table and applied in the various reporting tools. The latest version of SAP Business objects was come up the new approach and it leverages the easy implementation of the security at the various levels like column, row and level. In this blog, we would be reading about difference in traditional way and new approach of Business Objects.

Traditional way:

The Row-level Security is the force restrictions into WHERE Clause of the inferred SQL. The Traditional way of implementing Row level security by creating a Security table having all user id‘s and their appropriate access as columns, now join this security table with fact table based on a common dimension or a common key between both the tables and this should be a mandatory join. A filter will be created with value @variable(“BOUSER”) and this filter should be applied on the universe (check the use filter as mandatory in query option) meaning when using any of the objects from this universe, this filter will be applied automatically. Since we are using this filter in the report and since there is a direct join between security table and fact table, user gets to see only his or her data.

New Approach:

Same filter condition will be applied into WHERE clause of the inferred SQL but there is no security table for maintaining user ids and their Security rules. The User ids and access levels will be stored in the separate data profile in the same universe itself. The Filter condition will be applied automatically based on the data profile which created for users or user groups

What is the difference between traditional way and new approach?

S.No.		Traditional Way	New Approach
1.	Implementation	Security table is to be created with user ids and its access levels. It is quite difficult to implement.	No Security table involved. Data Profiles are created for various access levels. It is easy to implement.
2.	Maintenance	Difficult to add new users in the Security table.	Easy to add new users or group in the data profile.
3.	Migration	We can apply the same logic when the reports are migrated from Business objects to Other Reporting tools and vice versa.	New implementation of the security models
4.	Upgrade	As Part of user and groups migrated, It is easy to upgrade from one version to another version	Upgrade is very simple
5.	Promotion	Security model is promoted as part of universe. But we need to Promote Security tables from one environment to another environment.	Universe Promotion is much enough
6.	Client tools used for this	Universe Design Tool or Information Design Tool	Information Design Tool
7.	Universe Format	Support both .unx and .unv format	Support only .unx universe
8.	Save and Publish	Need to Save and Publish the universe to the Repository, Whenever changes are on the Security Model	Changes are made on the Repository.