Vice Admiral
Vice Admiral
334 views

DXQue (ECMAScript) does not work

Jump to solution

 

Hello

 

https://github.com/lhaeger/dxqueue/blob/master/src/dxqueue-es/sendQueueEvent.js

 

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 

Receiver:

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 '%+C%14CStarting%-C' to state '%+C%14CRunning%-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="4.7.4.0">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: %+C%14C0-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="4.7.4.0">DirXML</product>
    <contact>NetIQ Corporation</contact>
  </source>
  <input/>
</nds>
[12/30/20 16:06:05.329]:RECEIVER ST:Applying policy: %+C%14C0-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="4.7.4.0">DirXML</product>
    <contact>NetIQ Corporation</contact>
  </source>
  <input/>
</nds>
[12/30/20 16:06:05.336]:RECEIVER ST:Applying policy: %+C%14C0-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="4.7.4.0">DirXML</product>
    <contact>NetIQ Corporation</contact>
  </source>
  <input/>
</nds>

 

 

 

 

 

 

Capture2.PNG

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>

 

 

Regards.

Maqsood.

 

Labels (1)
0 Likes
1 Solution

Accepted Solutions
Vice Admiral
Vice Admiral

@geoffc  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.

 

/Maqsood

View solution in original post

5 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

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.

 

Vice Admiral
Vice Admiral

@geoffc  I can see this is ECMAScript is doing already:

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

/Maqsood. 

0 Likes
Vice Admiral
Vice Admiral

@geoffc  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.

 

/Maqsood

View solution in original post

Knowledge Partner Knowledge Partner
Knowledge Partner

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.

 

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Good catch. I just like to be complete.  🙂

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.