Group By Adapter or Transformation
Currently, the only way for us to create group memberships is to take a connector that contains a unique list of groups and do a relational.dn join to get its members.
Eg,
class connector contains class 001,
student enrolment connector contains a relationship between Student1 and 001
student enrolment connector contains a relationship between Student2 and 001
relational join on class:student1,student2
However, in some cases we may wish to create groups based on aggregate values (ie, group by) within a single connector - without a relationship connector.
Eg, Student connector that has Name, academicYearLevel and homeRoomClass
It would be great if i could create attribute-based groups based off of these values without a second connector that contains a unique list of academicYearLevels to join against.
Eg:
This would create an adapter that contains a unique list of academic years with a multi-value field that has DN's for the students
This would create an adapter that has attribute based groups for both academicYearLevel AND studentID... This is essentially 'union' functionality so that you don't need a seperate adapter for every type of attribute-based group. Fields are "groupkey" and "studentID". Note the prefix allows you to distinguish between the two groups (is pre-pended to attribute value)
Is equivalent to SQL group by school,academicYearLevel. Would return a group for each yearLevel at each school. The columns returned would be groupkey (containing school:academicYearLevel) and "studentID" (multi-value list of DN's... column name matches
Customer support service by UserEcho
The following description from
PRODUCT-54summarises the requirements better for the first part of the issue (the second part has already been done on another issue):Moved to v4.1.
Isn't this already possible using a Group transformation and setting the relational connector as itself?
Matthew Clark, I think it was more the ability to return a reduced number of entities from the transformation. In this case by grouping on a non-unique field, and ending up with that field unique and a members field of all the keys. Would probably not even have to do the membership, as this could be handled by another transformation built off the new key.
Migrated to VSO.