In article http://www.novell.com/communities/node/2854/checking-and-creating-ous-policy-builder Father Ramon offers a great solution to problem of testing if the destination container you want to place a user in exists, before you create the user. The code snippet in the answer is very useful, but does not explain WHY this will work. I think there is value in talking about why it works.

Father Ramon suggest a very cute and efficient manner of testing. My initial thought on reading the Problem segment was to use the Query token to query for an object, then XPATH out the src-dn of the result. His suggestion is WAY smarter than my approach (which is probably why they pay him the big bucks!). He relies on the fact that while a naming attribute (CN for most things, OU for Org Units, and possibly other attributes for other object classes) is almost always mandatory for objects, eDirectory Schema does have an implicit mandatory attribute - that of Object Class. That is, there is an attribute every eDirectory object MUST have - always, with no exceptions.

If something is wrong with the object, it gets set to an object class of Unknown. In fact, if you violate schema somehow (usually if there is a mandatory attribute of DN syntax, and you delete the object the DN points at), then the object class becomes Unknown. So basically if an object exists, in eDirectory it must have a value of something for Object Class.

The suggested solution uses the Parse DN token to remove the leaf most node (length of -2) to remove the CN from the destination DN and set it into a local variable. For example, bob.nyc.acme.com would get stripped down to nyc.acme.com (or as Identity Manager uses, COM\ACME\NYC from COM\ACME\NYC\BOB).

    <do-set-local-variable name="target-container">
     <arg-string>
      <token-dest-dn length="-2"/>
     </arg-string>
    </do-set-local-variable>

Then he sets a local variable to the value of the Object class of the destination attribute that is defined by the target-container local variable. This is the parent OU that is either there or not, that we want to place the object into.

    <do-set-local-variable name="does-target-exist">
     <arg-string>
      <token-dest-attr name="Object Class">
       <arg-dn>
        <token-local-variable name="target-container"/>
       </arg-dn>
      </token-dest-attr>
     </arg-string>
    </do-set-local-variable>

Finally, he tests to see if he got a value back.

   <conditions>
    <and>
     <if-local-variable name="does-target-exist" op="available"/>
     <if-local-variable name="does-target-exist" op="equal"/>
    </and>
   </conditions>

Local variables are always available, once they are instantiated, even if they are empty. This is different from eDirectory attributes, where if they have no value, they do not take up space, and will fail the is-available test.

The second test is, "is it equal to nothing?" If it is there and equal to nothing, then there is no object at the destination DN he calculated, and the OU does not exist, and so must be created in the next snippet.

   <actions>
    <do-add-dest-object class-name="Organizational Unit" direct="true">
     <arg-dn>
      <token-local-variable name="target-container"/>
     </arg-dn>
    </do-add-dest-object>
   </actions>

Very classy solution - typical of Father Ramon. (Yes I am sucking up in the hopes he will continue to answer my posts in the forum! But he really is that good at this stuff!)