The rule definition processes two types of events. It consists of filter rules and complex event processing rules.
These filter rules are for two types of events.
1 | on LocationEvent { |
Below is an explanation of each line.
Line 1
This is a filter rule for a location information event (LocationEvent).
Line 2
This search expression extracts only the events where a registered store can be found in the area (one with an "areaID" equal to the "areaID" in the "storeInfo" store master) while walking ("status" is "1"). The left side of "$areaID == $areaID" is the "areaID" of the input events, and the right side is the "areaID" of the master data.
Line 3
To assign member master information to the input events, this uses the data of the member master "MemberInfo" to join the events that have equal member IDs.
Line 4
This outputs the member ID and area ID that are in the input events, as well as the age information of the member master, as a "FilteredLocationEvent".
Line 7
This is a filter rule for a coupon event (CouponEvent).
Line 8
This uses the store master "StoreInfo" data to join the events that have equal store IDs.
Line 9
This outputs the store ID, coupon ID, and target age that are in the input events, as well as the area ID of the store master, as a "FilteredCouponEvent".
These complex event processing rules are for the two types of events processed by the filter rules.
1 | create schema outEvent (memberID string, storeID string, couponID string); |
Below is an explanation of each line.
Line 1
This defines the format of the events being output (used in the next named window definition).
Line 3
This is a complex event processing statement that creates a named window to retain the output events for a set time period and to ensure that the same coupon is not sent to the same person twice within that period. This retains the first output events for member ID and coupon ID pairs, one at a time. After the set period (3 minutes in the sample) has elapsed, they are deleted from the window.
Line 5
This defines the complex event processing statement to perform the main process. Its name is "EPL1".
Line 6
This inserts the output of the main process in the named window.
Line 7
This outputs the member IDs of location information events and the store IDs and coupon IDs of coupon events, as the results of the main process.
Line 8
This is for the "FilteredLocationEvent", which is one source of input for the main process. When "unidirectional" is specified, the reception of this event will be the trigger for operating this process ("FilteredCouponEvent" will not be the trigger).
Line 9
This is for the "FilteredCouponEvent", which is the other source of input for the main process. This event is retained in memory for a set period only (3 minutes in the sample) and is joined to "FilteredLocationEvent".
Line 10
The join condition for "FilteredLocationEvent" and "FilteredCouponEvent" is that the "areaIDs" are equal and that "age" and "targetAge" are equal.
Line 12
This is a complex event processing statement for outputting the processing results of "EPL1" (line 5 onwards). Its name is "EPL2".
Line 13
By assigning a debug log listener, this outputs the output events to the engine log.
Line 14
This outputs only the new events registered in the named window. Even if there are more than one of the same event entered in the named window, specifying "std:firstunique" (in "create window") will ensure that only the first event will actually be stored.
Lines 16 to 18
This is a complex event processing statement for performing debug log output of a filtered location information event (FilteredLocationEvent). This is for checking the filtering process and can safely be deleted.
Lines 20 to 22
This is a complex event processing statement for performing debug log output of a filtered coupon event (FilteredCouponEvent). This is for checking the filtering process and can safely be deleted.