Managing the Access Request Catalog

12 Managing the Access Request Catalog

The Access Request Catalog provides a simple, intuitive, web-based user interface that allows business users to request access to roles, application instance, and additional access (also known as entitlements) within applications.

This chapter contains the following topics:

12.1 Access Request Catalog

The Access Request Catalog allows a business to categorize and publish roles, application instance, and entitlements to the Catalog and provide additional business context using extensible metadata. Users use familiar request access for themselves using an intuitive ‘catalog search’ and ‘shopping cart’ user experience.

This section provides an introduction to the Access Request Catalog. It contains the following sections:

12.1.1 Access Request Challenges

Enterprises have tried to simplify and streamline the process of managing the identity lifecycle and access privileges of end users as part of improving operational efficiency and reducing IT costs.

To meet these goals, businesses have tried to implement various solutions to allow end users to manage their own identity and access. However, they have faced several challenges in doing so:

End-users had to be trained to understand IT concepts and terminology and use IT processes to request access.
The training cycle had to be repeated as new employees joined, lowering productivity, and increasing IT costs.
End-users had to get IT assistance when their requests were not fulfilled in a timely manner and did not have visibility into the status of their request.
Typically, additional access within an application had to be granted by IT or by Application administrators.
This limited business users' view of available access and limited their productivity, while forcing them to rely on IT.

The Access Request Catalog addresses these challenges by providing an easy to use web interface where users can search and browse various types of access and select the ones they need to perform their job duties. It provides the following benefits:

The end user does not need to know technical jargon or follow IT processes to request access. The Catalog uses well-known and familiar search and shopping cart patterns to guide the user through the access request process.
The end-user does not need to know specific application instance, role or entitlement names. The Catalog provides an extensible metadata model and provides tagging capabilities. This allow business users to specify alternate terms to be used to search for the specific access. End users can search the Catalog using combinations of keywords and wildcards to search for the access they need.

12.1.2 Access Request Catalog Concepts

Some of the key concepts related to the access request catalog are catalog item, category, application instance, enterprise role, entitlement, catalog item metadata, and catalog synchronization.

The following introduces the key access request catalog concepts:

Catalog: Catalog (aka Request Catalog) offers a consistent and intuitive request experience for customers to request Roles, Entitlements and Application Instances following the commonly used Shopping Cart paradigm. The catalog is a structured commodity with its own set of metadata.
Catalog Item: A Catalog Item is an item (Roles, Entitlements or Application Instances) that can be requested by a user, either for themselves or on behalf of other users.
Category: A Catalog Item Category is a way to organize the request catalog. Each catalog item is associated with one and only one category. A catalog item navigation category is an attribute of the catalog item. Catalog Administrators can edit a Catalog Item and provide a value for the category.

Note:

You cannot leave Category field blank for a catalog item. Therefore, you must ensure that a value is present for the category.
Application Instance: An Application Instance represents an account on particular target. When users request an application instance, they are requesting an account in a particular target. Application Instances can be connected, if fulfillment is automated via a Connector, or disconnected, if fulfillment is manual. Application Instances can have entitlements associated with them.
Enterprise Roles: Enterprise Roles are defined by customers. Enterprise Roles have policies associated with them. Users can request enterprise roles via the Catalog. When a role is granted, application instances or entitlements are provisioned to the user.
Entitlement: Entitlements are privileges in an application that govern what a user of the application can do.
Catalog User-defined field: Catalog User-defined fields are additional attributes that are added by customers to the Catalog entity
Catalog Item Metadata: Catalog Item Metadata refers to the values for the Catalog Item attributes. Metadata can be managed on a per-item basis by the Catalog Administrator or can be populated in bulk.
Tags: Tags are search keywords. When users search the Access Request Catalog, the search is performed against the tags. Tags are of two types:
- Auto-generated: The Catalog synchronization process auto-tags the Catalog Item using the Item Type, Item Name and Item Display Name
- User-defined: User-defined Tags are additional keywords entered by the Catalog Administrator
Catalog Administrator: The Catalog Administrator is a global security role. The Catalog can be managed by members of this role only.
Shopping Cart: The Shopping Cart refers to the collection of Catalog Items that are being requested. A user can have only one cart active at any given time and the cart can contain roles, application instances, entitlements, or any combination of the three.
Catalog synchronization: Catalog synchronization refers to the process of loading roles, application instances, and entitlements into the Catalog.

12.1.3 Access Request Catalog Use Cases

Typical use cases of using the access request catalog are to make applications and entitlements in the applications and roles visible in the catalog and allowing users to request access to them via simple web-based interface.

Use cases in this section explain how the access request catalog make it easy for end users to request roles, application instance, and entitlements required to perform their duties.

Requesting Access

Mary, a Manager in MyCorp, would like to request access to MyCorp Trading application for herself and her directs. To do this, she searches the Catalog using the keyword trading. The catalog returns all items that match Mary's keywords and that she is allowed to request. Mary filters the search results by selecting Application from the list of categories. The Catalog returns a reduced set of search results. Mary adds the MyCorp Trading application to the cart and checks out. She adds herself and her directs to the request and submits the request.

Description of the illustration req_acc_1.gif

Administering the Catalog

Jim, a Catalog Administrator, would like to onboard new application instance and their entitlements, add additional attributes and improve the searchability of the catalog items. He runs the Catalog Synchronization Job scheduled job to harvest the new application instance and their entitlements. Next, he extends the Catalog metadata by adding additional attributes and identifies certain attributes as searchable. Next, he loads the catalog with metadata and tags for the new attributes. For certain Catalog items, he searches the Catalog and edits the Catalog item in place.

Note:

The Catalog Administrator must have the System Configuration Administrator admin role for running the Catalog Synchronization Job.

Description of the illustration req_acc_2.gif

These use cases are typical examples of using the Access Request Catalog to make applications and entitlements in the applications and roles visible in the Catalog and allowing users to request access to them via simple web-based interface.

12.1.4 Features and Benefits of Access Request Catalog

The Access Request Catalog is a searchable, categorized collection of entities that are requestable in Oracle Identity Manager. Any authenticated user can access and search the Catalog using one or more keywords and search operators, add one or more Catalog items into a shopping cart, and submit a request for themselves and others.

Key features of the access request catalog include:

Extensible Catalog schema that allows administrators to add additional attributes

and specify how the attribute is rendered using a simple browser-based UI
Automated harvesting of roles, applications, and entitlements
Automated loading of Catalog metadata using a CSV file
Powerful search using keywords with support for complex search operators
Flexible categorization model that allows the Catalog to be organized based on customer choice
Catalog search results secured based on viewer privileges of the requester
Catalog item data available via a web service for use in workflows

12.1.5 Access Request Catalog Architecture

The access request catalog architectural components include catalog tables, catalog loaders, catalog metadata, and catalog user interface in Identity Self Service.

Figure 12-1 shows the components of the Access Request Catalog and its relationship with other components of Oracle Identity Manager.

Figure 12-1 High-Level Catalog Architecture

Description of "Figure 12-1 High-Level Catalog Architecture"

12.2 Configuring the Access Request Catalog

Configuring the access request catalog involves adding attributes to the catalog search form, configuring application selection limit in entitlement search, and configuring the catalog to use a custom search form.

This section describes the following configurations for the access catalog:

12.2.1 Adding More Attributes to the Default Search Form

Additional attributes can be added to the catalog search form.

The attributes marked as searchable are displayed automatically as text fields in the default search form. These attributes must be added to the cart details form via customization. For information about defining a custom attribute, see Configuring Custom Attributes.

12.2.2 Configuring Application Selection Limit in Entitlement Search

You can configure the number of applications that can be selected in the default search form during entitlement search.

The search limit is configurable by using the Catalog Advanced Search Maximum Applications system property. For information about this system property, see Default System Properties in Oracle Identity Governance.

12.2.3 Configuring Catalog to Use a Custom Search Form

For advanced customizations to the catalog search, the default catalog search form can be replaced with a custom-built search form.

The catalog search form can be configured by using the Catalog Advanced Search Taskflow system property. For information about developing a custom taskflow for catalog search, see Customizing Catalog Search in Developing and Customizing Applications for Oracle Identity Governance.

12.3 Administering the Access Request Catalog

Administering the access request catalog involves setting the prerequisites for catalog administration, performing common administration tasks, configuring catalog auditing and hierarchical attributes of entitlements, and implementing best practices related to the database and text index optimization.

This section describes the basic administration of the Access Request Catalog. It consists of the following topics

12.3.1 Prerequisites of Catalog Administration

Prerequisites of catalog administration include setting up the catalog administrator, defining catalog metadata, and adding attributes to the catalog.

The Access Request Catalog is used by end-users to request access to roles and entitlements to help them perform their duties. As a result, it is very important that the Catalog be current, have a rich metadata and be organized so that users can find the right access. To ensure this, you need to have a plan to manage the Access Request Catalog. The ensuring sections give the steps that you should follow to administer the Catalog. Before implementing those steps, there are certain pre-requisites. These include:

12.3.1.1 Setting Up the Catalog Administrator

The Catalog Administrator is an admin role, similar to the System Administrator and System Configurator role. A member of this role (and those of the System Administrators role) can perform the following actions:

Load the Catalog
Manage Catalog Items
Manage Request Profiles

This role is a global role and not scoped by organization.

To grant the Catalog Administrator:

Log in to Oracle Identity Self Service.
Click the Manage tab, and click Organizations.
Search and open the Top organization.
Click the Admin Roles tab.
Select the Catalog System Administrator admin role and click Assign in the toolbar.
Search and select the users that you want to assign, and click Add Selected.
Click Add to add the users.

The new members of the Catalog System Administrator role can login to the Self Service Console and start managing the Catalog.

12.3.1.2 Defining the Catalog Metadata

A rich catalog metadata is important to for the following reasons:

End-users are only interested in getting access to what they need to perform their job duties. When they search and browse the Catalog, the information presented to them must relate to the business. If the Catalog is sparse (minimal attributes), users will not know which access to pick. If the Catalog is rich but technical, users will get confused and will choose not to use the Catalog.
Requesters and Approvers need as much contextual information as possible to help them submit a request or approver one. When approvers review a request, the Catalog item detail helps them understand what is being requested, why and the impact of approving the request.
Approval workflows use routing rules to correctly determine approvers. These rules need access to additional context about the requested item to do approver resolution. If the Catalog information is sparse, the routing rules will not have enough data available to determine the correct approvers.

To meet these challenges, the Catalog must contain additional metadata that can help place the access, that is the Catalog item, in the correct business context.

12.3.1.3 Adding Attributes to the Catalog

To add one or more attributes to the Catalog:

Log in to the Oracle Identity System Administration Console.
Create and activate a sandbox. See Managing Sandboxes in Developing and Customizing Applications for Oracle Identity Governance.
Under System Entities, click Catalog.
Click Custom New Attribute to add an attribute.
Select from one of the pre-defined attribute types and click OK.
Provide the necessary information and click Save and Close.

Note:

If new custom attribute (UDF) is made Searachable, it is recommended to create a normal index on the database column of the custom attribute for optimal search performance. You can find the database columns of custom attributes in CATALOG table of Oracle Identity Manager schema.
Add additional attributes as required.

You have completed the first step in extending the Catalog.
If you do not want to modify the Catalog search results or Catalog Item details UI, then you can have your changes reviewed and after approval of the changes, export and publish the sandbox. It is recommended that you export the sandbox to store all the changes made in your sandbox.

If you want to modify the Catalog search results and Catalog Item details UI, then proceed further.
Logout and login to the Identity Console as a member of the System Administrator role.
Create a new sandbox and activate it.
Add the attribute to the catalog details page by referring to Adding a Custom Attribute.
Export and publish the sandbox.

12.3.2 Common Tasks to be Performed by the Catalog Administrator

Some common tasks to be performed by the Catalog Administrator are on-boarding and automating the on-boarding of applications and roles, bootstrapping and enriching the catalog, and managing catalog items.

This section describes the common tasks to be performed by the Catalog Administrator. It consists of the following tasks:

12.3.2.1 Onboard Applications and Roles

The Access Request Catalog must be populated with enterprise roles, application instances and entitlements so that users can search and request for access. You must develop a process by which enterprise roles, application instances and entitlements can be on-boarded to the Catalog with minimal administrator intervention. This section covers the various steps involved in on-boarding roles, application instances and entitlements into the Catalog.

12.3.2.1.1 Prepare an Onboarding checklist

Use the following oboarding checklist items to develop a high-level process for onboarding roles, application instances and entitlements into the Access Request Catalog. Later, you can follow individual checklists for roles, application instances, and entitlements.

Identify Catalog Administrators
Identify and extended Catalog attributes
Customize Catalog search results UI
Customize Catalog Item Details UI
Identify navigational categories
Identify Owners, Certifiers, Approvers for roles and applications
Identify sources of truth for Catalog Item metadata/glossary
Develop procedures to generate and load Catalog item metadata/glossary
Develop glossary of tags and a process to maintain tags

12.3.2.1.2 Onboarding Roles

There are no onboarding steps for enterprise roles. Roles, belonging to a role category other than Oracle Identity Manager Roles are published directly to the Catalog when they are created.

When user edits the role and changes its category from Oracle Identity Manager Role to any other category, then the Catalog Synchronization Job scheduled job must be run to have the role searchable in the catalog.

12.3.2.1.3 About Onboard Application Instances

Application Instances require additional configuration before they can be requested by end users. Use the following checklist items to make sure that you have performed the configuration required to onboard application instances:

Ensure that the Connector is installed (for new targets).
If you are upgrading Oracle Identity Manager from Release 11g, then see Upgrading Oracle Identity Manager from 11g in Upgrading Oracle Identity and Access Management for information about mandatory post-upgrade steps.
Verify that the process forms have an IT resource field.
Verify that you have defined the form field properties correctly.
Verify that you have created the application instances with suitable display names and descriptions.
Verify that you have created the forms required for account requests.
Verify that you have published the application instances to the relevant organizations.
For disconnected applications, verify that you have created the application instances. See Managing Disconnected Resources for detailed description of the steps.

After verifying the steps in the check list, follow the instructions below to onboard application instances.

12.3.2.1.4 Onboarding Application Instances

To onboard Application Instances:

Login to the Identity System Administration as a member of the System Administrator role.
In the left pane, under System Configuration, click Scheduler.
Search for the Catalog Synchronization Job scheduled job.
Check the Process Application Instances parameter.
Set the parameter Mode to Incremental.

12.3.2.1.5 About Onboard Entitlements

Use the following checklist items to make sure that you have performed the configuration required to onboard entitlements.

Note:

Job entitlement list loader should be executed before executing the Catalog Synchronization Job scheduled job.

Ensure that the Connector is installed (for new targets).
If you are upgrading Oracle Identity Manager from Release 11g, then see Upgrading Oracle Identity Manager from 11g of the Upgrading Oracle Identity and Access Management for information about mandatory post-upgrade steps.
Verify that the process forms have an IT resource field.
Verify that you have defined the form field properties correctly.
Verify that you have correctly associated the parent and child forms.
Verify that you have run the common lookup reconciliation job for ICF-based targets.
Verify that you have run the connector-specific lookup reconciliation jobs for non-ICF connectors.
Verify that you have created application instances correctly, corresponding to the resource object and IT resource instance specified in the Lookup Reconciliation job.
Verify that you have published entitlements to relevant organizations.
Verify that you have run the entitlement list loader job, so that data can be populated in ent_list table.

After verifying the steps in the check list, follow the instructions in Onboarding Entitlements to onboard entitlements.

12.3.2.1.6 Onboarding Entitlements

To onboard Entitlements:

Login to Identity System Administration as a member of the System Administrator role.
In the left pane, under System Configuration, click Scheduler.
Search for the Catalog Synchronization Job scheduled job.
Check the Process Entitlements parameter.
Set the parameter Mode to Incremental.
Note:
- If its a first time harvesting, then you should set the parameter to Full.
- If the parameter mode is Incremental, then only those entities will be picked by scheduled task for processing, whose create date is greater than update date for creation, and update date is greater than update date value.

12.3.2.2 Bootstrapping the Catalog

This section describes about bootstrapping the catalog in the following topics:

12.3.2.2.1 About Bootstrapping the Catalog

Bootstrapping refers to the process of populating the Catalog for the first time. After Bootstrapping large number of any entity, you can gather statistics on base tables. This section refers to bootstrapping the Catalog after you have installed Oracle Identity Manager 12c (12.2.1.3.0).

If you are upgrading from Oracle Identity Manager 11g, then see Upgrading Oracle Identity Manager Single Node Environments in Upgrade Guide for Oracle Identity and Access Management.

The pre-requisites for bootstrapping Catalog are as follows:

You have extended the Catalog using the Catalog system entities by following the steps given in Defining the Catalog Metadata.
You have carried out the necessary UI customization steps required when a user-defined field is added to the Catalog.

There are two ways to bootstrap the Catalog with Roles.

Bootstrapping the Catalog with Roles when you are not using Oracle Identity Analytics customer.

Roles are published immediately to the Catalog when they are created and assigned a role category other than the Oracle Identity Manager Roles category. If you have made changes to the role categories or need to synchronize the enterprise roles with the Catalog, perform the steps given in Bootstrapping the Catalog with Roles.
Bootstrapping the Catalog with Roles when you are using Oracle Identity Analytics for managing the lifecycle of enterprise roles.

Bootstrapping the Catalog with Application Instances requires additional steps to be carried out. Use the checklist given in About Onboard Application Instances to ensure that you have completed the pre-requisites.

Bootstrapping the Catalog with Entitlements requires additional steps to be carried out. Use the checklist given in About Onboard Entitlements to ensure that you have completed the pre-requisites.

12.3.2.2.2 Bootstrapping the Catalog with Roles

To bootstrap the catalog with roles:

Login to Identity System Administration as a member of the System Administrator role.
In the left pane, under System Configuration, click Scheduler.
Search for the Catalog Synchronization Job scheduled job.
Check the Process Roles parameter.
Set the parameter Mode to Full.

Note:

If you are running the job for the first time and the Mode is set to Full, then you must not provide any value in the Update Date parameter.
Click Run Now to run the job immediately or provide a date and time to run the job later.

12.3.2.2.3 Bootstrapping the Catalog with Application Instances

Once you have completed the pre-requisites, follow the steps given below to onboard application instances:

Login to Identity System Administration as a member of the System Administrator role.
In the left pane, under System Configuration, click Scheduler.
Search for the Catalog Synchronization Job scheduled job.
Check the Process Application Instances parameter.
Set the parameter Mode to Full.

Note:

If you are running the job for the first time and the Mode is set to Full, then you must not provide any value in the Update Date parameter.
Click Run Now to run the job immediately or provide a date and time to run the job later.

12.3.2.2.4 Bootstrapping the Catalog with Entitlements

Once you have completed the pre-requisites, follow the steps given below to onboard entitlements.

Login to Identity System Administration as a member of the System Administrator role.
In the left pane, under System Configuration, click Scheduler.
Search for the Catalog Synchronization Job scheduled job.
Check the Process Entitlements parameter.
Set the parameter Mode to Full.

Note:

If you are running the job for the first time and the Mode is set to Full, then you must not provide any value in the Update Date parameter.
Click Run Now to run the job immediately or provide a date and time to run the job later.

12.3.2.3 Ongoing Synchronization

To automate the process of onboarding roles, application instances, and entitlements, you can configure the Catalog Synchronization Job scheduled job in the following manner.

Login to Identity System Administration as a member of the System Administrator role.
In the left pane, under System Configuration, click Scheduler.
Search for the Catalog Synchronization Job scheduled job.
Check the Process Roles, Process Application Instances, and Process Entitlements parameters.
Set the parameter Mode to Incremental.
Provide a date and time to run the job later.
Set the Job frequency to run every five minutes.

12.3.2.4 Enrich the Catalog

This section describes how to enrich the Catalog in the following sections:

12.3.2.4.1 About Enriching the Catalog

Enriching the Catalog refers to the process of populating the Access Request Catalog with data so that the information is available for end-users to see. The additional data helps end-users understand the business context associated with the Catalog Item. The additional data is also available as part of the approval workflow, allowing the workflow to make intelligent routing decisions based on the data about the Catalog Item.

The pre-requisites are:

You have extended the Catalog using the Catalog system entities by following the steps given in Defining the Catalog Metadata.
You have added UI customizations required when a user-defined field is added to the Catalog. See Configuring Custom Attributes for information about adding user-defined fields and customizing the UI to display the user-defined field in the UI.
.
You have created a Catalog Administrator role and assigned users as given in Setting Up the Catalog Administrator.

12.3.2.4.2 Editing a Catalog Item Online

To edit a Catalog Item online by using the Oracle Identity Self Service:

Note:

Name, Display Name, and Description cannot be edited on the catalog screen. These are base level attributes and you cannot edit from Catalog UI.

When editing a Catalog Item, for list of values (LOV) type of fields, it is recommended to select and specify values by picking from the associated lists, instead of typing the values into the fields directly.

Log in to Identity Manager Self Service as a member of the Catalog Administrator role.
Click Catalog to access the request catalog.
Enter one or more keywords and click Search.
Use the Refine Search to find the Catalog Item(s) to be edited.
Select the Catalog Item to be edited.
In the Detailed Information section, edit the Catalog Item and click Apply. Verify the confirmation message.

12.3.2.4.3 Enriching the Catalog in Bulk from External Sources

While Catalog Administrators can make use of the robust Catalog Item editing capabilities in the Oracle Identity Self Service, there are scenarios where the data needs to be loaded in bulk from external sources. Examples of bulk updates:

MyCorp wants to provide users with asset information from their IT CMDB system or from their Corporate Asset Management system. The information cannot be entered manually since the CMDB or AMS system gets updated on a regular basis. In such a scenario, MyCorp needs a way to update the Catalog in bulk.
MyCorp was using a home grown access request application prior to implementing Oracle Identity Manager 11g R2. This application contains the glossary and other relevant information about the roles, application instances and entitlements. As part of migrating to Oracle Identity Manager, MyCorp Catalog Administrators would like to move the Catalog Item information from the legacy system.

12.3.2.4.4 Loading data from an external source

Follow the steps given below to load data from an external source into the Catalog:

Export the data to be loaded into a comma-separated values format file.
Ensure that the first line of the file contains the Catalog attribute names.
Move the file to a file system that is accessible from the server on which is Oracle Identity Manager is deployed.
Login to Identity System Administration as a member of the System Administrator or System Configurator role.
In the left pane, under System Configuration, click Scheduler.
Search for the Catalog Synchronization Job scheduled job.
Provide the full path to the file in the parameter File Path.

Set the value of the parameter Mode to Metadata. Table 12-1 provides sample parameter details.

Table 12-1 Catalog Metadata Loader Sample

Parameter	Value
ENTITY_TYPE	Role
ENTITY_KEY	12
ENTITY_NAME	test
IS_REQUESTABLE	1
USER_DEFINED_TAGS	UDTags
CATEGORY	mycategory
AUDIT_OBJECTIVE	AO111
APPROVER_USER	1
APPROVER_ROLE	1
FULFILLMENT_USER	1
FULFILLMENT_ROLE	1
CERTIFIER_USER	1
CERTIFIER_ROLE	1
ITEM_RISK	5
CERTIFIABLE	1
STUDF	1

Click Run Now to run the job immediately, or select a date and click Apply to run the job later.

12.3.2.5 Managing Catalog Items

This section describes about managing catalog items in the following topics:

12.3.2.5.1 Deleting a Catalog Items of Type Roles

To delete role Catalog Items:

Login to Identity Self Service.
Search for the role to be deleted and delete the role.
The associated Catalog Item will be marked as soft-deleted and will not appear in the Catalog.
For deleting large number of roles, use the APIs to delete the role. It is not recommended to use database techniques to delete roles.

12.3.2.5.2 Deleting Catalog Items of Type Application Instances

Application Instances, in almost all use cases, represent a target system (sometimes known as an endpoint) and an account in a target system. When you delete an Application Instance, you are essentially decommissioning the target system from Oracle Identity Manager. Depending upon the scale of your deployment and the number of accounts provisioned to the target system, deleting an Application Instance can have a significant impact to the end users and their access.

To delete application instance Catalog Items:

Login to Oracle Identity System Administration.
Click Application Instances.
Search for application instances.
Select one or more application instances. Delete and confirm.
Click Scheduler.
Search for the Catalog Synchronization Job scheduled job.
Set the Mode to Incremental.
Click Run Now to run the job immediately or set it up to run at a particular time.

See Understanding the Deletion of Application Instances for more information about deleting application instances.

12.3.2.5.3 Deleting Catalog Items of type Entitlements

To delete entitlement Catalog Items:

To delete Entitlements, login to Oracle Identity System Administration.
Click Lookups.
In the Code column, enter the name of the Lookup Definition that contains the entitlement. Refer to the Connector documentation to find out the name of the Lookup Definition.
Delete one or more entitlement values.
Click Scheduler.
Search for the Entitlement List Load job.
Click Run now.
Search for the Catalog Synchronization Job scheduled job.
Set the Mode to Incremental.
Click Run Now to run the job immediately or set it up to run at a particular time.

12.3.3 Catalog Auditing

You configure catalog auditing to track who changes what and when in the access request catalog through the UI.

This section describes about catalog auditing in the following topics:

12.3.3.1 About Catalog Auditing

Catalog auditing maintains a footprint of changes in the access request catalog. By enabling catalog auditing, you can track who changes what and when in the access request catalog through the UI.

Catalog auditing stores the footprints of the following changes in the access request catalog:

A change in the value of a catalog UDF.
Any value of a catalog item attribute is changed from the catalog UI or any other custom UI.
Following is the list of consolidated catalog attributes that are part of auditing during updation of catalog item:

Category, Audit Objective, Approver User, Approver Role, Fulfillment User, Fulfillment role, Certifier User, Certifier Role, Item Risk, Certifiable

Note:

Auditing takes place only for those entities that can be modified through the Catalog UI. Audit does not happen for entities that are modified in the catalog through synchronization. In addition, auditing is not supported for User Defined Tags.

12.3.3.2 Configuring Catalog Auditing

To configure catalog auditing:

Login to Oracle Identity System Administration.
Under System Configuration, click Configuration Properties.
Search for the Catalog Audit Data Collection system property with keyword XL.CatalogAuditDataCollection. The default value of this property is none, which specifies that catalog auditing is disabled.
Set the value of the XL.CatalogAuditDataCollection system property to catalog. This enables catalog auditing.
Click Save.

After enabling catalog auditing, the changes in the access request catalog are audited. For changes in the access request catalog, such as changing the risk level of a role, the footprints of the changes are stored in the CPA_CATALOG and CPA_CATALOG_FIELDS tables in the database on running the Issue Audit Massages Task scheduled job. For information about this scheduled job, see Predefined Scheduled Tasks.

12.3.4 Configuring Hierarchical Attributes of Entitlements

You configure the hierarchical attributes of entitlements to display additional details of entitlements.

This section describes about the configuration of hierarchical attributes of entitlements in the following topics:

12.3.4.1 About Hierarchical Attributes of Entitlements

You can enable the display of hierarchical attributes of entitlements to requesters, approvers, and certifiers to view additional details of entitlements (hierarchical attributes) in the catalog detail screen. The additional details of entitlements is called technical glossary. The technical glossary is displayed in a list view with bread crumbs at the top showing the navigational path. For information about viewing the additional details in the catalog detail screen, see Viewing Hierarchical Attributes of Entitlements in Performing Self Service Tasks with Oracle Identity Governance.

Note:

The child entitlements are not requestable in the access catalog. The hierarchical entitlements feature is meant for display purpose only.

The additional details or hierarchical attributes is read-only information. This information must be provided in the form of an XML, which is seeded in Oracle Identity Manager. The technical glossary is inserted and replaced in the database. The following is a sample XML code of the hierarchical attributes:

<oim>
      <applicationInstances>
            <applicationInstance>SampleEBS</applicationInstance><!-- Application Name for which entitlements are seeded-->
      </applicationInstances>
      <attributes>
            <attribute name="Responsibility Name"><!-- Label name of the field which is marked Entitlement field in Child form-->
                  <entitlementValues>
                        <entitlementValue><!-- Below is the Hierarchical data XML for Entitlement and Entitlement Display Name is used to denote entitlement -->
<value>Payables Menu</value>
<attributes>
      <attribute name="Menu">
            <entitlementValues>
                  <entitlementValue>
<value>ALR_OAM_NAV_GUI_USER_NAME</value>
<description>Alerts Manager View</description>
<attributes>
      <attribute name="Function Code">
            <entitlementValues>
                  <entitlementValue>
      <value>ALR_OBJ_ACTIVATE_ACCT</value>
      <description>Create, Activate, Deactive User Account</description>
</entitlementValue>
<entitlementValue>
<value>ALR_OBJ_EDIT_FORM</value>
</entitlementValue>
<entitlementValue>
<value>ALR_OBJ_VIEW_PERSON</value>
                  </entitlementValue>
            </entitlementValues>
      </attribute>
</attributes>
                  </entitlementValue>
                  <entitlementValue>
<value>EMPLOYEE_W2_MENU</value>
<description>Alerts Manager View</description>
<attributes>
      <attribute name="Function Code">
            <entitlementValues>
<entitlementValue>
      <value>Employee_OBJ_ACTIVATE_ACCT</value>
      <description>Create, Activate, Deactive User Account</description>
</entitlementValue>
<entitlementValue>
      <value>Employee_OBJ_EDIT_FORM</value>
</entitlementValue>
<entitlementValue>
      <value>Employee_OBJ_VIEW_PERSON</value>
</entitlementValue>
            </entitlementValues>
      </attribute>
                        </attributes>
                  </entitlementValue>
                  <entitlementValue>
<value>VISION_OAM_NAV_GUI</value>
<description>Alerts Manager View</description>
<attributes>
                        </attributes>
                  </entitlementValue>
            </entitlementValues>
      </attribute>
                              </attributes>
                        </entitlementValue>
                  </entitlementValues>
            </attribute>
      </attributes>
 
</oim>

RDBMS features, such as Securefile LOB and Oracle XML DB, are used for storing hierarchical data in Oracle Database. Securefile is a new re-architecture featuring entirely new disk formats, network protocol, space management, redo and undo formats, buffer caching, and intelligent I/O subsystems. It delivers substantially improved performance along with optimized storage for unstructured data, which resides in Oracle Database as compared to LOB's storage structure. Oracle XML DB provides a high-performance, native XML storage and retrieval technology. It absorbs the W3C XML data model into the Oracle Database, provides new standard access methods for navigating and querying XML, and provides the advantages of relational database technology together with the advantages of XML.

12.3.4.2 Enabling the Display of Additional Details of the Entitlements

To enable the display of additional details of the entitlements in the access request catalog:

Seed the additional hierarchical data in Oracle Identity Manager. To do so, create a XML file per the XSD with all the additional details about the entitlement. The XSD is used to register XML schema in the database.
Place the XML file in a directory in the Oracle Identity Manager server. You must have read and write permissions on the directory.
Specify the details of the technical glossary in the Catalog Synchronization Job scheduled job. To do so:
1. Login to Oracle Identity System Administration.
2. Under System Configuration, click Scheduler.
3. Search and open the Catalog Synchronization Job scheduled job.
4. In the Parameters section, in the Mode field, enter Technical Glossary.
5. In the File Path field, enter the directory path of the XML file.
6. Click Apply.

When you run the Catalog Synchronization Job scheduled job, a new link, which is called technical glossary details, is displayed just before the catalog details link for entitlements. Clicking this links opens the technical glossary additional information in a different tab. The XML file is deleted from the directory after processing and is moved to the archive directory with time stamp appended to its name.

Any failed record is logged in a file, which is placed in the xmlprocessedlogs directory. The log file has the name of the XML file with time stamp appended to it.

12.3.5 Database Best Practices for Access Request Catalog

Some database best practices for the access request catalog involves optimization for text index, and addressing some frequently asked questions about database usage related to the catalog.

Following sections are aimed at providing more information in this regard for Oracle Identity Manager administrators and database administrators.

12.3.5.1 About Database Best Practices for Access Request Catalog

Access Request Catalog uses "Oracle Text" option in Oracle database for text search capabilities. Oracle Text is a fast and accurate full-text retrieval technology integrated with Oracle Database.

The CATALOG table which contains catalog items is indexed using CONTEXT index type of Oracle Text. Although Oracle Text index operates like a regular database index, the architecture and processing behind Text index highlights the importance of best practices when creating the Text index and also the on-going maintenance.

12.3.5.2 One-Time Optimizations for Oracle Text Index

When you install Oracle Identity Manager, the Text index for Access Request Catalog is created with possible optimizations. However, Oracle Text has some more optimizations that are better applied based on the characteristics of the deployment. Following are the optimizations that you should consider applying for improving Access Request Catalog search performance. It is important to note that Access Request Catalog is not usable when applying these and these are recommended to be done during a scheduled maintenance window.

Note:

Catalog Synchronization Job and Access Request Catalog should be down when these one-time optimizations are applied.

12.3.5.2.1 Storage of Text Index

Oracle Text index is stored in relational tables (DR$) which are presently resides in the default tablespace of Oracle Identity Manager schema. It is recommended to separate them out to their own tablespace. You can use the following commands to do that. You are recommended to be familiar with these steps and also make changes where needed.

Login to SYS schema and create a new tablespace to hold the text index internal tables. You can use the following sample command for it. Replace DATA_DIR with the directory in which you want to store the data file and adjust the size and other parameters as necessary for your environment.
```
CREATE TABLESPACE catalog_text_ind_tables
 DATAFILE 'DATA_DIR/catalog_text_ind_tables_01.dbf' SIZE 2048M REUSE
 EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
```
Connect to the database using Oracle Identity Manager schema.

Create a storage preference using the commands below. Oracle recommends you to be familiar with BASIC_STORAGE clause of Oracle Text and add more storage clauses if required. You can find more info on BASIC_STORAGE in Oracle Text Reference document.

Begin
Ctx_Ddl.Create_Preference('cat_storage', 'BASIC_STORAGE');
End;
/
 
Begin
ctx_ddl.set_attribute('cat_storage','I_TABLE_CLAUSE','tablespace catalog_text_ind_tables storage (initial 5M next 5M)');
End;
/
 
Begin
ctx_ddl.set_attribute('cat_storage', 'K_TABLE_CLAUSE','tablespace catalog_text_ind_tables storage (initial 5M next 5M)');
End;
/
 
Begin
ctx_ddl.set_attribute('cat_storage', 'R_TABLE_CLAUSE','tablespace catalog_text_ind_tables storage (initial 1M) lob (data) store as (cache)');
End;
/
 
Begin
ctx_ddl.set_attribute('cat_storage', 'N_TABLE_CLAUSE','tablespace catalog_text_ind_tables storage (initial 1M)');
End;
/
 
Begin
ctx_ddl.set_attribute('cat_storage', 'I_INDEX_CLAUSE','tablespace catalog_text_ind_tables storage (initial 1M) compress 2');
End;
/

Apply the new storage preference using the following command. Make sure the Text index status is valid after this step.
```
ALTER INDEX CAT_TAGS rebuild parameters ('replace storage cat_storage');
```
Verify that the above tables are moved to the new tablespace by querying USER_SEGMENTS table.

12.3.5.2.2 KEEP Pool Settings for Text Index

Oracle recommends put all the tables that make up the Text index in database KEEP pool to improve the performance of Access Request Catalog search. You must resize the KEEP pool (DB_KEEP_CACHE_SIZE) correctly so that these Text index tables and other Oracle Identity Manager objects are retained in KEEP pool. To do so:

Connect to the database using Oracle Identity Manager schema.
Compute the size of the text index using the following query and use that to set/adjust DB_KEEP_CACHE_SIZE accordingly.
```
SELECT ctx_report.index_size('CAT_TAGS') FROM dual;
```

Run the following commands as Oracle Identity Manager schema user to put the tables in KEEP pool.

ALTER INDEX DR$CAT_TAGS$X STORAGE (buffer_pool keep);
ALTER TABLE DR$CAT_TAGS$R STORAGE (buffer_pool keep);
ALTER TABLE DR$CAT_TAGS$R STORAGE (buffer_pool keep) MODIFY lob (data) (STORAGE (buffer_pool keep));
ALTER TABLE DR$CAT_TAGS$K STORAGE (buffer_pool keep);
ALTER TABLE DR$CAT_TAGS$I STORAGE (buffer_pool keep);

12.3.5.3 Text Index Optimization

The Text index could become fragmented due to on-going catalog synchronization. Optimizing the text index on regular basis removes the old data and minimizes the fragmentations, which can improve the search performance of Access Request Catalog. To perform this, Oracle Identity Manager has introduced the following Oracle Database scheduler jobs:

FAST_OPTIMIZE_CAT_TAGS
REBUILD_OPTIMIZE_CAT_TAGS

Note:

You can check for the jobs logged into Oracle Identity Manager schema by running the following query:

SELECT * FROM user_scheduler_jobs;

These jobs reside in Oracle Identity Manager database schema and they are disabled by default. Oracle strongly recommends you to view these jobs, make schedule changes if needed and enable them. When changing the schedule, make sure the new schedule is set on the same line as the default schedule.

FAST_OPTIMIZE_CAT_TAGS is meant to be running on frequent basis. By default, it is scheduled to run once a day at 1 AM. REBUILD_OPTIMIZE_CAT_TAGS does a full optimization and rebuilds the Text index. REBUILD_OPTIMIZE_CAT_TAGS is not meant to be running frequently. By default, REBUILD_OPTIMIZE_CAT_TAGS is scheduled to run every Sunday at 2 AM. Note that optimization may take a long time if your Text index is big.

Make sure that the default schedule (daily 1 AM for FAST and every Sunday 2 AM for REBUILD) is acceptable to your environment. If not, change the schedule. If you are not sure, then you can keep the default schedule and change later when needed.

Note:

The Text index optimization can be done when the server is up and search of Access Request Catalog takes place.

12.3.5.4 Frequently Asked Questions about the Access Request Catalog

Some of the frequently asked questions about the access request catalog are related to catalog search, supported search operators, and text index.

This section answers some frequently asked questions about the access request catalog.

What is the access request catalog?

The Access Request Catalog is a searchable, categorized collection of entities that are requestable in Oracle Identity Manager. Any authenticated user can access and search the catalog using one or more keywords and search operators, add catalog items to a shopping cart, and submit a request for themselves and others.

What is Oracle Text Index?

Built on the RDBMS Oracle Text component, Oracle Text (previously known as intermedia Text and ConText) is an extensive full-text indexing technology that lets you efficiently query free text and produce document classification applications. It provides indexing, word and theme searching, and viewing capabilities for text. Oracle Text has various options for domain-based indexes:

ConText
CatSearch
CtxRule

Out of these, only ConText is in the scope of Oracle Identity Manager’s Oracle Text.

What are the supported search operators for Oracle Identity Manager?

Use the Catalog field to specify a (case-insensitive) keyword for searching or browsing the request catalog. The supported search operators are:

One or more keywords (sample value: administrator)
- This search condition finds all catalog items that start with the term administrator.
- Sample value for more than one keyword: web administrator
- This search condition finds all catalog items that start with the terms web and administrator. Because a space character between keywords behaves as an AND operator, this search automatically applies the AND operator to the search keywords. Alternatively, you can use an & operator to denote an AND relationship explicitly. For example, web administrator and web & administrator return catalog items that starts with both web and administrator.
Phrase
- To search for catalog items that start with the exact phrase you enter, you must specify the search condition within double quotes (").
- For example, searching for web administrator returns catalog items starting with the phrase web administrator.
OR [|] search
- Use the OR [|] operator to search for catalog items starting with any of the search keywords.
- Sample value 1: web | administrator. This search condition returns catalog items starting with the term web or administrator.
- Sample value 2: vision purchasing | administrator. This search condition returns catalog items starting with the phrase vision purchasing or the term administrator.

Why do we perform One-Time Optimizations for Oracle Text index?

When you install Oracle Identity Manager, the Text Index for Access Request Catalog is created with possible optimizations. However, Oracle Text has other RDBMS recommended optimizations that are better applied, based on the characteristics of the deployment. All one-time optimizations for Oracle Text index are seeded by default in Oracle Identity Manager. If you have an upgraded deployment of Oracle Identity Manager, then you must apply the one-time optimizations manually (if not already present).

What is required for ongoing maintenance of Oracle Text index?

The Text Index can become fragmented because of ongoing catalog synchronization. Regularly optimizing the Text Index removes the old data and minimizes the fragmentations, and can improve the search performance of the Access Request Catalog.

FAST_OPTIMIZE_CAT_TAGS and REBUILD_OPTIMIZE_CAT_TAGS are the Oracle Database scheduler jobs which are executed for the text index maintenance.

What are the prerequisites for applying One-Time Optimizations for Oracle Text index?

The Catalog Synchronization Job scheduled job and the Access Request Catalog must be down when the One-Time Optimizations are being applied.

What are the prerequisites for applying Text Index Optimizations?

Text Index optimization can be performed when the server is up and Access Request Catalog is being searched.

How to troubleshoot Oracle Text errors?

The CTX_USER_INDEX_ERRORS view shows the row ID of the failed row in the source table. Use this row ID to update the row in the source table that failed.

Specifically, perform a dummy update against the column that holds the text index (update table x set columnx = columnx where rowid = ?). This will generate a row in the CTX_USER_PENDING view.

Then perform CTX_DDL.SYNC_INDEX, which will index the rows in the CTX_USER_PENDING view.

SELECT err_timestamp, err_text
FROM ctx_user_index_errors
ORDER BY err_timestamp DESC;

Pending DML requests can be queried with the CTX_PENDING and CTX_USER_PENDING views.

DML errors can be queried with the CTX_INDEX_ERRORS or CTX_USER_INDEX_ERRORS view.

SELECT pnd_index_name, pnd_rowid, TO_CHAR( pnd_timestamp, 'dd-mon-yyyy hh24:mi:ss' ) TIMESTAMP
FROM ctx_user_pending;

How to re-create the catalog’s Text index?

If CAT_TAGS index is found to be present in the database in INVALID status because of some reason, and you want to re-create the Text index, then perform the following steps:

Connect to Oracle Identity Manager schema, and run the following SQL command to check the current status of the CAT_TAGS index:
```
SELECT index_name,table_name,status, parameters, domidx_status,domidx_opstatus 
FROM user_indexes 
WHERE index_type='DOMAIN';
```
Expected output is for CAT_TAGS domain index to be present in INVALID status.

Connect to Oracle Identity Manager schema, and run the following PL/SQL blocks in the order in which they are given:

Drop and recreate the Text Index CAT_TAGS.

SET SERVEROUTPUT ON
DECLARE 
  P_DROPINDEX NUMBER; 
  P_CREATEINDEX NUMBER; 
  STRERRMESSAGE_OUT VARCHAR2(200); 
BEGIN 
  P_DROPINDEX := 1; 
  P_CREATEINDEX := 0; 

  OIM_PKG_CATALOG_INDEX.OIM_SP_CREATEDROPCATALOGINDEX( 
    P_DROPINDEX => P_DROPINDEX, 
    P_CREATEINDEX => P_CREATEINDEX, 
    STRERRMESSAGE_OUT => STRERRMESSAGE_OUT 
  ); 
DBMS_OUTPUT.PUT_LINE('STRERRMESSAGE_OUT = ' || STRERRMESSAGE_OUT); 
END; 
/

Recreate the Text Index.

SET SERVEROUTPUT ON
DECLARE 
  P_DROPINDEX NUMBER; 
  P_CREATEINDEX NUMBER; 
  STRERRMESSAGE_OUT VARCHAR2(200); 
BEGIN 
  P_DROPINDEX := 0; 
  P_CREATEINDEX := 1; 

  OIM_PKG_CATALOG_INDEX.OIM_SP_CREATEDROPCATALOGINDEX( 
    P_DROPINDEX => P_DROPINDEX, 
    P_CREATEINDEX => P_CREATEINDEX, 
    STRERRMESSAGE_OUT => STRERRMESSAGE_OUT 
  ); 
DBMS_OUTPUT.PUT_LINE('STRERRMESSAGE_OUT = ' || STRERRMESSAGE_OUT); 
END; 
/

Re-run the SQL command given in step 1. The following output is displayed;

CAT_TAGS    CATALOG    VALID     sync (on commit) stoplist CTXSYS.EMPTY_STOPLIST lexer CATALOG_PREFERENCE    VALID    VALID

Is catalog search using stopwords (such as a, d, I, s, t) very slow and sometimes freezes the UI?

Remove stopwords from the CAT_TAGS Oracle Text index, by following the steps in My Oracle Support document Remove stopwords from CAT_TAGS text index in OIM (Doc ID 2217118.1).

Does catalog search of entitlements with "_" (underscore) character not displayed correctly and/or returns incorrect results?

Remove stopwords from the CAT_TAGS Oracle Text index by following the steps in My Oracle Support document Remove stop words from CAT_TAGS text index in OIM (Doc ID 2217118.1).

Does wild card search with large data-matching result in errors?

This is default functionality in interMedia (Oracle Text). We cannot use a wild card (such as % or *) in the search string. Oracle Text interrelates this as a wild card by itself and tries to return all products as if you are searching using just %. This causes the error from Oracle Text.

In Oracle Database 11g, the maximum number of distinct tokens (not rows) that a wild card can match without producing an error is 50,000. You can use the wildcatters property of the word list if you decide to return more than 20,000 distinct tokens in Oracle Database 11g and 5,000 distinct tokens in Oracle Database 10g R2.

In the wildcatters property, specify the maximum number of terms in a wild card (%) expansion. Use this parameter to keep wild card query performance within an acceptable limit. Oracle Database returns an error when the wild card query expansion exceeds this number. To implement the solution, perform the following steps:

BEGIN
ctx_ddl.create_preference('<Pref_name>','BASIC_WORDLIST');
  ctx_ddl.set_attribute('<Pref_name>','WILDCARD_MAXTERMS', 50000);
END;
/

ALTER INDEX cat_tags rebuild parameters ('replace metadata word list <Pref_name>');

Repeat the search.

Here, 15,000 is the maximum number if the database version is lower than 10.2.0.3, or 50,000 if the database version is 10.2.0.3 or higher. The number can be set to a number between 5,000 (default value) and 15,000/50,000, based on the database version, to any number that enables a successful search. However, the higher you set this value, the more memory it will take.

How to handle break/escape characters in Oracle Text index?

We can use the backslash \ character to escape characters with special meaning and treat them as regular text. Run the following command from Oracle Identity Manager schema:

BEGIN
  CTX_DDL.CREATE_PREFERENCE ('my_lexer', 'BASIC_LEXER');
  CTX_DDL.SET_ATTRIBUTE ('my_lexer', 'PRINTJOINS', '~!@$%^&*()-_=+|;:,"./');
  
       --OR 
  
  CTX_DDL.SET_ATTRIBUTE ('my_lexer', 'SKIPJOINS', '`-=[];''\,./~!@#$%^&*()_+{}:"|?§'"½¼¾¤Φ£€©™®'); 
END;
/

How to collect diagnostic data for Oracle Text index?

To collect diagnostic data, run the following SQL commands from Oracle Identity Manager schema:

To set Oracle Text index size:

SELECT ctx_report.index_size('CAT_TAGS') FROM dual;

To describe Oracle Text index:

SELECT ctx_report.describe_size('CAT_TAGS') FROM dual;

To collect Oracle Text index statistics:

CREATE TABLE output(result CLOB);

DECLARE
  x CLOB := NULL;
BEGIN
  ctx_report.index_stats('CAT_TAGS',x);
  INSERT INTO output VALUES(x);
  COMMIT;
  dbms_lob.freetemporary(x);
END;
/

SELECT * FROM output;

To create Oracle Text index script:

SELECT ctx_report.create_index_script('CAT_TAGS') FROM dual;

Is single character search slow even after removing stop words?

Create Prefix index with min and max length (recommended). To do so, from Oracle Identity Manager schema, run the following SQL commands:

To create new preference:

BEGIN 
ctx_ddl.create_preference('mywordlist', 'BASIC_WORDLIST'); 
ctx_ddl.set_attribute('mywordlist','PREFIX_INDEX','TRUE');
ctx_ddl.set_attribute('mywordlist','PREFIX_MIN_LENGTH',1);
ctx_ddl.set_attribute('mywordlist','PREFIX_MAX_LENGTH',3);
END;
/

To rebuild parameters:

ALTER INDEX cat_tags REBUILD PARAMETERS('replace word list mywordlist');

To rebuild Text index:

BEGIN
dbms_scheduler.run_job ('REBUILD_OPTIMIZE_CAT_TAGS');
END;
/

12.4 Managing the Lifecycle of the Catalog

You can extend the Catalog, customize the Catalog UI, and develop and test the customizations in a test environment, and then eventually roll out the customizations to your production environment.

This section describes how to move Catalog customizations from a test environment to a production environment. It includes the following topics:

12.4.1 Overview of Catalog Customization

While the Access Request Catalog provides robust and rich functionality by default, there may be scenarios where you need to extend the Catalog and customize it to meet your business needs.

The following scenarios illustrate common scenarios where the Catalog may require customization.

MyCorp would like to add additional attributes, such as Cost to Line of Business and License Required, to give the requester an idea about the cost that would be incurred by the Line Of Business, when the requested item was granted. To support this scenario, the Catalog System Administrator extends the Catalog and adds two additional attributes, Cost to Line of Business and License required. Next, the administrator customizes the Catalog search results and Catalog item details page.

Note:

In the request catalog, only String type of UDF can be created. If you mark that attribute as searchable attribute, it will be of size 256 Char. If it is not a searchable attribute, then it will be of size 2000 char. You cannot mark a non-searchable attributes to searchable.
MyCorp would like to show the Risk associated with an entitlement as part of Catalog search results. To support this scenario, the Catalog System Administrator customizes the Catalog search results and adds the item risk as an image widget.

These customizations will be implemented by System Integrators or the customer's own IT staff and need to be moved to Test and to Production. Figure 12-2 shows the high-level process of moving customizations from Test to Production for the Catalog.

Figure 12-2 Test to Production Process for Catalog

Description of "Figure 12-2 Test to Production Process for Catalog"

Catalog customizations have three components:

ADF customizations

ADF customizations include Catalog UI customizations including search results, item details, cart details and Catalog attributes added or modified using the Form Designer. These customizations should be done within a Sandbox session. For more information on Sandboxes, please refer to Test to Production Procedures for Catalog Customizations
Oracle Identity Manager metadata customizations

When you add new attributes to the Catalog entity or modify an existing attribute and change its properties, additional metadata is generated in Oracle Identity Manager. For example, if a new attribute, Secondary Approver, is added to the Catalog entity using the Catalog system entities, Oracle Identity Manager adds a database column corresponding to the attribute. If the attribute is searchable, Oracle Identity Manager stores additional metadata. These customizations should be moved from Test to Production using the Deployment Manager.
Data Migration

The Catalog needs to be populated with relevant information, after adding/ modifying attributes in the Catalog to make the Catalog business-friendly and provide enough information so that users can use the Catalog effectively. Once this additional information, also referred to as the Glossary, has been reviewed and approved, it needs to be moved to Production.

12.4.2 Test to Production Procedures for Catalog Customizations

Catalog customizations can be imported and exported by using the sandbox and the Deployment Manager.

This section describes the steps to perform for moving the Catalog definition from Test to Production. It consists of the following steps:

12.4.2.1 About Test to Production Procedures for Catalog Customizations

Depending upon the type of customization done, you may need either one or both the steps. Use Figure 12-2 to make a determination of which steps to carry out.

Table 12-2 Catalog Customization Steps

Customization	Sandbox required	Deployment Manager required
Adding/ Modifying a seeded Catalog attribute	Yes	Yes
Adding/ Modifying a Catalog UDF	Yes	Yes
Customizing Catalog UI	Yes	No
Populating Catalog	No	No

12.4.2.2 Exporting Using the Sandbox and Deployment Manager

This section describes about exporting Catalog definition using the sandbox and deployment manager in the following topics:

12.4.2.2.1 Exporting Using the Sandbox

To move the ADF customizations from Test to Production, follow the steps given below:

Login to Oracle Identity System Administration as a member of the System Administrator role.

Note:

In scenarios where you need to switch between the Self Service (or Identity) and System Administration interfaces and the Oracle Identity Manager deployment is not protected by Single Sign On, you must log out of one console before logging in into another.
Click Sandbox and select the Sandbox to be exported.
Click Export Sandbox. A sandbox can be exported as a file for transporting, sharing, and other usages where packaging it as a file is required.
Specify a file location for the zip file created.

12.4.2.2.2 Exporting Using the Deployment Manager

To export the Oracle Identity Manager metadata from Test to Production, follow the steps given below:

Login to Oracle Identity System Administration as a member of the System Administrator or System Configurator role.
In the left pane, under System Configuration, click Export.
Select Catalog Metadata as the object to be exported.
Enter * in the search field and click Search.
Follow the steps to generate the Deployment Manager XML.

Note:

Perform the following optional steps as a best practice:

Backup/Check-in the sandbox zip file and the Deployment Manager XML as a single file into a source code control system like Subversion, SourceSafe, and so on.
Repeat the steps above in the target (Production) environment and backup the Catalog entity and the Catalog UI.

12.4.2.3 Importing Using the Sandbox and Deployment Manager

Importing the customizations should be done in the reverse order. This is required since the ADF customizations expect the Oracle Identity Manager metadata to be present, when the ADF customizations are imported. This section contains the following:

12.4.2.3.1 Importing Using the Sandbox

To move the ADF customizations from Test to Production:

Login to Oracle Identity System Administration as a member of the System Administrator role.

Note:

In scenarios where you need to switch between the Self Service (or Identity) and System Administration interfaces and the Oracle Identity Manager deployment is not protected by Single Sign on, you must log out of one console before logging in into another.
Click Sandbox and then click Import Sandbox.
In the dialog, select the file to be imported.
In the left pane, under System Configuration, Click Import.
In the Sandbox Manager, select the sandbox and click Publish Sandbox.
Logout and log back in to view and verify the changes.

12.4.2.3.2 Importing Using the Deployment Manager

To import the Oracle Identity Manager metadata from Test to Production:

Login to Oracle Identity System Administration as a member of the System Administrator or System Configurator role.
In the left pane, under System Configuration, click Import.
In the File browser popup, select the Deployment Manager XML file to be imported.
Follow the wizard steps to import the XML.
For detailed steps see, Importing Deployments

12.4.3 Limitations of the Test to Production Procedures

Some limitations of the Test to Production process of the catalog are related to sandbox usage and the Deployment Manager.

There are some limitations in the Test to Production process for the Catalog, which including the following:

All ADF customizations must be done within a single sandbox session. While you can have multiple sandboxes, only one sandbox can be active at a time and as a result, changes in the System Administration Console i.e. Catalog entity extension and those done in the Identity Console, that is, Catalog UI customization, must be done in the same sandbox.
Changes done outside a sandbox or done either before creating and activating a sandbox or after, are not visible in the sandbox.
Once you publish a sandbox, you cannot export it or revert it. As a result, you must export the sandbox while it is still activated and not published and also ensure that you back your customizations before you import and publish a sandbox.
Deployment Manager imports are committed immediately. There is no rollback capability in the Deployment Manager.

12.5 Troubleshooting Access Request Catalog

Some of the troubleshooting requirements for the Access Request Catalog are related to catalog synchronization, catalog security, catalog search, and request failure.

This section describes the troubleshooting procedures to be followed while resolving issues with the Access Request Catalog. It contains the following topics:

12.5.1 Catalog Synchronization Issues

Catalog synchronization issues occur when roles, application instances and entitlements are not visible in the Access Request Catalog.

Use the flow charts given below to troubleshoot synchronization issues for each of three Catalog item types that can be requested.

Note:

Harvesting job picks up the data for harvesting on the basis of the Update date parameter. If the update is blank, then all the records are fetched for processing.However, if the user has specified some date in the Update date parameter, only that data is processed which is created or updated after the given date.

Troubleshooting synchronizing Roles with the Catalog

The synchronization of Roles with the Catalog is real-time in nature. When a role is created, it is published to the Catalog immediately as long as it does not belong to the Oracle Identity Manager Roles category.

Note:

The Oracle Identity Manager Roles role category is meant for Oracle Identity Manager usage only. Customers should not use this category for their enterprise Roles.

In a new Oracle Identity Manager installation, enterprise roles created by customers will be available in the Catalog and the visibility will be based on the organization scoping. In an upgraded environment, customers will have to run the Catalog Synchronization job in a bootstrap mode to publish the existing roles to the Catalog. New roles, created after upgrade, will be available in the Catalog immediately.

Figure 12-3 shows a diagnostic flowchart that customers can use to troubleshoot scenarios where the roles created in Oracle Identity Manager are not visible in the Catalog.

Figure 12-3 Catalog Synchronization Diagnostic Flowchart

Description of "Figure 12-3 Catalog Synchronization Diagnostic Flowchart"

Troubleshooting synchronizing Application Instances with the Catalog

The synchronization of Application Instances with the Catalog is controlled by the Catalog Synchronization job. Application Instances require more configuration (than enterprise roles) and hence are not synchronized immediately with the Catalog.

Figure 12-4 shows a diagnostic flowchart to be followed when troubleshooting issues related to synchronizing application instances with the Catalog.

Figure 12-4 Trouble Shooting Synchronization Application Instances Flowchart

Description of "Figure 12-4 Trouble Shooting Synchronization Application Instances Flowchart"
Troubleshooting synchronizing Entitlements with the Catalog

Figure 12-5 Trouble Shooting Synchronizing Entitlements Flowchart

Description of "Figure 12-5 Trouble Shooting Synchronizing Entitlements Flowchart"

12.5.2 Catalog Security Issues

Catalog security issues might occur because of the type of security model used for the deployment.

Catalog security is driven by two factors:

The security model that uses Organization-based scoping for users, roles, application instances and entitlements. This security model controls what items a requester can see in the Catalog search results and the users who can be added as target users.
The security model that is not scoped by organization and is used for global Admin Roles such as Catalog Administrator.

Typical issues with Catalog security are:

Requesters cannot see the Catalog item even though they have entered the correct search keyword.
Requesters are not able to add target users to the request
Requesters are not able to provide additional information for application instance requests
Requesters cannot see Catalog Item details such as Approver User, Approver Role, Fulfillment User, and Fulfillment Role.
Catalog Administrators do not see the Catalog Item in an edit mode and are not able to edit the Catalog Item
Catalog Administrators are not able to create Request Profiles

Figure 12-6 shows a diagnostic flow chart to be followed to troubleshoot issues with Catalog security.

Figure 12-6 Diagnostic Flowchart With Security Issues

Description of "Figure 12-6 Diagnostic Flowchart With Security Issues"

12.5.3 Catalog Search Issues

Some of the catalog search issues can be related to text syntax and text indexing.

Figure 12-7 shows a diagnostic flow chart to be followed to troubleshoot issues with Catalog search.

Figure 12-7 Catalog Search

Description of "Figure 12-7 Catalog Search"

12.5.4 Common Reasons for Request Failure

When the associated operations specified in a request fail to execute, the request cancels any pending operations and moves the request to the Request Failed stage. Clicking the Request Failed hyperlink displays the reason for request failure.

A request can fail for any one of the following reasons:

If you are requesting a role, then your request can fail due to an SoD violation.
If you are requesting an application instance and that application instance depends on another application instance, then the request moves to 'Request Approved Fulfillment Pending' status because the parent application instance is not provisioned. For example, to successfully provision a user to a Microsoft Exchange account, the user must have a Microsoft Active Directory account in the domain controller that is managing the users of the Exchange server.

In addition to the preceding reasons, failures can occur because of incorrect password, password policy violation, target system being unavailable, and so on.