Friday, October 06, 2006
Can't See Workflow
Successful migrations of Oracle Access Manager (formerly COREid) configuration data rely heavily on consistent directory naming of entries between envionments. It is not enough for configuration data objects to share the same user friendly names, they must have the same RDN (Relative Distinguished Name) values in the directory server. This forms the basis of clean migrations. As well, objects must share the same properties. If this setup is performed in advance of using the COREid Migration Service or alternatively, corrected in a pre-existing environment using the COREid Migration Service migrations will run smoothly. The situation described below illustrates how having inconsistent environments can cause problems.
Have you ever copied a workflow definition from one environment to another and had the workflow not appear in the Oracle Access Manager (formerly COREid) Workflow applet? You double check the target directory server and indeed all of the entries are there so you wonder what could possibly be happening.
If this sounds familiar, then this is likely highlighting a difference between your two environments that you might not know existed. The problem is probably related to when your environments were first built manually independent of one another.
The cause is that there are different objectclasses associated with the tab_id that the workflow is meant to manage.
For instance say in the development environment the Employees tab (default user tab in Oracle Access Manager) has associated with it structural objectclasses of user and oblixOrgPerson. But in the quality assurance environment where you migrated the work flow to it has objectclasses of user, obligOrgPerson and auxCompanyPerson.
This provides an obvious barrier to performing clean migrations between environments. The way to correct this problem is to make the objectclasses look the same. The best way to do this is to get one environment in a pure state (i.e. contains all of your active development) and then migrate it to the other environments. This way all of the environments will be the same and ready to migrate information from one environment to another.
Have you ever copied a workflow definition from one environment to another and had the workflow not appear in the Oracle Access Manager (formerly COREid) Workflow applet? You double check the target directory server and indeed all of the entries are there so you wonder what could possibly be happening.
If this sounds familiar, then this is likely highlighting a difference between your two environments that you might not know existed. The problem is probably related to when your environments were first built manually independent of one another.
The cause is that there are different objectclasses associated with the tab_id that the workflow is meant to manage.
For instance say in the development environment the Employees tab (default user tab in Oracle Access Manager) has associated with it structural objectclasses of user and oblixOrgPerson. But in the quality assurance environment where you migrated the work flow to it has objectclasses of user, obligOrgPerson and auxCompanyPerson.
This provides an obvious barrier to performing clean migrations between environments. The way to correct this problem is to make the objectclasses look the same. The best way to do this is to get one environment in a pure state (i.e. contains all of your active development) and then migrate it to the other environments. This way all of the environments will be the same and ready to migrate information from one environment to another.
Permalink posted by Dave Bennett @ 3:29 p.m. 
