Inbound integration core plugin interfaces

PolicyCenter provides the multi-threaded inbound integration system in plugin interfaces for two use cases. Each interface defines a contract between PolicyCenter and inbound integration high-performance multi-threaded processing of input data. The interfaces are in the gw.plugin.integration.inbound package.

InboundIntegrationMessageReply

Inbound high-performance multi-threaded processing of replies to messages that a gw.plugin.messaging.MessageTransport implementation sends. This interface is a subinterface of gw.plugin.messaging.MessageReply.

If your code throws an exception, the transaction of the message processing is rolled back. The original message is restored to the queue.

InboundIntegrationStartablePlugin

Inbound high-performance multi-threaded processing of input data as a startable plugin. Use a startable plugin for all contexts other than handling replies to messages that a MessageTransport implementation sends. This interface is a subinterface of gw.api.startable.IStartablePlugin.

If your code throws an exception, PolicyCenter uses the value of the stoponerror parameter in the configuration file to determine what action to take. If that value is true, PolicyCenter performs error handling that is applicable to the integration type. If the value of stoponerror is not true, PolicyCenter skips the item that caused the exception. Ensure that your code logs any errors or notifies an administrator.

For some use cases, you do not need to write your own implementation of these main plugin interfaces. PolicyCenter includes plugin implementations that support common use cases and that are supported for production servers. Both file and JMS plugin implementations are provided in variants for message reply and startable plugin use.

PolicyCenter supports the following types of inbound integrations:

File inbound integrations

Use this integration to read text data from local files. Poll a directory in the local file system for new files at a specified interval. Send new files to integration code and process incoming files line by line, or file by file. You provide your own code that processes one chunk of work, either one line, or one file, depending on how you configure it. Your code is called a handler plugin.

JMS inbound integration

Use this integration to get objects from a JMS message queue. You provide your own code that processes the next message on the JMS message queue. Your code is called a handler plugin.

Custom integration

If you process incoming data other than files or JMS messages, write your own version of the InboundIntegrationMessageReply or InboundIntegrationStartablePlugin plugin interface. In both cases, for custom integrations you must write multiple classes that implement helper interfaces such as WorkAgent.

You can implement your plugin code using any of Gosu, Java with no OSGi, or Java as an OSGi bundle. If you use Java or if you require third-party libraries, Guidewire recommends implementing your code as an OSGi plugin.

In all cases, you must register and configure plugin implementations in the Studio Plugins Registry. See each topic for more information about which implementation classes to register. Additionally, for file and JMS integrations, you write handler classes.

The definition of a plugin implementation for an inbound integration in the Plugins Registry includes a plugin parameter called integrationservice. That integrationservice parameter defines how PolicyCenter finds configuration information in the inbound integration configuration XML file.