4.8 and "do-add-dest-attr-value" token

[Zalkus]

Hello gentlemen!

I've detected strange behavior of "do-add-dest-attr-value" in the IDM 4.8: in case of multiple calls in a row it doesn't create one "modify" (as before) but splits data to several "modifies".

For example, if I call:

<do-add-dest-attr-value class-name="Class1" name="Attr1">
	<arg-dn>
		<token-text xml:space="preserve">someDN</token-text>
	</arg-dn>
	<arg-value type="string">
		<token-text xml:space="preserve">value1</token-text>
	</arg-value>
</do-add-dest-attr-value>
<do-add-dest-attr-value class-name="Class1" name="Attr2">
	<arg-dn>
		<token-text xml:space="preserve">someDN</token-text>
	</arg-dn>
	<arg-value type="string">
		<token-text xml:space="preserve">value2</token-text>
	</arg-value>
</do-add-dest-attr-value>

I expect to receive a "modify with 2 attributes:

<modify class-name="Class1" dest-dn="someDN">
	<modify-attr attr-name="Attr1">
		<add-value>
			<value type="string">value1</value>
		</add-value>
	</modify-attr>
	<modify-attr attr-name="Attr2">
		<add-value>
			<value type="string">value2</value>
		</add-value>
	</modify-attr>
</modify>

But I receive 2 "modifies": 

<modify class-name="Class1" dest-dn="someDN">
	<modify-attr attr-name="Attr1">
		<add-value>
			<value type="string">value1</value>
		</add-value>
	</modify-attr>	
</modify>
<modify class-name="Class1" dest-dn="someDN">	
	<modify-attr attr-name="Attr2">
		<add-value>
			<value type="string">value2</value>
		</add-value>
	</modify-attr>
</modify>

It happens for "add to current operation" and "add after current operation" modes. (I didn't tried for other modes)

Does somebody detect such behavior? How can I avoid it? I don't really want to rewrite very huge policy using "append xml element" tokens and so on 🙂

[Michiel Los]

I found the same which troubled our behavior on the driver. I thought the solution was to set the dn to the same value, but that does not help in your case i see. Will do some testing and let know what the current solution is at my install.

Best regards
Michiel Los

[Zalkus]

Hello!

Yes, unfortunately same DN doesn't help.

[Alex McHugh]

same class name is also key to ensuring the engine sees it as part of the same modify. Assume you have explicitly specified class name.

[Michiel Los]

Read the example i would suggest🤣

[Zalkus]

Same class and same DN didn't help in this case...

Even more, such code works as expected on previous versions, but on 4.8 it is behaving strangely.

[cpedersen]

Something similar was the case in an earlier version - it could be the same bug.

[lhaeger]

It might be fixed in 4.8.3.1 already, at least this is what I see in Designer when patched with the latest dirxml*jars from the Hotfix:

AIE-Driver :    Applying rule 'test'.
AIE-Driver :      Action: do-add-dest-attr-value("Attr1",class-name="Class1",arg-dn("someDN"),"value1").
AIE-Driver :        arg-dn("someDN")
AIE-Driver :          token-text("someDN")
AIE-Driver :          Arg Value: "someDN".
AIE-Driver :        arg-string("value1")
AIE-Driver :          token-text("value1")
AIE-Driver :          Arg Value: "value1".
AIE-Driver :      Action: do-add-dest-attr-value("Attr2",class-name="Class1",arg-dn("someDN"),"value2").
AIE-Driver :        arg-dn("someDN")
AIE-Driver :          token-text("someDN")
AIE-Driver :          Arg Value: "someDN".
AIE-Driver :        arg-string("value2")
AIE-Driver :          token-text("value2")
AIE-Driver :          Arg Value: "value2".
AIE-Driver :Policy returned:
AIE-Driver :
<nds dtdversion="4.0" ndsversion="8.x">
  <source>
    <product version="4.8.3.1">DirXML</product>
    <contact>NetIQ Corporation</contact>
  </source>
  <input>
    <add class-name="User" qualified-src-dn="o=dirXML Test\ou=Users\cn=User1" src-dn="o=dirXML Test\ou=Users\cn=User1">
      <association>o=dirXML Test\ou=Users\cn=User1</association>
      <add-attr attr-name="Surname">
        <value type="string">Surname1</value>
      </add-attr>
      <password>initialpwd</password>
    </add>
    <modify class-name="Class1" dest-dn="someDN">
      <modify-attr attr-name="Attr1">
        <add-value>
          <value type="string">value1</value>
        </add-value>
      </modify-attr>
      <modify-attr attr-name="Attr2">
        <add-value>
          <value type="string">value2</value>
        </add-value>
      </modify-attr>
    </modify>
  </input>
</nds>

[Zalkus]

Hi Lothar!

Did you check it in the Designer's Simulator?

[lhaeger]

Yes

[lhaeger · Accepted solution]

---

@Zalkus wrote:

Does somebody detect such behavior? How can I avoid it? I don't really want to rewrite very huge policy using "append xml element" tokens and so on 🙂

---

I've only seen something like this when those tokens do-add/set-src/dest-attr do not follow each other immediately, or if class/dest-dn/association are not exactly the same, e.g...

<do-add-dest-attr-value class-name="Class1" name="Attr1">
				<arg-dn>
					<token-text xml:space="preserve">someDN</token-text>
				</arg-dn>
				<arg-value type="string">
					<token-text xml:space="preserve">value1</token-text>
				</arg-value>
			</do-add-dest-attr-value>
			<do-add-dest-attr-value class-name="Class2" name="Attr2">
				<arg-dn>
					<token-text xml:space="preserve">someDN</token-text>
				</arg-dn>
				<arg-value type="string">
					<token-text xml:space="preserve">value2</token-text>
				</arg-value>
			</do-add-dest-attr-value>
			<do-add-dest-attr-value class-name="Class1" name="Attr2">
				<arg-dn>
					<token-text xml:space="preserve">someDN</token-text>
				</arg-dn>
				<arg-value type="string">
					<token-text xml:space="preserve">value2</token-text>
				</arg-value>
			</do-add-dest-attr-value>

...will always create three modifies instead of two.

Not sure if you can avoid this (or your suspected bug, if you're already on the latest version - are you?).

You can, however, add a rule at the end of your policy to merge those modifies back into one. Something like this could be a starting point:

<do-for-each>
	<arg-node-set>
		<token-xpath expression="following-sibling::modify"/>
	</arg-node-set>
	<arg-actions>
		<do-set-local-variable name="current-siblings" scope="policy">
			<arg-node-set>
				<token-xpath expression="$current-node/following-sibling::modify[@class-name=$current-node/@class-name and @dest-dn=$current-node/@dest-dn]"/>
			</arg-node-set>
		</do-set-local-variable>
		<do-clone-xpath dest-expression="$current-node" src-expression="$current-siblings/modify-attr"/>
		<do-strip-xpath expression="$current-siblings"/>
	</arg-actions>
</do-for-each>

Now repeat this on the resulting merged modify for possibly duplicate modify-attr/@attr-name nodes and you should get nicely optimized XDS.

If you implement that as a generic library you can even include it all over the place, in case the issue hits you elsewhere, too.

[Zalkus]

Thanks! It works!