Scripted attribute dependencies

[Wessel, Keith]

Hi, all,

In converting our <Dependency> elements in our 3.4 attribute resolver config to <InputDataConnector> and <InputAttributeDefinition> elements, I noticed something that seemed unusual, and I wanted to ask if it was intentional.

Previously, when I was using attributes from a data connector dependency, this check was sufficient to ensure that there were values before calling getValues().get(0):

If ( typeof sAMAccountName != "undefined" && sAMAccountName != null )

But I decided to start using our uid attribute definition as an input rather than three data connector inputs that each pull from a different Active Directory OU. Made for a cleaner configuration. The uid attribute definition is pulling from those same InputDataConnectors, and I saw no reason to duplicate that.

However, I discovered that a similar check evaluated to true, even for an empty list of values:

If (typeof uid != "undefined" && uid != null )

This check evaluated to true even when uid got no values back from its InputDataConnectors, but then uid.getValues().get(0) obviously failed with an index out of range exception. I had to change my "uid != null" to "uid.getValues().size() > 0".

The null check still works when I'm using an InputDataConnector as a dependency, presumably because the variable isn't set if the attribute doesn't exist in the results from the DataConnector's LDAP query.

This doesn't seem consistent to me. I don't mind working around it, but was this intentional?

Also, is there a better way to handle my conditionals than checking for a type not of undefined and a list with a size greater than 0?

Thanks,
Keith