I had noticed the Oracle EBS drivers get 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.

In the first article I made it through the configuration, GCVs, and the started working through the Subscriber channel.

In the second article I finished the Matching policy in the Subscriber channel and got into the Command Transform.

In the third article I finished the Command Transform and started into the Output Transform.

In the fourth article I finished the Output Transform, and started in on the first policy in the Input Transform.

In the fifth article I almost finished the Input Transform.

In the sixth article I finished the Input Transform and started on the Publisher channel getting through the Event Transformation.

In this article I will work through the rest of the Publisher channel.

That leaves us with the Publisher Matching Policy set. There are two policy objects in there.

Publisher Matching Policy set:

 

• NOVLORAHENT-pub-mp-EntitlementsImpl

• NOVLORAHDCFG-pub-mp

NOVLORAHENT-pub-mp-EntitlementsImpl

There is only one rule, "Employee entitlement: do not match existing accounts" and it is kind of interesting. It checks to see if Entitlements are in use (Looks at GCV drv.entitlement.Employee), and if true, blocks matching attempts. The comments say that since Entitlements are in use, then you do want to match, you want an Entitlement in the IDV on the user to control access.

This has me a bit confused. Seems like a chicken and egg thing, doesn't it? I thought this was the Oracle EBS HR module, that is an HR system, which normally would be the source of users. Thus on a new hire, in EBS HR, no IDV user exists. I would have expected that this hire event here is what would have created the IDV user.

I get the feeling I am missing the point somehow.

Anyway, the policy comment is nice enough to note that if you wish to match existing users to replace this policy. What it does to block matching is it sets the operation property 'attempt-to-match' to false. The next rule will check for that before matching.

In a more common scenario, the policy here would check to see if it is in the right Source DN, or meet some other criteria, and if so set attempt-to-match to true.

NOVLORAHDCFG-pub-mp

There are three rules here.

• veto out-of-scope events

• Add CN attribute if not available

• Matching Policy

veto out-of-scope events

This is the very usual check of the attempt-to-match operation property discussed in the previous rule. If false, veto the event.

Add CN attribute if not available

The comment is helpful here, but a bit simplistic. "Employee in Oracle EBS not contains any user name. So forming a user name from first name and last name". Which is what it does, use first character of the first name, followed by all of the last name.

Of course that is simplistic, since that is unlikely to be anyone's actual naming model. In this case, CN is probably a bad match criteria if it does not exist in EBS HR.

Amusingly the condition is If Operation equal add, but of course you can only ever hit the Match policy on an add event so it is superfluous. The next condition is if operation attribute CN is not available, but seems like it never would be available if EBS does not have it?

The actions add the destination attribute value for CN, as described above (FLASTNAME model) and then uses the Set Operation Source DN token to set it to the value of the CN attribute it just set. This way you have an -dn. It is interesting that there does not otherwise seem to be a src-dn when coming out of EBS? I would have assumed the src-dn would have been the ebsPersonId (as well as the association value).

Matching Policy

This rule is a bit odd to me. It is a Find Matching Object call which is appropriate, but the target is the "entry" DN of Unmatched Source DN.

Several problems here. If I read that right, the source DN was just set a moment ago in the previous rule based on the CN, which is based on the first letter of the first name and then the entire last name. But it is just that, a single CN like attribute value.

Doing an Entry level search will thus never find such an object in the IDV, since of course objects are not floating out there flat, rather they exist in containers. Finally, the value of the DN to look for, uses the Unmatched Source DN token, which is also problematic since that only has a value, within the same policy object that called an If Source DN in subtree or similar compare. I.e. Unmatched Source DN needs to have something to have matched against, to be the unmatched part. Now it may be that in a case like this it returns the entire Source DN, I am not certain, but even if so why do it that way?

This rule makes little sense to me, and I wonder if there is something I am missing in this approach?

I would almost certainly create my own Matching policy, which to be fair, the previous policy object encouraged us to do. Maybe this is just the barest minimum of a placeholder approach to avoid incorrectly matching, so they chose a sample match that will always fail? Hmm, that is vaguely possible.

That wraps up the Matching policy set. The Creation Policy set is empty, so on to the Placement Policy set, where there is one policy object:

Placement Policy Set:

 
NOVLORAHDCFG-pub-pp

This has a single rule, named "Placement Policy" that just places users as Source Name() (so the calculated CN) in the idv.dit.data.users container GCVs location.

No attempt at a Unique Name call to avoid naming collisions. Sort of a simplistic, bare bones approach, which again to be fair it sort of warned us about. Of course the Unique Name token would not make much sense here, since Source Name() is the CN that was calculated in the Matching rule and if you think about it, a Matching Rule that tries to generate a unique user name, to then try to match with is always going to fail to match. Sort of by definition. Find a unique name, and it never ever matches an existing name, go figure, right?

Of course the better match criteria would have been the DirXML-ebsPersonId attribute value, but if that is not already on existing users, that does not help much either.

That is it for the Placement Policy set, onwards to the final Policy Set, Command Transform. There are two policy objects here.

• NOVLORAHENT-pub-ctp-EntitlementsImpl

• NOVLORAHATRK-pub-ctp-WriteAccountsOnAdds

NOVLORAHENT-pub-ctp-EntitlementsImpl

Well that is odd. There are zero rules in this policy object. Did not expect that. That was so odd and unexpected that I did a quick flip over to the XML Source tab to see whether they had left anything behind. What do you know? They did!

There is a rule in there, in fact two, but by changing the node <rule> to <!--rule> and closing the </rule> as </rule--> they turned them into XML comments. What is unclear is why they hid it this way, instead of just using the Disable button on the rule nodes. (This sets the XML attribute of disabled='true').

The two disabled (oddly) rules are:

• Strip Dirxml-TerminationDate from operation (Disable Option)

• Strip Login Disabled from operation (Disable Option)

Strip Dirxml-TerminationDate from operation (Disable Option)

This rule checks two GCV's that control the Entitlement handling functionality. First are entitlements in use for Employees, and if true, second are we disabling such users. Then if it is a User object and the attribute DirXML-TerminationDate is available, we strip it out of the event document. What is interesting is that the DirXML-Termination attribute is not mapped to anything in the EBS HR Schema. So as the rest of the driver stands, this will never come across in an event. Oh sure you could add it by hand yourself, mapped to say P_EFFECTIVE_END_DATE but then it would be your problem to consider how to handle it. I guess they had some grander plans they simplified down for the full driver release.

The notion being, since Entitlements control EBS HR user status, if the status changes in EBS, then do not let that sync to the IDV, I.e. The DirXML-TerminationDate is not a driver specific attribute, it is the sort of thing that an HR system should set, and apply to all instances of the user. Thus if you were using it (I Know the SAP HR driver will set it, but I am not sure of any drivers or policies that implement terminations based on this attributes data. You could of course have written your own, but none out of the box come to mind) you would probably want to decide how to handle it yourself here.

This is sort of an odd rule, oddly commented out as well.

Strip Login Disabled from operation (Disable Option)

This rule is basically the same rule as above, for much the same reasons, and differs only in that it handles Login Disabled. It has all the same issues even to the point of not having anything in EBS HR mapped to it via the Schema Map.

So what attribute in EBS HR should trigger a change in Login Disabled? Looking at the schema like I did earlier in this series, I do not really see anything that directly maps. In fact the only thing that would make sense would be to map P_EFFECTIVE_END_DATE to Account Expiration, doing appropriate time conversion from the pretty format EBS sends to CTIME that eDirectory wants in time syntax attributes along the way. Then you would have an expired account when the Effective End date came around. You could then use a driver like the PWNotify or any driver you want to react to a scheduled Job event (A Job is really just a cron task that executes in the IDM environment and sends a <trigger> event) and query for users with expired accounts. I mention PWNotify from Lothar Haeger since the IDM Query token is somewhat limited in comparison to the LDAP search filtering ability. The primary two relevant examples I can think of would be:

1. LDAP can query for presence or absence of a value. (attribute=*) or (!(attribute=*)), whereas the IDM token cannot really.

• For Time syntax attribute fields, LDAP can do a time range compare that IDM Query cannot. (AccountExpiration>=20140101000000Z)

I am sure there are many more things that an LDAP based query can do that the IDM Query token cannot, but I cannot think of them off the top of my head, and really these are the relevant ones right now for our concern. I did ask one of the IDM developers once about this. I was wondering if it was a limitation of JClient, but of course the LDAP query is processed by NLDAP which uses JClient or its C based sibling DClient to talk to eDirectory anyway, so if NLDAP can do it, in principle it seems like JClient should be able to do it as well. I caught him at a moment without access to source code, so he did not look it up to see why, but I will have to nag him again to see if he ever did look and see if there was a good reason for this limitation. (Or put another way, a reason why it could not be implemented). I got no promises from him, but it was worth reminding him in person about it.

With the PWNotify approach using LDAP you could easily copy some of the policies that handle passwords about to expire, to send emails on accounts about to expire (Which I think it actually does this part) but also to do something with the account once it has expired. Perhaps disable it once it has expired? Create a Work Order to delete it in 90 or 180 days? Or move it to a disabled container (I do not like this approach personally)

You have lots of possible options and the PWNotify driver can make implementing them a lot simpler.

NOVLORAHATRK-pub-ctp-WriteAccountsOnAdds

This is the standard Account Tracking content which I will cover in a later series that I want to do as standalone content.

Well would you look at that? I think we are all done! Not too bad. So in review, interesting driver, uses SOAP against an endpoint that is exposing the database table as SPML. Uses entitlements against an HR system which seems odd, when usually HR systems are the authoritative sources for users.

I hope you found this series helpful. I suppose I should go look at the EBS TCA and EBS UM drivers next.