DXQue (ECMAScript) does not work






I am trying my hard to queue a event to a driver from another driver using ECMAScript version of DXQUEU, but it does not seem to work for me


I have two drivers:

Sender (running under admin as security equavalent)

Which uses ECMASCRIPT to send event 


Which receives custom event:


Both drivers are running on the same server, 


When i Stopped Receiver, I can see Custom Event in Cache (Driver Cache)

When I start Receiver driver, the following appears: (an empty input  XDS)




[12/30/20 16:06:05.311]:RECEIVER ST:Received state change event. [12/30/20 16:06:05.312]:RECEIVER ST:Transitioned from state '% CCStarting%-C' to state '% CCRunning%-C'. [12/30/20 16:06:05.314]:RECEIVER ST:Successfully processed state change event. [12/30/20 16:06:05.315]:RECEIVER ST:Start transaction. [12/30/20 16:06:05.316]:RECEIVER ST:type(custom-event) [12/30/20 16:06:05.317]:RECEIVER ST:Processing events for transaction. [12/30/20 16:06:05.318]:RECEIVER ST: <nds dtdversion="4.0" ndsversion="8.x"> <source> <product edition="Advanced" version="">DirXML</product> <contact>NetIQ Corporation</contact> </source> <input/> </nds> [12/30/20 16:06:05.322]:RECEIVER ST:Applying event transformation policies. [12/30/20 16:06:05.323]:RECEIVER ST:Applying policy: % CC0-sub-etp-Monitor%-C. [12/30/20 16:06:05.325]:RECEIVER ST:Policy returned: [12/30/20 16:06:05.326]:RECEIVER ST: <nds dtdversion="4.0" ndsversion="8.x"> <source> <product edition="Advanced" version="">DirXML</product> <contact>NetIQ Corporation</contact> </source> <input/> </nds> [12/30/20 16:06:05.329]:RECEIVER ST:Applying policy: % CC0-sub-etp-EntitlementGranter%-C. [12/30/20 16:06:05.331]:RECEIVER ST:Policy returned: [12/30/20 16:06:05.332]:RECEIVER ST: <nds dtdversion="4.0" ndsversion="8.x"> <source> <product edition="Advanced" version="">DirXML</product> <contact>NetIQ Corporation</contact> </source> <input/> </nds> [12/30/20 16:06:05.336]:RECEIVER ST:Applying policy: % CC0-sub-etp-Scopefilter%-C. [12/30/20 16:06:05.337]:RECEIVER ST:Policy returned: [12/30/20 16:06:05.338]:RECEIVER ST: <nds dtdversion="4.0" ndsversion="8.x"> <source> <product edition="Advanced" version="">DirXML</product> <contact>NetIQ Corporation</contact> </source> <input/> </nds>








The details of custom event is see as on driver cache inspector:



Event details from cache:



<add cached-time="20201230144415.430Z" class-name="DirXML-WorkToDo" event-id="0" event-priority="normal" qualified-src-dn="O=MGMT\OU=Resources\OU=WorkOrders\OU=WorkToDo\CN=someuser-O365-POST-E3ToDo01/01/1970 12:59 AM" src-dn="_____TREE\WorkOrders\WorkToDo\someuser-O365-POST-E3ToDo01/01/1970 12:59 AM" src-entry-id="2585445" timestamp="1609339450#23"> <add-attr attr-name="Description"> <value timestamp="1609339450#21" type="string">post task for the sku E3</value> </add-attr> <add-attr attr-name="DirXML-nwoDN"> <value timestamp="1609339450#22" type="dn">______TREEE\WorkOrders\someuser-O365-POST-E3</value> </add-attr> <add-attr attr-name="DirXML-nwoContactName"> <value timestamp="1609339450#23" type="string"><!INTENTIONALLY REMOVED FROM LOG-->\someuser</value> </add-attr> <add-attr attr-name="DirXML-nwoContent"> <value timestamp="1609339450#20" type="string">someuser</value> </add-attr> <operation-data prop.retried.Event="true" prop.sub.etp.zimbra.Id="jamesdean@xxxx"> <retry> <idmserver>CN=ZZ,OU=Servers,OU=Services,O=TREE</idmserver> <retried>1</retried> <retrying>2</retrying> <maxretryallowed>3</maxretryallowed> <correlationid>c6f60422-0733-4857-8414-9105d5129632-someuser</correlationid> <originaleventdatetime>20201230T15:44:28</originaleventdatetime> <scheduleddatetime>20201230T16:16:35</scheduleddatetime> <lasterror>{"erorr": "ERROR:ERROR : System.Management.Automation.RemoteException: Recipient **PERSONAL INFORMATION REMOVED** already has an archive. This task doesn't support multiple archives per recipient."}</lasterror> <reason>O365-POST-E3</reason> </retry> </operation-data> </add>






  • In my OTP I use this policy...  I try to remove the 2nd, 3rd, nth events and enqueue them so that only one is processed at a time.

    <rule> <description>[LS] Split additional events into Op data for replay.</description> <comment xml:space="preserve">SOAP has a hard time doing multiple documents at once, because some APIs require a unique endpoint or unique SOAP Action header, which makes it hard to send all in one. To solve this there are probably a bunch of possible options: 1) In the shim split the events and send them one by one. 2) In Policy split the events and try to send them as seperately queued events. 3) Remove the events after the first one, before the XDS->SOAP and write the extra to op-data, then once a success is processed send it back into the queue for processing. (Similar to storing the SOAP document to replay later approach). This policy will attempt option #2 and split the events off, and inject them into the queue to process as unique after this event. What is tricky is that second pass, the current event is now a SOAP document, so do not strip/resend anything unless it is actual XDS at this point.</comment> <comment name="author" xml:space="preserve">Geoffrey Carman</comment> <comment name="version" xml:space="preserve">1</comment> <comment name="lastchanged" xml:space="preserve">Oct 26, 2020</comment> <conditions> <and> <if-operation mode="regex" op="equal">add|modify|move|rename|delete</if-operation> </and> </conditions> <actions> <do-set-local-variable name="inout" scope="policy"> <arg-string> <token-xpath expression="name(/nds/input | /nds/output)"/> </arg-string> </do-set-local-variable> <do-set-local-variable name="EVENTS" scope="policy"> <arg-node-set> <token-xpath expression="/nds/*[name()= $inout]/*"/> </arg-node-set> </do-set-local-variable> <do-trace-message> <arg-string> <token-xml-serialize> <token-local-variable name="EVENTS"/> </token-xml-serialize> </arg-string> </do-trace-message> <do-for-each> <arg-node-set> <token-xpath expression="$EVENTS"/> </arg-node-set> <arg-actions> <do-if> <arg-conditions> <or> <if-xpath op="true">$current-node/add</if-xpath> <if-xpath op="true">$current-node/modify</if-xpath> </or> </arg-conditions> <arg-actions> <do-set-local-variable name="DOC" scope="policy"> <arg-node-set> <token-xml-parse> <token-text xml:space="preserve">&lt;nds>&lt;input/>&lt;/nds></token-text> </token-xml-parse> </arg-node-set> </do-set-local-variable> <do-clone-xpath dest-expression="$DOC/nds/input" src-expression="$current-node"/> <do-trace-message> <arg-string> <token-xml-serialize> <token-local-variable name="DOC"/> </token-xml-serialize> </arg-string> </do-trace-message> <do-set-local-variable name="DUMMY" scope="policy"> <arg-string> <token-xpath expression="es:sendQueueEvent($dirxml.auto.driverdn,$DOC)"/> </arg-string> </do-set-local-variable> </arg-actions> <arg-actions/> </do-if> </arg-actions> </do-for-each> <do-strip-xpath expression="/nds/*[name()= $inout]/*"/> </actions> </rule>


    I think the key point is that I wrap the Operation in the <nds> and <input> nodes.  Which maybe you are not.

    I made myself one ECMA object (addinng with permission to my ECMA library I share) to with both sendQueueEvent() and migrateAPp() functions, since they are basically the same, differing really in one function call.


  •   I can see this is ECMAScript is doing already:

    Queuing supplied XDS => <nds dtdversion="4.0" ndsversion="8.x"><source><product edition="Advanced" version="">DirXML</product><contact>NetIQ Corporation</contact></source><input>


  • Verified Answer

      I found out , actually all the references in the XDS must exist in IDV , in my previous examples XDS has reference back to WorkTODO object which was deleted. If i do not delete WorkToDO object i can submit XDS without any issues.



  • Good catch. I just like to be complete. 

  • That is interesting I guess this is a manifestation of the DN and DOM issue.  the XDS while shown at text, is stored as DOM in memory/cache and I guess the text representation of DN's is not per se a text string but rather an object ID refrerence. In both cases, it is more efficient, takes less memory and is easier to handle.


    So when you are submitting it, the text cannot resolve to an object and back. Good to know.