Saturday, January 14, 2017

The BO security model: object names

In this blog series I will try to share insights I’ve gathered over the years on how to setup a effective security model: simple, structured, maintainable, flexible, expandable and easy to use.
In this third part of the blog series I will focus on the names of objects. As stated the goal is to create a security model that is simple and structured. The object names play a big part in this

User types

Let’s assume there are four types of users on your systems:
  • Endusers
  • Analysts
  • Reporters
  • Designers
Where each type is an extension of the previous one, so there is some kind of structure in these types.

Per type there will be a user group and a CAL.

      

When I assign these user groups to folders it looks like this:


Although they are sorted alphabetically I don’t like that very much, So I make a little change to the user type user groups, to make use of the alphabetic sort:


After this little name change it’s much easier on the eye. And it’s making the model a bit more structured.

Organisation user groups

Lets add a department to the system, Sales. I create folders which represent the structure of the sales department and corresponding user groups. Theses folders and user groups are used to define access. Both have the same structure but the don't have the same names.


Doing this makes them appear neatly ordered when they are assigned to the folders:









Total user security on folder Sales \ EMAE \ NL now looks like this:




Tuesday, December 27, 2016

The BO security model: high level breakdown


In this blog series I will share insights I’ve gathered over the years on how to setup an effective security model: simple, structured, maintainable, flexible, expandable and easy to use. In the previous blog I concluded that a security model consists of CALs, user groups and folders.
In this second blog I will focus on the structure of the user groups from a high level.

·         This blog series is aimed at experienced BO administrators, which means there will be no how-to screenshots
·         This blog series can be used as a guideline, it cannot be used as a manual
·         This blog series only covers the internal BO stuff. No windows AD or SAP roles and no IAM software

I will divide the user groups into two parts:

  • The assignment part
    Underlying groups are only used to assign imported windows AD or SAP roles to.
  • The configuration part
    Underlying groups are used to config the system.

Configuration user groups

The configuration part holds all user groups used to configure access throughout the system. It is divided (for now) into these two:



  • The organisational part: who can see what
    This part consists of user groups which are modelled according to the organisational structure. Which folders a principal can see is determined here,
    it’s about access.


  • The user types part: who can do what
    This part covers the different user types. What a user
    type can do with the content is determined here,
    it’s about functionality.

Assignment user groups

The assignment part is not divided (for now). This part holds all the user groups that are used to assign business users to. You should create a group for every combination of the organisation and the user types that will be used:


The assignment groups all are members of the configuration groups. The group "HR - Attrition - Endusers" is a member of "HR - Attrition", which defines the folders and reports that can be used. And it is a member of "1 - Endusers"which defines what can be done with the reports.




The model now looks like this:






Saturday, December 17, 2016

The BO security model: an introduction

Over the years I have seen a lot of BO security models. Probably most of them were quite nice when they were implemented. They always start out as simple and structured models and everybody is determined to keep it that way. I am sure that if there were no business users on the system it would stay that way, simple and structured. But in real life a security model evolves, new business departments join and have different needs: we don’t want everybody to be able to schedule reports. More mature BO users may come up with extra needs: we want some users to only see their own instances and others to see all instances. The system grows: we only want to see a list of our colleague’s when we sent a report not the whole world. And new functionality to BO is added, like the commentary in BO 4.2.

After some time the simple and structured model begins to turn into a big ball of mud: haphazardly structured, sprawling, sloppy, duct-tape and bailing wire: 

  • complete custom access levels (CAL) are copied and then one little thingy is changed
  • user groups are created with weird names and very specific functions
  • users are directly assigned to folders and given advanced rights 

In this blog series I would like to share some insight I gathered over the years. These can serve as guidelines the next time you have to work on a model. 

·         This blog series is aimed at experienced BO administrators, which means there will be no how-to screenshots
·         This blog series can be used as a guideline, it cannot be used as a manual
·         This blog series only covers the internal BO stuff. No windows AD or SAP roles and no IAM software

When I’m implementing a new security model I want it to be effective. Where effective stands for: simple and structured. But also maintainable, flexible, expandable and easy to use.
Simple, structured, maintainable, flexible, expandable and easy to use. That’s a lot! Well actually they are interrelated, if you give it structure and keep it simple it will be easy to use and maintain. And if you’re lucky it turns out to be flexible and expandable as well. 

Tip
I never re-use any of the existing CALs because I don’t want to mess with the existing model. When you create new CALs you can run both models on the same system for comparison and testing. And reverting to the original model in case of issues is easy, just delete all the new CALs.

Tip
I prefer to create the new model on a sandbox machine and when it’s finished and tested, promote it to a live system. Start with development, then test, UAT and production. When issues are found resolve them, go back to the sandbox, make the same adjustments to your model and start promoting again.

Tip
If a model is a mess, don’t recreate the mess in a structured way. If a model is a mess manage expectations and preach that the new model will not be exactly like the old one.

A BO security model consists of: 
  • access rights (view, edit, delete etc.) 
  • users 
  • objects (reports, universes, connections etc.) 
  • assignments: the relations between them 
There are hundreds of access rights, they will be grouped in custom access levels (CALs).
There can be hundreds of objects, they will be grouped in folders.
There can be hundreds of users, they will be grouped in user groups

In the assignments I will only use these grouped items: folders, user groups and CALs.

It is a humongous mistake maybe even a mortal sin to assign directly on an object ! Even if it is only once !

Exception: Calendars don’t have a folder structure, if you want Calendars to not be visible to everybody you should grant access on object level.

In the next blog I will talk about the structure of the model from a very high level.

Tuesday, March 10, 2015

Adjust Layout

I discovered another nice feature in the WebI charting engine. I don’t know how to name it yet. It’s stuffed away behind the Adjust Layout checkbox. Which is available for the Title, Legend and both Axis areas.
When the Adjust Layout checkbox is checked two new settings appear: Layout Width and Layout Height.



I think I start with an example right away. Take a look at this beautiful chart.


Now when I change the Layout Height Proportionality of the category axis to Fixed; 4 centimetres, the chart looks like this:




The category axis now is 4 centimetres in height. When I change it to 7 centimetres, the chart looks like this:



When I change the Layout Height Proportionality to proportional; 0,5, the chart looks like this:
  


The category axis height is now 50 % of the total chart height. Which becomes very clear when I change the chart a little bit. 


I think this is a great feature, even if it has no real name. You can use it to create more consistent charts, for example in sections.


Normal chart

Chart with fixed with

Saturday, February 7, 2015

Lean WebI customization

In 4.1 there is this new feature to customise the Web Intelligence interface. It's a nice feature, but can it be useful? Yes it can, well at least I think so.

When this feature is combined with opendocument there is a huge visual impact. And this can be very useful, especially when the opendocument link comes from outside of BO, for example a sharepoint portal. Changes are that the business user clicking this report link doesn't know anything about BO Web Intelligence.

The 'standard' opendocument view is something like this


But realizing that the business user knows nothing about Web Intelligence, there is a lot of visual noise and cluttering on this screen. Lets make some customization and remove all the Web Intelligence stuff to make it lean.

I created an extra usergroup in BO and assigned the business user to this group. For this usergroup I set the customization:

Now the 'lean' opendocument view is presented:

This is much better!

Monday, April 14, 2014

WebI options

Spine line

before

after



Rounded corners

before                                                                 after
      


Unit scale factor

Please vote for my idea to add a formula to the unit scale factor: Set "Unit Scale Factor" (on value axis) using formula editor.

 before                                                                    after
 


Fixed value axis scaling




Axis label delete factor






Wednesday, April 9, 2014

Starting with BI Workspaces

Workspaces are a unknown part of the BusinessObjects environment and maybe also an underestimated part, Workspaces are created in the BI Launchpad. They can be used as landing page or they can be opened from the launchpad manually.
What I am going to show here is how to build a very simple workspace with templates.
Open the workspace editor using the Application menu in the BI Launchpad.


Click the layout dropdown box and change to Freeform.


On an empty workspace drag in a navigation list component.


Edit it using the wrench symbol in the top right corner and select 2 webi report. Or drag and drop 2 webi reports on the navigation list.


There it is, it’s done. Your first workspace. Now you can save it and execute it from the BI Launchpad. You do not have to save it, exiting edit mode gives you a change to test the new workspace.

When you click 1 of the reports on the navigation list, by default, the report runs it the total workspace window. Click the square symbol on the left side to return to the navigation list.




And when the other report is clicked:



If you want to run the webi report in a part of the workspace window, you need to drag in a viewer component.  No configuration is needed, the are connected automatically.




Click one of the reports:


And click the other report:


If there are multiple navigation lists and multiple viewers on the workspace some configuration is needed.




I named the viewers top and bottom (using the edit / wrench of the viewers).




Then I connected each navigation list to a specific viewer. (using the edit / wrench of the navigation lists).