Problem using Composite Key Relationship
I am trying to configure an instance of a Relational.Composite transformation by following the online guide for this, specifically with the goal of deriving a new DN attribute via a composite key relationship. I was originally trying to find out what the parameter name might be (the equivalent group transformation has a "GroupTarget" parameter) but couldn't find anything (see comment on the link above). However, I since realised that I am probably supposed to be setting the "target" property of the dn element itself ... but now that I am doing this I am getting an erroneous "The column ValueLevel1ID is a pre-existing column in adapter Meta Tuple Value Adapter". I say erroneous because there is no such duplicate declaration.
My suspicion here is that most people have been using the "columnMappings" element with this transformation instead of "dn" and hence this question hasn't come up before - and the example xml appears to include redundant properties InputKey and RelationshipKey, so I am thinking there might be another doco inconsistency here too?
Customer support service by UserEcho
Problematic adapter configuration is presently as follows:
Note that if I replace the above Relational.Composite adapter with Relation.Group.Composite and replace the dn "target" property with a "GroupTarget" property of the adapter, the service starts and there is no error ... but I don't want a group transformation for the first of the above two adapters.
Hi Bob,
This is a relational transformation, there is no "group target".
Are you after a group based transformation?
If not, and this is the one you are after, can't you just use the dn generator for the adapter?
Adam - that's what I am trying to do now (use the dn generator), and I'm getting the above exception (figured there was no group target) ... and no, I don't want a group transform
Could you please attached the full exception details (stack trace etc)?
Thanks.
I have been running with the group equivalent Relation.Group.Composite while this investigation is going on, and just altered it to the Relational.Composite and restarted the service (removing the GroupTarget property of the adapter node, and replacing it with a target property of the dn node) and got the following 2 Application Event log entries:
How can you be running with the Relation.Group.Composite when that is not what you desire? What is it that you are trying to do?
I can see an issue in the code, but I would like to schedule a fix for it, as the change involves quite a large design change.
Can you work around the issue with a columnMappings attribute instead of the dn attribute, and use an adapter level dn generator instead?
Thanks.
Adam - my requirement for the above adapter is a single value reference attribute and a multi-value reference attribute. It works if I treat them as 2 multi-value reference attributes, but the first will map to a single value reference attribute in the metaverse and what I want (in the case of bad data) is a "discovery error" not a "sync error" (i.e. the discovery error will point to either bad data or some other database problem which if allowed through to the sync engine could be misinterpreted).
Anyhow ... I am guessing there's more than one way to do what I want to do, and am happy to use your work-around once I get my head around what you mean by this (presumably in a chain-list).
I'm still not sure how you can be working with a multi-value reference value instead of a single value. The single reference works using a one-to-one relationship, whereas the multi-value is generated on a one-to-many relationship.
Let me know how you go.
Thanks.
It "works" because a one-to-one relationship can always be considered a special case of a one-to-many relationship, that's all. In my case I can build with a one-to-many relationship because it generates a DN for me ... and so long as I don't happen to get multiple values in this property I can treat it as a single value and don't get any flow errors. However I don't want to leave it this way, and will try your suggested work-around.
Resolved issue with multiple contributions to a key. (v3.0.7)
Have yet to try this myself, but closing anyhow. If there is a problem with the latest fix I will re-open.