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 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:
There is so much to say about packages, that I wanted to continue on to some more of the interesting features.
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 this article I would like to start 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.
Lets start with the simplest of them all, Global Configuration Variables (GCV). In order for all this package stuff to work, the way GCVs are stored needed to be modified. Initially they were stored as an XML blob in the DirXML-ConfigValues attribute on a driver or driver set object. However, that model just does not scale properly into multiple packages and the ability to add/remove packages.
For IDM 4 what Novell did was to make GCVs available via a new object, that stores the XML blob in a single attribute still, but is linked into the driver or driver set object. In many ways it is better to store all the values as a single blob because then XPATH against the XML is very easy. If it were a set of attributes it gets more complicated for no clear advantage.
To add a GCV object to a package, you create it somewhere in the Driverset structure that you want it to exist, as you would any other GCV object. The difference in IDM 4 is that the GCV object is now a stand alone object which gets linked into a driver or driver set object, not just attributes on either the driver or driver set.
Once created, you can right click on it (I have my Identity Vault set in Package Developer Mode still for this entire series of articles, you need that to get the various options under discussion), and you get an option to add to Package. It shows you a list of unreleased packages that you own, so I only see my current package in the list. Then you go back to your package, in the package catalog, and in the tree structure of: Catalog then Category then Group then Package name, there is a version number node. Under the version number node you will see a new folder, Global Configurations, with the newly added GCV object shown.
When I right click on it I can Generate Prompt Resource, which will allow me to specify how the imported package will ask the importer for more information. This will create an item under the Resources folder, named MyGCVName-Prompt much like the Setting prompts I discussed in the fourth article in this series. I am still tracking down information on how the XSLT stylesheets are expected to work to better understand them.If you edit the Properties of the GCV object in the Package now, you get three options, General I am happy to see includes a Notes field. I love comment and notes and description fields. As you might have noticed I am a bit of a chatter box, but I really think it is important to leave as many bread crumbs behind in your project as possible. (Heck I even use the Comment field in the Filter objects now! Did not know it was there? Aha! A great feature! Now to get it added to the Schema Map XML DTD and UI as well!!!)
The second page is Installation, which I find interesting as the choices for placement are greyed out. I guess since I created it in a Library object (Called New Library) it kept the location. I am not clear how I would change that after the fact, short of literally editing the XML, since I can probably figure out where this data is stored in the Designer project file system itself. This is one nice thing about Designer and Identity Manager. Many things that the User Interface might not directly expose are often available if you use a slightly different approach. You can see an application of this, in regards to managing email templates, where the Novell editor for Email templates is great, but hard to use to copy a template in one pass. Whereas if you use the Eclipse standard XML editor to edit the Email Template object, it is much easier:
Using and Copying Email Templates in Identity Manager
I am not sure what the consequences of the Installation Server, but I assume it means, if there is more than one Server in the driver set, which should you add it too, since of course this is Write managed attributes, and server specific. All, Preferred Server, and None seem to cover the easy cases. Anything beyond that seems like you would get into so much complexity it is easier and smarter to let a human decide at implementation time.
Linkage does not give me any options at this time, probably because I did not link the real object to any drivers yet. But I get an Apply button unghosted which is a bit odd.
Now to link a GCV into a driver, it seems like the right place to do it would be in the Driver or Driver Set properties on the GCV item. In fact, when you look at a driver with a bunch of GCV objects inked in, you see a tab per GCV linkage as you can see in the screen shot.
But there is no add, link or any such option. So how do you add a new GCV object into the driver or driver set? Well as I have said before, it is linked in like ECMA library objects, which in this case is exactly how it is done. If you look at the Driver Configuration page of the properties, there is:
Driver Module
Authentication
Startup Options
Driver Parameters
ECMAScript
Global Configurations
That last one is the key, and you can add them in that page.
I suppose I would prefer if the UI allowed you to add in both places and maybe even edit in both places.
Previously I had added the GCV object to the package but now after that was already done, I made a change by linking it to a driver. However when I go look at the Package contents it does not show this link yet. I need to right click on the object (not the copy in the package, the real one) and choose to Sync to Package in order to update the package with the changes I made.
An interesting note is that changes to packages does not dirty the workspace. That is, you do not get an asterisk (Asterisk is shift 8 on the US keyboard. Asterix is a little Gaulish man from the comics. I honestly got told that at my thesis defense since I apparently referred to asterix not asterisk as I spoke).
It is also worth noting that non-Packaged objects get a little icon flag in the Outline view. It looks like a window pane with four squares inside a square.
The image attached sort of shows it poorly. As before on the bottom right of the TEst object there is an indicator that it is not currently linked to a driver. On the bottom left is the 4 square indicator that shows it is not part of a Package. This is a new indicator with Designer 4.
What I noticed when I linked the GCV object into a Driver, its weight was set to 21, which would place it below all the others, who default to a weight of 20 it would seem. This allows you to build packages that try and place the object of interest in an appropriate location. Of course it requires a fair bit of coordination between people working on the project, but what else is new these days?
Filters are the next interesting thing to discuss. These are non-obvious from the UI, and I had to go find an existing Filter extension object to figure it out. They are stored as Resource objects (Generic objects that have a DirXML-ContentType attribute to define what kind of resource they are. A very elegant general solution I think). The Content Type for a filter is application/vnd.novell.dirxml.filter-ext xml
The various types of resources you can make are:
application/vnd.novell.dirxml.mapping-table xml;charset=UTF-8
text/ecmascript;charset=UTF-8
text/vnd.novell.idm.entitlementConfiguration xml
text/xml
text/ text
application/vnd.novell.dirxml.sso-application xml
application/vnd.novell.dirxml.sso-repository xml
application/vnd.novell.dirxml.ds-object xml
application/vnd.novell.dirxml.pkg-prompt xml
application/vnd.novell.dirxml.filter-ext xml
The first six Mapping Tables, ECMA Script, Entitlement Configuration (See this article for more about these: Converting Entitlements to Resources, more details, XML Text, Text text, SSO Application, and SSO repository are all pre-existing resource types available in IDM 3.6.1. I think ds-object was available before, but I recall seeing it was a new feature in IDM 4. I think my confusion may stem from the fact that the DTD for configurations has supported ds-object to describe objects during a driver import, but it may be that creating a Resource object of content type DS Object might be new in IDM 4.
The Package Prompt and Filter Extensions are new. I was sort of disappointed but the GCV objects got their own new class type. I figured they would have been resources as well. I would be curious if someone from the design team could explain the reasoning behind that choice, I imagine it would be quite enlightening!
Filters need to be handled different as discussed in the first article of this series, because the Filter is actually stored as a single XML blob attribute on the driver object in the attribute DirXML-DriverFilter. Unlike GCV's where they changed how the engine handles them, with Filters they chose an less intrusive route and it looks like the Filter extensions just add and remove as packages are added and removed from the big old blob of XML.
I did notice an interesting thing. When I created my test Filter resource, I chose to build it in a Library object, just for keeping my testing in a clean space and not cluttering up my project. Well its a test project so I am not sure if that accomplishes anything anyway. But after I created it, and opened it, the editor was the default XML editor for a DS Object. In fact, I looked at the properties of the object I just created, and it was now a DS Object instead of a Filter extension. Even more interestingly to me, Filter extension was not in the list of content types available. I infer from this (due to lack of documentation) that Filter extensions should only reside inside a driver object. This is an interesting containment issue, since of course, they cannot use the object class's containment values in the schema definition, since all 9 resource types listed above are of the object class DirXML-Resource. Rather they differ based on an attribute DirXML-ContentType which eDirectory does not allow you to enforce in schema. Thus it must be Designer enforcing it. Interesting. Recreated the policy under a driver object, and I was able to edit it as a Filter object, with the appropriate editor and Content Type.
As you can see there is lots and lots of interesting things to see about Packages, and this series may go on for a while. 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.
Support
Documentation
Learning Services
Partner Programs