WSO2 Complex Event Processor is succeeded by WSO2 Stream Processor. To view the latest documentation for WSO2 SP, see WSO2 Stream Processor Documentation.
||
Skip to end of metadata
Go to start of metadata

Introduction

This sample demonstrates how to set up an execution plan with a pattern matching siddhi query to detect non-occurrences. In this sample we use patterns to detect non-delivered packages of a courier service within a predefined time period (for demonstration purposes we assume the time limit to deliver a package is 2 minutes here).

The queries used in this sample is as follows. 

from arrivals_stream#window.time(2 minutes)
select *
insert expired events into overdue_deliveries_stream;


from every arrivalEvent = arrivals_stream ->
deliveryEvent = deliveries_stream[arrivalEvent.trackingId == trackingId] 
    or overdue_delivery = overdue_deliveries_stream[arrivalEvent.trackingId == trackingId]
select arrivalEvent.trackingId as trackingId, arrivalEvent.customerName as customerName, arrivalEvent.telephoneNo as telephoneNo, deliveryEvent.trackingId as deliveryId 
insert into filter_stream;


from filter_stream [ (deliveryId is null)]  
select trackingId, customerName, telephoneNo
insert into alert_stream;  

 

The first query keeps each arrival event for 2 minutes and then emits it to overdue_deliveries_stream which is then used in the second query.

The second query uses a pattern. It looks for a pattern where, there an arrival event (through the arrivals_stream) which is followed by a delivery event (through deliveries_stream) or else an overdue delivery event (this is an arrival event which is 2 minutes old, coming through the overdue_deliveries_stream)

Now, if the pattern detects an arrival event followed by an overdue delivery event with no delivery event, that means the package is not delivered within the 2 minute time limit. 

To detect whether the delivery event is null, we use the third query (deliveryId is null) where the deliveryId will be null if the delivery event is null.

Prerequisites

  • See Prerequisites in CEP Samples Setup page for generic prerequisites. (copy apache-axiom.jar to <CEP_HOME>/samples/cep/lib directory to send XML event types)

Building the sample

Start the WSO2 CEP server with the sample configuration numbered 0111. For instructions, see Starting sample CEP configurations. This sample configuration does the following:

  • Points the default Axis2 repo to <CEP_HOME>/samples/cep/artifacts/0111 (by default, the Axis2 repo is <CEP_HOME>/repository/deployment/server).

Executing the sample

  1. Open a new terminal, go to <CEP_HOME>/samples/cep/consumers/generic-log-service and run the command below. It builds the sample log service web app and deploys in the webapps repository that is relevant to the sample.

    ant -Dsn=0111
  2. See the logs in CEP server when logger service is deploying. For example,

    After deployment, the Web app is able to receive messages sent from the CEP server. 

  3. Navigate to to <CEP_HOME>/samples/cep/producers/http and execute the following command.

    ant -Durl=http://localhost:9763/endpoints/packageArrivalsHTTPReceiver -DfilePath=../../artifacts/0111/arrivalEvents.txt


    This reads the arrivalEvents.txt file which contains a few sample arrival events and then sends it to the url given.

  4. Then execute the following command:

    ant -Durl=http://localhost:9763/endpoints/packageDeliveryHTTPReceiver -DfilePath=../../artifacts/0111/deliveryEvents.txt

    This reads the deliveryEvents.txt file which contains some sample delivery events and then sends it tot the url given.

  5. After 2 minutes, we can see the outputs on the console as follows.

  • No labels