Programming Guides › Connector Programming Guide › Connector Review Checklist › Connector Coding Considerations

Connector Coding Considerations

Consider the following when assessing the general coding of the connector's logic:

1. Is the coding and configuration of the connection pool correct?
2. Is the streaming of search results supported? streaming always / threshold between streaming and not / no. If streaming is supported:
   • Is super-streaming of search results supported?

     Note: You do not need all ids / primary keys in memory at once.

   • Is streaming used for all object classes, and if it is not, is the subset for which it is used listed?
   • Is a new connection taken from the pool and released for each search result (or a small number of search results), so that many concurrent searches can be active and share available connections fairly? If not, then detail what the connector does in this regard. Include the reason that the same connection is used for the whole search. For example, this can be necessary to support super-streaming or because the native API mandates it.
3. Has maximum use been made of the CA IAM CS framework services and existing connector implementations, or both?
   • Has any reuse that was possible and any specialization that was required been summarized?
   • Have any extra connector-specific metadata settings that were required been summarized?
   • Have any connector-specific validator or converter plug-ins that were written for the connector been summarized?
4. Have Validator and Converter plug-Ins been used to minimize custom coding?
5. To what degree is the conversion LDAP search filters to native filters supported?
   • Minimal—Only expressions like (objectclass=eTDYNAccount) and (eTDYNAccountName=a*) are supported
   • Partial—A richer set of filter syntax and attributes are supported, presumably by morphing the LDAP filter using a FilterVisitor)
   • Complete—Complete filter syntax is supported.
   • If support is not complete, has the isConnectorFilterable=false metadata setting been used to flag attributes which the connector is unable to respect in filter assertions?
6. Are complete one-level and subtree search semantics supported so that clients other than the Provisioning Manager can use them?
7. Are all attributes that can be returned from an object scope search also supported for one-level and subtree cases?

   Note: This approach is highly recommended.

8. How has exception handling been implemented?
   • Are exceptions not being swallowed, that is, caught and simply ignored?
   • Is ldapExceptionPrefix prepended to the message for all exceptions raised in the connector's code?
   • Are native exceptions being carefully mapped into LdapNamingExceptions with suitable ResultCodeEnum codes, especially:
     • LdapNameAlreadyBoundException for ADD requests
     • LdapNameNotFoundException for other requests
   • Have retriable exceptions been distinguished explicitly in code where required?

     Note: For more information, see RetryOpProcessorProxy.

   • Has resiliency support been properly configured and tested, that is, are retry group messages in connector.xml accurate and complete?
9. Are the remaining TODOs small in number and minor in consequence?
10. Has optimal caching of information during activate() been implemented to improve performance, where applicable?
11. Does the connector depend on any objects with specialized lifecycles? For example, connector sibling objects, objects which clients poll and change asynchronously and such.