KPI Partners Blog

OBIEE Groups, Webgroups, and Delivers

Posted by KPI Partners News Team on Mon, Oct 31, 2011 @ 11:30 AM

by Kurt Wolff

I thought it would be worth exploring the interrelated topics of repository groups, web groups, system session variables,  Delivers, the SA System subject area, and My Account. 

First comment: I am not sure that anyone knows any more, if they ever did, how all these things are actually supposed to interrelate. The best we can do is try things, see what happens, and learn from experiment and experience.

To that end, I created the table Users1 with information about  four users, including their BI server (RPD) group and presentation server (Web) group memberships. My practice is to not use the same names for BI server groups and presentation server groups.  (Things get confusing rapidly if you do that, in my opinion). This is the content of the table:

Groups   Picture1





User authentication occurs via an initialization block called “Authenticate”. The SQL of the Authenticate init block is:

, Displayname
, RPDGroup
, Webgroup
upper(Logon) = upper(':USER')

The session variables populated by this init block are

Groups   Picture2




There are a couple of basic things to know here.  :USER is the user ID entered by the user in the logon screen (or passed to the BI Server by some external authentication system, such as Oracle SSO). :PASSWORD is the password entered by the user. Both of these have to be typed in upper case in the SQL.  Note: Enclosing the constraint on password with NQS_PASSWORD_CLAUSE as shown in the SQL above is required with Delivers. If your system uses SSO to authenticate users, then remove the password constraint from the init block completely.

The session variables to be populated by the init block have to be in the same order as the columns in the SQL. Variable population depends on the order only, not in matching the names of the columns to the names of the variables. NOTE : because order of the variables is the only thing that matters, beware that sometimes, spontaneously it seems, the order of variables can change. If this occurs, break up your init block into multiple init blocks until the order of variables remains stable.

The variables names used here are special system session variables. Note: The variable “GROUP”  is singular, but you can assign a user to multiple groups in the init block. “WEBGROUPS” is plural. If you enter “WEBGROUP” (singular) the init block will not assign users to web groups.

In the Users1 table, users are being assigned to multiple groups and web groups with group and webgroup names separated by semi-colons. (Another way to do this would be to populate GROUP or WEBGROUPS variables using  row-wise initialization. As far as I can tell, both methods work the same in all respects.)

To illustrate how this works, let’s use an example RPD having five presentation catalogs.

Groups   Picture3





BI Server group “GroupA” has access to Retail Data A. GroupB has access to Retail Data B, etc.  The table User1 puts A in GroupA and GroupB. Here’s what A sees in Answers.

Groups   Picture4






If A goes to My Account in the web UI, it shows that A is a member of the web group  WebA.

Groups   Picture5




User B logs in and also sees Retail Data A and Retail Data B, since B is also a member of GroupA and GroupB. My Account shows B belongs to web groups WebA and WebB.

Groups   Picture6




User C logs in, sees three subject areas, and is a member of three web groups.

Groups   Picture7Groups   Picture8






At this point in time, users A, B, and C have logged in but user D has not. Now the administrator user logs in and examines the list of users and groups in the Administration UI in the web. Here’s what the administrator sees: users A, B, and C are listed as users.

Groups   Picture9








If Administrator looks at who is a member of WebA, however, no one is listed.

Groups   Picture10







The user’s name persists once the user logs in,  but the web group membership appears not to.

In Delivers, you can name a web group as a recipient of an alert. What happens when the alert is addressed to members of WebA at this point? Since WebA has no members, there are no recipients. Users A, B, and C will not receive the alert. If  the administrator tries to add A, B, and C to WebA, he will see this.

Groups   Picture11








In this context, the web catalog appears to remember that A, B, and C have been assigned to WebA, and it is not possible for the Administrator to add them.  Now suppose User D logs in.  He now becomes a listed Catalog User and a member of WebD, as shown on his My Account page.

describe the image




Now if Administrator logs in and attempts to add users to WebA, this is what he sees.

Groups   Picture13








D, who has not been a member of WebA, can be added, but not A, B, or C. Suppose the administrator adds D to WebA.

Groups   Picture14








When D logs in and goes to the My Account page, it shows his group membership includes WebA and WebD.

Groups   Picture15




Now suppose the Administrator creates an iBot using the subject area Retail Data A with Personalized data visibility and chooses the group WebA as a recipient.

Groups   Picture16




Groups   Picture17






When User D logs in he will not see the alert.

Groups   Picture18



The reason is that only members of the repository group GroupA have access to the subject area Retail Data A. When the Administrator modifies the data visibility setting of the alert so that it is Not Personalized and is run as the Administrator user, User D will receive the alert.

Groups   Picture19




Groups   New20


Groups   Picture20






User A is a member of GroupA, therefore has access to the subject area Retail Data A. When A logs in, he doesn’t see the alert notification, since A is not an explicit member of Web Group A – he is a member by virtue of the value of the WEBGROUPS session variable.

describe the image


However, when he clicks on More Products|Delivers|Show iBots Acting On My Behalf, the alert is listed. It’s listed as acting on his behalf but, apparently, he won’t receive the contents of the iBot!

Groups   Picture22




However, when he clicks on More Products|Delivers|Show iBots Acting On My Behalf, the alert is listed. It’s listed as acting on his behalf but, apparently, he won’t receive the contents of the iBot!

Groups   Picture23








Even if A is logged on at the time the iBot is running, he will not see the iBot alert.

What about the “SA System” subject area? The basic purpose of SA System is to set the delivery profiles of users, providing default delivery settings for users who have not entered settings in My Account. (SA System can also overwrite user settings in My Account if a parameter to do that is set in instanceconfig.xml).

In this example, SA System columns are mapped  to columns in the Users1 table or to string constants in the metadata for logical columns Email, Email Type, Email Priority, Cell Phone, and Cell Phone Priority.

describe the image




When UserC, who has not set up and devices or delivery profiles, views My Account settings, he sees a System Email device and a System Profile.

Groups   Picture25











These conform to the settings from SA System.

Groups   Picture26





Groups   Picture27







When A views My Account, he sees the settings from SA System, but they are not active, since A has defined his own settings.

Groups   Picture28









There is a way to get Delivers to deliver content to all members of WebA, however. Set up another request (it could use the SA System subject area, but it doesn’t have to) that will return the members of WebA. Then make this request the conditional request for the iBot.

Groups   Picture29







The following query was saved as “Deliver to WebA”.image

This query was specified as the conditional request in the iBot.

Groups   Picture30







The Recipients tab was set to determine recipients from the conditional request.

Groups   Picture31





The Delivery Content tab is where the query that generated content was specified.

Groups   Picture32





The iBot was fired off. When user A logged in, this time he saw the alert.

describe the image



However, the shortcoming here is that you cannot deliver personalized results. Suppose there are filters on Groups A, B, and C when querying Retail Data A. GroupA sees only Product A, GroupB sees only ProductB, and GroupC sees only ProductC.

UserA and UserB are members of both GroupA and GroupB. Their results include both Product A and Product B.

Groups   Picture34



Members of Group C (which User C belongs to)  see only Product C.

Groups   Picture35



An iBot that has a conditional request (“Deliver to WebA”), specific named recipients (Users A, B, and C), and personalized data visibility does not get delivered.

Groups   Picture36








After modifying this iBot so that the conditional request is the same as the content (the query “QS” is used for both), Users A, B, and C receive the iBot with personalized content.

Groups   Picture37









So where are we? It would be nice to be able to assign users to web groups using session variables, to send iBots to those users by specifying groups as recipients, and to personalize the content of the iBots. It seems as though there ought to be a way to do all this, but the pieces in OBIEE don’t really seem to fit together at this time. Depending on what you want to achieve, you may need to use a variety of methods to configure iBots and deliver alerts.