Wednesday, May 26, 2010

eDirectory Installation Errors

More troubleshooting fun today.  Large customer, lots of users, lots of drivers, needed more horsepower.  How do we get more horsepower?  That's easy, throw another server in the mix.  Step one of adding a new server to IDM, install eDirectory and join it to the tree.  This is where I got hung up and for some reason it actually took a little while to click in my head.

I was starting the installation, then receiving timeout errors.  Come to find out, I had forgot to turn off the stupid Windows Firewall.  It was blocking the replication and all of the other things I need to work to get the tree working.  My install should work now, but I need to go through and cleanup that old install and get cracking on the new one, there are a few things that I have to do for this to work.

First, I had to do the basic Add/Remove programs thing.  Of course, being Windows, this rarely, if ever, actually removes the entire program.  The next step was to go remove the C:\Novell directory in its entirety.  I had to escalate to admin privileges for this.

At this point, you would think it works, but it does not.  The stupid NDS console thing still exists in the control panel and needs to be removed.  This is the tricky one.  To remove this (and complete the uninstall), you must remove the following file:

C:\Windows\System32\NDScpa.cpl

Now, you can actually start the eDirectory installation again, but you have another problem.  The eDirectory object name for the server already exists.  Due to the installer crashing out early, you must go and manually delete two objects from the directory.  The server object and the ndsPredicateStats object.  Both will be named pretty obviously specific to your server (unless you changed them, in which case, shame on you).

After this, you can continue the installer (this time without the windows firewall!) and everything is happy.

Tuesday, May 25, 2010

Novell IDM Syntax Violation Errors

I was recently working on a driver.  I had finished the driver and everything was working great.  I then started getting the following errors on my driver:

Code(-9010) An exception occurred: novell.jclient.JCException: createEntry -613 ERR_SYNTAX_VIOLATION

After yanking out some of the hair on my scalp, I took two traces, one of a user that was created successfully, and one of a user that kicked back this error.  I looked at the XML document after all the driver logic was finished just before it tried to create the account.

What I found was there were very few differences (I hope not), but what ended up standing out is that in one of the traces, the user had a blank value for their Title attribute, and looked similar to this:

<add-attr attr-name="Title">
   <value type="string"/>
</add-attr>

Why is this significant?  Because if you look at the schema for eDirectory, the attribute Title is sized, with a minimum length of 1 character, meaning a blank attribute is not valid.

The resolution for this was simple.  I found all attributes that had sizing restrictions on them, then simply did a check and stripped them out if they had a blank value.  Here is what the Title attribute sample looked like:

<rule>
   <description>Strip Title if blank</description>
   <comment xml:space="preserve">If title is a blank value, strip it so it doesn't cause a syntax violation.</comment>
   <conditions>
      <and>
          <if-class-name mode="nocase" op="equal">User</if-class-name>
          <if-op-attr mode="nocase" name="Title" op="equal"/>
       </and>
   </conditions>
   <actions>
       <do-strip-op-attr name="Title"/>
   </actions>
</rule>

Once this was done all of the errors disappeared!

Thursday, May 20, 2010

Sharing Policies between Drivers in Novell IDM

Working with Novell IDM to integrate an HMS Payroll System hosted on an AS400 system in a DB2 database.  The customer has approximately 120 of these databases that need to be interfaced.  In order to accomplish this, I need to create 120 separate JDBC drivers.

I was able to architect and implement the drivers in such a way that all of the policies are identical.  The only differences between them are the connection parameters and some GCV's.  With all of the policies identical, I wanted to deploy them in such a way that updates to the drivers are easier than duplicating the modification 120 times.

By creating a new Library container within the driverset, I was able to reference the policies within the drivers from the shared Library.  This allows all of the drivers to subscribe to the same policy and XSL objects.  When an update needs to occur for the 120 drivers, the policy in question is updated in the library, then all of the drivers are restarted. 

To expedite the process of restarting all of the drivers, I simply restart DirXML on the servers hosting the drivers.  This will force a restart of these drivers, so long as they are set to automatic startup.

Please note that the Filter cannot be shared as it must exist on the driver object, so changes to filter will still require changing all 120 drivers individually.

Wednesday, May 19, 2010

Novell IDM CSV Fanout Driver

In a traditional Novell IDM CSV driver, you have one event, which will create one output CSV file.  You can use the output transform to format the CSV files output so it does not necessarily have to be a true CSV file, but a text file of any format you wish.

I was recently presented with a unique challenge where I needed upwards of 120 or so CSV files for a single event.  The total number of files was dependent on a few factors, but they are irrelevant as that logic was programmed in policy.  The part that was pretty nifty was creating my own version of a CSV fanout driver.

Instead of using the traditional CSV driver, I used a Null Services driver.  I used typical policy to determine my outputs, but did so in a loop, so I could loop through each iteration of an output.  Each time I hit a valid output, I constructed my text file format and held it in a local variable.  It looked something like this:


<do-set-local-variable name="lv.outputString" scope="policy">
      <arg-string>
            Construct string here
      </arg-string>
</do-set-local-variable>


I then added a ECMAScript object to my driver and added it to the driver configuration.  The ECMAScript was very simple:

importPackage(Packages.java.io);

function writeFile(fileName, contentString)
{
    try {
        var printFile = new Packages.java.io.PrintStream(fileName);
        printFile.print(contentString);
        printFile.close();
        return "";
   } catch (e) {
        return e.toString();
   }
}

All I needed to do at this point was use an XPATH expression to call my ECMAScript function.  I pass it the path to the file I want to create and the string I created.  The function will create the file with the contents I specified.

The only thing to note about this is you will need to use unique filenames.  The way I found to most easily do this is to use a timestamp.  The following file path uses a timestamp down to the millisecond, so it should always be unique.

   <do-set-local-variable name="lv.outputFile" scope="policy">
      <arg-string>
          <token-global-variable name="outputfilelocation"/>
          <token-text xml:space="preserve">\</token-text>
          <token-time format="yyyyMMddHHmmssSSS"/>
          <token-text xml:space="preserve">.csv</token-text>
      </arg-string>
   </do-set-local-variable>

Once we have the output file string, the contents string, and the ECMAScript object created and added to the driver, we just need to use our XPATH expression to call it and write out our files.

  <do-set-local-variable name="result" scope="policy">
     <arg-string>
          <token-xpath expression="es:writeFile($lv.outputFile,$lv.outputString)"/>
     </arg-string>
  </do-set-local-variable>

The local variable "result" is holding the return value, which should be blank.  If it is not blank, then there was a problem and the exception that was caught should be held in this value.  This can be used for simple error checking.

Novell IDM Fun at a Large Hospital

I’ve been working with a large hospital chain and working on solving some pretty complex challenges.  Recently, we have been working on implementing some McKesson applications within their organization, but we also wanted to implement it with the concept of ‘Roles’ kept in mind.

Let me first start with our application challenges.  The two most commonly used McKesson applications are HCI and HPP.  For HCI, we found that there is an engine underneath called cloverleaf that uses a standard protocol called HL7 to send messages around.  We have three options to explore.  The first is a proprietary HL7 driver that will connect to an HL7 listener, and pass it a carefully constructed HL7 message (the message I have to construct in the driver output transform).  The second is to use an HL7 emulator that is already in place to consume a text file in the format of that same HL7 message.  The third is to use an open API that I found to open a socket using the java api.  I can call the java api from ECMAScript and use an XPath expression within my driver to do it.  Once I open the socket, I simply pass the same HL7 message used by the other two steps through it.  Currently, I’m debugging option three, and we have already done some preliminary testing on option 2.  If we can’t get option 3 working, we can fall back on 2.

For HPP, we did something pretty nifty as well.  The customer identified an API that could be used to interface with the HPP database.  They stood up a web service that I could send calls to in a very specific format to add/modify/disable users from that system.  I simply construct a URL with a bunch of arguments on the end and call the URL.  The webserver will take the URL, process the transaction and post back a return code instead of a bunch of HTML.  Very simple implementation.  The key part was to encrypt the arguments so I wouldn’t be sending username and password combinations over the wire in clear text.  I did this by implementing an encryption protocol using ECMAScript and XPath within my driver.  So now, my URL has a bunch of seemly meaningless characters on the end, but the webserver can decode this into a meaningful set of arguments.

The next challenge for implementing these two applications came up when the customer requested to not have over 200 drivers to do this implementation.  There are over 100 locations for this customer and each location has an HCI and HPP implementation.  We needed to architect the drivers in such a way that one HCI or HPP driver could service more than one location.  Just to add a little more fun and complexity, the customer also wants the “Roles” concept to be built in as well.

I worked with the customer and we kicked ideas back and forth until we came up with what we thought would be a great implementation.  We took the idea of a ‘role’ and decided to turn it into an edirectory object.  We also decided that we may as well make each ‘facility’ its own object as well.  We already have objects for each ‘user’.  Here is how they all tie together.  For HCI, there will be a ‘role’ for each role in that system (or you can define a role in HCI as a combination of attributes that consists of access to that system).  For each facility, we will create a ‘facility’ object.  We already have a ‘user’ object for each user in their system.  So, now we have a ‘role’ object with a bunch of attributes that define what the “Nurse” role in the HCI system consists.  We also have a facility object for Hospital 123, with some attributes telling us information about that location, such as the location of its HCI system, the port number, private key file used for securely coping files over, and such.  The only information we need to store on the actual user is what role and what facility (Role – Nurse, Facility – 123).

Due to the fact that a user at this customer could potentially have access to multiple locations at the same time, we had to ensure that the attribute where we store the role and facility for HCI and HPP were multivalued.  So, we now have two attributes attached to user (well, attached to an aux class, which is attached to our users).  These two attributes are multivalued lists of facilities with roles.  We now have what access and where it should be provisioned in a list format attached to each user.

In the actual logic, we keep an eye on this attribute to know when we need to provision/deprovision/modify an account on a respective system.  I used a series of loops to go through each value and did ECMAScript functions with XPath calls to actually write out files or call URL’s.  This allowed me to service multiple sites with a single driver.  I just used a multivalued GCV on the driver to list which facilities are supported by this driver (so I could split the load if required).  When the driver determined work needed to be done for a user, I would retrieve the access information from the role object using an XPath call, then retrieve the information on where to provision this information from the facility object, tag all that information with what I need from the user (username, password, etc), then make my call.

We were able to successfully implement complex IDM systems, such as McKesson HCI and HPP, using the out-of-the-box Novell IDM components and some creative architecture.  This also gave us the ability to grant roles into the framework and service multiple sites with a single driver for each system.  The drivers can be split up if required for load balancing.   Also, if a role needs to be modified in the future, we simply need to modify the ‘role’ object in question, without having to touch the potentially thousands of users subscribing to that ‘role’.