In part 1 and 2 of this series I talked about some of the new things in Designer 4.5.1. In this article I will try and get through the rest of the items listed in the readme.

The last new features is the following.

Designer's Document Generation feature now includes linked GCV objects. To display the GCV resource name, the Source column is included in the GCV table.

This is good news and a nice fix to add in. With the switch to Packages, and the break out of some components into individual objects that can be linked in order, not everything kept up changes. Document Generation is one of those. I think I offended one of the developers who had worked very hard on the Document Generation component, when I said "It is very pretty, but functionally useless". Earlier versions had memory issues (since it generated it all as one document and ate all available memory), and missed things. It generates thousands of pages of documentation, but it is not that useful as a reference, and you could not easily rebuild from it, so it is unclear who is the target audience. As I understand it, this component was written for the Consulting arm at Novell, so that when a job was complete, hit a button and you have a 1200 page PDF to deliver that looks good and looks very useful. Of course then you start reading it and realize maybe it is not quite so useful. I like the idea, I want it to continue to be supported, but I am not sure it is something I would ever look at.

Regardless, it was missing GCV's that were included via GCV objects (from a Package) instead of being an attribute on the Driver object. This is good to see fixed.


Then the Readme goes on to list fixes included, which I guess are meant to be high profile bugs that affect people.

Fixes included:

Designer 4.5.0.1 resolves the connectivity issue observed while using the Version Control feature of Designer on a secure server.4.5.0.1

Version Control for IDM,

Designer 4.5.0.2 no longer reports errors if you deploy a Workflow from Designer 4.5 to an older version of User Application.4.5.0.2

This was important, because you want to be able to work with one instance of Designer (hopefully the latest) on older versions of Identity Manager and User Application. This would be especially for someone like me who works on multiple projects during the day and has to switch between them. Can you imagine the pain of constantly reloading Designer for each time I needed to task switch. This was one of the few compatibility issues I had seen, so I am glad to see it fixed.

Designer now includes "error.do-find-matching-object" error variable in the Variable browser under Policy Builder.

There are a series of error variables that Identity Manager supports, and Designer is supposed to show. Usually they are for asynchronous processes. For example, Send Email and Add Role are processes where you kick something off, and it goes on its merry way. But the key is, you start it in one action in the policy, that either starts or fails, and then you continue on, and the new process goes off and does its thing.

Thus when you start a workflow or request a Role add, this is a SOAP call that kicks off a process on the User App server. You cannot wait for it to complete, but you can at least get back an error message if it fails to start. This way you can add some error handling in your policy. Same idea with the Send Email tokens, you hand off to an SMTP server to process them. But at least confirm if you have a bad connection to the SMTP server.

When you do a Match, you start a query process and it returns an error if more than one match is found, along with the values of the DN's found. You could get an error that an associated user was found who matches as well. If you knew the name of the error variable you could use it, but Designer was not properly showing it. Nice to see it properly added in. Confusingly, an operation property of a similar name was added to the event as well with some of this information.

Designer now lists all the versions of the packages except the existing versions on Designer. Earlier Designer listed only the latest versions of packages during online package updates.

This is a nice feature that allows you to see what it is you are really downloading. Sometime when they release updates to a package, there might be more than one revision. In that case, there might be reasons to download both versions. Probably more likely if you install a new Designer instance, you might go to get updates and since this Designer release there had been many versions of the package released.

In the past, you would see one entry for each package, even if more than one version was available. This is confusing if you are looking for a specific version, do a Check for Package Updates and do not see the one you are looking for.

With this change you get to see all the versions. Personally I think I would prefer a setting to control this, because I can envision cases where I care to see all the versions (very small portion of the time) and most of the time where I do not wish to see all the noise.

It is worth mentioning a small detail of how package updates work that is quite confusing. If you develop a package in your project and deploy it all is well. When your coworker tries to import it, they will be told that the package is missing in their project.

This is because Packages are stored three different ways.

1. In a particular project as the objects that define it in the Package Catalog.

• As a JAR file, built from the Package Catalog, but only in the Projects which have imported it.

• Persisted in the Designer install path.

For the third approach, the only way to get them in, officially, is to download them via Check for Package Updates. When they are persisted this way, as you import the driver from the Identity Vault your Designer instance finds the matching Package and automatically adds it to this project's Package Catalog.

To get from the first or second case to the third, you need to Build your driver, which generates the initial JAR file you could share for step #2. When you select Build, there is a tick box for Release, which once done locks the package in the catalog so that further changes cannot be made, and the datestamp component of the version number is locked in as well. Otherwise, every time you build it, you would get a new datestamp in the version string, and thus could never match the version you deployed.

Once Released, the right click menu gets an extra setting for Publish, which when pointed at the proper directory builds or updates the site.xml file with a reference to this driver, and put the JAR's it generates in the proper locations.

Now if you point your Designer instance at that path (file:///c/path/to/dir/holding/site.xml/ ending in a forward slash) you can import the package that you have built, into the persisted path in the Designer install directory.

This is why on Windows it was a problem installing Designer to the typical C:\Program Files directory, since that is protected by UAC (User Access Control) and you could download a Designer upgrade (which makes sense, since of course that updates the Designer files) or Check for Package Updates, and it would download, claim to install, restart and yet nothing happened. UAC would block the writes since you did not have the needed permissions. Thus I started always running Designer 'As Administrator'. In Designer 4.5 they simply resolved this by installing to c:\netiq\Designer instead, a non-protected folder.

The "Copy server-specific settings…" dialog box now displays properly upon maximizing the window.

This is a minor GUI fix, I find it interesting that they actually called it out.

During the base package upgrade, Designer now preserves the Data Abstraction Layer changes added through a User Application non-base package.

I need to look into the specifics of this issue, but I am happy to see work being done on Packages and the Provisioning side of the house. Alas this is a weak part of the Package system. There are a number of issues with Packaging content for the User Application.

One of the issues was that many of the components of the DAL (Directory Abstraction Layer) control things you would like to update, but are part of the base package. An example is the Categories that you can define a Workflow or a Role to exist in. Those two are actually stored as List objects in the DAL, such that if you want a new category for those, you edit the DAL, find the proper List object and update it. If you wanted to deliver this as a packaged element you cannot since the User Application delivers this content. Once an item is packaged, you cannot overwrite it with another piece of packaged content. You can modify it and leave it as dirtied in the project, if you do it by hand. But not by delivering a package.

Secondarily, I have found in the past and not tested recently to see, that there may be an extra version check in the Provisioning side of Packaging. When you build a package, one of the items you can specify is which drivers it applies too, and which versions of IDM it should use. That is the way it should be. But somehow the Provisioning packages are adding in a version check for the User Application version it was built with. Not a problem, only want to apply it to the proper version, so that is fine. But what about when you upgrade User App and you want to build a new version of that content? I ran into an issue where I was unable to apply my package to a User App driver, to update it for the new version. I got locked into the old version.

I really should revisit this and see if this is resolved. But it was a major pain point. Especially as I wanted to deliver some complicated Provisioning bits for an upgrade. I was thinking that maybe I should export to an XML file, and build a brand new package from scratch, since upgrading the actual package seems to maintain this internal version number that is not quite manageable.

Overall I am quite happy with this upgrade. The change to 64 bit and the new Eclipse version in Designer 4.5 was an excellent upgrade, since it really helped with performance.

I was looking through Bugzilla to find interesting bugs they fixed on top of this, but there were not a lot of major ones that stood out. What did come clear is that they got someone very good at QA to find a whole bunch of cases where things that should work, failed, and those were resolved. Lots of Null Pointer Exceptions when trying some action were fixed. This was good news to me. That is a very good sign, someone who is really doing a good job at QA. Designer has gotten to be so big that fixes sometimes break other things and finding all those edge cases can be difficult.

Thus overall, it seems like the high level features called out are the main ones, but there was a distinct push for better quality in this build. I think we can all get behind that idea!

Now on to what is new in the rest of IDM 4.5 Patch 1. That should be quick, right?