I had noticed the Oracle EBS drivers added to Designer a few patches ago, but never really had much of a chance to look at them. As I have been doing in my driver walkthrough series, I decided to do the Oracle eBusiness HR driver next.

You can find more of my driver walkthrough collections here:
http://wiki.novell.com/index.php/Detailed_driver_walk_through_collection

As is usual as I start these articles, now in the era of Packages, I list off the specific package versions I reviewed, which can explain why your version may differ from mine.

Package levels for this series:

Oracle EBS HR Base			2.2.0.20140317180347
Oracle EBS HR Account Tracking		2.2.0.20140328105811
Oracle EBS HR Default Configuration	2.2.0.20140327145325
Oracle EBS HR Entitlements		2.2.0.20140317180440
Oracle EBS Managed System Information	2.2.0.20140227165912
Audit Entitlements common		1.0.0

When I first used Designer to add the driver so I could examine it I noticed a couple of things.

First that they had a Package prompt that showed a warning message as follows during install:

Important Notice:
MSG driver version 4.0.0.6 or later is required for this package.
Version 1.0.0.1 is required for Subscriber.pkb and Publisher.pkb PL/SQL scripts

I am curious what specifically changed in the MSG driver 4.0.0.6 that is required. When I look at the Managed System Gateway patch, 4.0.0.6:
https://dl.netiq.com/Download?buildid=ohcun-DLZ6I~

The only part that looks relevant is the combination of two bugs:

• MSGW Does not use Query-ex. Bug 840604

• <operation-data> will not add correct details during subsequent queries. Bug 849137

My guess is that they needed query-ex support, since you will have lots to query, and when they added it, they found it was not properly handing operation data on the follow up queries after the first.

The second item I noticed was that for an Oracle driver, I assumed we would be talking to a database, this is Oracle after all, right? But apparently not. There is a web service endpoint for communication, that the driver suggests during configuration.

http://myoracleserver.com:8000/webservices/SOAProvider/plsql/idm_driver_s

Probably it would help to spend a little time explaining why there are three Oracle EBS drivers as well. The docs do a nice job of this in the Introduction section:

But basically the three drivers handle three different types of users in an Oracle EBS suite. The Driver for User Management, like the SAP UM driver, is meant to create a user who can login to the EBS suite and do work in it. This is a record in the FND_USER table, after all this is still Oracle, so it is Potemkin databases all the way down.

The driver for HR like the SAP HR driver handles records for people, in this case in the PER_ALL_PEOPLE_F table. This covers Employee, Part-time worker, Contractor, and others. Some Oracle apps require a record here to work, even if you have a User account to login (like iExpense).

The Driver for TCA (Trading Community Architecture) is meant to handle customer or vendor records. These are records in the HZ_PARTIES table. They still need records in the FND_USER table, but are linked via the PERSON_PARTY_ID column in FND_USER to the PARTY_ID column in the HZ_PARTIES table.

Reading through the configuration documentation the answer to my sup rise at the SOAP endpoint is that in fact, the shim uses some PL/SQL scripts provided by NetIQ that get exposed as a SOAP web service. So it really is databases, just not using JDBC to get them, using a SOAP front end. I wonder about the efficiency of that transformation on the Oracle side?

One interesting note between the three drivers is that the EBS HR driver has only a UserAccount entitlement, but the EBS User Management and EBS TCA drivers have two more entitlements Role and Responsibility. Roles seem to be querying against the ORACLEEBSROLES table, for the column WF_ROLE_NAME and Responsibility against the table ORACLEEBSRESP, for the column RESPONSIBILITY_KEY. More on that topic when I start working through those drivers.

I see that there is no XSLT transformations in these packages, which leads me to think these are shim wrapped drivers, which is annoying as it means the XSLT that transforms the XDS to SOAP is hidden from sight. But most importantly it means it is hidden from manipulation in case there is a bug. Most of the pre built SOAP based drivers work this way, like the SAP Portal and Salesforce.com shims.

From the documentation there are some good notes about how the system works, and is worth quoting from this page: https://www.netiq.com/documentation/idm402drivers/oracle_ebs_suite/data/alvpn4u.html

The Oracle Workflow Business Event System (BES) is an application service that uses Oracle Advanced Queuing (AQ) technology to communicate business events among different Oracle systems. The BES consists of the Event Manager and Workflow that process event activities. The BES can propagate Add, Delete, and Modify event data to the Identity Vault. Only events specifically selected by the system administrator are transported from the Oracle EBS system to the PL/SQL APIs. The PL/SQL APIs (installed in the Oracle EBS system as part of the driver installation) handle the parsing of the events and read the appropriate data fields specified by the driver configuration, and provide secure transport of the data over an HTTP/HTTPS port to the Publisher channel. Figure 1-1 shows the Publisher channel data flow from the Oracle EBS system to the Identity Vault.

The business events are cached and stored into a database table (idmusrmgt.idm_events table) in the Oracle EBS system. To guarantee the delivery of events to the Identity Manger, the events remain in the idmusrmgt.idm_events table until they are successfully send to the Identity Vault. The Publisher channel uses a SOAP endpoint to poll the idmusrmgt.idm_events table for certain future events such as future add or delete events or modification of roles and responsibilities to the existing users, which are meant to be executed at a later time. A future date of when these events need to be executed is specified along with the events. Future events are immediately synchronized with the Identity Vault. The login attribute is disabled for the future events until when they are required to be operational.

From those notes you can see that the database is exposed over SOAP and the underlying tables in play. Interesting approach.

The driver configuration itself looks just like every SOAP driver you may have ever configured, with control over each channel, SSL settings (Trust file, keystore file for mutual auth, and password). There is support for a web proxy since this is SOAP it runs over HTTP and you might need to go through a proxy to get to the end point. There is a list of HTTP errors to retry as well.

On the Publisher channel configuration options, the usual, enabled the channel, listen on IP and port, authentication ID and password, SSL controls, heartbeat, and polling intervals.

Nothing very interesting here to comment on. You have seen one SOAP driver you have seen them all. The only thing I might add is that the options to send additional headers is missing. But I bet that if you needed too, you could likely add in additional header settings, by adding in some configuration values in the raw XML editor. The regular SOAP shim looks for config options called optKey1-1 and optValue1-1 pairs for the header name and a value to send. I am pretty sure that might actually just work if you set it. (Anyone have a working system to try against? I think that would be fun to validate).

Global Configuration Values (GCV):

After looking at the driver configuration, lets take a look at the GCVs that come with this shim. I often find the things they control illustrative of what the driver supports.

There are three packaged GCV objects plus the driver attribute GCVs:

• Oracle EBS HR Driver (Driver settings)

• Managed System Information

• Account Tracking

• Entitlements

Oracle EBS HR Driver (Driver settings)

My first critique is that the driver itself is NOT supposed to include any GCV values. That is, with the switch in IDM 4.x to Packages a new GCV holding object, DirXML-GlobalConfig object class was instantiated and holds GCV settings. The drivers DirXML-ConfigValues should remain empty in new packaged content. Alas there is actually a GCV in the drivers attribute, named "Set Oracle EBS HR As Authoritative Data Source". This one piques my attention, I wonder if it is doing something particularly cool when true, like modifying the filter somehow on the fly?

Alas, as I read the comment in the mouse over my hopes are dashed. Basically it looks like this is a control used in the Subscriber Event Transform to veto Add and Delete events, allowing Modify events through.

Managed System Information
Account Tracking

These two sets of GCVs are basically the standard packaged ones you see in most drivers these days. I do not see anything unique in them worth calling out. I did check the ITP rule that manipulates the MsysInfo GCV object and they did remember to set the type to a new value (OracleEBS if you care) which is my other first thing I check in new drivers.

Entitlements

As there is only one Entitlement in this driver (UserAccount) the GCVs here are simpler to read than in a multiple entitlement driver. There is an overall control for requiring Entitlements, which oddly defaults to false. I wonder if that is to make setting up a base driver simpler, since you can test user synchronization without having to grant entitlements to do it. But considering the push to use RBPM and Entitlements that seems like a bit of an odd choice. Not major, just remember to enable it, if when you need it.

Other than that not much to see in this entitlement. I do wish the entitlementConfiguration object would ship in packages with a bare bones version, since you need a successful driver start to create it in the ITP policy. I find it interesting to see how it looks for each driver, and without a working target it can be hard to see. I suppose I could try and run that policy through Simulator and see what comes out. The problem is that it is querying for a number of objects that I am not entirely sure what the response should be. I guess I could go fake out the results from another driver, but that seems like a lot of work.

The other question I am unclear on relates to the value of an entitlement in this case. What is accomplished by taking a user from the Identity Vault giving it an entitlement to this system and propagating that user in the Oracle EBS HR suite? Usually users go the other way, that HR hires them which causes them to synchronize to the Identity Vault. I can understand why you would want to associate users in IDV with HR, so that changes potentially can flow back to HR, but the docs note that this driver writes users to the PER_ALL_PEOPLE_F table.
But in describing the Subscriber channel says it writes updates to the table: idmusrmgt.idm_events

So there is a minor lack of clarity here for me.

Not a lot of configuration or GCV settings to go through on this driver, which is interesting. Lets move on to the Subscriber channel and start walking up the fishbone diagram of policy sets.

Subscriber Event Transform

There is only a single policy here.

NOVLORAHDCFG-sub-etp-VetoRenameAndMove

This has a single rule, "Veto rename and move operations" that as its name suggests stops the flow of rename and move events, since Oracle does not really support such a concept. A move makes sense since a database table entry is not really like a directory structure layout. But a rename seems like something that would be useful to have, after all usernames do change, especially if you have usernames based on last name. After all names change with marriage and divorce (and other reasons, but those two are the most common). I guess this is an Oracle side issue. I suppose in a case like that you would want to rename it manually in Oracle. Maybe add a policy in this driver, checking if the user is associated, and if so, and a rename, send an Audit event, or an email warning someone to go do the task on the Oracle side.

Subscriber Match Policy Set:

There are three policy objects in this policy set.

• NOVLORAHDCFG-sub-mp-Scoping

• NOVLORAHENT-sub-mp-EntitlementsImpl

• NOVLORAHDCFG-sub-mp

NOVLORAHDCFG-sub-mp-Scoping

There is a single rule in here named "Only match users that reside in the configured container/subtree" which is the standard match policy beginning. It uses the If Source DN in subtree condition test token, which then activates the Unmatched SourceDN noun token. If the Source DN is in the subtree specified, then the Unmatched SourceDN token will return the unmatched part of the DN. That is, for a user whose DN looks like:

edu\domain\users\empl\temp\geoffc

And the If Source DN test was using the target subtree of edu\domain\users
then the Unmatched SourceDN value would be empl\temp\geoffc

Now that only persists for the duration of the policy object, so how do you get info from one policy object to the next? Driver scoped local variable? Possible but not a good idea as if you forget to clear it you reuse old data. This is what Operation Properties were meant for, and thus inside the rule the action is to set the operation property "unmatched-src-dn" to this value to carry it forward and set the operation property attempt-to-match to true as well.

This way you can filter by container here, and possibly not need to modify the actual match rule. It is a generic approach used by most of the drivers to allow for easy adding on of custom matching policies in your own specific package.

That is about it for now, stay tuned for the next episode in this series! (Remember 3 drivers this time, not 1, so this could take a while).