Sample 0106 - Using in-memory event tables
Introduction
This sample demonstrates how to set up an execution plan to filter out credit card transactions that make use of an in-memory event table to identify blacklisted transactions. This sample uses the Event Simulator for inputs and the logger publisher for logging the outputs to the DAS console.
The execution plan used in this sample is as follows:
define table CardUserTable (name string, cardNum string, blacklisted bool) ;
Given above is the table definition. It does the following.
- Defines a table named
CardUserTable
with the given attributes. This is by default an in-memory table.
from CardUserStream select * insert into CardUserTable;
The first query,
- Processes the events received through the
CardUserStream
. - Selects all the attributes under the
select
clause, from each event received. - Inserts it to the
CardUserTable
.
from BlackListStream select cardNo as cardNum, true as blacklisted update CardUserTable on cardNum == CardUserTable.cardNum;
The second query,
- Processes the events received through the
BlackList
Stream
. - Selects the
cardNo
and renames it ascardNum
, introduces a new attribute namedblacklisted
with the valuetrue
under theselect
clause, for each event received. - Updates the
CardUserTable
with the conditioncardNum == CardUserTable.cardNum
. Here theblacklisted
attribute in the table is updated with the new value.
from PurchaseStream#window.length(1) as p join CardUserTable as c on p.cardNo == c.cardNum and c.blacklisted == false select p.cardNo as cardNo, c.name as name, p.price as price insert into WhiteListPurchaseStream ;
The third query,
- Defines a length window that keeps 1 event of the input stream
PurchaseStream
. - Joins it with the
CardUserTable
with the conditionp.cardNo == c.cardNum and c.blacklisted == false
. In this condition, the events withblacklisted == true
in the table gets filtered out and then the remaining events are joined based on the card number. - Emits those events as output events through the
WhiteListPurchaseStream
.
from DeleteAllUsers delete CardUserTable on deleteAll == true;
The last query is used to clean up the table from an external trigger event through the DeleteAllUsers
stream.
- It processes the events received through the
DeleteAllUsers
. - Checks for the condition
deleteAll == true
and if it exists, deletes all the records in theCardUserTable
.
Prerequisites
Set up the prerequisites required for all samples.
Building the sample
Start the WSO2 DAS server with the sample configuration numbered 0106. For instructions, see Starting sample CEP configurations.
This sample configuration points the default Axis2 repo to <DAS_HOME>/samples/cep/artifacts/0106
(by default, the Axis2 repo is <DAS_HOME>/repository/deployment/server
).
Executing the sample
Log into the DAS Management Console.
- Go to Tools -> Event Simulator. Under the Multiple Events section, 4 files with sample data are listed as shown below.
The
userEvents.csv
file contains sample data that is used to fill the in-memoryCardUserTable
. Click Play to start sending events to fill the table.- The
blackListUserEvents.csv
file contains sample data that is used to mark user entries in CardUserTable asblacklisted
. Click Play to start sending blacklisted events and mark some table entries as blacklisted. - The
purchaseEvents.csv
file contains credit card transactions data. Click Play to send the transaction data. After sending sample events from the
purchaseEvents.csv
file, you an view the output as shown below.