Novell Identity Manager initially came with a Console One plugin to manage policies and stylesheets, back when it was still called DirXML. Then as the product matured and DirXML Script became available we got iManager with plugins to manage it.
When Designer for Identity Manager was released, it really was a game changing paradigm shift for Novell's product. Being able to take a project offline, work on it, come back, push out (and double check) your changes made how we work on IDM projects totally different. Documentation generation did not hurt either!
Each release of Designer has added new features and functionality. I recently worked through a series on what is new in Identity Manager 4 Advanced Edition (and compared it to what was introduced with IDM 3.5 and 3.6 releases), which you can read here:
Of course most of those features discussed included support for managing them in Designer. In fact, the series on what has changed is more focussed on what has changed in Designer. But that was a high level overview and so much more has changed down low in weeds it is going to take a fair bit of work to get through them all.
With Identity Manager 4 Advanced Edition there are some major engine and Designer changes that are yet another example of a paradigm shift, and it can be summed up in one word, Packages. I started talking about Packages in these articles:
I wanted to continue on to more interesting features of packaging. Last article I talked about versioning, base packages, building prompts, interesting linkages, GCV and filter extensions.
I have not yet tried it, but I am told that localizing a package is much easier which will make our non-English speaking friends happier. (What do you mean the whole world does not speak English?). I personally only speak one language, but can read two others (I have a lousy vocabulary in each and am quite slow to come up with words on the fly so I cannot really speak them) so this is not of that much interest to me, but is important to Novell. Novell has always been very supportive of multiple language. I heard a good story about why some of that happened. Apparently in Utah, where Novell (and WordPerfect another early adopter of multi language support) were based initially, there happen to be a fairly large concentration of Mormons, who often go off on missions to other locales. They usually come back having learned some additional language or three in the process, and thus Utah for this otherwise inexplicable reason has a lot of people available who speak many other languages. More so than in most of the rest of the United States.
Anyway, once you have a package mostly ready, you can export the localization files, have them translated, and when done, import them back in to finish the package. This should make life a lot easier for supporting all those languages. Now alas, Comments in the policy (or in XSLT) are not really supported for localization as far as I know, the focus is more on prompts and names of things, but even so, it is nice having this support. Additionally not everything is flagged as localizable, and it is not clear how you would add additional items into the list of things being localized.
The export generates a simple file, with the name of the resource, and then the string describing it in English. You would then copy the file, send it to some one who speaks the target language and get them to edit all the strings in English to be in their language of choice. Once done, you rename the file they have with _XX (EN for English, DE for German, and so on) and you can import the other languages back in. Neatly after you do that, Designer recognizes the extra language support in the display.
When you import a Package, much like you used to do when importing a default configuration, there is a Wizard that prompts you for various bits of information. This reacts to set of packages selected to install, and allows you go backwards and forwards through the process, which is a nice change. How this wizard generates pages and prompts is controlled by the prompts configured by the package builder.
On top of all this, there is also a notion of dependencies and ordering. That is really two different things, but sort of similar. First off we have dependencies. This means Package B cannot be installed unless Package A is already selected or installed. For example, you probably cannot install the Exchange mailbox management packages until you have the Active Directory packages. Kind of makes sense, and clearly you need this sort of support.
But then there is an even better twist! You can specify a version dependency! That is, this version of Package B cannot be installed unless Package A, version 1.0.3 or higher is installed. In fact the package can require a specific version of Identity Manager, with a minimum and maximum value specified. By default all packages start with a minimum requirement of IDM 4.0.0 since that is the first version that can support packages. Additionally a package can be set up so that it will only install with certain drivers, or all or none. This is useful for the previous example of password management policies which are involved in most drivers, but then Exchange mailbox management might only make sense in the case of the Active Directory driver.
However, just because we have dependency enforcement in the package installation is not the end of the story. Without some way to resolve those dependency conflicts we would be back in the days of DLL hell, and RPM madness. Thankfully, if you select a package with some mandatory dependencies then Designer will show and select the packages needed so you can actually successfully install what you want. Without this feature, it would have been a huge problem.
The second part is ordering and priority. What this means is that when you build a package and you are inserting a policy object into the say Command Transformation policy set, well thats a pretty busy policy set. In the old default Active Directory driver configurations, you had 4 or 5 password management policy objects, the Identity tracking policy, two or three other policy objects. It is quite cluttered. This feature allows you to specify how to insert the rule with better finesse into the appropriate location in the chain of policies. After all, if you are expecting a certain XML document to come into your room, and a previous policy object normally makes a change you are depending on, then you need to get that sequence correct.
There are package targets, such that you can make a driver package, a driver set package, even an Identity Vault package. This gives you lots of functionality. Alas, schema extensions are not yet supported but are on that ever growing future wish list of features to be added.
At a more practical level, when you use Designer 4, at the root of each project, in the Outline view there is now a Package Catalog. Your project starts empty of packages. Designer comes with them, but you have to choose which to import into your specific project, all, none, or some. You can also use this to import third party packages, say from a vendor that has a specific driver you want to use, like a Google Apps driver or the like that Novell does not offer. Of course, just like Novell has a Check Updates for Designer itself now, (at least two updates were pushed this way for Designer 3.5) there is also an update channel for Packages. This way, instead of needing to get a new configuration file from Novell or a vendor, you can get the updates online. Of course if you are working in a dark dungeon with no internet connectivity you can smuggle in some packages via the file system and import it. As a consultant, you can turn the Identity Vault into Package Developer mode, and start building your own packages right away. They end up as a JAR file with a subdirectory or two, so they are easy to distribute. You can make them available via any web server exposing the file structure to a browser.
Once you have packages imported into your project, you then have them available when you try to add a new driver to your driver set. You can open the Properties of the Identity Vault, Driver Set or Driver and on the Packages tab, add, remove, upgrade or downgrade packages. Perhaps you can understand more of my enthusiasm for this feature now! This is going to be awesome to use!
There is all sorts of fun meta data associated with a package. Of course the version information is critical. But also there is a whole set of Vendor information, so you might be able to track down who wrote the package at a later date if they fill in the information. I am a huge fan of extra meta data, and commentary where possible, so this aspect makes me happy. They track company name, web page, phone number etc, but only one field is mandatory.
Along with this level of information there is a README field that shows up when you are selecting a Package to import, or install. You can enable the Readme view and as you cursor down through the packages a readme pops up in the right hand side. This is great if you are trying to figure out which package you want to install.
I have to give big kudos to the Novell engineers who worked through building packages from all the existing driver configurations. I am often harsh on the default driver configurations, and though I have not yet had time to work through any of the packaged drivers in detail yet, I am very happy to see that all the meta data fields seem to be filled out, and the readme's have lots of useful versioning information in them. This is a definite step in the right direction. Of course, now that we have packages making it so easy to upgrade a driver configuration, I expect to see a lot more updates made available as issues are recognized and fixed.
Now not only is there a readme section, but when you develop a package, you can supply a license agreement that means the package cannot be installed without agreeing to the license. This is nice if you are a developer of third party drivers. This is a legal sort of thing for protecting intellectual property. There is also a protected flag which will prevent changes being made to packages which is nice as well.
There is some hierarchy of packages as well. They gave us two levels of ordering, mirroring the pallete on the right side of Designer somewhat. There is a high level category, which is basically like the roll up/roll down segment of the driver pallete, with things like Directory, E-Mail, Notification, Service, etc. Within each Category there are groups to break it down further. Under Directory, there is a Active Directory, eDirectory, and LDAP set of groups. The Active Directory group has the following packages:
Active Directory Account Tracking
Active Directory Audit Entitlement
Active Directory Base
Active Directory Default Configuration
Active Directory Entitlements and Exchange Mailbox Support
Active Directory Managed System Information
Active Directory Password Synchronization
Now as it turns out there are a number of dependencies that these drivers expect like:
Audit Entitlements Common
Account Tracking Common
Data Collection Common
Advanced Java Class
Common Settings
You can see that there are some packages that are common and shared, just from the names, and others that add the specific driver related stuff. When you look at the depth and scope of the package catalog that comes with Designer you get an idea of how much work was involved in this conversion. It also explains why from the engine side of Identity Manager it does not look like too much changed in IDM 4. However the more you look at packages the more you realize how monumental a task this was to build and bring to market, even if it is somewhat hidden in the back end.
Overall I am a huge fan of the idea, and now I need to find the time to start playing with the packages, complaining about things I do not like (Since that is mostly what I do. Those who can, do. Those who can't, complain) and trying to get them fixed.
Support
Documentation
Learning Services
Partner Programs