In part 1 of this series I started explaining the driver configuration for the Ellucian Banner driver.

In part 2 of this series I started looking at the Global Configuration Variable values.

In part 3 of this series I finished going through the GCVs and other settings.

In part 4 of this series I started working through the Input Transform.

In part 5 of this series I continued through the Input Transform, Matching, and Creation policy sets.

In this article I will continue down the Publisher channel.

Having completed the Matching and Creation policies in the last article on to the next policy set, Placement.

There are two policy objects in this set.

• NOVLBNNRUSER-pub-pp_UserPlacement

• NOVLBNNRATRK-pub-pp-WriteAccountsOnAdds

NOVLBNNRUSER-pub-pp_UserPlacement

There is a single rule, "User Placement Policy" that simply uses the idv.dit.data.users followed by the CN generated in the Input Transform. This is where I would normally have implemented the CN generation code not in the Input Transform. But it should work both ways.

NOVLBNNRATRK-pub-pp-WriteAccountsOnAdds

This policy is a bit unexpected, usually the Account Tracking stuff is Input and Output transform specific. Maybe a little Command Transform, but not in the Placement policy.

There are two rules in this policy set.

1. AccountTracking - disregard policy if disabled

• AccountTracking - on add operation add Dirxml-Accounts

AccountTracking - disregard policy if disabled

This one tests the GCV drv.acctTrk.enable to see if Account Tracking is even enabled, and if not, breaks out of processing the policy set.

AccountTracking - on add operation add Dirxml-Accounts

If the operation is an add event, then the rule does a add destination attribute of Object Class with a value of DirXML-Identity which is the auxiliary class that carries the DirXML-Accounts attribute. After all, newly created users will never actually contain this class yet.

Then we get into the DirXML-Accounts attribute management. It loops over the list GCV drv.acctTrk.identifiers and for each of them looks for an appropriately named operation property. These were set in the Input Transform, which I did not review in detail since I plan on working through the Account Tracking policy sets in a standalone series.

What is interesting here is that they are processing this aspect in the Placement policy as opposed to the Command Transform where it would normally be done. This makes me wonder about the case of a merge, if it would be missed. That is, when a user in the Banner system is added who matches a user in the Identity Vault it seems like you would not properly get the DirXML-Accounts attribute added to it.

That wraps up the Placement policy set, and when I look at the Publisher Command Transform policy set I see 4 policies, all the basic Password Sync ones, that are much the same on most drivers. I have reviewed these before in this pair of articles:

• Password Transformation Rules in the Publisher Channel

• Password Transformation Rule Sets

The first is the Publisher channel and the second is the Subscriber channel set of rules.

Nothing special worth calling out here.

That actually wraps up the Publisher channel so on to the Subscriber channel! Again there is no Event Transformation policies, nor any Matching policies. So Creation is the first set to work through.

Subscriber Channel

There is a single policy object NOVLBNNRUSER-sub-cp_UserCreatePolicy with a single rule, Block Add Events from being sent to Banner, which vetos all events.

The comment here is informative, "In order for Add events to successfully be processed in from eDirectory to Banner, the BEIS needs to be configured. Each instance of BEIS and Banner will be unique. The process for creating objects is going to be custom for each Banner instance. To configure this process you will need to work with your BEIS team."

I was not sure if it was possible to write back new users to Banner, and it seems it may be, just needs to be properly configured. I know that BEIS is using SOAP with the SPML dialect, so an add event should get properly converted to the needed SPML event, I just gather it is a permissions and attribute set issue that needs to be properly configured.

It is interesting to see this sort of a comment in a driver, since at some levels it is true of every driver, but the feeling I get is that Banner may be a bit trickier to handle than other drivers.

Placement is empty as well, after all Creation vetoed everything.

The Command Transform policy set is again the basic password policies as seen in the Publisher Command Transform, nothing interesting to report here as well.

Last up is the Output Transform. Here there are three policy objects:

• NOVLBNNRUSER-sub-otp_BannerDataConversion

• NOVLBNNRATRK-otp-Subscribe

• NOVLPWDSYNC-otp-EmailOnFailedPwdPub

NOVLBNNRUSER-sub-otp_BannerDataConversion

There are two rules in this policy set.

1. Add Available Attributes on Modify and Add

• Convert Phone Numbers to the Format Necessary to Send to Banner

Add Available Attributes on Modify and Add

This rule looks for an operation of add or modify, using the cute trick of a Regex compare for the operation name. That is, if operation is equal, but instead of case insensitive as the compare type, specify Regular Expression. Then a value of add|modify is a nice way of doing an inline logical OR.

Then it sets a variable, that is fed the query of this objects information from eDirectory, but the attribute list does something odd. They do a Replace all for tildes, to replace them with commas, on the GCV gcv.NOVLBNNRUSER.RequiredSubscriberAttrList which does not exist. I have never tried, but I wonder if you use a Query token and the attribute list, instead of being multiple nodes in the XML is a single node with many attributes, if it gets processed sort of like an LDAP filter? Regardless this looks like an oversight. In the end i do not think this will accomplish much. It looks like an unfinished bit of policy left behind and I have reported the issue.

Convert Phone Numbers to the Format Necessary to Send to Banner

For phone numbers we discussed earlier in this series how Banner likes to use multiple components to store phone stuff and the ECMA function used to convert them. This rule thus checks for any of the three known phone numbers, CampusPhone, MobilePhone, or Fax changing to then reformat them. Recall of course that we are in the Output Transform and thus the schema is in the remote naming model since we are past the Schema Map policy.

There is a minor problem is dealing with a fax number next to 'normal' phone numbers. The Facsimile Telephone Number in eDirectory is actually a structured attribute that allows a fax number to be stored with bit depth, speed, and finally a number. In theory this was all going to be needed for faxing, but ended up being functionally moot.

Regardless, you can see a clever approach taken, by doing a for-each, over the XPATH value:

//*[@attr-name='Fax']//value/component[@name='faxNumber']/text() | .//*[@attr-name='CampusPhone' or  @attr-name='MobilePhone']//value/text()

Had Fax not been in the set it would have been a simple Reformat Operation Attribute, or a For Each over each Operation Attribute (or maybe also over each Removed Attribute ) token. But because you need to grab a specific component of the Fax number XML they do it this way.

That XPATH really has two main sections, and the second one has two sections.

//*[@attr-name='Fax']//value/component[@name='faxNumber']/text() 

This part says any (//) node (*) with an XML attribute named attr-name, with a value of Fax, then add-value or modify-value (the // means any child node, search down) value node, and select the component whose XML attribute name is faxNumber, and get the text value.

.//*[@attr-name='CampusPhone' 
	or  
@attr-name='MobilePhone']//value/text()

This part says much the same, but does an internal OR inside the predicate (the square brackets part) to handle the other two phone attribute names, CampusPhone and MobilePhone, to get their value nodes text contents.

Now as it turns out, if you wanted it to be easier to read, inside a For Each's loop definition, you can have multiple Noun or Verb tokens which are then evaluated in turn since this is a nodeset context. As opposed to having their values concatenated as they would in a string context. Thus they could have used the first part of the XPATH to handle Fax, but then used the Operation Attribute token for the CampusPhone and MobilePhone, but also Removed Attribute for each.

That would be more unwieldy, with 5 tokens in there, but slightly more readable. However as I look farther I see that their generic reformatting via ECMA depends on each loop having the same context for XPATH so that probably would not work.

I think I probably would have used two Reformat Operation Attribute tokens, one for each of CampusPhone and MobilePhone and then handled Fax slightly differently, by still using a Reformat Operation Attribute, and still calling the ECMA function, but instead of passing it $current-node as the value to convert, I would have passed it: $current-node/component[@name='faxNumber'] instead.

Three Reformat Operation Attribute tokens seem simpler, easier to read, and more consistent to me personally. After all they are really three different attributes. I get the urge to try and solve the whole problem once, which this clearly does, but it seems with a level of complexity that might not be required. A similar issue I ran into is in the Active Directory driver. eDirectory and Active Directory have many phone number attributes but they manage them very differently. In eDirectory it is simple, telephoneNumber, mobile, etc are all multi valued attributes. How else would you handle it? Well I am glad you asked, since Active Directory does it different. In Active Directory the attributes you see in eDirectory are actually single valued and there is an 'other' version of the attribute that is actually multi valued. Perhaps this explains the UI oddity, where in Active Directory Users and Computers (ADUC or dsa.msc) you see the Telephone Number field, then an Other button for more. The 'more' are stored in a second attribute. For mobile, for example, the multi valued version is otherMobile and so on.

Well what if you want to sync a set of values from a multi valued attribute in eDir to a single valued multi valued pair of attributes in AD. Not too big a deal to do, and if you are actually reading articles like this, should be a piece of cake. Ok hotshot, pop quiz then. What about if you want to use the equivalent of "Reset" functionality in the filter? That is, changes in AD should be discarded, since eDir is authoritative. I had to do this once for a customer, and was able to come up with a model where I used a mapping table to hold the single valued attribute name and then the multi valued attribute name, and managed it there. It added a lot of processing, since of course every event written to AD loops back, and has to be reprocessed to be rejected, but that was fun. In that case, because I had 4 or 5 such attributes (Amusingly the 'wwwHomePage' attribute is the same, and its other equivalent is 'url' but otherwise the same model). In that case, it seemed like a generic solution was better than handling each one, the same way, 4 times. Also this allowed them to add/remove attributes from processing just by modifying a mapping table, instead of changing policy code. (Configuration vs coding is a better approach, where possible)

Nonetheless this approach looks good, and is a clever way to handle it.

NOVLBNNRATRK-otp-Subscribe
NOVLPWDSYNC-otp-EmailOnFailedPwdPub

These last two policy objects are basically standard ones, Account Tracking and Password policy emailing. Thus I will not dig deep into them.

That about wraps up the driver. Phew, a bit shorter than the Office 365 series (that took 16 articles!).

Overall this is an interesting driver that is configured for mostly Publisher channel operations, but can support Subscriber channel ops, but you would need to do some work on the Banner end to understand what is being sent by IDM to be received by the BEIS server and handle it properly. Pretty much only for users, not course data (that is a different problem), but the BEIS server can provide the course data if you are looking for it in IMS Global's LIS schema format.

Not sure what driver I will walk through next, maybe the Oracle E-Business ones? I have not tried those yet, so that could be a fun next target. Let me know if you have any requests, I do take them.