1 Using the Deployment Manager

The Deployment Manager enables developers to move an Oracle Identity Manager deployment from one server to another while minimizing the problems that often occur during a migration. The Deployment Manager allows multiple developers to work on different parts of a deployment and upload only the part of the deployment that they have changed, rather than waiting for the entire deployment to be rebuilt.

Caution:

The most recently imported data overwrites the previous data. Developers should not export data that can overwrite the work of another developer.

This chapter discusses the following topics:

• Features of the Deployment Manager

• Export System Objects Only When Necessary

• Export Related Groups of Objects

• Group Definition Data and Operational Data Separately

• Use Logical Naming Conventions for Versions of a Form

• Export Root to Preserve a Complete Organizational Hierarchy

• Provide Clear Export Descriptions

• Check All Warnings Before Importing

• Check Dependencies Before Exporting Data

• Match Scheduled Task Parameters

• Compile Adapters and Enable Scheduled Tasks

• Export Entity Adapters Separately

• Check Group Permissions

• Back Up the Database

• Import Data When the System Is Quiet

• Update the SDK Table

• Remove Data Object Fields Before Importing Event Handlers as Dependencies

1.1 Features of the Deployment Manager

The Deployment Manager helps you to 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 associated with components to be exported, so that those resources can be included

• Provide information about exported files

• Add comments

The Deployment Manager handles the following types of information:

• Resource objects

• Adapters

• IT resource types

• User-defined forms

• Organizations

• User-defined field definitions

• Rule definitions

• E-mail definitions

• System and error codes

• Lookup definitions

• User groups

• Password policies

• Access policies

• Scheduled tasks

The following are important limitations of the Deployment Manager:

• Merge Utility: The Deployment Manager is not a merge utility.

  It cannot handle modifications done in both production and test environments. It replaces the object in the target system with that 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 only use it as a means to move data between environments.

• Code Moving: The Deployment manager does not move JAR files in the JavaTasks directory or other locations.

  You must do this manually.

• Custom Labels Move: The Deployment Manager does not move labels defined in the customResources.properties file or the property files in the connectorResources directory. You must do this manually.

1.2 Export System Objects Only When Necessary

You should export or import system objects, for example, Request, Xellerate User, and System Administrator, only when it is absolutely necessary. Exporting system objects from the testing and staging environments into production can cause problems. If possible, exclude system objects when exporting or importing data.

You may want to export or import system objects when, for example, you define trusted source reconciliation on Xellerate User resource objects.

Caution:

The Deployment Manager keeps track of imported components and structures, but not of completed imports. After an import is completed, you cannot roll it back to a previous version. A new import is required.

1.3 Export 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 logical 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 an integration between Oracle Identity Manager and a target system that includes processes, resource objects, adapters, IT resource type definitions, IT resource definitions, scheduled tasks, and so on. For this environment, you should create groups of related objects before exporting.

For example, if you use the same e-mail definitions in multiple integrations, you should export the e-mail definitions as one unit, and the integrations as a different unit. This enables you to import changes to e-mail definitions independently of target system integration changes. 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 one or more sets of exported data at a time. For example, you can import a resource object definition, an e-mail definition, and an IT resource type definition in a single operation.

1.4 Group Definition Data and Operational Data Separately

You must group and export definition data and operational data separately.

You configure definition data in the testing and staging environment. Definition data includes resource objects, processes, and rules.

You typically configure operational data in the production environment. Operational data includes groups and group permissions. The testing and staging servers usually do not include this data.

By grouping data according to where it is changed, you know what data goes to testing and staging, and what goes to production. For example, if approval processes are changed in production, you should group approval processes and export them with other operational data.

1.5 Use Logical Naming Conventions for Versions of a Form

You often revise forms multiple times before exporting them. Avoid generic names, for example, "v23," to differentiate among versions of a form. Create meaningful names, for example, "Before Production" or "After Production Verification." Do not use special characters, including double quotation marks, in version names.

1.6 Export 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, you must export the root of the hierarchy.

1.7 Provide Clear Export Descriptions

The Deployment Manager records some information automatically, for example, the date of the export, who performed the export, and the source database. You must also provide a meaningful description of the content of the export, for example, "resource definition after xxx attributes added in reconciliation." This informs the importer of the file of the contents of the data being imported.

1.8 Check All Warnings Before Importing

When importing information to the production environment, check all the warnings before completing the import operation. Treat each warning seriously.

1.9 Check Dependencies Before Exporting Data

The wizard in the top right pane shows resources that must be available in the target system.

Consider the following types of dependencies:

• 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.

1.10 Match Scheduled Task Parameters

Scheduled tasks depend on certain parameters to run properly. You can import scheduled task parameters to the production server. Table 1-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 1-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.

1.11 Compile Adapters and Enable Scheduled Tasks

After an import operation, the adapters are set to recompile and the scheduled tasks are disabled. This prevents these items from running before their associated resources and settings are configured.

After importing the classes and adjusting the task attributes, manually recompile the adapters and enable the scheduled tasks.

1.12 Export Entity Adapters Separately

Entity adapters are modified to bring just the entity adapter, not its usage. If you want to export the usage of an entity adapter, you must separately export each use with a data object by exporting the data object. If you export a data object, all the adapters and event handlers attached to the object along with the permissions on the object are exported. You must pay special attention when exporting data objects. For example, to export a form, you should also add the data object corresponding to the form. This ensures that the associated entity adapters can use the form.

1.13 Check Group Permissions

When you export groups, group permissions on different data objects are also exported. However, when you import data, any permissions for missing data objects are ignored. If the group is exported as a way of exporting group permission setup, check the warnings carefully to ensure that permission requirements are met. For example, if a group 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 group permissions for C must be added manually, or the group must be imported again.

When you export groups that have permissions for viewing certain reports, ensure that the reports exist in the target environment. If the reports are missing, consider removing the permissions before exporting the group.

1.14 Back Up 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 making 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.

1.15 Import 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, for example, overnight.

1.16 Update the SDK Table

The SDK table contains metadata definitions for user-defined data objects. When you import data from an XML file into the SDK table, the values in the SDK_SCHEMA column might be modified with the schema name of the source system where the XML file was created. For this reason, after you import data from an XML file into the SDK table, you must check the schema name in the SDK_SCHEMA column, and if necessary, manually change it to the schema name on the target system where the Oracle Identity Manager database is running. To update the schema name in the SDK_SCHEMA column, run a SQL query similar to the following with SQL*Plus on Oracle Database installations or with SQL Query Analyzer on Microsoft SQL Server installations:

UPDATE SDK SET SDK_SCHEMA='target system schema name'

If you do not update the schema name in the SDK_SCHEMA column, an error similar to the following might be generated when you import other XML files that modify user-defined field (UDF) definitions:

CREATE SEQUENCE UGP_SEQ
java.sql.SQLException: ORA-00955: name is already used by an existing object

1.17 Remove Data Object Fields Before Importing Event Handlers as Dependencies

The Deployment Manager does not import event handlers that include data object fields if the event handlers are imported as dependencies. For this reason, you must remove the data object fields from any event handlers that you want to import as dependencies with the Deployment Manager.