Selecting the Appropriate Capture Point
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 you will be selecting from. Therefore, it is useful to know the capabilities and limitations of the various capture points.
When possible, you should use the JMS Integrated 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 more reliable than other types of communication. 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 Integrated 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.
Legacy capture points are no longer supported.
The only other bi-directional capture point is the Database Capture Point, which 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.
The Web Service Integrated 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 Integrated 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 Integrated 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 Genesys side, can be propagated to the source system.
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 Integrated Capture Point.
Proper Use of Extended Attributes
Where possible, use iWD extended task attributes to map the source system's data fields that you intend to use in business rules. This is preferable to the use of custom attributes, because the extended attributes are out-of-the-box. That is, no additional configuration is required to use them. Columns are already included in the Interaction Server databases for these attributes and their associated Interaction Custom Properties are defined in Configuration Server. In addition, they are better supported in iWD Data Mart because some of these extended attributes are already dimensions in the iWD Data Mart database and can be queried out-of-the-box.
Optimizing the Use of Custom Attributes
Do not capture unnecessary custom attributes from the source system. This increases the size of the attached data and the Interaction Server and Event Log databases. Include a custom attribute only within the CreateTask message, if you plan to use the attribute in one or more of the following ways:
- In business rules
- In a routing strategy
- To display to a user through the Global Task List
- To display to a user through an agent desktop, such as Genesys Interaction Workspace
- To use for reporting
- To display data to an employee on the desktop, consider the desktop on which the employee will access work on the task. If the employee is working directly on the source system desktop to fulfill the task, then it might not be necessary to capture attributes, if only to provide this data to the employee.