Programming Guides › Connector Programming Guide › The Object Model › Metadata › Operation Bindings

Operation Bindings

Operation Bindings metadata is stored as the value of the eTOpBindingsMetaData attribute on the eTNamespace object for an endpoint type. The metadata can be used to register custom logic to wrap around the processing of LDAP operations. For example, in JDBC stored procedure support. As such, it is less frequently used than datamodel metadata. OpBindings documents adhere to the schema cs-home/conf/xsd/opbindings.xsd.

Each XML fragment can consist of multiple OpBindingType elements specifying:

• A guard element. The guard for an opbinding must match a particular operation on a particular object class for the CA IAM CS framework to execute its payload. The guard therefore has elements specifying:
  • Which Operation matching an LDAP request (ADD / MODIFY etc) the binding targets.
  • Which target objectClass(es) (account / group) the binding targets

    Note: If no objectClass elements are specified, signifies the guard is intended to match all object classes defined in the datamodel metadata.

  • An LDAP Boolean, which when true, denotes that the object class or classes are specified in LDAP terminology (for example, eT…Account, eT…Group) instead of in connector terminology (for example, account or group).
• A payload, which can be either:
  • A native method called on the target system (used for JDBC stored procedure support) using specified parameter definitions.
  • A complete script (or script function in a global script) to be called. Script and script functions derive from a ScriptType base type which contains:
    • A scriptLanguage string field specifying the language the script is written in (currently only javascript is supported).
    • An executedDirectly Boolean field which specifies whether the script does its work directly, or instead generates a string that the connector's script-style processor executes.
• A timing which can be:
  • PRE—Execute the opbinding before the target Operation. For example, it can be used for an ADD request to retrieve an additional attribute value from an external source of data and add it to the attribute values to be stored persistently.
  • OP—Execute the opbinding instead of the target Operation on the connector.
  • POST—Execute the opbindings after the target Operation on the connector, for example, to write an audit record.
• A strictCompletion Boolean. If true, specifies that a failure encountered while executing the payload (either an exception, or a non-null textual error status return) causes the framework to treat the whole LDAP operation as failed. Where the endpoint system supports transactional behavior (such as DYN JDBC) a failure when strictCompletion is true is treated as a reason to roll back the transaction.
  • An order integer

    If there is more then one guard condition matching a particular LDAP request and their order of execution is important, the order integer specifies the order in which opbindings are executed.

Examples of opbindings metadata configuration can be found at cs-sdk-home/connectors/sdkscript/conf/sdkscript_opbindings.xml.

Note: For more information about coding of script payloads, see Writing Scripts.

Note: In this case, an entire connector is implemented using JavaScript but it is also possible to provide opbindings for only a few guard conditions, to customize some behavior of an existing connector. We recommend this method of implementation for what were previously known a connector program exits in CA IdentityMinder 8.1 SP2. For example, the AS400 and OS400 connector which is part of CA IdentityMinder r12, includes a sample opbinding.