Wednesday, October 11, 2017

Concatenating multiple rows in webi is not an easy tasks to do. But concatenation multiple rows in Oracle is easy. Creating an object in the universe with the LISTAGG analytical funtion will do the trick.

Saturday, January 14, 2017

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 this third part of the 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.

·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

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:

Tuesday, December 27, 2016

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 partUnderlying groups are only used to assign imported windows AD or SAP roles to.

The configuration partUnderlying 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 whatThis 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 whatThis 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.

Saturday, December 17, 2016

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.

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.

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.

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.