Web service to start and stop workflow

In order to start and stop the WebLogic Integration process responsible for distributing the units of work to request queues, a Java Web Service (JWS), which is specified in accordance to JSR 181, is created with two methods of interest:

Instead of calling the workflow directly, the Web service places a message on a JMS queue, called
Worker.Message, to send messages to the distribution JPD. This allows the implementation of the Web service to be decoupled from the workflow to preserve its modularity. In WebLogic Integration, there is a concept called an event generator that is configured with the WebLogic Integration Administration Console. One event generator is configured to take the message off the JMS
Worker.Message queue and deliver it to a logical concept known as a Message Broker channel. The distribution workflow listens on the
/UnitOfWork/StartWorkflow channel, which is tied to the JMS event generator associated with the JMS
Worker.Message queue. As soon as a String "start" message is delivered on this channel, the workflow begins. Similarly, once started, the distribution workflow listens on a Message Broker channel known as
/UnitOfWork/StopWorkflow in one of its Event Choice nodes to receive a "stop" message from a
Worker.StopMessage JMS queue. Again, an event generator associates the JMS message on the
Worker.StopMessage queue to the channel
/UnitOfWork/StopWorkflow to deliver the message.

This effectively creates a service-oriented approach decoupled from the implementation to start and stop the distribution workflow. The Web service can easily be tested via a Web service client, or using the supplied WebLogic Integration Workshop Test Browser.

The Distribution Workflow

Figure 2 illustrates the relevant portions of the
DistributeFlow.jpd responsible for the distribution of the units of work, our simple matrix objects, to the request queue:

Figure 2. Workflow for distributing units of work (click the image for a full-size screen shot)

A while loop continuously loops until a stop message changes the value of a boolean variable to break out of the loop and complete the workflow. The Event Choice waits on one of two Control Receive callbacks. The first one is to receive a Stop message from a Message Broker channel via the Web service just described. The second callback responds to a Timer control that has been set via its property panel to occur every five seconds. This continues the processing, and the next activity calls the custom Java control to browse the
Worker.Request queue to get the number of pending requests. Next, the decision node checks to see if the number of requests exceeds a maximum number of requests, which has been set to 5 in a variable. If it doesn't, a perform node is called to use a JMS control to place five matrix objects on the request queue as follows.