Migrating Quantities of Disconnected Application Instances in OIM

This is an add-on to a previous post regarding migrating disconnected app instances.

We created 50+ app instances that were replacing a manual paper/email process. Each app instance collected info and forwarded that to the data owner for approval. This add-on post is just to point out a simplification to our process when migrating a large number of app instances. We will go through the whole process rather than just hashing out the differences between the two posts.

The first step is to import the database objects. A common object required for disconnected apps is the adpManualProvisioning Task Adapter. Import that only once before everything else and that will prevent Deployment Manager from complaining about it being missing.

Next, a working order to use to successfully import objects for Disconnected Apps is:

  1.  IT Resource Definition
  2.  IT Resource
  3.  Lookups
  4.  Process Form
  5.  Resource
  6.  Event Handlers
  7.  Process
  8.  Request Dataset
  9.  App Instance

This order prevented errors from appearing for us with our 50+ sandboxes, but someone more knowledgeable may point out a simpler order. We eventually coded a quick program that made use of the OIM APIs to export the objects into a single xml file which worked remarkably well after some trial and error. That coding was worth the effort due to the number of App Instances but may not be valuable in every case.

Once all of the objects are imported, we move on to the sandboxes. Now in the previous article we mentioned that you needed to modify the CatalogAM.xml.xml and BizEditorBundle.xlf in the sandboxes to make sure the catalog and forms don’t complain.

Well we discovered a simplification for the procedure rather than updating every single sandbox with information from all of the preceding sandboxes.
After analyzing the files, we discovered that for CatalogAM and BizEditorBundle when you import a new sandbox it effectively overwrites the files rather than appending it.

Now there are additional objects in the sandboxes besides these two files so we did two things:

First, we got the unique information from CatalogAM and BizEditorBundle and put it in a single xml document. Due to the large number of sandboxes we dealt with, we wrote some code that reads into those two files in the zip packages and records it to a single xml (we’ll leave writing that code as an exercise for you).

Second, we proceeded to publish each individual sandbox without updating the CatalogAM and BizEditorBundle files until we got to the last sandbox. Now, understandably, this procedure that we have been describing will break the catalog until we’re finished the whole process.

You must import and then publish sandboxes one at a time! If you import more than one, the first will successfully import and then you will see a concurrency error on the second and subsequent imports.  Oracle’s recommendation is to delete and rebuild the sandbox, since we’re performing a migration you can simply delete and re-import the sandboxes one at a time and you shouldn’t see any issues.

So when we got to the last sandbox, we updated the CatalogAM and BizEditorBundle files with the xml that our code had recorded as well as any code from pre-existing application instances (which we had before we started this process) and added that to the final sandbox. We imported and activated the sandbox, and then the important step is to go to all of the Application Instances in /sysadmin and associate the app instance with its form. That’s as simple as going to the Application Instance and clicking the drop down next to form to select the proper value. Click apply and go to the next Application Instance. For a large number of App Instances, this can be monotonous but we haven’t found a workaround yet to manually selecting those.

Once all of the Application Instances have a form selected and with the sandbox still activated, go to the catalog to ensure you do not see any errors. It is highly recommended to go through the time consuming process of adding all of the application instances to the cart and then verifying that the forms are appearing properly. Catching errors here can save headaches later.

Once you are assured there are no errors, publish the final sandbox and all of your newly migrated App Instances are ready for use.

Overall this is very similar to the previous post on Disconnected Application Instances, but hopefully this may save some time and effort if you are migrating a large number of App Instances.