Selecting an Appropriate Capture Point

Selecting the appropriate capture point to use for each source system requires an understanding of the capabilities of the source system. For example, some source systems such as business process management (BPM) systems or systems that use enterprise message middleware such as WebSphere MQ Server or TIBCO Enterprise Message Service, will support the Java Message Service (JMS). Other source systems that include a workflow component will have the ability to integrate with SOAP-based Web services. Older systems that lack these integration capabilities may be able to generate text files. These text files may already be in an XML format but if not, scripting can be used to transform the message from the source system’s native text format to an XML format that can be read by iWD. Finally, systems that do not support JMS or Web services, and which cannot produce flat files, will still have operational databases. iWD can directly query the database of such systems in order to create tasks, update tasks, etc.

The capture point you select will depend on the capabilities of the source system from which you are capturing tasks. In some cases, there will be multiple options to select from. Therefore, it is useful to know the capabilities and limitations of the various capture points.

JMS Capture Point

When possible, you should use the JMS Capture Point if the JMS (Java Message Service) enterprise messaging service is supported by your source system. This capture point is bi-directional, supporting an input queue and an output queue. Since it uses an enterprise messaging system, it is the most reliable way to set up communication between the source system and iWD. For example, if iWD has a notification to provide to the source system, that notification will be placed in a JMS message queue by the JMS Capture Point. If there is a loss of communication between the JMS Provider and the source system, the notification message will remain in queue until communication is restored.

Database Capture Point

The Database Capture Point is also bi-directional and is very flexible. However, to leverage the bi-directionality, it is necessary to update tables on the source system database. In some environments, this will not be possible.

Web Service Capture Point

The Web Service Capture Point is an excellent choice for integration with any source system that has the capability of invoking SOAP/HTTP messages from within its workflow. The message set of the Web Service Capture Point is very straightforward and is easy to integrate. The SOAP payload, in XML format, is easy to understand and is logically organized.

While the Web Service Capture Point is not bi-directional, you can use the Web Service Capture Point from the source system to request the latest status for a particular task, including the current values of all the task attributes. This could be done from the source system just before taking certain actions on the source system, to ensure that the latest updates that might have occurred on the iWD side, can be propagated to the source system.

XML File Capture Point

The XML File Capture Point is a good option when it is being integrated with legacy host systems that do not have support for web services or modern messaging systems. In most cases, these systems can generate flat files that consist of lists of attributes for each work item in its database. These flat files could be converted to an XML format and then read by the iWD XML File Capture Point. The XML File Capture Point is bi-directional in that notifications from iWD are put into directories on the local or network file system that can then be picked up and read by the source system.

Bear in mind that the XML File Capture Point involves more I/O with the file system, which may carry a performance overhead.

Message Transformation – Yes or No?

The integrated capture point functionality in Interaction Server supports optional message transformation for the File and JMS capture points. Internally, these capture points work with messages in XML format. XML message transformation can be applied to each incoming and outgoing message, allowing integration with custom interaction definitions and XML formats.

Using XML message transformation with the JMS or XML file capture point decreases the overall throughput of the capture point, so that should be considered. In low-to-mid-volume deployments it may not matter, but for very high-volume deployments Genesys recommends not using XML message transformation. From a practical standpoint this means using the Interaction Server native message format. If the source system cannot create an Interaction Server-compatible XML message, the only way to avoid using capture point message transformation is to transform the message on the source system prior to submitting it to iWD.