20 Moving From Test to Production
This chapter describes T2P migration for Oracle Identity Manager. It contains the following topics:
20.1 About Test to Production Migration
Configurations and customizations in Oracle Identity Manager can be migrated from one deployment to another deployment. For example, you might want to migrate configurations and customizations from a test environment to a production environment. This is referred to as Test to Production (T2P).
With T2P, you use the Deployment Manager tool for exporting and importing Oracle Identity Manager configurations and customizations. This is used when target/production setup is already configured and you want to move certain specific artifacts/configuration incrementally into the target setup.
20.2 Migrating Incrementally Using the Deployment Manager
Incremental migration of deployments by using the Deployment Manager involves importing and exporting deployments, and understanding the best practices and troubleshooting of the Deployment Manager.
This section discusses how to migrate Oracle Identity Manager incrementally using the Deployment Manager. It contains the following topics:
Note:
Only the system administrator can use the Deployment Manager to import and export deployments.
20.2.1 About the Deployment Manager
The Deployment Manager is a tool for exporting and importing Oracle Identity Manager configurations. Usually, you use the Deployment Manager to migrate a configuration from one deployment to another, (for example, from a test to a production deployment) or to create a backup of your system.
You can save some or all of the objects in your configuration. Exporting your configuration lets you develop and test it in a test environment. You can then import the tested objects into your production environment. You can export and import an object and all of its dependent and related objects at the same time. Alternatively, you can export and import each object individually.
The Deployment Manager allows you to retrieve configuration information and binary data from the source system, store the information in an XML file, and then import the information from the XML file to the target system. The binary data includes plug-ins, Java archives (JARs), and custom resource bundles.
You must import an exported object into the same type of repository.
Note:
You can also use the sandbox feature to migrate configurations and customizations from one deployment to another. For information about working with sandboxes, see Managing Sandboxes in Developing and Customizing Applications for Oracle Identity Governance.
20.2.2 Features of the Deployment Manager
The Deployment Manager enables you to import and export supported configuration artifacts along with additional comments and information about the exported files.
The Deployment Manager helps you migrate Oracle Identity Manager deployments from one server environment to another, such as from a testing environment to a staging environment or from a staging environment to a production environment.
The Deployment Manager enables you to:
-
Update individual components of a deployment in different test environments
-
Identify objects that are associated with exported components, so that those resources can be included
-
Provide information about exported files
-
Add comments
The Deployment Manager handles the following types of configuration artifacts:
-
Access Policy
-
Admin Role
-
Application Instance
-
Application Template
-
Approval Policy
-
Attestation Process
-
Catalog metadata
-
Certification Configuration
-
Certification Definition
-
Custom resource bundle
-
Data Object Definition
-
E-mail Definition
-
Entity Adapter (Deprecated)
-
Error Code
-
Event Handler
-
Generic Connector
-
GTC Provider
-
Identity Audit configuration
-
Identity Audit Rule
-
Identity Audit scan definition
-
IT resource definition
-
IT resource
-
JAR
-
Lookup
-
Notification templates
-
Orchestration Event handler
-
Org Metadata
-
Organization
-
Password Policy
-
Policy
-
Plugin
-
Prepopulate Adapter
-
Process
-
Process Form
-
Provisioning workflows and process task adapters
-
Request dataset
-
Resource
-
Risk configuration
-
Role metadata
-
Role
-
Rule-deprecated
-
Scheduled job
-
Scheduled task
-
System property
-
Task Adapter
-
User metadata
Note:
-
On the source deployment, the following artifacts might contain references to specific users, roles, application instances, entitlements, or organizations:
-
Certification definitions
-
Policies
-
Identity Audit configurations
-
Identity Audit scan definitions
These references are scrubbed when you export the artifacts. You must open and update these artifacts on the target deployment. For example, the remediator name for the Identity Audit policy is deleted when it is exported, and must be reselected on the target environment. An artifact that lacks specific references may cause errors in the deployment.
-
-
All rules other than Identity Audit Rules can only be exported and imported with their policy and cannot be exported or imported independently.
-
If you use Connector Installer to create an application, and if you then import the application to another environment using the Deployment Manager’s Application Instance artifact, then you must import the scheduled jobs by using the Deployment Manager. However, if you create an application by using the application onboarding feature in Identity Self Service, then the scheduled jobs are automatically created and do not have to be imported.
The Deployment Manager has the following limitations:
-
Merge Utility: The Deployment Manager is not a merge utility.
The Deployment Manager cannot mix modifications that are made in both production and test environments. It replaces the object in the target system with the object in the XML file.
-
Version Control Utility: The Deployment Manager does not track versions of imported files, and does not provide rollback functionality.
You can use the Deployment Manager only to move data between environments.
20.2.3 Enabling Deployment Manager in SSL Mode
When you enable Secure Sockets Layer (SSL) for the Oracle Identity Manager server, you must provide the URL host and port as the OIMFrontEndURL for the Discovery MBean, log in to Identity System Administration using the HTTPS protocol using the appropriate port, and clear the browser cache.
To enable Deployment Manager in SSL mode:
-
Enable SSL for the OIM server. You can follow the steps given below to enable SSL:
-
In the WebLogic Server Administration Console, click Environment and select Servers. The Summary of Server page opens.
-
On the Configuration tab, select the server name (for example, OIM_Server1). The Setting page for the server opens.
-
On the General tab, select the SSL Listen Port Enabled check box. Enter the SSL Listen Port details.
-
Click Save.
-
-
Make sure to provide the URL host and port value as OIMFrontEndURL for Discovery MBean.
-
Oracle recommends that you log in to Oracle Identity System Administration using the HTTPS protocol and the appropriate port. If the HTTPS certification is invalid, accept the default certificate.
-
Oracle recommends that you clear the browser cache before you access Oracle Identity System Administration. Otherwise, JavaScript and HTML files may be cached.
20.2.4 About Exporting Deployments
You can export objects from your Oracle Identity Manager system and save them in an XML file. The Deployment Manager has an Export Wizard that lets you create your export file.
Add objects one type at a time: for example, roles, then forms, then processes.
Note:
Application instances are exported and imported without the datasets. The datasets are migrated as a part of UI customization.
If you select an object that has child objects or dependencies, you have the option to add dependency. When you have all the objects you want, the Deployment Manager saves them in a single XML file.
When user-defined fields are associated with a specific resource object, the Deployment Manager considers them dependencies only if the values of the fields are not empty.
20.2.5 Exporting Deployments
Use the Export Configuration page in Identity System Administration to export a deployment.
To export a deployment:
-
Login to Oracle Identity System Administration.
-
In the left pane, under System Configuration, click Export to open the Export Configuration page.
-
To search for an object, enter the name of the object.
You can use an asterisk (*) as a wildcard in the name search field. An asterisk represents zero or more occurrences of an alphanumeric character. For example, you can enter Role*, *Role, *OIM*, and similar types of searches. By default, an asterisk is appended at the end of an entered string.
-
Select Type from the list, and click the Search icon. The search result appears in the Available Entities table.
By default, Type is set to All. The objects supported by the Deployment Manager for migration are available for exporting. For the list of objects supported by the Deployment Manager for migration, see Features of the Deployment Manager.
Note:
When you search for an entity name across all entity types, then the number of records displayed is controlled by value set for DMGlobalSearchResultSize system property. For more information on this system property, see Default System Properties in Oracle Identity Governance.
To narrow your search, choose the entity name or entity type from the list.
-
In the Available Entities table, select the checkbox next to the entity to be exported. The entity is moved to the Selected Entities table. You can select multiple entities.
To remove any entity from the Selected Entities table, click Remove.
To navigate to a page, click the page number at the bottom of search table or enter a page number in the page number text. Use the Rows Displayed option to specify the number of rows in the search table.
Note:
You can perform multiple searches and add any combination of entities to the Selected Entities table to build a list of exportable objects. -
Click Next, or click Export Options to open the Export Options page.
-
If dependent entities are to be downloaded, set Dependency to Yes. Otherwise, set to No.
By default, Dependency is set to Yes.
-
Click Next or click Summary to open the Summary page.
-
Make sure that all the required entities are selected, and that they appear in the Selected Entities panel. Make sure that the dependency information appears in the Export Options panel, and then click Export to open the Export window.
-
In the Export window, enter a description for the file. This description appears when the file is imported.
-
Click Export to open the Save As dialog box.
-
Enter a file name or browse to find a location.
-
Click Save.
20.2.6 About Importing Deployments
When objects have been exported into an XML file by using the Deployment Manager, you can use the Deployment Manager to import these objects into Oracle Identity Manager.
The Deployment Manager ensures that the dependencies for the objects that you are importing are available either in the import or in your system. When you import, you can substitute an object that you are importing for one in your system. For example, you can substitute a group that is specified in the XML file for a group in your system.
Note:
-
If a user belongs to a group to which the Import menu item has been assigned, then that user must also have the necessary permissions for the objects that the user wants to import. Without these object-specific permissions, the Import operation fails. Only System Administrators can see Deployment Manager menu items in the UI.
-
When you use Deployment Manager to import more than a thousand resources, process definitions, parent forms, child forms, access policies, roles, and rules, the size of the EIF table increases. The amount of data in this table can be reduced by running a simple SQL query such as Delete from EIF.
20.2.7 Importing Deployments
To import a deployment, use the Import Configuration page in Identity System Administration.
Note:
Before importing data that contains references to menu items, you must first create the menu items in the target system.
20.2.8 Best Practices for Using the Deployment Manager
Best practices for using the Deployment Manager include exporting related groups of objects at once, using logical naming conventions for form versions, providing clear export descriptions, backing up the database, and importing data when system activity is low.
This section includes the following topics:
20.2.8.1 Do Not Export System Objects
Avoid exporting or importing system objects unless it is absolutely necessary. (Examples of system objects include Request, Xellerate User, and System Administrator.) Exporting system objects from the testing and staging environments into production can cause problems. Whenever, possible, exclude system objects when you export or import data.
You may want to export or import system objects when, you define trusted source reconciliation on Xellerate User resource objects, or in similar situations.
Caution:
The Deployment Manager keeps track of imported components and structures, but does not keep track of completed imports. After an import is completed, you cannot revert to a previous version of the imported component.
20.2.8.2 Exporting Related Groups of Objects
Oracle recommends that you use the Deployment Manager to export sets of related objects. A unit of export should be a collection of items that you want to group together.
Avoid exporting everything in the database in one operation, or exporting items one at a time. For example, suppose that you manage integration between Oracle Identity Manager and a target system that includes processes, resource objects, adapters, IT resource type definitions, IT resource definitions, and scheduled tasks. In this environment, you should create groups of related objects before you export items.
For example, if you use the same e-mail definitions in multiple integrations, export the e-mail definitions as one unit, and the integrations as a different unit. You can then import changes to e-mail definitions independently of changes to the target system integration. Or, if multiple resources use the same IT resource type definition, you can export and import the type definition separately from other data.
You can import multiple sets of exported data once. For example, you can import a resource object definition, an e-mail definition, and an IT resource type definition in a single operation.
20.2.8.3 Using Logical Naming Conventions for Versions of a Form
When you revise forms multiple times before you export them, avoid generic names, such as, "v23," to differentiate versions of a form. Instead, create meaningful names, such as, "Before Production" or "After Production Verification." Do not use special characters, such as double quotation marks, in version names.
20.2.8.4 Exporting Root to Preserve a Complete Organizational Hierarchy
When you export a leaf or an organization in an organizational hierarchy, only one dependency level is exported. To export a complete organizational hierarchy, export the root of the hierarchy.
20.2.8.5 Providing Clear Export Descriptions
The Deployment Manager records some information automatically, including the date of the export, who performed the export, and the source database. You should also provide a meaningful description of the content of the export, such as, "resource definition after xxx attributes added in reconciliation." This informs the importer of the file of the contents of the item being imported.
20.2.8.6 Checking Dependencies Before Exporting Data
The wizard in the top right pane displays the resources that must be available in the target system.
Consider the following:
-
If the resources are already available in the target system, they do not need to be exported.
-
If the resources are new (not in the target system), they must be exported.
-
If the target system does not include the resources, such as lookups, IT resource definitions, or others that are reused, then record the data and export it in a separate file so it can be imported if necessary.
Note:
When you export a resource, groups with Data Object permissions on that form are not exported with the resource.
20.2.8.7 Matching Scheduled Task Parameters
Scheduled tasks depend on certain parameters to run properly. You can import scheduled task parameters to the production server. Table 20-1 shows the rules for determining how to import scheduled tasks. Note that parameters may be available for tasks that no longer reside on the target system.
Table 20-1 Parameter Import Rules
Parameter Exists in Target System | Parameter Exists in the XML File | Action Taken |
---|---|---|
Yes |
No |
Remove the parameter from the target system. |
No |
Yes |
Add the parameter and current value from the XML file. |
Yes |
Yes |
Use the more recent value of the parameter. |
20.2.8.8 Deployment Manager Actions on Reimported Scheduled Tasks
One of the objects that you can import by using the Deployment Manager is a scheduled task. Typically, you import a scheduled task into your Oracle Identity Manager environment and later change the values of the scheduled attributes to meet your production requirements. However, if you import the same scheduled task a second time into the same Oracle Identity Manager server, the Deployment Manager does not overwrite the attribute values in the database. Instead, the Deployment Manager compares the attribute value of the reimported XML file to any corresponding attribute values in the database.
The following table summarizes the actions performed by the Deployment Manager when a scheduled task is reimported:
Does the Scheduled Task have attribute values in the XML file being imported? | Are there any corresponding attribute values in the database? | Deployment Manager Action |
---|---|---|
Yes |
No |
Store attribute values in the database |
No |
Yes |
Delete existing attribute values in the database |
Yes |
Yes (newer attribute values indicated by time stamp) |
No change in the database |
Yes (new attribute values indicated by time stamp) |
Yes |
Update the database with the new attribute values |
20.2.8.9 Compiling Adapters and Enable Scheduled Tasks
Adapters are automatically recompiled after being imported if their Java dependencies (classes) were previously imported. After the import, the adapter status is set to OK. If the Java dependencies were not imported before the adapter was imported, then after you import the classes and adjust the task attributes, manually recompile the adapters and enable the scheduled tasks.
20.2.8.10 Checking Permissions for Roles
When you export roles, the role permissions on different data objects are also exported. However, when you import data, permissions for missing data objects are ignored. If you are exporting the role as a way of exporting the role permission setup, then check the warnings carefully to ensure that the permission requirements are met. For example, if a role has permissions for objects A, B, and C, but the target system only has objects A and B, the permissions for object C are ignored. If object C is added later, the role permissions for C must be added manually, or the role must be imported again.
When you export a role that has permissions for viewing certain reports, ensure that the reports exist in the target environment. If the reports are missing, then consider removing the permissions before exporting the role.
20.2.8.11 Creating a Backup of the Database
Before you import data into a production environment, back up the database. This enables you to restore the data if anything goes wrong with the import. Backing up the database is always a good precaution before significant changes.
Note:
When you import forms and user-defined fields, you add entries to the database. These database entries cannot be rolled back or deleted. Before each import operation, ensure that the correct form version is active.
20.2.8.12 Importing Data When the System Is Quiet
You cannot complete an import operation in a single transaction because it includes schema changes. These changes affect currently running transactions on the system. To limit the effect of an import operation, temporarily disable the Web application for general use and perform the operation when the system has the least activity, such as, overnight.
20.2.8.13 Exporting and Importing Data in Bulk
The Deployment Manager is not a tool for data movement or for the migration of large volumes of data. Use your judgment when you use the Deployment Manager to export or import objects. When the volume of data is large, use other bulk tools to export and import entities, such as users, organizations, and roles.
To avoid exporting or importing these kinds of entities, ensure that users, roles, and organizations are always loaded, synchronized, or both before you move configuration objects such as policies, rules, application instances, and connector configuration.
Note:
When you export or import large volumes of data, timeouts may occur in the UI.
20.2.8.14 Exporting Entity Publications
When you use the Deployment Manager to export or important entity, any publication previously associated to the entity is removed. If you do not export the publication, no publication is assigned by. Therefore, when you import an admin role (for example) that is published to an organization in the source environment, the admin role's publication information is lost in the target environment. You must import the entity publication along with the admin role.