OIM Reconciliation Process: Quick Peek

Few months ago, I had read an interesting article on OTN. It’s authored by Firdaus Fraz and gives us an insight into ICF and how reconciliation logic is designed in general. I happened to revisit this article and noticed that there could have been more details about the reconciliation process. So basically, over here, I am trying to provide a step by step guide to what happens during reconciliation in OIM – it’s not very detailed as such, but more from a conceptual perspective.

Use Case

  • Target Reconciliation
  • Executed via a Scheduled Job (generally a part of a Connector or maybe even a custom one)
  • Utilizes OIM Reconciliation APIs
  • Reconciliation is executed via scheduled job within (generally)

1. Each instance of the recon schedule job execution process is associated with an unique identifier – the Job ID

2. The client code (connector or custom written schedule task) creates a reconciliation event by using createReconciliationEvent() method – either a single event or bulk event using bulk API. The API itself can be explored here. Along with other parameters, the recon event method accepts the recon data as a method argument – it a java.util.Map object

3. The createReconciliationEvent() API invocation results in creation of a new Job ID in the RECON_JOBS table (inserts a new row in the table)

Info contained within RECON_JOBS table

RJ_KEY — auto generated key (the Job ID)
RJ_NAME — name of the scheduled job
RJ_JOB_STATUS — current status of the job
RJ_EVENT_CNT — number of recon events which were associated with this job …………… few other columns as well. Not important @ this juncture

4. Recon processing in OIM takes place in bulk i.e. in a batched manner.

The batch info is captured in the RECON_BATCHES table. After RECON_JOBS table is populated, an entry in the RECON_BATCHES table is created. it contains the key of the job id from the RECON_JOBS table as a foreign key

Info contained within RECON_BATCHES table

RB_KEY — unique batch number
RJ_KEY — foreign key corresponding to job id from the RECON_JOBS table
RB_BATCH_STATUS — current status of batch execution
RB_EVENT_CNT — count of the number of events in the batch …………… few other columns as well. Not important @ this juncture

5. Subsequently, an entry is created in the RECON_EVENTS table. This is the table where all the individual reconciliation events are stored.

Info contained within RECON_EVENTS table

RE_KEY — unique event key
RJ_KEY — the job id corresponding to this event (from RECON_JOBS)
RB_KEY — the batch id (from RECON_BATCHES)
OBJ_KEY — name of the Resource Object for which recon is executing …. and other columns as well

6. At last, there is an entry into the recon staging table corresponding to the Resource Object. This is nothing but the RA_* table. This table consists of the data in ‘horizontal table‘ style i.e. all the attributes of a recon event are stored in various columns and each row/entry in the table is corresponding to a particular event for that resource

Info about RA_* table

RECON_TABLE_KEY — unique key
RE_KEY — the recon event key to which the entry belongs … and more columns

7. The data keeps filing up until the number of recon events in the batch (RB_EVENT_CNT column in RECON_BATCHES ) reach the limit which is configured by the OIM.ReconBatchSize system property (500 by default)

As soon as this happens, the batch id (RB_KEY) is sent to the JMS queue in OIM. The JNDI name of the queue is queue/oimReconQueue. The JMS queue holds the key to asynchronous processing of reconciliation events.

More about the JMS part

  • As with all queues, there is a listener deployed to accept the messages dumped into the queue. In this case the listener class is oracle.iam.platform.async.messaging.MessageReceiverMDB. Internally there are other classes which it extends which in turn actually implement the javax.jms.MessageListener interface and provide concrete logic for the onMessage() method.
  • This method implementation is responsible for invoking a task in a different thread all together which in turn takes initiates the recon event processing.

Going into further details in not in the scope of this article. So, to summarize, the JMS processing layer ensures that the reconciliation event processing is triggered asynchronously in a batched fashion by invoking the Stored Procedures in the database layer. This in my opinion is a fairly robust design and has in fact improved the reconciliation processing by leaps and bounds!

That’s all for now folks!  🙂


About Abhishek

Loves Go, NoSQL DBs and messaging systems
This entry was posted in Oracle Identity Manager and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s