Oracle Transactional Business Intelligence

Products Banner

Oracle BIEE 11.1.1.9 to 12c (Oracle Cloud HCM Update22A) Catalog Group migration to Application Role

Received Response
56
Views
3
Comments

Summary:

Need Guidance in transitioning Catalog Groups available in Oracle BI Enterprise Edition 11.1.1.9 to Oracle BI Enterprise Edition 12C.

Oracle is performing the quarterly upgrade 21D to 22A or later, part of this upgrade Oracle Transactional Business Intelligence is also being upgraded from functionality available in Oracle BI Enterprise Edition 11.1.1.9 to 12c. Per the documentation https://docs.oracle.com/en/cloud/saas/otbi/otbi-notable/index.html#TBIWD-GUID-69D70740-2CFC-44C5-B595-6B5C1086F27C

Part of this Catalog groups used to organize users and application roles are migrated to application roles in this release. New custom application roles use a naming convention with a suffix of "_GRP2ROLE".

What we are looking:

We have Custom Catalog groups that are build with user profiles (User name information) only as outlined in the below screenshot for meeting certain business need for restricting access to reporting or enabling the reports to functional as expected that is not achievable via the application roles, So we are looking for recommendations on what can be done to achieve the same desired functionality post the 22D quarterly update.

Any one who encountered the similar situation or have recommendations please do share

Content (required):

We have Custom Catalog groups that are build with user profiles (User name information) only as outlined in the below screenshot for meeting certain business need for restricting access to reporting or enabling the reports to functional as expected that is not achievable via the application roles, So we are looking for recommendations on what can be done to achieve the same desired functionality post the 22D quarterly update.

Any one who encountered the similar situation or have recommendations please do share

Version (include the version you are using, if applicable):

Oracle BIEE 11.1.1.9 [As part of the Oracle quarterly update 22A the Oracle BIEE is upgrading to 12c]

Code Snippet (add any code snippets that support your topic, if applicable):

21D Current State

1.Manage Catalog Groups accessible from Administration

2.Catalog Group Definition in 21D

3.Security for BIP Object using the Catalog group in 21D


Per 22A , The Manage Catalog groups are moved to roles and the same is evident from below screenshot in a demo pod


Answers

  • We are in the same boat and do not see how to move forward.

    Regards,

    Tarun

  • Hi Team, Please review -

    Goal :

    In 22A Catalog groups are no longer supported, during the upgrade to 22A existing Catalog Groups were converted to roles. How to add users to these new roles that were created from catalog group.

    Solution :

    The migrated roles are marked as unassignable so cannot be assigned directly. To add the converted groups you would need to create a new role and add the catalog group converted role as a role hierarchy member and use this new role that you created for any assignment.


    Hope this is helpful.

  • Due to a separation of duties, the system support team at our institution does not have access to security console, so we can't make assignment roles and add the users to them without causing more work for the accounts security team. It would also be significantly slower than using catalog groups.

    Further, the reporting hierarchy that catalog groups added (1. User, 2. BI Group, 3. Catalog Group, 4. Application Role) was integral to how we set up the exclusions and exceptions in folders. With Catalog Group gone, and BI Group functionally useless with its position at #2 in the hierarchy (BI Group should be lowest), we had to abandon our normal method and just use User and Application Role.

    The short of it is that we now use application role for groups like payroll, benefits, compensation, etc., but for the disparate groups that were joined by a catalog group, we just apply by user instead (this often means that instead of adding users to a catalog group and applying that catalog group to the folder, we take each user and apply the user to the folder, for each folder in the hierarchy). This is an exponential increase in manual work but we didn't see any reasonable workaround.

    The best solution would be to just bring back catalog groups, it was asinine to remove them.