OIM first adopted MDS with the release of 11gR1. Prior to MDS, many Oracle Middleware products used files on the filesystem as configuration stores, in various formats (XML, Java properties files, etc.). One of the purposes of MDS to create a standard configuration store across the Middleware stack.
For the connector JARs and plugin JARs in OIM, rather than storing them in MDS, we instead store them as BLOBs inside database tables in the OIM database schema. However, once again, the possibility of cluster inconsistencies which existed in 9.x (where these JARs lived on the filesystem) is eliminated.
Problem with storing configuration files on the filesystem (e.g. xlconfig.xml in OIM 9.x), is that in a clustered environment there is a risk of inconsistencies in configuration between the nodes, which may have inimical effects. In OIM 11g, by storing the configuration in the MDS database schema, this possibility is eliminated.
OIM 11gR2 provides an easy way of customizing the UI through sandbox.
"...a sandbox is a temporary storage area to save a group of runtime page customization before they are either saved and published to other users, or discarded."
All customization and form management are performed in a sandbox. A sandbox allows us to isolate and experiment with customization without affecting the environment of other users. Any changes made to a sandbox are visible only in the sandbox. we must create and activate a sandbox to begin using the customization and form management features. After customization and extending forms are complete, we can publish the sandbox to make the customization available to other users.
Though, the user form, catalog entry, etc are contained within the sandbox as well as any modifications we may have done to them, but the App Instance, Resource, etc are not included.
Part of the reason for this division of objects is due to the fact that sandboxes only store front-end objects and modifications.
The Resource, IT Resource, etc are all back-end database objects. These are objects we can interact with in design console or can view if you connect directly to the database and perform queries.
These Database objects can technically exist without the UI changes. We could create a sandbox with a new database object, publish it, and then in a subsequent sandbox delete all of the UI components of the database object and we won't see any errors assuming there are no remaining references to the object on any pages. If there are references remaining, we will see ADF Faces errors referencing the missing component
Hence for moving a solution in between different environment consists of two main component -
1. The sandbox with all the front end UI customizations, ADF pages ( as well as create/modify/bulk pages for the Object forms created ) and PageDefinitions including the VO and EO objects and their associations.
2. A "Request Dataset" export from the Deployment manager of the SYSADMIN console. The reason for taking the export of a request dataset is , it consists of every aspect of a form including IT Resource,IT Resource definition,app instance, Process forms (parent and child), Resource obj, Process definition, lookups - adapters attached to the form etc.
( An important point here would be - request dataset export DO NOT consists of the artifacts not associated directly with the form but necessary nevertheless, such as Configuration lookups, Schedulers, etc. We need to go back and "Add More" to the export for each of these.)
* This export needs to be imported in next environment by deployment manager.
for the sandbox part of it, it includes two files which holds entries very specific to an environment , If this files are not edited properly, it may as well bring down the entire next environment, until fixed.
The files are :
- sandbox_XYZ\persdef\oracle\iam\ui\catalog\model\am\mdssys\cust\site\site\CatalogAM.xml.xml
- sandbox_XYZ\xliffBundles\oracle\iam\ui\runtime\BizEditorBundle.xlf
The Catalog.xml file holds the VO - ViewObject entries of each Object forms and the User form of any envronment.
The BizEditorBundle file holds entries for each attributes of each Object forms and the User form of any envronment.
Since not all the forms are same across each OIM environemt , you simply can not export and import a sandbox from one OIM env to another.
We need to select the entry tags from both the files which are relevant to us, and append them in the same files of the enxt environment.
A sample tag from BizEditorBundle will be as below :
A sample tag from Catalog.xml will be as below :
Reverting Sandboxes :
It may as well be that after publishing the sandbox if we came to know that the changes we have made is not correct, we can revert that sandbox and bring the OIM to same state as before. But we cannot perform this action using OIM GUI. However, we can revert back to the state before publishing the sandbox changes through EM console by following the below steps.
Thanks for Reading !
No comments:
Post a Comment