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

I wanted to continue on to more interesting features of packaging. 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 this article I would like to talk about some of the states that a package might go through in terms of usage, and in terms of recommended development paths.

When you are building your own packages there are a couple of states it can be in. You can see some of the options in the screen shot below.



Note that you have to have set the IDVault (aka the tree) Properties page to enable Package Development mode to get these menu items.

The first item on that menu is Generate Prompt Resource, which gives two sub choices, Initial Settings and Upgrade Settings. This was discussed somewhat in the first article in this series, that there is a sophisticated prompting system to allow you to interact with the user and do all sorts of interesting things with the policies, both at the install time and at the upgrade time. We saw some of the screen shots of the results in the third article, where many of the packages in the Active Directory driver had prompt pages.

When you choose either of those options, a container is created under the Version number, called Resources, with objects TEST-IntSettingsPrompts and TEST-UpgradeSettings created. These are the Prompt resource objects that you have to then use to build the prompts.

When you first click on Properties of either of them, you will something like this screen shot:


You can see this is something of a generic tool, since you can change the type of the Resource after the fact. The Order field is meant to allow you to give priorities and allow certain prompts of greater priority to run first. Perhaps you want to chain the results together or the like.

Targets is kind of interesting as you can see what it is linked too.

The Prompts item in the left hand column is the general GCV style editor. Nothing new to see there.

Prompt Transformation and Target Transformation are XSLT style sheets that do the magic. I will have to find some time to work through how this works, since this looks interesting and complicated!

Next is localization. As discussed in the second article in this series, you have an option for localizing the various prompts and fields in your Packages. The submenu will show two choices:

• Generate Property Files

• Import Property Files.

You generate them, get them localized and then import them back in. When you select to Generate the property file, it asks for a directory to put the files, and it probably generates one file per package, or might even do it per object in your package, I would have to test to find out. A localization file looks something like:

pkg.description=This is a test package
pkg.name=Testing

You can see I am starting with a silly basic package. Alas, all the packages from Novell are already in the 'Released' state and therefore I cannot generate the property file from them to see what they look like in a real use case. However, since the packages are basically distributed as Java JAR files, which are basically ZIP files, it is pretty easy to open them up and look at the contents. So I looked into the JAR file that the packages are distributed as, and there is an XML configuration file there, with typical driver export files that Designer or iManager might generate. Looking at one of them, I see a series of properties nodes: (with the lang='en' indicating the language code)

<properties lang="en">IwojV2VkIFNlcCAxNSAwMToyMDozOCBNRFQgMjAxMApwa2cuZGVzY3JpcHRpb249QXVkaXQgdXNlciBhY2NvdW50IGVudGl0bGVtZW50IGFjdGl2aXR5Lgpwa2cubmFtZT1BY3RpdmUgRGlyZWN0b3J5IEF1ZGl0IEVudGl0bGVtZW50cwo=</properties>
<properties lang="de">IwojTW9uIFNlcCAyMCAxNjo0NzoyMyBNRFQgMjAxMApOT1ZMQURBVURFTlQuYXBwY29uZmlnLmxhbmc9ZGUKcGtnLmRlc2NyaXB0aW9uPUJlbnV0emVya29udG9iZXJlY2h0aWd1bmdzYWt0aXZpdFx1MDBFNHRlbiBwclx1MDBGQ2Zlbi4KcGtnLm5hbWU9QWN0aXZlIERpcmVjdG9yeSBBdWRpdC1CZXJlY2h0aWd1bmdlbgo=</properties>

Those are Base 64 encoded text strings, which decode to something like:

#Wed Sep 15 01:20:38 MDT 2010
pkg.description=Audit user account entitlement activity.
pkg.name=Active Directory Audit Entitlements

Usually to base64 decode something, I use a web based decoder that lets you paste the text in. Since I was on the bus ride home as I wrote this, with no Internet, I just wrote a quick rule in Designer that had an action that looked like:

<do-set-local-variable name="TEST" scope="policy">
	<arg-string>
		<token-base64-decode>
			<token-text xml:space="preserve">IwojV2VkIFNlcCAxNSAwMToyMDozOCBNRFQgMjAxMApwa2cuZGVzY3JpcHRpb249QXVkaXQgdXNlciBhY2NvdW50IGVudGl0bGVtZW50IGFjdGl2aXR5Lgpwa2cubmFtZT1BY3RpdmUgRGlyZWN0b3J5IEF1ZGl0IEVudGl0bGVtZW50cwo=</token-text>
		</token-base64-decode>
	</arg-string>
</do-set-local-variable>

Then I ran the Simulator (it is in the upper right hand corner of each Policy tab, a little chevron (looks like one of the Policy Set chevrons) with a little Run button on it. Which I thought was a funny way to do something. I am running my laptop on Windows, so I do not have a native base 64 decoder installed. Linux usually comes with such a tool as part of some package you install just to get running.

In order to add additional languages, you take the localization file, which is driverName.Version_en.properties and you replace the _en with the two letter code for your language. So that would be _de for German, _fr for French and so on. Copy the english version file, rename it to the appropriate language code indicator, and then hand it to someone to translate. This way, they have the template of what the English says, and they can just replace the English string with their languages translated version.

Obviously the first part stays the same (pkg.name for example), it is the second half of each line that gets translated (Active Directory Audit Entitlements).

Anyway, once you have the localization complete, or even a single language complete, you would just import it back, (by specifying the correct directory it reads back all language versions in the directory) in to your Designer via the same basic menu item and then you have multi language support ready. In fact after you do that, you can go to the Propeties of the package page, and look at the language tab, and although all the languages are ghosted out, you should see check boxes for the imported languages you added.

Next on the menu is New Package. This presents a screen, that is familiar from when you created the package in the first place.



This is used for when you are getting ready to release a new build of the package. You can copy the content from the previous version into the package and then modify it as needed for the new release. This would allow someone running the 0.0.1 build, once they had the later builds in their package catalog, to upgrade. Packages can target the Identity Vault, the Driver set or the Driver, so you would need to look in the proper place to find the package to upgrade.

Of course you have to increment the revision, since the current revision is already in use. Then you go through the usual steps of setting Identity Manager minimum (implicitly 4.0 since only 4.0 supports packages so far) and if you want, a maximum value. You can then update the vendor information and complete the process. Now you have a copy (if you wanted) of your previous package with a new version number, ready to be tested, built and when ready released.

Next in the menu is the Copy Package, which is much the same as New Package version, but a little more generic, in case you want to copy someone else's package and work from that as a base. If you wanted to release a new version of someone's else's package, New version would not work.

The build menu item is where you generate the JAR file that you would distribute to a client to test with. There is a prompt asking for a Build directory where Designer will place the JAR file it builds. Inside the JAR, which is really just a ZIP file, there is a Manifest file in a subdirectory, and a file package_import.xml that looks like a typical driver configuration file. This contains just the components you have defined in your package. It is worth noting there is a tick box, Release Package, that is important on this page. Releasing a package means the build is closed, and you can no longer modify it, from the released package. The project in which you built it, with the 'source' of the package can still work on it, but not anyone who is working from a released copy.

From that walk through you can see there are a number of states a package can be in, depending on who is using it, and how they got it.

Imported (no ownership) and not released:

This is the category you don't want to have in your catalog. Somebody gave you a package but did not consider it done and thus did not release it. This means that the vendor of that package might send out other copies of that same package and version but with different content. Until it is released the version number is not locked down.

Imported (No Ownership) and Released

This will probably be the most common category of packages for end users. Novell and partners will provide released packages through an online update site or bundled-up with the product. These packages are guaranteed to never change except through new versions. Once released, the content is locked for that version. All you need is a way to point Designer at your storage location for the JAR file, via the file system (file:///) or via a web interface and then you will be able to import it into your Package Catalog to use.

Not imported or claimed ownership and not released:

This category is what most package developers will see during their development. They have a number of unfinished (unreleased) packages in their catalog and are actively making changes to their content. The unreleased packages are considered incomplete and in progress.

Claimed ownership allows the Designer project that created the package (Only that project! Though I am told that information is synchronized via SVN so you could share a project in which you build packages via Subversions source control.) to open a package back up by claiming to be the owner. Thus you could have the state as being built or reopened. Once you release the package it is locked.

Not imported or claimed ownership and released:

This category is what most package developers will see when they have finished a development cycle/iteration for a package. Packages will be developed in multiple iterations before they reach the functionality and quality to be published to the public. Each iteration should be released, though, and handed off to testing or beta customers as a released package. That ensures that the next iteration can be upgraded to and also locks down what's in that iteration. Some of the packages, which are part of the initial IDM4 release, have reached a version of 0.x.10 and higher. Some even went through more than 20 iterations until they finally settled.

Package Versioning:

Just because a certain version of a package has been released, does not mean the package should be considered final or released. The version should be used to indicate the state of a package. Here is what Novell is recommending (and the policy they followed for the IDM 4 release) for use of version numbers:

0.0.1 - First iteration
0.0.2 - Second iteration
0.0.n - n-th iteration
0.1.0 - Mile stone (we use the minor version for localization milestones)
0.n.n - n-th iteration after n-th milestone
1.0.0 - Release 1.0.0
1.0.1 - Patch 1 of 1.0.0

There is so much of interest to talk about in packaging, I think this may go on for a while! I think I should start talking about some of the interesting features of resources that can go into a Package in the next article in this series. Stay tuned for more! If you have found something new and interesting in Designer or any Novell product, feel free to write an article like this of your own!