Replace Operation Attribute - Results of Query in Input?

I'm trying to replace an operation attribute with the results of a search to a different object class. Looking for some advice on how to accomplish....

So an incoming user has a location object set - say Houston. The actual CN (location code) for Houston is HOU.

So i want to query Ou=Locations,O=Tree for objectclass=SiteCodes, City=Houston and return HOU, and replace the original location presented with HOU. Anyone have an example? Find matching object only searches objectclass=User. I tried the query token but that also is only yielding user queries.


Thanks
  • The query token is what you want, and you should be able to set the object
    class in there (or leave it out to query any class) to whatever you like,
    along with the base DN and various attribute/value pairs for the filter.

    https://www.netiq.com/documentation/identity-manager-developer/dtd-documentation/dirxmlscript/token-query.html

    With the result I think you'll have a Nodeset, but if you only get the one
    value maybe you can treat it like a string... I don't recall right now.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • On 3/11/2019 2:34 PM, el triad wrote:
    >
    > I'm trying to replace an operation attribute with the results of a
    > search to a different object class. Looking for some advice on how to
    > accomplish....
    >
    > So an incoming user has a location object set - say Houston. The actual
    > CN (location code) for Houston is HOU.
    >
    > So i want to query O for objectclass=SiteCodes,
    > City=Houston and return HOU, and replace the original location presented
    > with HOU. Anyone have an example? Find matching object only searches
    > objectclass=User. I tried the query token but that also is only
    > yielding user queries.


    Find Matching is ONLY for use in the Match policy. You want to Query.
    Or you could use Source/Dest attr (depending on direction).

    Query will simply do this:
    <do-set-local-variable name="QUERY" scope="policy">
    <arg-node-set>
    <token-query class-name="SiteCodes">
    <arg-dn>
    <token-text xml:space="preserve">Ou=Locations,O=Tree</token-text>
    </arg-dn>
    <arg-match-attr name="city">
    <arg-value type="string">
    <token-op-attr name="L"/>
    </arg-value>
    </arg-match-attr>
    </token-query>
    </arg-node-set>
    </do-set-local-variable>

    Note: set to a nodeset variable. In theory could return 0, 1, or more
    values. I am assuming 0 or 1 only.

    Then to get the specific value, do this:
    <do-set-local-variable name="LOC" scope="policy">
    <arg-string>
    <token-parse-dn dest-dn-format="slash" length="1"
    src-dn-format="slash" start="-1">
    <token-xpath expression="$QUERY/@src-dn"/>
    </token-parse-dn>
    </arg-string>
    </do-set-local-variable>

    <do-reformat-op-attr name="L">
    <arg-value type="string">
    <token-local-variable name="LOC"/>
    </arg-value>
    </do-reformat-op-attr>





  • For extra credit, when you get your nodeset back from the query, check to see if you got 0, 1, or many results. What should your policy do for 0 results? 1 result? Many results?

    Decide this now and handle it, so that you won't to come back to it a year or two from now wondering why your objects have attributes with no value (0 results), or what happened when somebody set up "Chicago" (CHI) and "China" (CHI) in your location tree.
  • dgersic wrote:

    >
    > For extra credit, when you get your nodeset back from the query, check
    > to see if you got 0, 1, or many results. What should your policy do for
    > 0 results? 1 result? Many results?
    >


    Really good point. Also recall that a query consists of a status and 0 or more
    instances.
    It is legal to get back a status of error and no results.

    --
    If you find this post helpful, and are viewing this using the web, please show
    your appreciation by clicking on the star below
  • dgersic wrote:

    >
    > For extra credit, when you get your nodeset back from the query, check
    > to see if you got 0, 1, or many results. What should your policy do for
    > 0 results? 1 result? Many results?
    >


    Really good point. Also recall that a query consists of a status and 0 or more
    instances.
    It is legal to get back a status of error and no results.

    --
    If you find this post helpful, and are viewing this using the web, please show
    your appreciation by clicking on the star below