Directory Harvester
The Directory harvester is used to harvest information from an AD (Active Directory) or LDAP directory.
Configuring the Directory Harvester
Image 1, Directory Harvester properties
| Harvester |
| Name |
The name of the harvester in use by the selected Query-node. To change harvester, select the name property and click on the ellipsis button. Select the appropriate harvester in the form that is displayed. |
| Directory |
| Path |
The path to the directory you wish to harvest. When you add your harvester to your model, the path to the default directory is suggested. If you leave this property empty, the path to the default directory is evaluated at runtime. |
| Filter |
Filter the data harvested from the directory. In this example we harvest information about persons in the directory. |
| Sort |
You may select an attribute to sort the results by. You must select an attribute that is in the resultset. |
| Result |
| Array delimiter |
If an attribute contains an array of values, these values are joined together using the specified delimiter. The default delimiter is a comma followed by a space. |
Adding relations
We use the model displayed in image 1 to list all users in our Active Directory and for each user list some details. The model is silly of course, since the details could just as well be harvested by the root node directly, but the model does demonstrate how to use relations to harvest a tree of information.
In order to harvest related information, i.e. a tree of information, we need to describe how the information in our model is related. For the directory harvester, there are two ways to do this. You can use any of the methods, or a combination of them.
1. Parent relation
Every query node (except for the root node), independent of which harvester it uses, has a parent relation property in the XML section.
Image 2, the parent relation property
To add or edit a parent relation, select the property and click on the ellipsis button.
Image 3, managing the parent relation
All leaves of the selected node, having Column Name specified in the Source section, are listed in the Column combo box, and all parent leaves, having Column Name specified in the Source section, are listed in the Parent column combo box. In the first column you can either select any of the listed options, or you can type your own value. In the second column you must select one of the avaliable parent column options. You can add any number of relations.
The root node selects the common name of all the users in the active directory. The Details query element is executed once for every row returned by the root query, selecting some more attributes for the users where the common name matches the common name selected by the root node. I.e. for each user selected by the root node, we select the detailed information.
2. Tagging the filter property
Using the directory harvester you may tag the filter using the following syntax; <parent.ColumnName>, where ColumnName is the value of the Column Name property for the parent column/leaf. At runtime, the tag will be substituted with the harvested value of the specified parent column.
Image 4, tagging the filter property
In the example in image 4, we have entered a filter selecting only persons with the same common name as the parent, i.e. the root node selects the common name of all the users in the active directory and the directory harvester of the Details2 query element is executed with the parents common name substituted into the filter.
The root node does not have a parent, hence you cannot substitute any tags with parent column values for havesters applied to the root node. However, when executing the model, you can supply a filter, that is passed to the harvester of the root node. The directory harvester may make use of this filter by adding the tag <param.filter> to the filter property.
When you add a directory harvester to the root node, you may notice that the default value for the filter property is <param.filter>, i.e. by default the harvester uses the supplied filter.
