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!
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.
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 this article I mostly want to talk 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.
For example, in Package Developer Mode, once you create a package, while you can change some of the settings, like the name, shortname, and Description, you cannot directly change the version, for that you need to right click on the package version and select New Package version. This is important, as you might think as you were working and fixing issues, it would be nice to just increment the value after a certain amount of changes. This forces a bit more rigidity and probably in a good way, to keep different versions around. Thus you will have a history of your work you can revert too. (You can lead a fish to water, but you cannot make him swim... It only works if you use it.)
What I found interesting was that once it was created, you cannot change the Target (IDVault, DriverSet, or Driver), Category, Group, or whether it is a base package or not. I suppose when you think about it, that makes sense as this would imply a move of the package from one place to another. However you do have the flexibility at create time to create a new Category and Group, since it is such a pain to move one around. Though you could make a new package in the new location and just copy all the contents of the old one into it instead.
In the seventh article I talked a lot about the prompts, and how they work upon some XML that comes from the objects. Well the Package itself has an Initial Settings tab, that you can look at after it is created. I trimmed it down to one line per item referenced. That is, in the Health config I left only the green node. In the Schema definition node I left it with just one attribute and so on and so forth, just so you get a feel for the XML structure. Seeing the structure makes it easier to understand how some of the XSLT might apply to it better. I think this is the content, or at least a similar set of content that the curDoc variable that we discussed in the previous article is referring too. Thus the Target Transformation works on XML that looks like this sample document.
This is much the same as you have in a iManager driver export so it is pretty easy to understand if you have ever looked at one of those exports in detail. I had an instance where I needed to roll out an upgrade to a 35 driver project and we had lots of changes. We edited the export file to remove all the password prompting, and libraries and things we knew had not changed, and used that to update the existing configuration.
<?xml version="1.0" encoding="UTF-8"?><ds-attributes>
<ds-value>Active Directory Driver</ds-value>
<class-def class-name="user" container="true">
<attr-def attr-name="accountExpires" multi-valued="false" type="int"/>
<!-- Trimmed a couple of dozen attributes -->
<!-- password capabilities -->
<!-- supports publisher modify password notification when Active Directory password changes -->
<!-- supports subscriber password and modify password commands to change Active Directory password -->
<!-- supports subscriber verify password commands by attempting a login to Active Directory -->
<unprocessed-size op="lt" value="2000000"/>
<transactions op="gt" over-last="2" source="publisher-reported-events" value="0"/>
<sample-history minutes="2" op="lt"/>
<transactions op="gt" over-last="2" source="subscriber-command-results" transaction="total" value="0"/>
<sample-history minutes="2" op="lt"/>
<generate-event id="1230" level="log-info">
<event-argument name="value" value="0"/>
<event-argument name="value3" value="1"/>
<event-argument name="text2" value='Driver entered "Green" state'/>
<driver-config name="Active Directory Driver">
<header display-name="xlfid(NOVLADBASE.initial.settings.param.header.AuthenticationOptions)Authentication Options"/>
<definition display-name="xlfid(NOVLADBASE.initial.settings.param.auth-options)Show authentication options" name="auth-options" type="enum">
<description>xlfid(NOVLADBASE.initial.settings.param.dscr.auth-options)Show driver authentication options. These parameters control how the driver shim authenticates to the Active Directory domain controller.</description>
<definition display-name="xlfid(NOVLADBASE.initial.settings.ecv.dirxml.engine.retry-interval)Subscriber channel retry interval in seconds" display-name-ref="ecnm_rint" name="dirxml.engine.retry-interval" range-lo="1" type="integer">
<description description-ref="ecds_rint">xlfid(NOVLADBASE.initial.settings.ecv.dscr.dirxml.engine.retry-interval)The subscriber channel retry interval controls how frequently the DirXML Engine will retry the processing of a cached transaction after the application shim's Subscriber object returns a retry status.</description>