| Oracle® Identity Manager Best Practices Guide Release 9.0 Part Number B32139-01 |
|
|
View PDF |
| Oracle® Identity Manager Best Practices Guide Release 9.0 Part Number B32139-01 |
|
|
View PDF |
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: Be aware that the most recently imported data overwrites the previous data. Developer should not export data that can overwrite the work of another developer. |
This chapter discusses the following topics:
The Deployment Manager helps migrate Oracle Identity Manager deployments from one server environment to another, such as from a test environment to a staging environment, or from a staging environment to a production environment.
The Deployment Manager provides the following benefits:
Updating individual components of a deployment in different test environments
Identifying objects associated with components to be exported, so that those resources can be included
Providing information on exported files
Allowing the exporter to 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
Email 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 changes done in both production and test environments. It will replace the object in target system with what is in the XML.
Version Control Utility: 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: Deployment manager does not move .jar files in JavaTasks or other locations.
You must do this manually.
Custom Labels Move: 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.
Only export or import system objects, for example, Request, Xellerate User, and System Administrator, when it is absolutely necessary. Exporting them from testing and staging environments into production can cause problems. If possible, exclude system objects when exporting or importing data.
Some circumstances might require you to export or import system objects, for example, when defining Trusted Source Reconciliation on Xellerate Users resource 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 email definitions in multiple integrations, you should export the email definitions as one unit, and integrations as different unit. This enables you to import changes to email 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, email definition, and IT resource type definition in one operation.
You should group and export definition data and operational data separately.
You configure definition data in test and staging. Definition includes resource objects, processes, rules, and so on.
You typically configure operational data in production. Operational data includes groups and group permissions. The test and staging servers normally do not include this data.
By grouping data according to where it is changed, you know what data goes to test 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.
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 Pre Production" or "After Production Verification". Do not use special characters, including double quotes, in version names.
|
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. |
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.
The Deployment Manager records some information automatically, for example, 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, 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.
When importing to production, check all the warnings before completing the import. Treat each warning seriously.
The wizard in the top right pane shows resources that must be available in the target system.
The following types of dependencies may occur:
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 may or may 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.
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.
After an import operation, adapters are set to recompile and scheduled tasks are disabled. This prevents these items from running prior to configuring their associated resources and settings.
After importing the classes and adjusting the task attributes, manually recompile adapters and enable scheduled tasks.
Entity adapters are modified to bring just the entity adapter, not their usage. You must separately export each use of an entity adapter with a data object by exporting the data object. Exporting a data object exports all the adapters and event handlers attached to the object along with the permissions on the object. You need to 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 associated entity adapters can use the form.
When exporting groups, group permissions on different data objects are also exported. However, when importing 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 make sure 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 has to be imported again.
Back up the database before importing data into a production system. 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 importing, be sure that the correct form version is active. |
You cannot complete an import operation in a single transaction because the import includes schema changes. These changes affect currently running transactions on the system. To limit the impact of an import operation, separate the web application from general use and perform the operation when the system has the least activity, for example, overnight.
