SMILA/Documentation/QueueWorker/Listener

What is Listener

The main goal of Listener is to get Record from JMS queue and process by BPEL workflow but it also make any Queue Worker specific tasks like resending Record into new JMS Queue.

Interface

there is no public interface. Its only possible to manually change workers quantity for every Rule by JMX management API/console. It may be useful for workload balancing.

Configuration

Schema: "org.eclipse.smila.connectivity.queue.worker/schemas/QueueWorkerConfig.xsd" Location: "configuration/org.eclipse.smila.connectivity.queue.worker/ListenerConfig.xml"

Configuration is a list of listening rules. There are only three difference with Router rules:

• <Source BrokerId="broker1" Queue="SMILA.connectivity"/> - source queue reference (BrokerID should be specified in Broker Connection Service configuration).
• WaitMessageTimeout - timeout for attempts to pull JMS message from queue
• Workers - startup number of threads to listen queue under this rule.

Look at the Router documentation for complete list of tags/operations common for Listener and Router

Condition

Each listener Rule is a set of Queue consumers (workers) grouped by value of Condition tag. Condition is a String whose syntax is based on a subset of the SQL92 conditional expression syntax pointed in JMS specification ( [| spec] ) and it's absolutely the same syntax that used in Router Condition tag.

There are two JMS properties supported during all queue related processes in router/listener

• Operation
• DataSourceID

Other properties may also be added/used in conditions, look at the second configuration sample below.

Configuration Sample

<ListenerConfig xmlns="http://www.eclipse.org/eilf/queue"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="schemas/QueueWorkerConfig.xsd"
>
 
 
  <Rule Name="Default ADD Rule" WaitMessageTimeout="10" Workers="2">
    <Source BrokerId="broker1" Queue="EILF.connectivity"/>
    <Condition>Operation='ADD'</Condition>
    <Task>
      <Synchronize Filter="no-filter"/>
      <Process Workflow="AddPipeline"/>
    </Task>
  </Rule>
 
  <Rule Name="Default Delete Rule" WaitMessageTimeout="10" Workers="2">
    <Source BrokerId="broker1" Queue="EILF.connectivity"/>
    <Condition>Operation='DELETE'</Condition>
    <Task>
      <Synchronize Filter="nothing"/>
      <Process Workflow="DeletePipeline"/>
    </Task>
  </Rule>
 
</ListenerConfig>

More complex Configuration Sample

<ListenerConfig xmlns="http://www.eclipse.org/eilf/queue"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="schemas/QueueWorkerConfig.xsd"
>
  <Rule Name="Default ADD Rule"  WaitMessageTimeout="10" Workers="2">
    <Source BrokerId="broker1" Queue="EILF.connectivity"/>
    <Condition>Operation='ADD' and NOT(DataSourceID LIKE 'web%')</Condition>
    <Task>
      <Synchronize Filter="no-filter"/>
      <Process Workflow="AddPipeline"/>
    </Task>
  </Rule>
 
  <Rule Name="WEB ADD Rule - STEP 1" WaitMessageTimeout="10" Workers="1">
    <Source BrokerId="broker1" Queue="EILF.connectivity"/>
    <Condition>Operation='ADD' and DataSourceID LIKE 'web%' AND step_one_is_passed IS NULL</Condition>
    <Task>
      <Synchronize Filter="no-filter"/>
      <Process Workflow="WebPipeline_STEP1"/>
    </Task>
    <Send BrokerId="broker2" Queue="EILF.connectivity">
        <SetProperty Name="step_one_is_passed">YES</SetProperty>
    </Send>
  </Rule>
 
 <Rule Name="WEB ADD Rule - STEP 2" WaitMessageTimeout="10" Workers="1">
    <Source BrokerId="broker2" Queue="EILF.connectivity"/>
    <Condition>Operation='ADD' and DataSourceID LIKE 'web%' AND step_one_is_passed='YES'</Condition>
    <Task>
      <Synchronize Filter="no-filter"/>
      <Process Workflow="WebPipeline_STEP2"/>
    </Task>
  </Rule>
 
</ListenerConfig>

"Default ADD Rule" applied if Operation equals to "ADD" and DataSourceID does not start with "web".

The most interesting situation occurs if Record's DataSourceID starts with "web". It will be processed by the Rule (consumer) named "WEB ADD Rule - STEP 1". During processing, Record will be synchronized and processed with some hypothetical pipeline "WebPipeline_STEP1". After that Record will be serialized to JMS message with added, by default, JMS properties "Operation" and "DataSourceID" and with additional configured JMS property "step_one_is_passed" with value "YES". JMS Message will be send to the second queue broker with id "broker2".

The third Rule "WEB ADD Rule - STEP 2" that works with "broker2" and JMS message from last step exactly satisfies to its "Condition" value. So, message will be caught, synchronized with Blackboard and processed with BPEL pipeline "WebPipeline_STEP2".

This configuration is only a hypothetical sample that illustrates two-step processing listener configuration. Processing split on steps may be useful you need to process Record with few pipelines that may be unstable or too much resource-consuming.

As it was already mentioned above, look at the Router documentation for details.