Overview
When creating Reports or custom Workflows in RSA Identity Governance & Lifecycle, the recommendation is to always use the Public Schema Views documented in the
RSA Identity Governance and Lifecycle Public Database Schema Reference Guide for your version of RSA Identity Governance & Lifecycle. The views constitute the public interface to the RSA Identity Governance & Lifecycle database and are intended to insulate the internal implementation and to provide a simplified path to query the data.
Accessing the data through these views is less likely to change between versions, and any changes are documented to plan your upgrade. Using internal tables directly instead of these public views can cause problems such as:
- Customizations failing after an upgrade due to changes to internal tables (which are intentionally not documented as they are proprietary.)
- Performance degradation due to table contention.
- Data corruption if internal tables are updated.
Access
The RSA Identity Governance & Lifecycle public views are accessed from a separately configured Oracle user account, ACMDB, or in the case of Reports, AVDWUSER, installed on the same database instance as the base RSA Identity Governance & Lifecycle database schema (AVUSER). Check with your RSA Identity Governance & Lifecycle system administrator for the specific passwords used to access these accounts.
If you are designing custom workflows (Requests > Workflows > {Workflow-type tab} > Create Workflow > add SQL Select or SQL Execute node), refer to these tables in one of the following ways where public view USERS is shown as an example:
- ACMDB.USERS
- AVUSER.PV_USERS
If you are designing or modifying a report (Reports > Tabular/Chart > {Create Report} > Query tab), you are automatically connected the AVDWUSER database schema. Refer to these tables in one of the following ways where public view USERS is shown as an example:
- USERS
- ACMDB.USERS
- AVUSER.PV_USERS
Custom Attributes
The RSA Identity Governance & Lifecycle public views are dynamically updated to reflect any custom attribute configuration on the base system schema. For example, if custom user attributes are added (Admin > Attributes > User) such as Workforce, ID, DN, Cost Center, and so on, then these attributes would automatically be added to the public schema USERS view.
Public Views
