Can a Relation.Group.dn transformation be used in conjunction with a filter?

Bob Bradley 13 years ago updated by anonymous 9 years ago 9

I have configured the following adapter which references a placeholder PERSON connector, and I am trying to get back an "Orgs" collection using a Relation.Group.dn transformation. The following is my adapter configuration:

        <!-- 000 Person -->
        <AdapterConfiguration BaseConnectorId="{A672CB12-2CA2-498b-8992-EAB883A1FC44}"
              AdapterName="Person Adapter"
              class="person" >
            <dnComponent name="Field" key="AccountName" attributeType="UID" />
            <dnComponent name="Constant" value="People" attributeType="OU" />
          <adapterEntityTransformationFactory name="ChainList">
            <adapter name="Relation.Group.dn"
               InputKey ="AccountName"
               RelationshipConnectorId ="{429AE766-0A1F-404a-ACC1-B4804C859146}"
               RelationKey ="UserIDName"
               RelationReference ="subKey"
                <dnComponent name="Field" key="Code" attributeType="UID" />
                <dnComponent name="Constant" value="Orgs" attributeType="OU" />

The problem I have is that this will return all (distinct) subKey objects associated with the UserIDName derived from an existing claims connector, where I only want to return those where another claims attribute ApplicationName="ESS". Is this possible, and if so how?

I don't believe there is some xml you could add that would do that but one of the product guys could tell you for sure. It might be possible to use a .csv connector with just the filter value you want in it then do some joining foo to exclude the data you don't want.

Daniel is correct that the CSV connector is often useful in situations such as this.

However, after discussions with Ross, I believe an extended transformation may be able to do the job and is certainly worth a shot.

Please take a look at IDBXT306:Composite key group with string priority relationship. And although it is designed for composite keys, from the code it appears to be possible to use a single key.


Thanks Dan - I've been thinking along similar lines already, and am really hoping for some quick pointer that can stop me going down the wrong path ... we have hit a project stumbling block, and the use of Identity Broker to jump this hurdle depends on its ability to handle this type of scenario easily.

Thanks Adam - eagerly looking now ... hoping to avoid CSV.

/facepalm I should have known that adapter.

D@rn it ... Unify.Framework.UnifyServerStartException: Generator named Relation.Group.Composite.Filter.String not registered

I'm using version ... so I am presuming from the "IDBXT306" article that I need another installer? I've only ever installed from https://unifysolutions.jira.com/wiki/display/SUBIDB/Downloads ... and just discovered https://unifysolutions.jira.com/wiki/display/SUBIDBXT/Downloads then. Can I just download it and install side by side Adam?


The Identity Broker version matches the version of Identity Broker that is installed. We incorporate extended transformations into the core product during the release cycle for Identity Broker.

Lovely - I've installed it, configured a couple of instances of the transformation, and will let you know how the testing goes (the service starts now with the new transform at least!)

Thanks Adam/Ross/Dan ... installed and working @ DEEWR. I did notice some weirdness trying to put 3 of these things together (only one appeared in the adapter), but commented out 2 of the transformations for now and am running with just the one for now ... seems to be working a treat!