Article

folboteur's picture
article
Reads:

3659

Score:
0
0
 
Comments:

1

Making Sure Your Work Orders Work!

Author Info

24 October 2008 - 10:59am
Submitted by: folboteur

(View Disclaimer)

Problem:

I have a work order driver that creates work-orders for processing at a future time. When a user who has an outstanding work order is renamed or moved, the work order is not updated to reflect the new DN, and so the work-order attempts to act on a non-existent object and is never completed.

Solution:

Update the "Target DN" of the work-order whenever a move or rename occurs. Note: The "Target DN" is not the object name, and does not have referential integrity to another object in the tree, hence the problem.

** The solution that follows relates to rename operations, though the same could be done for "move" operations.

Let's talk a little bit about the "stuff" visible in the screenshot below:

Click to view.

Object Name (pop-up-box title bar):

There are two relevant/interesting things about the name.

First is that I have a policy that fires any time a work order beginning with PosDelete is processed. The work-order itself doesn't do anything except store values. The Work-Order driver checks the DirXML-DueDate, and if it is in the past, it processes the work-order, turning it into a "DirXML-WorkToDo" object that is sent down the Publisher channel.

My publisher Command Transform policy contains a rule listening for any DirXML-WorkToDo objects with PosDelete anywhere in its name. That explains the beginning of the Work Order object name.

The second (debatably) interesting thing is that the remainder of the name is guaranteed to make the Work Order object name Unique. My particular process is acting on a multi-valued attribute. I found I needed to append additional information to the CN to allow the Work Order driver to create multiple work order objects when multiple positions were simultaneously ended on a user. So be aware, if you are working with multi-valued attributes.

Back to the policy… and our solution…The publisher policy says, "When a DirXML-WorkToDo with PosDelete in its name is processed, delete the value found in DirXML-nwoContent from the "positions" attribute, on the object specified (I call it the "TargetDN") in the "Description" attribute of the DirXML-WorkToDo object.

Novell (out of the box) does not provide an attribute that equals the "TargetDN" of the object on which this work-order should act." So, to provide a DN for your policy logic, you must store the DN somewhere. Many people I have read about here in the forum store this data in the "DirXML-nwoContent" attribute, because often the action to be taken is to simply delete or inactivate the account referenced. Since I was working with a specific value of a multi-valued attribute, I had already used DirXML-nwoContent as the storehouse for the value I wanted deleted, at the end date specified after the last "pipe (|) character.

(Side note: I set the DirXML-nwoDueDate using this value, too. The DirXML-nwoDueDate is the date/time at which you desire the Work Order Driver to take action on a particular work order.)
The point? It doesn't matter WHICH attribute you store it in, as of IDM3.5.1, you have to store the DN of the object you want acted upon in some attribute.

And here's where the problem arises. Since there is no referential integrity to custom made text-string attributes that store a DN, you have to create a way to update the string when the user it refers to is renamed. At first, this seemed like a job that would involve serious overhead on the Work Order driver, to assess whether or not a work-order existed for each rename operation. However, I found that renames for users that DO have outstanding work-orders also contain an association to the work-order object(s) that relate to them. <rename> operations that relate to users that do NOT have outstanding work orders, do not have associations, and so get vetoed for trying to act on an unassociated object. (error -8019)

Revising the "target" DN only requires that you modify whatever attribute you are using to store the target value, inserting the SRC-DN in the case of <rename> operations. Note in the next picture, after a "rename" operation, the Work Order's name still reflects the "wrong" or old user name, but the RELEVANT name is in the "Description" attribute.

The Policy:

Very Simple Code. I placed this code on the Subscriber Event Transform…

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE policy PUBLIC "policy-builder-dtd" "C:\Program Files\Novell\Designer\eclipse\plugins\com.novell.idm.policybuilder_3.0.0.200807211539\DTD\dirxmlscript3.5.1.dtd"><policy>
	<rule>
		<description>Rename:  Update Relevant WorkOrders</description>
		<comment xml:space="preserve">If a work order has been created for a user, and then the user CN is renamed, the work order Description field is updated to reflect the new DN.</comment>
		<conditions>
			<and>
				<if-operation mode="case" op="equal">rename</if-operation>
			</and>
		</conditions>
		<actions>
			<do-set-local-variable name="WODiN" scope="policy">
				<arg-string>
					<token-replace-all regex=" \(.*\)" replace-with="">
						<token-replace-first regex="WorkOrder" replace-with="WorkOrders">
							<token-association/>
						</token-replace-first>
					</token-replace-all>
				</arg-string>
			</do-set-local-variable>
			<do-set-src-attr-value class-name="DirXML-WorkOrder" name="Description">
				<arg-dn>
					<token-text xml:space="preserve">\</token-text>
					<token-global-variable name="treeName"/>
					<token-text xml:space="preserve">\</token-text>
					<token-text xml:space="preserve">system\idm</token-text>
					<token-local-variable name="WODiN"/>
				</arg-dn>
				<arg-value>
					<token-src-dn/>
				</arg-value>
			</do-set-src-attr-value>
		</actions>
	</rule>
</policy>

**Comment: In declaring the WODiN variable, I have to modify the text "WorkOrder" to be "WorkOrders", due to a discrepancy between what I named my WorkOrder OU and what the Work Order Driver wanted it named. You may not have to use this section of code, if you named your containers exactly as Novell specifies in the setup of your work order driver.

I also have a GCV for Tree-Name, so that the DN's will work properly between Lab and Production environments, where the tree-names vary.

Rename Document Input to the Work Order Driver

[10/21/08 16:26:32.955]:@@@ ST:
<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product version="3.5.10.20070918 ">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <rename cached-time="20081021202632.846Z" class-name="User" event-id="IDVault-01-DS#20081021202623#1#1#2" old-src-dn="\IDVault\data\usr\edu\amorem" qualified-old-src-dn="O=data\OU=usr\OU=edu\CN=amorem" qualified-src-dn="O=data\OU=usr\OU=edu\CN=zanatm" remove-old-name="true" src-dn="\IDVault\data\usr\edu\zanatm" src-entry-id="40030" timestamp="1191963986#1">
      <association state="associated">\WorkOrder\PosDeleteamorem0191019151214 10/21/2008 16:26 (Pending)</association>
      <new-name>zanatm</new-name>
    </rename>
  </input>
</nds>

Trace File Output:

[10/21/08 16:26:32.955]:@@@ ST:
<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product version="3.5.10.20070918 ">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <rename cached-time="20081021202632.846Z" class-name="User" event-id="DEV-IDV-01-DS#20081021202623#1#1#2" old-src-dn="\IDVAULT\data\usr\edu\amorem" qualified-old-src-dn="O=data\OU=usr\OU=edu\CN=amorem" qualified-src-dn="O=data\OU=usr\OU=edu\CN=zanatm" remove-old-name="true" src-dn="\IDVAULT\data\usr\edu\zanatm" src-entry-id="40030" timestamp="1191963986#1">
      <association state="associated">\WorkOrder\PosDeleteamorem0191019151214 10/21/2008 16:26 (Pending)</association>
      <new-name>zanatm</new-name>
    </rename>
  </input>
</nds>
[10/21/08 16:26:33.336]:@@@ ST:  Applying to rename.
[10/21/08 16:26:33.336]:@@@ ST:    Evaluating selection criteria for rule 'Rename:  Update Relevant WorkOrders'.
[10/21/08 16:26:33.337]:@@@ ST:      (if-operation equal "rename") = TRUE.
[10/21/08 16:26:33.338]:@@@ ST:    Rule selected.
[10/21/08 16:26:33.338]:@@@ ST:    Applying rule 'Rename:  Update Relevant WorkOrders'.
[10/21/08 16:26:33.339]:@@@ ST:      Action: do-set-local-variable("WODiN",scope="policy",token-replace-all(" \(.*\)","",token-replace-first("WorkOrder","WorkOrders",token-association()))).
[10/21/08 16:26:33.340]:@@@ ST:        arg-string(token-replace-all(" \(.*\)","",token-replace-first("WorkOrder","WorkOrders",token-association())))
[10/21/08 16:26:33.341]:@@@ ST:          token-replace-all(" \(.*\)","",token-replace-first("WorkOrder","WorkOrders",token-association()))
[10/21/08 16:26:33.342]:@@@ ST:            token-replace-all(" \(.*\)","",token-replace-first("WorkOrder","WorkOrders",token-association()))
[10/21/08 16:26:33.343]:@@@ ST:              token-replace-first("WorkOrder","WorkOrders",token-association())
[10/21/08 16:26:33.344]:@@@ ST:                token-replace-first("WorkOrder","WorkOrders",token-association())
[10/21/08 16:26:33.345]:@@@ ST:                  token-association()
[10/21/08 16:26:33.346]:@@@ ST:                    Token Value: "\WorkOrder\PosDeleteamorem0191019151214 10/21/2008 16:26 (Pending)".
[10/21/08 16:26:33.347]:@@@ ST:                  Arg Value: "\WorkOrder\PosDeleteamorem0191019151214 10/21/2008 16:26 (Pending)".
[10/21/08 16:26:33.348]:@@@ ST:                Token Value: "\WorkOrders\PosDeleteamorem0191019151214 10/21/2008 16:26 (Pending)".
[10/21/08 16:26:33.349]:@@@ ST:              Arg Value: "\WorkOrders\PosDeleteamorem0191019151214 10/21/2008 16:26 (Pending)".
[10/21/08 16:26:33.350]:@@@ ST:            Token Value: "\WorkOrders\PosDeleteamorem0191019151214 10/21/2008 16:26".
[10/21/08 16:26:33.350]:@@@ ST:          Arg Value: "\WorkOrders\PosDeleteamorem0191019151214 10/21/2008 16:26".
[10/21/08 16:26:33.351]:@@@ ST:      Action: do-set-src-attr-value("Description",class-name="DirXML-WorkOrder",arg-dn("\"+token-global-variable("treeName")+"\"+"system\idm"+token-local-variable("WODiN")),token-src-dn()).
[10/21/08 16:26:33.353]:@@@ ST:        arg-dn("\"+token-global-variable("treeName")+"\"+"system\idm"+token-local-variable("WODiN"))
[10/21/08 16:26:33.354]:@@@ ST:          token-text("\")
[10/21/08 16:26:33.354]:@@@ ST:          token-global-variable("treeName")
[10/21/08 16:26:33.355]:@@@ ST:            Token Value: "IDVAULT".
[10/21/08 16:26:33.356]:@@@ ST:          token-text("\")
[10/21/08 16:26:33.356]:@@@ ST:          token-text("system\idm")
[10/21/08 16:26:33.357]:@@@ ST:          token-local-variable("WODiN")
[10/21/08 16:26:33.357]:@@@ ST:            Token Value: "\WorkOrders\PosDeleteamorem0191019151214 10/21/2008 16:26".
[10/21/08 16:26:33.358]:@@@ ST:          Arg Value: "\IDVAULT\system\idm\WorkOrders\PosDeleteamorem0191019151214 10/21/2008 16:26".
[10/21/08 16:26:33.359]:@@@ ST:        arg-string(token-src-dn())
[10/21/08 16:26:33.359]:@@@ ST:          token-src-dn()
[10/21/08 16:26:33.360]:@@@ ST:            Token Value: "\IDVAULT\data\usr\edu\zanatm".
[10/21/08 16:26:33.360]:@@@ ST:          Arg Value: "\IDVAULT\data\usr\edu\zanatm".
[10/21/08 16:26:33.361]:@@@ ST:  Direct command from policy
[10/21/08 16:26:33.361]:@@@ ST:  
<nds dtdversion="3.5" ndsversion="8.x">
  <source>
    <product version="3.5.10.20070918 ">DirXML</product>
    <contact>Novell, Inc.</contact>
  </source>
  <input>
    <modify class-name="DirXML-WorkOrder" dest-dn="\IDVAULT\system\idm\WorkOrders\PosDeleteamorem0191019151214 10/21/2008 16:26" event-id="DEV-IDV-01-DS#20081021202623#1#1#2">
      <modify-attr attr-name="Description">
        <remove-all-values/>
        <add-value>
          <value>\IDVAULT\data\usr\edu\zanatm</value>
        </add-value>
      </modify-attr>
    </modify>
  </input>
</nds>
[10/21/08 16:26:33.367]:@@@ ST:  Pumping XDS to eDirectory.
[10/21/08 16:26:33.368]:@@@ ST:  Performing operation modify for \IDVAULT\system\idm\WorkOrders\PosDeleteamorem0191019151214 10/21/2008 16:26.
[10/21/08 16:26:33.370]:@@@ ST:  Modifying entry \IDVAULT\system\idm\WorkOrders\PosDeleteamorem0191019151214 10/21/2008 16:26.
[10/21/08 16:26:33.373]:@@@ ST:  Processing returned document.
[10/21/08 16:26:33.373]:@@@ ST:  Processing operation <status> for .
[10/21/08 16:26:33.374]:@@@ ST:  
DirXML Log Event -------------------
     Driver:   \IDVAULT\system\idm\CLIENT Drivers\WorkOrder
     Channel:  Subscriber
     Status:   Success
	 
	 

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.




User Comments

geoffc's picture

Why not just use a DN syntax attribute instead of Description?

Submitted by geoffc on 24 October 2008 - 11:34am.

So why would you not just extend schema with acmeWorkOrderTarget attribute, (where acme is your company name), and make it a single valued DN syntax, and place the DN of the object that is the target in the value.

This way renames and moves are magically handled in the background.

Also, deletes are sort of implicitly handled by adding a rule that tests when you come to actually DO something in the WO driver, if there is no acemWorkOrderTarget, then self destruct the WO, since the target object obviously does not exist any longer. Or maybe throw an event, send an email, or whatever makes sense.

Your way looks like a lot of overhead to replicate a basic feature of eDirectory... (Which basically means there is a reason you have for doing it this way that I do not yet see...)

© 2013 Novell