Inside Activate
Search
Custom Query Handlers
7 min
this change introduces a new way to control how role membership is browsed within activate, enabling support for static roles and more flexible data sources beyond ldap browsing role members using custom query handlers in earlier versions of activate, browsing the members of a role relied solely on an ldap query this approach works well for active directory–based dynamic roles but has limitations for static roles and scenarios where role membership information is stored or derived from non ldap sources from activate 8 3 11, role member browsing can be customised by delegating the query logic to a script based handler overview of the change a new handler attribute has been added to the \<query> element this attribute allows the query to be resolved by a script rather than an ldap query the handler references a script parameter that is responsible for returning the role members this enables browsing members of static roles stored in the activate database combining data from multiple sources using additional tables such as adcache, adcachecustom, and extendedattributes implementing custom filtering or business logic that is not possible with ldap alone how the handler works when a \<query> element includes a handler attribute activate does not perform an ldap query for role membership instead, the referenced script parameter is executed the script must return a list of instances representing role members the script can return either a list of directory instances, or a provisioningdirectorycollection these results are then used by activate to populate the role member browse experience the results are not cached (unless cached results are used in the script), the script is executed on demand and the results returned script responsibilities the script referenced by the handler is responsible for querying the appropriate data source (for example, the activate database or cache tables) applying any required filtering or transformation returning a collection of instances in a format activate can consume because the logic is script based, it can be extended to join or correlate data across multiple tables or attributes that are not available via ldap example using a script based query handler the following example demonstrates how a web form query can delegate role member resolution to a script in this example, the \<query> element specifies a handler attribute that references a script parameter no ldap query is defined in the form itself \<?xml version="1 0" encoding="utf 8"?> \<webform> \<panel> \<validatedtextbox id="name" label="name" activatebind="username" isrequired="false" /> \</panel> \<query handler="=/getmembersscript"> \</query> \</webform> the referenced script is responsible for returning the instances to be displayed the following script returns a provisioningdirectorycollection containing the current user while the logic is intentionally simple, it illustrates the required structure and return type using system; using innovation activate; class script scriptbase { public provisioningdirectorycollection main() { provisioningdirectorycollection col = new provisioningdirectorycollection(); col loadfromdns(new string\[] { currentuser distinguishedname }); return col; } } in a real implementation, this script could instead query static role membership from the activate database use cached directory data from adcache or adcachecustom filter or enrich results using values from extendedattributes apply custom business rules to determine which instances are returned when to use a query handler using a query handler is recommended when the role is static and not backed by an ldap query role membership is derived from database records rather than active directory additional attributes or cached data are required to determine membership custom logic is needed to control which instances are returned for simple ad based dynamic roles, the existing ldap query approach remains appropriate version availability this functionality is available from activate 8 3 11 onwards and does not require a feature flag to be enabled