Writing a work set processor

To perform your actual work, you create a class called a work set processor, which implements the WorkSetProcessor interface or its subinterface TransactionalWorkSetProcessor. Both interfaces are in the gw.api.integration.inbound.work package.

The basic WorkSetProcessor interface defines two methods.

getInbound

Gets an object that acquires and divides resources to create work items. This method returns an object of type Inbound, which is an interface that defines a single method called findWork. Define your own class that implements the Inbound interface. The findWork method must get the work data set, which represents multiple work items. If your plugin supports unordered multi-threaded work, each work item represents work that can be done by its own thread. For example, for the inbound file integration, a work data set is a list of newly added files. Each file is a separate work item. The findWork method returns the data set encapsulated in a WorkDataSet object. The polling process of the inbound integration framework calls the findWork method to do the main work of getting new data to process. From Gosu, this method appears as a getter for the Inbound property rather than as a method.

process

Processes one work data item within a work data set. The method takes two arguments of type WorkContext and WorkData. The WorkData argument is one work item in the work data set. You can optionally choose to use the WorkContext argument to declare a resource or other context necessary to process the data item. Your implementation of WorkDataSet populates this context information if you need it. For example, if your inbound integration is listening to a message queue, you might store the connection or queue information in the WorkContext object. Your WorkSetProcessor can then access this connection information in the process method when processing one message on the queue.

If your agent is transactional, your implementation of the Factory.createWorkUnit method must return an instance of TransactionalWorkSetProcessor instead of WorkSetProcessor. The TransactionalWorkSetProcessor interface extends WorkSetProcessor.

The TransactionalWorkSetProcessor interface defines several additional methods.

begin

Begin any necessary transactional context. You are responsible for management of any transactions.

commit

Commit any changes. You are responsible for management of any transactions.

rollback

Rollback any changes. You are responsible for management of any transactions.

All three methods take a single argument of type TxContext. The TxContext interface extends WorkContext. Use the TxContext object to represent work context information that also contains transaction-specific information. Create your own implementation of this class in your getContext method of your WorkDataSet.