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:

• What has changed between Identity Manager versions - Part 1

• What has changed between Identity Manager versions - Part 2

• What has changed between Identity Manager versions - Part 3
  

• More on what's new in IDM 4

Of course most of those features discussed included support for managing them in Designer. In fact, the series on what has changed is more focused 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:

• A first look at some of Designer 4.0 New Features
  

• Let's talk some more about Packages in Designer 4 - Part 1

• Let's talk some more about Packages in Designer 4 - Part 2

• Let's talk some more about Packages in Designer 4 - Part 3

• Let's talk some more about Packages in Designer 4 - Part 4

• Let's talk some more about Packages in Designer 4 - Part 5

• Let's talk some more about Packages in Designer 4 - Part 6

• Let's talk some more about Packages in Designer 4 - Part 7

• Let's talk some more about Packages in Designer 4 - Part 8

There is so much to say about packages, that I wanted to continue on to some more of the interesting features. I realized after I finished the last article that this would really just be a series regurgitating the documentation, so I actually went and checked the documentation to see how much is there. That is when I realized there is almost nothing about building packages in the docs. There is a single long page with almost no useful details in it, so hopefully this series will be a good resource for others. If you see some details in a documentation page missing please be sure to use the Submit Comment button, as there really is a person at the other end of that link. (A busy person usually, but they do often respond).

In the first article Let's talk some more about Packages in Designer 4 - Part 1 I talked about versioning, base packages, building prompts, interesting linkages, GCV and filter extensions.

In the second article Let's talk some more about Packages in Designer 4 - Part 2 I talked about more details in the nitty gritty about packages like localization, dependencies and ordering, and finally about the package catalog and what is stored there.

In the third article Let's talk some more about Packages in Designer 4 - Part 3 I discussed how the process of adding a driver changes with the new package model.

In the fourth article Let's talk some more about Packages in Designer 4 - Part 4 I discussed options about building packages and some of the states that a package might go through in terms of usage, and in terms of recommended development paths.

In the fifth article Let's talk some more about Packages in Designer 4 - Part 5 I started looking at the various resource types that can be part of a package, and how they differ from their standard representation in a driver which would include the various new features added to support the package infrastructure. I was able to cover Global Configuration objects and Filter extensions.

In the sixth article Let's talk some more about Packages in Designer 4 - Part 6 I talked about how objects are named and how a Resource can make changes to the configuration as it is being imported.

In the seventh article Let's talk some more about Packages in Designer 4 - Part 7 I continued with further examples of how the XSLT in Prompt Resources can manipulate the driver configurations. The documentation on packages is pretty light at the moment, so I have been browsing through the packages included with IDM 4, specifically the Active Directory driver, the Managed Systems Gateway driver (used by Reporting) and the Data Collection Service driver (also used by Reporting), looking for interesting items. In the previous article I found a very simple example of using XSLT in the Target Transformation section of a Prompt resource to set an Engine Control Value. I was able to find something more complicated to work through in that article.

In the eighth article Let's talk some more about Packages in Designer 4 - Part 8 I mostly talked about administrivia. Things you ought to know, that are not that important by themselves, but I have not been able to find in the docs, nor find a good place to mention them yet.

In this article I want to continue talking about assorted minor details that are useful to know.

There is a whole bunch of interesting meta data about a package, that is not just configurations, policies, filters, objects. One thing still missing is the ability to deploy an eDirectory schema update, but that is on the to do list I am told. As you can imagine, if your driver required some schema additions in eDirectory it would be great to include them in the Package. Of course, upgrade, downgrade and uninstall would have strange meanings as it is unlikely you would ever consider removing schema from a tree in an automated fashion. Of course it is possible to modify schema, but this is something best left minimized and not directly encouraged.

If you look at the properties of a Package you are building there are all sorts of interesting things you can modify and control.

The pages are:
General
Constraints
Dependencies
Initial Settings
Languages
License
Readme
Targets
Vendor

The General page is where you can change some of the naming information. Name, Short name, and Description. Version as discussed before is set by right clicking on a package and starting a new version. There is also a flag for Released, once that is done it can no longer be modified by anyone else. As the Designer project that created it, a released package can be reopened, by requesting ownership. The good news is that the project can be replicated in Subversion (SVN, the version control program that Designer supports), so if you have multiple developers working on Packages, they can share and have multiple copies on different machines and keep them in sync.

Constraints is simply a place to specify the minimum and maximum version of IDM that this package can be installed on. The earliest is of course always only as low as IDM 4.0.0 since that is when Package support was added to the system. Not sure yet I have seen a use for the maximum version, but I guess that will depend on how IDM changes over the next couple of years.

The Dependencies tab is something I talked about in the eighth article as a real limitation right now. When you build a Package, you get to select what kinds of drivers it may apply too. If your new Package is not one of them, then it will not let you be dependant upon it. This means if you want to require the use of some of Novell's content you need to copy it and distribute it yourself.

Initial settings was discussed in the eighth article as well, and a sample was shown there. Kind of like the iManager export that you might have used in the past. Except of course, most of the thing an iManager export would hold should be represented by objects rather than in the Initial settings. I guess you could use this as an easy way to start a package, based on an older driver configuration, but it would be better if you modernized it by really utilizing the features of packaging.

Languages is all about localization. In the second article in this series I talked about localizing content. At any point, you can right click on the version of the package (has to be the version number node), select Localization, and then Generate Property File. It will then find any field it knows how to localize, and generate a file where you specify. What you do is you copy the file, rename it with _XX with the two letter language code instead of the xx. So for my Test package, I get a file named: TEST_0.0.1_en.properties, which I then copied to TEST_0.0.1_de.properties and entered some silly replacement strings, since my German is lousy. You repeat this for each language you want to support, and when done, you tell it to import the localization property file.

Once you have done that, the Languages page on the Package Properties will show that you have support for an additional language. Makes localizing really a piece of cake. Well done Novell, so much better than the various approaches in the past!

License is a nice touch. You can add a license agreement here, that can be HTML text. I had nothing handy, so I imported the readme.html from one of the Active Directory patches (It was the current directory, when I clicked on the Browse button) and it imported quite nicely and displayed.

There is a Template option that lets you select a language from a template, but I do not know how to set the Template data or location. Another one of those issues, which if you happen to have figured it out, please let me know. Also, even though I have two languages according to the Language tab, English and German, the language drop down for the License still only shows English. Maybe I have to export the localization files again and reimport to get the license in multiple languages. However when I tried that, it did not work. Hmm, not sure on this one.

When you install a package, the license is displayed, and the package cannot be installed, until the user clicks to accept the license. While this is probably not legally binding, it does let you add a EULA style license to your package which is nice, and an improvement over the past.

Next up is the Readme page. This is what got me started on this article topic. This is just a free form text page, but the magical part is the button in the upper right hand corner, that says "Append Package Change Log". When I tried that I got some text dumped in that looks like this:

Package Change Log
------------------------------------------
11/11/10 8:08 AM    Changed installation directive for 'null' (version='1.0.0').
11/11/10 8:08 AM    Changed installation directive for 'Testing' (version='0.0.1').
11/11/10 8:08 AM    Changed supported drivers for package 'Testing' (version='0.0.1').
11/15/10 6:24 PM    Generate property file 'u:\geoffc\Documents\Personal\cool-solutions\to-do\TEST_0.0.1_en.properties' for package 'Testing' (version='0.0.1').
11/15/10 6:37 PM    Changed installation directive for object 'TEST-InitSettingsPrompts' in package 'Testing' (version='0.0.1').
11/15/10 6:37 PM    Added object 'TEST-InitSettingsPrompts' (package association id '4QE9P54Y_201011151837300531') to package 'Testing' (version='0.0.1').
11/15/10 6:37 PM    Changed installation directive for object 'TEST-InitSettingsPrompts' in package 'Testing' (version='0.0.1').
11/15/10 6:37 PM    Changed installation directive for object 'TEST-InitSettingsPrompts' in package 'Testing' (version='0.0.1').
11/15/10 6:37 PM    Changed installation directive for object 'TEST-UpgradeSettings' in package 'Testing' (version='0.0.1').
11/15/10 6:37 PM    Added object 'TEST-UpgradeSettings' (package association id 'R34MACJ5_201011151837500359') to package 'Testing' (version='0.0.1').
11/15/10 6:37 PM    Changed installation directive for object 'TEST-UpgradeSettings' in package 'Testing' (version='0.0.1').
11/15/10 6:37 PM    Changed installation directive for object 'TEST-UpgradeSettings' in package 'Testing' (version='0.0.1').
11/16/10 6:05 PM    Changed installation directive for object 'Test GCV' in package 'Testing' (version='0.0.1').
11/16/10 6:05 PM    Added object 'Test GCV' (package association id 'V9LADBKM_201011161805280359') to package 'Testing' (version='0.0.1').
11/16/10 6:09 PM    Changed installation directive for object 'Test GCV-Prompt' in package 'Testing' (version='0.0.1').
11/16/10 6:09 PM    Added object 'Test GCV-Prompt' (package association id 'STFDTTG2_201011161809140171') to package 'Testing' (version='0.0.1').
11/16/10 6:09 PM    Changed installation directive for object 'Test GCV-Prompt' in package 'Testing' (version='0.0.1').
11/16/10 6:09 PM    Changed installation directive for object 'Test GCV-Prompt' in package 'Testing' (version='0.0.1').
11/16/10 6:16 PM    Changed installation directive for object 'Test GCV' in package 'Testing' (version='0.0.1').
11/17/10 7:42 AM    Changed installation directive for object 'Test GCV' in package 'Testing' (version='0.0.1').
11/17/10 7:42 AM    Changed installation directive for object 'Test GCV' in package 'Testing' (version='0.0.1').
11/17/10 7:42 AM    Sync'd object 'Test GCV' (association id = 'V9LADBKM_201011161805280359') to package 'Testing' (version='0.0.1').
11/17/10 7:43 AM    Changed installation directive for object 'Test GCV' in package 'Testing' (version='0.0.1').
11/17/10 7:43 AM    Changed installation directive for object 'Test GCV' in package 'Testing' (version='0.0.1').
11/17/10 7:43 AM    Sync'd object 'Test GCV' (association id = 'V9LADBKM_201011161805280359') to package 'Testing' (version='0.0.1').
11/17/10 7:43 AM    Removed object 'Test GCV' (association id = 'V9LADBKM_201011161805280359') from package 'Testing' (version='0.0.1').
 11/17/10 7:43 AM    Changed installation directive for object 'Test GCV' in package 'Testing' (version='0.0.1').
11/17/10 7:43 AM    Added object 'Test GCV' (package association id 'F79BJNGL_201011170743530437') to package 'Testing' (version='0.0.1').
11/22/10 8:43 AM    Changed license for package 'Testing' (version='0.0.1').
11/22/10 8:43 AM    Changed license for package 'Testing' (version='0.0.1').
11/23/10 1:45 PM    Built release of package 'Testing' (version='0.0.1') at 201011231345510953.
11/23/10 1:47 PM    Changed installation directive for 'Testing' (version='0.0.1').
11/23/10 1:47 PM    Changed package dependencies for 'Testing' (version='0.0.1').

It date stamps every change I made to the package and lists them off. This is great! Even if I were not going to import this into the readme, to distribute I am very happy to have this much tracking available. Would be nice to have access to it other than in this approach, but even this I will take with open arms. You can see all the goofing about that I have been doing with this test package trying to discover how some of the feature work.

You can see a couple of interesting things that come of value at a later date. For example, when I was looking at a driver export from an Identity Manager 4 Packaged version of the Active Directory driver, I noticed some new tags in the iManager Configuration file format export. If you have ever looked at one of those, you will know that the DTD is pretty well constructed as the tokens they use to describe things are quite readable and understandable. That is, all the stuff in the Subscriber channel is under an XML node token called, you guessed it subscriber. Thus by looking at the iManager configuration export you can understand it, and figure out how some of the underlying things work.

I have written before about how you might do something like this in this article:
Importing a Driver Export File Without Password Prompts

In that example I was able to easily find the part of the configuration that causes the passwords to be prompted for, during import. By removing them, the prompts go away.

Anyway, what you will see is that the format of the driver configurations that gets exported did not really change in a major way, with the advent of packages, rather they extended the XML format using a bunch of addition XML attributes. That is, the stuff that goes inside a node, like the attr-name="CN" that you see in many XDS documents.

One of the tricky bits that was unclear from looking just at the iManager configuration file export format is that there are a number of references within the export to the Package the rule comes from, mostly via a GUID like reference. (That is a long string of digits and letters). Well if you look in the log that was generated, you can see the object GUID's for each of the various components that I added into my test package.

Sync'd object 'Test GCV' (association id = 'V9LADBKM_201011161805280359') to package 'Testing'

The association id is the part I was referring too. There a couple of other interesting things I found while looking at the driver configurations when Packages are involved, but I think I shall save that for another day.

Now obviously this entire change log is not the sort of thing to leave for the customers to see, but darn if it is not useful for tracking some of the changes made, and when. Actually the time periods are pretty funny. You can see they are mostly mornings and evenings as I ride home on the bus. I do have to say, trying to grab and edit nice looking screen shots while the bus is bouncing around, using a touch pad turns out to be harder than I expected! (I wish I had room to use my mouse. Darn you New Jersey transit for such narrow seats!)

If you look at the Readme that is available when Importing Packages into a Project, you can see that Novell is at least adding some measure of detail as to what was changed in each version. What is a smidgen annoying is that when you are looking at USING a Package in a Project and trying to select a Package from the list, the Readme option is not available. It seems it is only available when you are importing into a project that does not yet have the Package. That is, your Designer will check with Novell for updated Package files from their Content Distribution Network, but that is loading it into the file system. Then per Project you need to import the set of Packages you wish to make available to the Project. (This information is NOT synchronized to the eDirectory tree, this is a Designer side project thing only). When you do this process (say you started an empty test project, and then select the Package Catalog at the root of the project and choose to Import Packages, then you get a Show Readme button on the interface that gets displayed. This is as far as I can tell, the only time you get to see this information. I think this is a mistake, as I would like to be able to more easily go back at any time and see what the Readme says for any arbitrary package.

Targets is the next page, which I am not entirely certain as to the point. It shows where the package is targeted, but of course while you are building it, it would be your test tree. Which obviously won't be stored in the package that way. I imagine this is more of a representation of something from the General page, which was Type, which allowed IDVault, Driver Set, or Driver. Thus this shows that it is targeted at a Driver Set.

Lastly is the Vendor page, so you can modify the Vendor information you entered when you first created the package. This is nice, since email and telephone information does change over time, through mergers, moves, and what not.

As you can see there is still a fair bit of functionality in Packages that needs to be looked into, but overall it is looking really good, and I am very much enjoying working through all the options.