When NetIQ released IDM 4 with IDM Designer v4.0, they introduced the concept of a driver “package”. This was followed by the idea of layering packages, so that new features could be added, old features removed, and generally we would no longer have single huge monolithic drivers to deal with.

By now, this is not news to anybody doing active work with Identity Manager. Neither is the fact that some aspects and features are not fully documented, if documented at all. Sometimes we only find out about a feature when we notice that a NetIQ package is using it.

It bugs me when I find a cool feature, but there is no documentation on how to use it myself. It seems like it should be obvious that documentation of features leads to adoption and use of those features. Not documenting them makes them less useful than they should be.

One of these undocumented features is the ability of a package install to link a single policy in to the driver in multiple places. I first noticed them doing this in the Data Collection Common package, in the Schema Map. Rather than try to build on top of the default map, they linked in a single policy that took the current document out of the normal XML namespace, first, then let it go through the Schema Map, which did nothing, then restored the document back to the usual XML namespace.

I saw an immediate possibility here for better crafting my own add-on packages for the default drivers. Some of the time, I need to be able to map a standard attribute, like Surname, to something non-standard. But the default packages map Surname to a standard attribute already. I wanted to get around that default, without having to customize Microfocus’ packaged content.

Sadly, while package development is done in Designer, Designer does not expose the ability to multi-link a policy set in to a driver. So, I set out to figure out how to do it, in a way that not only works, but that shows up as being a clean install when complete.

I am using the Schema Map here as the example, but this technique applies to any policy set.

First, create your package via the normal methods.

Second, create a new driver to apply your package to. My preference here is to keep all package development in a separate Designer project, so the only driver in it is a Null driver, in a simple ID Vault / Driver Set. All package development gets done in this project, which is then easier to back up or hand off to a coworker to maintain as needed.

Next, in the Schema Map, create a new policy. I borrowed and re-used the NOVLDATACOLL-smp-SkipSchemaMapping policy here from the Data Collection Common v.1.0.0 driver package.

 <rule>
  <description>skip</description>
  <conditions>
   <and>
    <if-operation mode="case" op="equal">instance</if-operation>
    <if-op-property mode="nocase" name="data-collection-query" op="equal">true</if-op-property>
   </and>
  </conditions>
  <actions>
   <do-trace-message>
    <arg-string>
     <token-text xml:space="preserve">skipping schema mapping for </token-text>
     <token-xpath expression="@src-dn"/>
    </arg-string>
   </do-trace-message>
   <do-for-each>
    <arg-node-set>
     <token-xpath expression="./attr"/>
    </arg-node-set>
    <arg-actions>
     <do-set-xml-attr expression="$current-node" name="attr-name">
      <arg-string>
       <token-xpath expression="concat('{',$current-node/@attr-name,'}')"/>
      </arg-string>
     </do-set-xml-attr>
    </arg-actions>
   </do-for-each>
   <do-clear-op-property name="data-collection-query"/>
   <do-set-op-property name="restore-attr-names">
    <arg-string>
     <token-text xml:space="preserve">true</token-text>
    </arg-string>
   </do-set-op-property>
   <do-break/>
  </actions>
 </rule>
 <rule>
  <description>restore</description>
  <conditions>
   <and>
    <if-op-property mode="nocase" name="restore-attr-names" op="equal">true</if-op-property>
   </and>
  </conditions>
  <actions>
   <do-trace-message>
    <arg-string>
     <token-text xml:space="preserve">restore @attr-name's for </token-text>
     <token-xpath expression="@src-dn"/>
    </arg-string>
   </do-trace-message>
   <do-for-each>
    <arg-node-set>
     <token-xpath expression="./attr"/>
    </arg-node-set>
    <arg-actions>
     <do-set-xml-attr expression="$current-node" name="attr-name">
      <arg-string>
       <token-xpath expression="substring-before(substring-after($current-node/@attr-name,'{'),'}')"/>
      </arg-string>
     </do-set-xml-attr>
    </arg-actions>
   </do-for-each>
   <do-clear-op-property name="restore-attr-names"/>
  </actions>
 </rule>

Now add this policy to your package, again using the usual methods.

Something that helps with the next step is to put something that you know to be unique in it. A comment like “Foo Bar Baz Quux” or "Sharkbait Fez" or some other nonsense that you know will not appear anywhere else is good.

Uninstall the package from your Null driver.

Once you have your policy added to your package, and the package uninstalled from the driver, close the project in Designer.

The next step depends on the operating system you are using on your workstation. You will need to find the file, under the Designer workspace directory, where your newly created policy was stored. It will be something like SC9U7F5B_contents.xml. The first part (SC9U7F5B) is important,  you need the SC9U7F5B.ScriptPolicy_ file under the Model/Project directory. If you are searching for a nonsense phrase that you know appears only in the policy you are looking for, you should find only one pair of files (contents and initial_state).

Linux users, grep -lR 'Foo Bar Baz Quux' * will get you there.

Windows users, you will either have to get a copy of grep for Windows (Cygwin or etc.), or find a way to get the Explorer “search” to do the job for you. Hint: grep is easier, faster, and you should learn to use it.

Once you have found the correct file, you can edit it with a normal text editor. Linux users, “vi” is your friend, unless you’re one of those crazy Emacs users. Gedit, Kate, etc. will also work. Windows users, get a copy of Notepad or something similar that can handle editing text files without making a mess of them.

Find the policy installation weight in the “Idm:InstallationDirective”, like:

<attributes xsi:type="com.novell.designer.model:CString" attrName="Idm:InstallationDirective" ... value="100" ...

Add your new installation weight to “Idm:InstallationDirective”, by duplicating the policy-set node of the XML. So if you started with XML fragment like:

<policy-set Driver="ZMG56D1X" channel="publisher" name="schema" order="Weight" package-id="5WS8LNHT_201902251058130731" value="100"/>

You would duplicate it and modify it like:

<policy-set Driver="ZMG56D1X" channel="publisher" name="schema" order="Weight" package-id="5WS8LNHT_201902251058130731" value="100"/><policy-set Driver="ZMG56D1X" channel="publisher" name="schema" order="Weight" package-id="5WS8LNHT_201902251058130731" value="900"/>

Note that I have changed it from a single link (weight=100) to dual (weight=100 and weight=900).

Then delete the “Idm:ContentChecksum” line.

Save your changes.

Now re-open the project in Designer. Install your package on your driver, and you should now have multiple linkages, like:



That’s it. Designer will recalculate the missing Idm:DirectiveChecksum for you, and the package now has your new policy with two installation links. You can edit these in Designer, you just cannot create them.