Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "SMILA/Documentation/QueueWorker/ConfigurationSamples"

Line 69: Line 69:
 
</ListenerConfig>
 
</ListenerConfig>
 
</source>
 
</source>
 +
 +
 +
  
 
=== Settings for direct processing without queue  ===
 
=== Settings for direct processing without queue  ===
Line 111: Line 114:
 
/>
 
/>
 
</source>
 
</source>
 +
 +
  
 
=== Sample of hypothetical 2 step processing for data source "web" ===
 
=== Sample of hypothetical 2 step processing for data source "web" ===

Revision as of 06:37, 25 November 2008

Configuration Samples

Default Settings

Shortly, the default behavior is

  1. Router put record into queue
  2. Listener get record from queue and start AddPipeline or DeletePipeline

ConnectionConfig.xml

<ConnectionsConfig xmlns="http://www.eclipse.org/smila/queue" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="schemas/QueueWorkerConfig.xsd"
>
 
  <ConnectionConfig Id="broker1">
    <URL>tcp://localhost:61616</URL>
    <User>any</User>
    <Password>any</Password>
    <ConnectionFactory>org.apache.activemq.ActiveMQConnectionFactory</ConnectionFactory>
  </ConnectionConfig>
 
</ConnectionsConfig>

RouterConfig.xml

<RouterConfig xmlns="http://www.eclipse.org/smila/queue"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="schemas/QueueWorkerConfig.xsd"
>
  <Rule Name="Default ADD Rule">
    <Condition>Operation='ADD'</Condition>
    <Task> 
      <Send BrokerId="broker1" Queue="SMILA.connectivity" RecordFilter="nothing"/>
    </Task>
  </Rule>
 
  <Rule Name="Default DELETE Rule">
    <Condition>Operation='DELETE'</Condition>
    <Task>
      <Send BrokerId="broker1" Queue="SMILA.connectivity"  RecordFilter="nothing"/>
    </Task>
  </Rule>
 
</RouterConfig>

ListenerConfig.xml

<ListenerConfig xmlns="http://www.eclipse.org/smila/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="SMILA.connectivity"/>
    <Condition>Operation='ADD'</Condition>
    <Task>
      <Process Workflow="AddPipeline"/>
    </Task>
  </Rule>
 
  <Rule Name="Default Delete Rule" WaitMessageTimeout="10" Workers="2">
    <Source BrokerId="broker1" Queue="SMILA.connectivity"/>
    <Condition>Operation='DELETE'</Condition>
    <Task>
      <Process Workflow="DeletePipeline"/>
    </Task>
  </Rule>
 
</ListenerConfig>



Settings for direct processing without queue

Shortly, the behavior is: Router executes AddPipeline or DeletePipeline immediately.


ConnectionConfig.xml

<ConnectionsConfig xmlns="http://www.eclipse.org/smila/queue" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="schemas/QueueWorkerConfig.xsd"
/>

RouterConfig.xml

<RouterConfig xmlns="http://www.eclipse.org/smila/queue"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="schemas/QueueWorkerConfig.xsd"
>
  <Rule Name="Default ADD Rule">
    <Condition>Operation='ADD'</Condition>
    <Task> 
      <Process Workflow="AddPipeline"/>
    </Task>
  </Rule>
 
  <Rule Name="Default DELETE Rule">
    <Condition>Operation='DELETE'</Condition>
    <Task>
      <Process Workflow="DeletePipeline"/>
    </Task>
  </Rule>
 
</RouterConfig>

ListenerConfig.xml

<ListenerConfig xmlns="http://www.eclipse.org/smila/queue"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="schemas/QueueWorkerConfig.xsd"
/>


Sample of hypothetical 2 step processing for data source "web"

This sample is hypothetical. ConnectionConfig and RouterConfig the same like for default configuration described above.

Shortly: records with "web" data source processed with 2 steps. After the first step, record put again into queue.


ListenerConfig.xml

  <Rule Name="Default ADD Rule">
    <Source BrokerId="broker1" Queue="SMILA.connectivity"/>
    <Condition>Operation='ADD' and NOT(DataSourceID LIKE 'web%')</Condition>
    <Task>
      <Process Workflow="AddPipeline"/>
    </Task>
  </Rule>
 
  <Rule Name="WEB ADD Rule - STEP 1">
    <Source BrokerId="broker1" Queue="SMILA.connectivity"/>
    <Condition>Operation='ADD' and DataSourceID LIKE 'web%' AND step_one_is_passed IS NULL</Condition>
    <Task>
      <Process Workflow="WebPipeline_STEP1"/>
      <Send BrokerId="broker2" Queue="SMILA.connectivity" RecordFilter="no-filter">
        <SetProperty Name="step_one_is_passed">YES</SetProperty>
      </Send>
    </Task>
  </Rule>
 
 <Rule Name="WEB ADD Rule - STEP 2">
    <Source BrokerId="broker2" Queue="SMILA.connectivity"/>
    <Condition>Operation='ADD' and DataSourceID LIKE 'web%' AND step_one_is_passed='YES'</Condition>
    <Task>
      <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". Record 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 again 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, deserialized to Record, 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.

Back to the top