Programming Guides › Connector Programming Guide › Writing Scripts › LOOKUP and SEARCH Query Operations through Script Opbindings Considerations

LOOKUP and SEARCH Query Operations through Script Opbindings Considerations

Consider the following when dealing with the LOOKUP and SEARCH query operations through script opbindings:

• Query Opbindings with Timing=PRE are not supported.
• LOOKUP opbindings with Timing=POST can access the attributes returned from the operation using the attrs scripting variable.
• Directly-executed SEARCH opbindings with Timing=OP can return search results through a NamingEnumeration as some form of java.util.Collection, where a simple synchronous implantation is chosen. However, it is also possible to specify that directly executed SEARCH opbindings with Timing=OP are executed asynchronously, by setting asynchronousSearch=true on their guards. When the property is set to true, the triggered script must queue search results by adding them to the queue bound to the searchResultsBlockingQueue scripting variable, and return null when it has finished its processing. In this case, the CA IAM CS framework automatically runs the SEARCH script in a separate thread and streams results back to the client asynchronously as they become available.
• Opbindings with Timing=OP (instead-of) are supported and mean that the script process the query, rather than the target connector being wrapped. The most difficult aspect in implementing SEARCH operations (whether using Java code or scripting) is the issue of manipulating and filter based on the provided LDAP filter.

  Note: For more information, see Querying Connector Objects.

• The CA IAM CS framework allows some flexibility in the way that LOOKUP and SEARCH results are represented.

  Instead of returning an Attributes object, LOOKUP operations can choose to return a Map, and SEARCH operations can return either a NamingEnumeration, or any form of java.util.Collection of Maps, instead of equivalent javax.naming.SearchResult values. Where Map is used, they must be compatible with the signature Map<String, Object>.

  Note: BaseConnector.CONN_NAME ("!nameId!") and LdapUtil.LDAP_OBJECT_CLASS (objectclass) are mandatory map entries with special significance to the framework.

• POST bindings on SEARCH operations need the following special handling:
  • Directly-executed synchronous SEARCH opbindings with Timing=POST can step through search results queued by the SEARCH operation itself by using the NamingEnumeration bound to the searchResults scripting variable.
  • Process search results by iterating through them one-by-one (recall that doSearch() returns a NamingEnumeration). This means that the streaming of search results is not supported when a SEARCH opbinding with Timing=POST timing is registered. It also means that ScriptStyleOpProxyHandler has to collate all results against each opbindings guard, so that each script is only invoked once for all objects matching it (rather than a script being executed for each individual search result).
  • Each NamingEnumeration can contain objects with any number of objectclasses depending on the LDAP filter passed in. This is one of the prime motivators that opbinding guard's allow multiple objectclasses to be specified.