A Forum reader recently asked:

“I have a case where I need to veto a synthetic add in the PeopleSoft driver. (I’m using PS Driver version 4.0.5 running on IDM I can recognize and veto the operation without issue. Setting the status of the PeopleSoft transaction following a veto is the problem.

What I would like to do is set the status of the transaction something other than “In Process”. As far as I’m concerned, the operation was a “Success” or “Cancelled” – anything but “In Process” (or “Error”).

I’ve tried setting the status to “Success” and then vetoing the op in the Event Policy set in the Publisher Channel. The op is a modify at this point; the synthetic add has not yet been generated. The “success” is reported in the trace but the subsequent veto kills everything from that point on.

No matter what I try, the veto action whacks everything in the <input> portion of the document. I do see policies being evaluated after the veto, but there is nothing to evaluate; all it has to evaluate for input is <input/>.

Any ideas on how to set the PS transaction status after a “successful” veto? I’m pretty sure I know what to send to PS to set the status as I wish. Or should I use something other than “do-veto” to stop the operaton?

And here’s the response from David Gersic …


Once you veto() it, it’s gone. But, if you just change the status, the event dies, and you can use that instead. I’m doing it here with these two bits of code.

First, on the Publisher Command Transform, I have this:

<?xml version="1.0" encoding="UTF-8"?><policy>
  <description>Veto Operation if niuAccountLockout is
    <if-dest-attr name="niuAccountLockout" op="available"/>
   <do-status level="retry">
     <token-text xml:space="preserve"
xmlns:xml="">Operation blocked by

This blocks all <modify> events to objects with the “niuAccountLockout” attribute on them. Then, on the Subscriber Output Transform, I have the following bit of XSLT that turns the “retry” in to a “warning” status going in to the PeopleSoft transaction table for this event:

<?xml version="1.0" encoding="UTF-8"?><xsl:stylesheet
exclude-result-prefixes="query cmd dncv" version="1.0"
 <!-- parameters passed in from the DirXML engine -->
 <xsl:param name="srcQueryProcessor"/>
 <xsl:param name="destQueryProcessor"/>
 <xsl:param name="srcCommandProcessor"/>
 <xsl:param name="destCommandProcessor"/>
 <xsl:param name="dnConverter"/>
 <xsl:param name="fromNds"/>
 <!-- identity transformation template -->
 <!-- in the absence of any other templates this will cause -->
 <!-- the stylesheet to copy the input through unchanged to the output
 <xsl:template match="node()|@*">
   <xsl:apply-templates select="@*|node()"/>
 <!-- add your custom templates here -->
* 16 February 2006 - dgersic
* Turn a return status of "retry" in to a return status of "warning" if the retry
* was issued by the Pub Command Transform policy used to implement
 <xsl:template match="output">
    <xsl:when test="status[@level='retry']">
     <xsl:variable name="msg">
      <xsl:value-of select="status/text()"/>
      <xsl:when test="contains($msg,'niuAccountLockout')">
       <xsl:message>Operation blocked by
       <status level="warning"/>
       <xsl:apply-templates select="node()"/>
     <xsl:apply-templates select="@*|node()"/>
* End of niuAccountLockout XSLT transform

I haven’t tried it, at least not that I remember, but you could probably put any of the valid status codes in there if you don’t want “warning”. I went with “warning” because it seemed to be unused for anything else, and since I wanted the transactions that I’m blocking to be really easy to spot in the transaction table if I need to go find them again. “Warning” as a status also seemed to make sense, since this would be an otherwise valid transaction that’s being blocked by an overriding policy from our security people.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

No Comments
By: dgersic
Jan 17, 2007
6:12 am
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow