Coding against specific OIM bundle patch jars

One of the difficulties of coding with the OIM API is that it occasionally changes.  A specific example occurred sometime before OIM 11gR2 BP11 where the behavior of the ProvisioningService.getAccountsProvisionedToUser(usrKey, searchCriteria) method call changed; at BP11 and above, this method call no longer returns the AccountData object in the Account instance.  This can obviously cause problems, and the person coding the Event Handler, Scheduled Task, or Process Task jar file won't know about the change until run time.  Use of Maven and JUnit testing will expose these issues during unit testing and prevent problems from occurring.

Best practice for dealing with this is to pull the needed jars file from the OIM server and push them up as jar files in your Maven repository.  One example that is used to provide many of the APIs is the file oimclient.jar so that will be described here.

I use a numbering scheme to reference the version similar to what Oracle does, for example the oimclient.jar file from the base R2, BP11 will be 11.1.2.0.11 and the oimclient.jar file from PS2 BP1 would be 11.1.2.2.1 and so on.  You can specify the version in your Maven dependencies of the pom file, but that doesn't make the file go into the repo.  You have to do that manually.

Here's how to push, for example, the oimclient.jar file from R2 BP11 up to Maven:

mvn install:install-file -Dfile=oimclient.jar -DgroupId=com.oracle -DartifactId=oimclient -Dversion=11.1.2.0.11 -Dpackaging=jar

Once that is pushed you can reference it successfully in your pom file.

One last thing, where do you get the oimclient.jar file from BP11 (or any BP)?  You should know by now that for R2, bundle patches are not done by overwriting all of the jars with new jars, and so you can't go into the bundle patch zip file and just pull out the jar files.  Bundle patches occasionally have a whole new jar file, usually if a class is to be removed from a jar, but most bundle patches are deltas, where in the patch folder the new classes are organized and the patch process replaces the class files in the jar files in place.  So the moral of the story is you have to patch a system before you can pull out the latest jar files, those jar files are nothing more than the current state of an organic system.  To figure out where the file is, use find: 

$ find $MW_HOME -name oimclient.jar -ls

Location of some jar files in OIM

Sometimes it is difficult to remember where the jar files are in OIM.  Here's my running list.

oracle.iam.connectors.icfcommon.* are in icf-oim-intg.jar

most of the rest of oracle.iam are located in OIMServer.jar including:

The implementation for ProvisioningService is in OIMServer.jar under:
oracle.iam.provisioning.implProvisioningServiceImpl

oracle.iam.selfservice.self.selfmgmt.impl.AuthenticatedSelfServiceImpl
oracle.iam.identity.usermgmt.impl.UserManagerImpl

oracle.iam.platform.tx.OIMTransactionManager is in oimclient.jar, iam-platform-utils.jar
com.thortech.xl.xjb.beansimpl.tcLookupOperationsBean is in xlDataObjectBeans.jar

org.apache.xml.serializer.ToStream is in xalan-2.6.0.jar

Thor.API.Operations.* interfaces, are implemented by classes in com.thortech.xl.ejb.beansimpl and are in the xlDataObjectBeans.jar file.

These often call a class com.thortech.xl.dataobj.APIUtils which is found in xlDataObjects.jar

Mappings getMapping are done by com.thortech.xl.orb.api.tcMapping which is in xlVO.jar which just converts a Map into an array of tcMapping objects.

The conversions are done in getColumnNameMap which maps the long values into short ones.  This is done in Thor.API.tcBaseUtility.getColumnNameMap and is in oimclient.jar

The query is:
select lku_field, lku_type_string_key from lku where lku_type='f' and lku_type_string_key in (" + msbCodeList + ")";

I have a utility called findclass that I use to search jar files for class names. 

Design Console - designconsole - The name of the Design Console is tcAppWindow and it is located in the file $OIM_ORACLE_HOME/server/client/lib/XellerateClient.jar