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:

 

 

 

 

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

Select
Logon
, Displayname
, RPDGroup
, Webgroup
from
Users1
where
upper(Logon) = upper(':USER')
NQS_PASSWORD_CLAUSE(and password =':PASSWORD')NQS_PASSWORD_CLAUSE

The session variables populated by this init block are

 

 

 

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.

 

 

 

 

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.

 

 

 

 

 

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

 

 

 

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.

 

 

 

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

 

 

 

 

 

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.

 

 

 

 

 

 

 

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

 

 

 

 

 

 

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.

 

 

 

 

 

 

 

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.

 

 

 

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

 

 

 

 

 

 

 

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.

 

 

 

 

 

 

 

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

 

 

 

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.

 

 

 

 

 

 

 

 

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

 

 

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.

 

 

 

 

 

 

 

 

 

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.

 

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!

 

 

 

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!

 

 

 

 

 

 

 

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.

 

 

 

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.

 

 

 

 

 

 

 

 

 

 

These conform to the settings from SA System.

 

 

 

 

 

 

 

 

 

 

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

 

 

 

 

 

 

 

 

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.

 

 

 

 

 

 

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

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

 

 

 

 

 

 

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

 

 

 

 

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

 

 

 

 

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

 

 

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.

 

 

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

 

 

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.

 

 

 

 

 

 

 

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.

 

 

 

 

 

 

 

 

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.