Handling Multi-valued attribute

[vikash]

Hello Everyone,

in my AL, I am reading group from file and i want to get the user id's for all the user under a particular group.
After reading the group name from file i am doing a ldap lookup with the following link criteria (ldap_groupname equals groupvalue_fromFile)
in the input map i have included the uid.

but since the group is a multi-value attribute how i can get all the uid's which belongs to this group.

i am just able to read only the first user id by using thisConnector.getFirstDuplicateEntry(); in on-multiple Entries hook.

how i can read all the entries?

Thanks

[John Dell'Oso]

Off the top off my head I can think of two ways (there are more):

1) After your LDAP lookup, use script something like this to get the members of the group (assuming that "member" is your work attribute - change accordingly)

var mbr;

for (mbr in work["member"].getValues()) {
// DO STUFF
task.logmsg("INFO", "The member is " + mbr)
}

.. you could also do this in your input attribute map and load the values into an array for example

... BUT my preferred method (and IMHO the best way) is to:

2) after your LDAP lookup, use an attribute value loop connector to iterate through the multi-valued attribute - set up one of these connectors and I'm sure you will be able to work out how to use it (it's a good learning exercise anyway :) )

Cheers,
JD

[yn2000]

Option #3) Connector Loop (branch connector).
same... (it's a good learning exercise anyway :) )
Rgds. YN.

[Eddie Hartman]

Post by yn2000
Option #3) Connector Loop (branch connector).
same... (it's a good learning exercise anyway :) )
Rgds. YN.

Being the nitpickler that I am, just wanted to show you that iterating attribute values in script is even simpler than your suggestion, John:

cnt = 0;
att = work.member; // att references an Attribute
for (memberDN in att) {
task.logmsg("att value #" + (cnt++) + ": " + memberDN
" type: " + typeof(memberDN)); // if member value, then all should be String
}

Now the fact that you are using .getFirstDuplicateEntry() makes me think that your lookup is not finding a single group - but rather multiple. If this is the case, you may want to first step through the entries returned, and for each you accumulate the members to, for example, and array:

collectMembers = new java.util.ArrayList();

// your looping logic, first grabbing each next duplicate entry (until null is returned)
// and for each entry, you look through the members:
for (member in entry.member) {
if (!collectMembers.contains(member)) {
collectMembers.add(member);
}
}

// Then later you can return the arraylist as an array, or whatever you need to do your work. Also note
// that the for-in loop for this type of collection, just like it works for Entries and Attributes:

for (member in collectMembers) {
// do something with this member value
}

[Franzw]

Post by Eddie Hartman

Post by yn2000
Option #3) Connector Loop (branch connector).
same... (it's a good learning exercise anyway :) )
Rgds. YN.

cnt = 0;
att = work.member; // att references an Attribute
for (memberDN in att) {
task.logmsg("att value #" + (cnt++) + ": " + memberDN
" type: " + typeof(memberDN)); // if member value, then all should be String
}
collectMembers = new java.util.ArrayList();
// your looping logic, first grabbing each next duplicate entry (until null is returned)
for (member in entry.member) {
if (!collectMembers.contains(member)) {
collectMembers.add(member);
}
}
// Then later you can return the arraylist as an array, or whatever you need to do your work. Also note
for (member in collectMembers) {
// do something with this member value
}

Well - when we are at nit picking I want to join the choir :-)

Although scripting is easy it has one problematic attribute - it hides the flow from the AL view...

We (my team in IBM) discussed this and in many case it is easy (or even easier) to this kind of thing in a script node - but when delivering an AL as a solution that runs for years in an environment and you need to find out what this component really does then scripting is not optimal.

I have preached for many years that you need to consider the maintenance burden more than the implementation cost when providing solutions - so if you doing something that is not a one-off then I would go for the attribute value connector or similar so the loop is clearly visible in the Eclipse UI...

But as always - there is no absolute truth here...

Regards
Franz Wolfhagen

[Eddie Hartman]

Post by Franzw

Post by Eddie Hartman

Post by yn2000
Option #3) Connector Loop (branch connector).
same... (it's a good learning exercise anyway :) )
Rgds. YN.

cnt = 0;
att = work.member; // att references an Attribute
for (memberDN in att) {
task.logmsg("att value #" + (cnt++) + ": " + memberDN
" type: " + typeof(memberDN)); // if member value, then all should be String
}
collectMembers = new java.util.ArrayList();
// your looping logic, first grabbing each next duplicate entry (until null is returned)
for (member in entry.member) {
if (!collectMembers.contains(member)) {
collectMembers.add(member);
}
}
// Then later you can return the arraylist as an array, or whatever you need to do your work. Also note
for (member in collectMembers) {
// do something with this member value
}

Well - when we are at nit picking I want to join the choir :-)
Although scripting is easy it has one problematic attribute - it hides the flow from the AL view...
We (my team in IBM) discussed this and in many case it is easy (or even easier) to this kind of thing in a script node - but when delivering an AL as a solution that runs for years in an environment and you need to find out what this component really does then scripting is not optimal.
I have preached for many years that you need to consider the maintenance burden more than the implementation cost when providing solutions - so if you doing something that is not a one-off then I would go for the attribute value connector or similar so the loop is clearly visible in the Eclipse UI...
But as always - there is no absolute truth here...
Regards
Franz Wolfhagen

Amen, Franz. Although scripted solutions can be as easy to read than AL component flows (just like AL component flows can offend the eye :), you do loose component features, like auto reconnect, configurable maps (also via files) and pooling.