A first look at some of Designer 4.0 New Features


Novell Identity Manager has a number of components that distinguish it from its competitors. DirXML Script is one of them. Being Event based is astonishingly powerful, when you look at the things other systems have to do to simulate the same thing (like reconciliation processes).

But the icing on the cake has been Designer for Identity Manager. Each release has gotten better and better, adding more features and functionality.

Some of these features have required engine changes, like adding new tokens, but others have been all about the user interface in Designer. A simple example of that would be the time token (Using the Time Tokens in IDM 3.5 ) which in iManager is pretty powerful,. but in Designer gets even better. The user interface for selecting time patterns is much nicer in Designer, and there is a Test button, which shows you the format that you have just specified, so you can double check that you got it correct. Simple UI tweaks like this can make a world of difference.

With the upcoming Identity Manager 4 release there is a new Designer (version 4 to match, current version is 3.5.1) that has several of this minor UI tweaks, some major interface changes and some very nice engine changes reflected in Designer.

This is just the first of many articles on new stuff coming out in Designer 4 (and of course Identity Manager 4.0) so stay tuned for much more as the release date gets closer and closer. (I have no idea nor inside information on when that date might be.)

The biggest change that Novell was showing already at Brainshare 2010, Utah in March was Packaging. This feature takes a moment to wrap your head around. The engineers are calling it RPM's for driver configurations.

I think an example can illustrate it nicely. Lets talk about the Active Directory driver. If you have ever looked at the policies in the default driver configuration you will have seen them evolve over time. In fact, I have a Designer project with IDM 2, 3, 3,5, and 3.61 drivers imported so I can go back and compare to see if a specific feature has been changed between the versions. Designer is perfect for this!

Over time a number of pieces of functionality have been added. There was the Identity Tracking rules for the Sentinel's Identity Injection that added policy to format events that come through to look the way Sentinel wants them. This is a set of policy objects, and some GCV's to enable or disable it.

Going back further, functionality to add support for Entitlements was added way back in the Identity Manager 3.0 (I think) or earlier time frame. Now with Roles Based Provisioning Module 3.7 and the advent of Resources to abstract away Entitlements, you need to add some policy to manage them (Convert Driver Entitlements to New RBPM 3.7 Resource Model, Converting Entitlements to Resources, more details).

In each of these cases, there is nice discreet functionality that has a number of pieces (Policy objects, GCVs, Filter changes, even PRD's, DAL entries, and more!).

What Novell has done is to cut out everything that is easy to cut out, to build a base package that gets you simple event synchronization between an eDirectory instance and Active Directory. Then they have bundled together all the bits and pieces that are needed to enable Entitlements, and the new Resource model. (You still need both, Resources are just an abstraction layer to hide the ugly naming of Entitlements, and a Resource points at a single Entitlement. Or as a friend said (Hi Mike W!) Entitlements are for computers, Resources are for people.)

Then they made a standalone package for Exchange provisioning. Then a package for Identity Tracking. They even carved out Password Synchronization, since that is an easy one consisting of the group of five or six rules in each Command Transform and a set of GCV's. (Subscriber and Publisher channels. You can read more about how these rules work in these articles:

Password Transformation Rule Sets

Password Transformation Rules in the Publisher Channel )

Thus now instead of applying a monolithic driver configuration policy that has everything in it, you will pick a package, that starts with a base package, which may have some dependencies (remember the RPM reference?) in terms of mandatory and optional package.

But perhaps best of all, the various packages all have version strings, and can require specific versions of the linked in packages. I LOVE version strings! (Almost as much as I love Comment fields!)

You can see how this will make an upgrade, like adding support for Exchange 2010 to the Active Directory driver easier. If you ever went through that process you would know that you need a new ADDriver.dll file (this new feature will not help that issue... Driver shims are outside the scope of Designer) and a new configuration parameter in the driver properties. The TID explains how to copy and paste the needed XML in, and I have to admit was not the clearest thing in the world. (I.e. I got it wrong on my first try!). Once we get going on packages, Novell could just release a version x.x.1 increment, say 4.0.1 of that driver shim and when you applied it, you would get the new GCV and maybe some new policy as well to manage it.

Even more interesting is that once you start using packages, there is a feature called Factory Mode (This is set Driver level, in the Packages item of the Driver Properties). This is really meant for support critters. A Identity Manager is a series of policies, in at least 15 different places. (Each channel has Event, Match, Create, Placement, Command (10), plus Input and Output transforms (12), the filter (13), the schema map (14), and the driver configuration (engine control values, GCV's, etc). That is before you start doing anything fancy like Entitlements or mapping tables or the like. Now imagine you are trying to support an Active Directory driver that is not working well. The client says, "I didn't change anything, I swear" and of course we believe them, right? Of course we don't, thats why we read through trace to see if we can see the problem and show them what they changed. Well in Factory Mode, if all your driver configuration cane from packages then there should be no changes. In Factory Mode, Designer reverts the driver to ONLY use exactly what is in the packages installed. It unlinks any added in policy objects, and any changes within Policy get reverted to the Factory default.

That sounds great, but how do you update a driver to fix a minor bug, once you have it deployed using packages? Well more good news! There is a Package Developer Mode switch (set on the Identity Vault) that allows you to make new Package objects, and start adding Policy, GCV's, Settings, etc to the Package.

When you are done, you can Build a package (and Release it, more on that later). You can then hand the built package to your testers to play with and once they have found all the bugs, you can then build it again, this time ticking the Release button. Once it is released, it is fully locked down, and that is new definition of what Factory Mode reverts too.

This means Partners and Consultants can actually deliver a "Build" version of the driver, and validate that it is in current use. As a consultant, this is a lovely thing. I of course want more, like a report that shows all the changes from Factory Mode, at any point in time. For example if I deliver a build to a client and come back a year later for the next phase, a refresh, or whatever, it would be great to run a report in Designer and see what tweaks they had made over the course of the year, and maybe even bundle that into a package itself! You can see why this feature is so appealing.

I also like the idea that by compartmentalizing some of the functionality that it should be easier to get changes made and tested. As many of my frequent readers will know ( http://wiki.novell.com/index.php/Detailed_driver_walk_through_collection ) I am a huge fan of documenting driver configurations, and really wish we could get Novell to do so. Well, once we go to Packages, it is a lot easier to dedicate a resource for a couple of hours to document a small package at a time, and then release it to the world, instead of trying to get the time committed to document the entire driver, which really is a large task, and I understand why it is considered low priority, even if I do not agree with it.

Next question is, how do we get these packages? How are they distributed? The good news is that Novell has a distribution URL set up for Designer online updates set up already. It is http://cdn.novell.com/cached/designer/updatesite3_5_0/ for Designer 3.5 and you can probably guess what the 4.0 site will be named. Once you build (released or not) a package, you get a JAR file with all the contents compressed in, and a features directory with a manifest file. Make that directory and JAR file available over HTTP (or HTTPS) publicly or protected with credentials and you can do an online update in Designer to look for more. Even better, Designer 4.0 will support more than one Update sites.

Thus a partner that makes their own drivers, could deliver the packages to all new Identity Manager 4.0 customers just by publishing a URL. (For a list of all the drivers I have tracked down, you can read: Open Call - IDM Association Values for eDirectory Objects where I have tried to link in Association values and drivers, for as many of the third party drivers I have found.) No special infrastructure needed, no App store to try to get it added too.

Packages are going to be so much fun in the coming releases, I am really looking forward to it!

There are still several more interesting things buried in the concept of packages, and that may be worth another article later. But first some new features in the engine that Designer exposes.

For me the killer change is such a simple one that I have wanted for a long time! In the Provisioning side of the house, when you are building Workflows, there is now a GCV.get() function! Yay! GCV's that are linked to the User Application driver are made available to the GCV.get() function, so if you already had defined some servers, DN's, etc you can reuse them in Provisioning, instead of having to come up with a model to create global variables yourself. Heck we even wrote a driver once in a big provisioning piece to detect changes to DirXML-Driver objects, for the DirXML-ConfigInfo attribute to detect changes to GCV's on a driver, and synchronize them to an easier to read format as objects in eDirectory. Then we could easily read them out in ECMAScript. This simple function obsoletes all that, and it is a lovely feature that makes me very happy.

In a similar vein on the Identity Manager/engine side of the house we have had the ability to store ECMAScript functions in a ECMA Resource object since Identity Manager 3.5. You link it to the drivers that you want to use it, and then when they call a function name it is available. On the Provisioning side of the house, you had to redefine your functions all the time, since you really could not build a library of them.

With the Identity Manager 4.0 and Designer 4.0 releases you will be able to call any ECMAScript function that you link to the User Application driver. When you get the ECMA function editor with the flowdata columns, there is a new provided value for ECMA functions.

This will save lots of repetitive typing and duplication. More than anything else, when you realize you have a bug in say a parser you use in every workflow, a single change will update all of them, instead of finding and fixing it in dozens of locations.

As you can see these changes are really going to make things better. As always, they have been working on performance, and memory footprint issues and general bug fixes across the board. It will probably take me a while to figure out some of the more subtle UI tweaks and changes, but I hope to be able to report on more as I run across them.

IDM 4 is going to be a great release! I can't wait!


How To-Best Practice
Comment List