| Oracle® Identity Manager Best Practices Guide Release 9.0 B25937-01 |
|
 Previous |
 Next |
| Oracle® Identity Manager Best Practices Guide Release 9.0 B25937-01 |
|
Previous |
Next |
The Deployment Manager enables developers to move a deployment from one server to another while minimizing the problems normally associated with such a migration. The Deployment Manager also 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: While the Deployment Manager allows multiple developers to export and import their work, be aware that the most recent import will overwrite the previous one. It is therefore important that each developer not export data that could overwrite the work of another developer. |
This chapter describes how you can best use the Deployment Manager. It covers 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:
Allows individual components of the deployment to be updated in different test environments
Identifies objects associated with components to be exported, so that those resources can be included
Provides information on exported files and allows the exporter to add comments
The types of information managed by the deployment manager include:
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
Before you can fully capitalize on the Deployment Manager functionality, you must understand the following limitations:
Merge Utility: The Deployment Manager is not a Merge utility and cannot handle changes done in both production and test environments. It will replace the object in target system with what is there in the XML.
Version Control Utility: Deployment Manager does not keep track of versions of import, and does not provide the rollback functionality. You can only use it as a means to move data between environments.
Code Moving: Deployment manager does not move the .jar files placed in JavaTasks or other. You must do this manually.
System objects such as Request, Xellerate User, and System Administrator should not be exported or imported unless absolutely necessary. Exporting them from testing and staging environments into production might result in unforeseen problems. Exercise utmost caution, and if possible exclude them, while performing an export or import.
Some circumstances might require you to export and import them, however. For example, when defining Trusted Source Reconciliation on Xellerate Users resource objects.
It is much better to use the Deployment Manager to export related objects such as groups, instead of trying to export everything in the database or items one at a time. For example, an integration with one target system that includes processes, resource objects, adapters, IT resource type definitions, IT resource definitions, scheduled tasks, lookups, error codes, email definitions, and so forth should first have its related objects grouped before exporting.
Define the unit of export as a set of related items. For example, if email definitions are reused with multiple integrations, export the email definitions as one unit, and integrations as different unit. This way, changes to email definitions can be imported independent of target system integration changes. As another example, if multiple resources use the same IT resource type definition, export and import the type definition separately. A unit of export is the collection of logical items that you want to group together.
During import you can use one or more of exports together. For example, you can import the resource object definition, email definition, and IT resource type definition together.
Definition data and Operational data should be grouped and exported separately, because definition data is defined in test and staging, while operational data is defined in production.
Definition includes resource objects, processes, rules, and so forth. Operational data includes groups and group permissions and is normally edited in the production environment. The test and staging servers normally do not include all of this data.
By grouping the different types of data according to where they are changed in the server system, you simplify your exports by knowing which ones go to test and staging, and which go directly to production.
For example, if resource objects and provisioning processes are developed in the test and staging environment, and then unchanged in the production environment, and the approval processes are changed in production, then the approval processes should be grouped and exported with the operational data.
Forms often go through many revisions before they are exported. Rather than leave them with names like "v23", it is better to rename them something that is easily recognized later on, such as "Before Pre Production" or "After Production Verification". Do not use special characters, including quotes, in the version names.
|
Caution: The Deployment Manager version control keeps track of import components and structures, but not of completed imports. Once an import is complete, it cannot be rolled back to a previous version. Instead, a new import is required. |
When you export a leaf or an organization within 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 certain information automatically, such as the date of the export, who performed the export, and the source database. Fill in the export description with a one-sentence description of the content of the export, for example, "resource definition after foo attributes added in reconciliation". This way the importer of the file knows what the import contains.
When importing to production, check all the warnings before completing the import. These warning are important, and each should be treated seriously as a yes or no question.
The wizard in the top right pane shows resources that must be available in the target system. There are different possible scenarios concerning dependencies:
If the resources are already available in the target system, then they do not need to be exported.
If the resources are new, and therefore 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 them in a separate file so they can be imported if necessary.
Scheduled tasks depend on certain parameters to run properly. The scheduled task parameters can be imported to the production server, however there are rules to determine how they are imported. Sometimes parameters are available for tasks that are no longer on the target system.
Adapters are set to recompile and scheduled task statuses are disabled when imported. This is to prevent them from executing before their associated resources and settings are in place. After importing the classes and adjusting the task attributes, manually recompile the adapters and enable the scheduled tasks.
Entity adapters are modified to bring just the entity adapter, not their usage. Each use of entity adapter with a data object must be exported separately, 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. For this reason, pay special attention when exporting data objects. For example, to export a Form, also add the data object corresponding to the form to make sure that any associated entity adapter can use the form.
When exporting groups, group permissions on different data objects are also exported. However, during import any permissions on 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 the permissions requirement is met. For example, if the group has permissions for objects A, B, and C, but the target system only had objects A and B, then the permissions for object C are ignored. If object C is added at a later time, then either the group permissions for C have to be added manually, or the group has to be imported again.
Before importing the deployment to production, backup the database. This provides you with a fail safe in case something goes wrong with the import. Backing up the database is always a good precaution before making any significant changes to the system.
|
Note: Importing forms and user-defined fields adds entries to the database. These database entries cannot be rolled back or deleted. Before importing, check to be sure that the correct forms version is active. |
You cannot perform an entire import in a single transaction because the import includes schema changes. These changes affect currently running transactions on the system. To limit the impact of the import on work performed by the system, separate the web application from general use and perform the import when the system has the least activity, such as overnight.
