Auxiliary Classes and IDM



A Forum reader recently asked:

"I've created a JDBC driver to pull data from a Database and publish to the ID Vault. It all works fine, but now I need to start using schema extensions to store extra attributes. I know how to create auxilary classes and populate the attributes using
IDM, but I'd like to know the best place to do this.

Which is the best policy set to put the code to apply the aux class to a user that's currently being created via IDM? Can I just set up a schema mapping for a DB field directly to an aux class attribute, if I know the ID Vault object being sync'd is already using the aux class?"

And here's some timely advice from Father Ramon ...


Usually the easiest way to deal with aux classes in IDM is to pretend that they don't exist and that their attributes are just part of the object.

Add the attributes to the filter and schema mapping for the base class (most often user), and they will automatically sync in. The aux class will be added automatically, if IDM detects that it is needed.

The exceptions to this are:

1. If the attributes could come from more than one aux class, IDM will automatically add all aux classes that they could come from, and you have to strip out the ones you don't want in the Publisher Command Transformation.

2. Any attributes you add via a direct command from policy or that are injected in the publisher command transformation will not have aux classes added automatically.

Also, if you want the aux class to be put on the object at creation time even though none of the attributes might be needed at that time, then you would usually do this by adding the name of the class to the Object Class attribute in a Publisher Creation policy.


How To-Best Practice
Comment List