|
|
| (13 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | == What is Listener==
| + | {{note|This has been removed in SMILA 0.9 by the [[SMILA/Documentation/JobManager|JobManager framework]]}} |
| − | | + | |
| − | The main goal of Listener is to get Record from JMS queue and process by BPEL workflow but it also make any [[SMILA/Documentation/QueueWorker|Queue Worker]] specific tasks like resending Record into new JMS Queue.
| + | |
| − | | + | |
| − | == Interface ==
| + | |
| − | there is no public interface
| + | |
| − | | + | |
| − | == Configuration ==
| + | |
| − | Schema: "org.eclipse.eilf.connectivity.queue.worker/schemas/QueueWorkerConfig.xsd"
| + | |
| − | Location: "configuration/org.eclipse.eilf.connectivity.queue.worker/ListenerConfig.xml"
| + | |
| − | | + | |
| − | Configuration is a list of listening rules.
| + | |
| − | There are only three difference with [[SMILA/Documentation/QueueWorker/Router|Router]] rules:
| + | |
| − | * <Source BrokerId="broker1" Queue="EILF.connectivity"/> - source queue reference (BrokerID should be specified in [[SMILA/Documentation/QueueWorker/BrokerConnectionService|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 [[SMILA/Documentation/QueueWorker/Router|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 ( [[http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/Message.html | spec]] ) and it's absolutely the same syntax that used in [[SMILA/Documentation/QueueWorker/Router|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==
| + | |
| − | <source lang="xml">
| + | |
| − | <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>
| + | |
| − | </source>
| + | |
| − | | + | |
| − | == More complex Configuration Sample==
| + | |
| − | <source lang="xml">
| + | |
| − | <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>
| + | |
| − | </source>
| + | |
| − | | + | |
| − | "Default ADD Rule" applied if Operation equals to "ADD" and DataSourceID does not starts with "web".
| + | |
| − | | + | |
| − | The most interesting situation occurs if Record's DataSourceID starts with "web". It's 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 processed 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 other second queue broker with id "broker2".
| + | |
| − | | + | |
| − | But there is 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".
| + | |
| − | | + | |
| − | As it was already mentioned above, look at the [[SMILA/Documentation/QueueWorker/Router|Router]] documentation for details.
| + | |
| − | [[Category:SMILA]]
| + | |
