EventHandlers do not exist in TDI 7.1. Therefore, in order to replace the deleted functionality in old solutions, we need to migrate your EventHandler configurations to Server/Iterator or Changelog Connector configurations.
For each EventHandler a corresponding AssemblyLine must be created. Then a Server/Iterator Connector corresponding to the EventHandler must be inserted into the AssemblyLine "Feeds" section. Then the Connector parameters must be set - this is specific for each EventHandler/Connector pair, but generally the Connector parameters must be set to the same values as the corresponding EventHandler parameters (which usually have the same names).
Any processing configured in the EventHandler must be re-implemented in the AssemblyLine "Flow" section.
The functionality of the "enabled" EventHandler parameter (otherwise known as "Auto-start service") is also available for AssemblyLines. If we want your AssemblyLine to be started right after the TDI Server is started, go to the Solution Logging and Settings section in the Navigator in your workspace in the Config Editor and add your AssemblyLine.
In general an EventHandler executes some piece of logic when a certain event occurs. "Event" has a different meaning for each EventHandler. For the HTTP EventHandler an "event" is an HTTP request. For the IBM Directory Server EventHandler an "event" is a change notification that comes from an IBM LDAP Directory.
Below are some general guidelines on migrating certain parts of a typical EventHandler. They are divided based on the titles of the UI tabs for an EventHandler in the pre-7.0 Config Editor:
The "Prolog" hook of an EventHandler corresponds to the "Prolog - After Init" hook of an AssemblyLine. This hook is invoked for each incoming "event".
The "Epilog" hook of an EventHandler corresponds to the "Epilog - After Close" AssemblyLine hook. This hook is invoked once after each incoming "event" is processed.
In both the "Prolog" and "Epilog" EventHandler hooks the "event" Entry is accessible under the names "conn" and "event". However in the AssemblyLine hooks we should modify your script to use "work" instead of "conn" or "event".
The "Shutdown Request" hook of an EventHandler corresponds the "Shutdown Request" AssemblyLine hook.
The Action Map of an EventHandler defines what actions should be taken when an "event" arrives. You should build the same actions into the logic of the AssemblyLine that you are preparing as a replacement of the EventHandler.
For example if the Action Map prescribed that a custom script should be executed if Attribute "x" of the event equals "3", then you could add an "IF" component to the AssemblyLine that checks for Attribute "x" being equal to 3 and executes a Script Component.
You must do the following to reproduce an old EventHandler's configuration into a new Connector's configuration:
There is no need to migrate existing configurations that use the TDI v6.0 Mailbox Connector, because the TDI v7.1 Mailbox Connector is compatible with the TDI v6.0 Mailbox Connector.
Configurations that use the Mailbox EventHandler, however, need to be migrated by following these steps:
Existing configurations that use the TDI v6.0 JMX EventHandler can be transformed into TDI v7.1 configurations that use the JMX Connector in the following way:
The TDI 7.1 SNMP Server Connector provides all features of the TDI v6.0 SNMP EventHandler except support for single-threaded mode. The TDI 7.1 SNMP Server Connector works in multi-threaded mode only. If we need to migrate an existing TDI v6.0 configuration using the SNMP EventHandler to a TDI v7.0 configuration, which uses an AssemblyLine with the SNMP Server Connector, we need to do the following:
Existing configuration that use the IBM Directory Server EventHandler can be migrated to use the IBM Directory Server Changelog Connector as follows:
As opposed to the EventHandler, the Connector does not let we select a part of the directory tree, for whose notifications it will listen - it subscribes for changes in the whole directory tree (the Connector does not have equivalents of the ldapEventBase and ldapSearchScope EventHandler parameters). If this is critical for you, we can implement some custom filtering in the solution to overcome this limitation of the Connector.
A configuration that uses the HTTP EventHandler can be migrated to use the HTTP Server Connector like this:
A configuration that uses the LDAP Server EventHandler can be migrated to use the LDAP Server Connector as follows:
The LDAP EventHandler catches notifications about changes in a directory tree. The EventHandler does not use a changelog, so it receives only real-time notifications. The Netscape/iPlanet/Sun Directory Changelog Connector offers basically the same functionality when run in real-time delivery mode. There are a few differences though:
The Connector does not have equivalents for the ldapSearchFilter and ldapSearchScope EventHandler parameters. To achieve the same functionality as in the EventHandler, we should implement some custom filtering that limits the set of received notifications.
The schema of the returned data differs between the Connector and the EventHandler. The Connector applies delta tagging to each Entry it returns, while the EventHandler provides the type of the change in the "ldap.operation" property. For details on the schema consult the documentation of each component.
Once the considerations above are resolved, we can migrate an existing configuration with the LDAP EventHandler to use the Netscape/iPlanet/Sun Directory Changelog Connector like this:
The migration from the AD Changelog EventHandler to the Active Directory Change Detection Connector is straight forward in the most aspects since the EventHandler itself has incorporated the older version this connector - Active Directory Changelog Connector in order to obtain changes from the AD.
Similar to the EventHandler the corresponding Connector can also be interrupted any time during the synchronization process, in that case it will store its state in the User Property Store. Both the EventHandler and the Connector rely on the uSNChanged mechanism in this process, by storing the USN number in the property store. They also offer sn API for retrieving the current USN synchronization values. The difference is that the EventHandler getUSNvalues method returns an Entry with Attributes:
START_USN END_USN CURRENT_USN_CREATED CURRENT_USN_CHANGEDT
whereas the Connector returns the current
synchronization value as long.
Another difference is that the AD EventHandler initializes internally
an LDAP Connector in order to block and receive change notifications.
This behavior can also be simulated in the ADCD Connector by enabling
the useNotifications parameter.
The following steps should be performed in order to migrate from
an EventHandler-based solution to Connector-based one:
The migration from the z/OS LDAP Changelog EventHandler to the
z/OS LDAP Changelog Connector is facilitated by the fact that this
changelog connector is explicitly developed to replace the EventHandler.
Both the EventHandler and the Connector rely on a poll mechanism for
extracting the changelog information since they do not support the
Unsolicited Event Notification.
The main difference consists in storing the state key. The EventHandler
uses a plain file passed as parameter - ldapChangeNumberFileName in
its configuration to keep track of the last used changenumber, whereas
the Connector takes advantage of the "Iterator State Key" mechanism
in TDI. Therefore, in order to migrate a solution from the from the
z/OS LDAP Changelog EventHandler to the z/OS LDAP Changelog Connector, the value of the changenumber in the ldapChangeNumberFileName-specified
file must be passed to the Connector for example with script before
the initial start of the iteration, like this script snippet:
where changenumber is
the name of the Iterator State Key and changeNumber is the
value obtained from the store file used by the EventHandler.
An alternative to this solution is to pass the changeNumber value
to the nsChangenumber parameter in the configuration of the
Connector.
The following steps should be performed in order to migrate from
an EH-based solution to Connector-based one:
The migration from the DSMLv2 EventHandler to the DSML v2 SOAP
Server Connector requires rework of the AssemblyLines that are previously
used with the EventHandler, so that they can be integrated in the
solution with the DSMLv2 SOAP Server Connector. This is because the
core architecture as changed; now a single AssemblyLine processes
all operations. Therefore, all the old AssemblyLines logic responsible
for handling the different types of DSMLv2 operations should be incorporated
into the new AssemblyLine containing the DSMLv2 Soap Server Connector, or should be invoked using a AssemblyLine Connector. For this purpose
branching components can be used in order to separate the logic for
the specific DSMLv2 operations (available in the dsml.operation Attribute).
The migration of a configuration with the DSMLv2 EventHandler to
a similar one with the DSMLv2 SOAP Server Connector consists of the
following steps:
z/OS LDAP Changelog Connector
Com.ibm.di.store.StoreFactory.getDefaultPropertyStore().setProperty("changenumber", new Long(changeNumber));
DSMLv2SOAPServerConnector