ALERT! The community will be read-only on April 19, 8am Pacific as the migration begins. Read more for important details.
ALERT! The community will be read-only on April 19, 8am Pacific as the migration begins.Read more for important details.
Lieutenant Commander
Lieutenant Commander
493 views

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

Jump to solution

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 🙂

0 Likes
1 Solution

Accepted Solutions
Knowledge Partner Knowledge Partner
Knowledge Partner

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

 

______________________________________________
https://www.is4it.de/identity-access-management

View solution in original post

11 Replies
Commodore
Commodore
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
0 Likes
Lieutenant Commander
Lieutenant Commander

Hello!

Yes, unfortunately same DN doesn't help.

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner
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.
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
Commodore
Commodore
Read the example i would suggest🤣
0 Likes
Lieutenant Commander
Lieutenant Commander

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.

0 Likes
Admiral
Admiral

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

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

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>

 

 

______________________________________________
https://www.is4it.de/identity-access-management
Lieutenant Commander
Lieutenant Commander

Hi Lothar!

Did you check it in the Designer's Simulator?

0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner
Yes
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

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

 

______________________________________________
https://www.is4it.de/identity-access-management

View solution in original post

Lieutenant Commander
Lieutenant Commander
Thanks! It works!
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.