GRC
HR
SCM
CRM
BI


Blog

 

A is for “Access Levels” (Part 1)

by Jay Riddle

May 13, 2010

Once you’ve successfully integrated SAP BusinessObjects Enterprise with your SAP environment, you may be leveraging the Business Intelligence Portal (InfoView) provided with SAP BusinessObjects Enterprise as a method for users to navigate and access BI content directly or through integration with SAP NetWeaver Portal, or you may have decided to avoid the portal as a method of delivery and chose to leverage the scheduling and bursting capabilities to strictly push content.  Regardless, at some stage, content is being placed within the SAP BusinessObjects Enterprise repository. 

Quite often clients become so focused on how they can leverage their existing SAP data-level security that content begins to be developed and published to SAP BusinessObjects Enterprise and managed in ways that don’t effectively leverage the available object level security options.  Unless I'm on an extended engagement where I have the task of assisting with long term strategy, often my time at a client site is constricted to getting the architecture integrated and working.  Although I try to provide as much knowledge transfer on recommended administration practices as possible, I’m often out the door as soon as the technology is adjudged to be working in the appropriate fashion and the client is comfortable with the high-level knowledge transfer provided.  Moving forward the importance of folder and application security frequently takes a back seat to getting the BI content  delivered to the business as soon as IT deems themselves capable of supporting the SAP BusinessObjects infrastructure and tools.

Understanding how to e ffectively leverage the fountain of available Access Control Entries (ACE) or “Rights” within SAP BusinessObjects Enterprise in order to develop a robust content management plan can help you avoid unnecessary headaches down the road.  

You might be saying “Who cares if the user gets to a report so long as when the user refreshes the report  our existing SAP data-level security is leveraged and the report will return blank or with an error.  The data remains secure!”

Sure, and “View On Demand” is even an Access Level that permits that SAP data-level security to be harnessed.  But do your users know what that behavior indicates?  Unless you’ve documented and included this as part of your end-user education plan, the first time a user reaches out to your support desk because their a report they refreshed returned an error, how many hours would you wager they spend troubleshooting what is initially assumed to be a bug, or escalating to your SAP support team to only discover this is expected behavior?

One-off situations are often unavoidable, but I’m here to remind everyone that Acc ess Levels are your friend.  As the amount of content and complexity of folder & user group hierarchies continues to grow, instead of spending time trying to forecast possible sticky situations like the example above and how to combat them, access levels in part with the rest of your security design can help you avoid future issues all together.  I’m even thinking of kicking off a global campaign accompanied by t-shirts and bumper stickers. 

In my next post I’ll go through some recommended practices, discuss Custom Access Levels, and provide a demonstration of a scenario in which you can leverage them to secure the SAP system folder used to house content published as a part of the BW Publisher process.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ