Tuesday, December 9, 2014

(#17) Well That was Unexpected - CEP Legitimized?


I'm at a Nerd Conference in Vegas. There's about 2000 nerds out here.  Mostly IT nerds. IT nerds from big companies. IT nerds from big companies talking about problems they have, that I used to have, that I no longer have.

And that makes me smile.

Much to my surprise, Event Processing made the bill.  Not as high on the charts as, oh say, Microservices and APIs. But there were three or so sessions dedicated to event processing in business.  The TLA CEP (Complex Event Processing) was scattered on a few slides too.

And that reminded me I hadn't come back to close off the situation presented in post #16.     In that post, I said that I had not been getting the results I had expected, nor wanted from Esper's CEP Engine.  When I posted my question to the Esper discussion groups, there were several responses saying I should abandon my EPL query and switch over to Match Recognize.


The Match Game

I don't know the history of this syntax. You'll find references to "match recognize SQL" in the documentation for Oracle 12c DBMS.  Whether Esper borrowed it or if it's a extension that Oracle came up with or if it's an emerging standard -- I don't know.  What I do know is that it worked.




Here's the new query using the Esper's Match Recognize syntax:

   anEPLQuery = "SELECT * FROM HHBAlarmEvent " +
            " MATCH_RECOGNIZE (" +
            " MEASURES A as a, B as b, C as c" +
            " PATTERN (A B C) " +
            " DEFINE " +
            "  A as A.macAddress = '000000B357' and A.deviceStatus = 'OPEN', "  +
            "  B as B.macAddress = '0000012467' and B.deviceStatus = 'OPEN', "  +
            "  C as C.macAddress = '000007AAAF' and C.deviceStatus = 'MOTION'"  +
                        ")";
   EPStatement arrivalStatement_EPL4 = cepAdm.createEPL( anEPLQuery );

      


Stare at it a bit, and you can kind of tease it out.  The Pattern we're going to recognize is (A B C).  The pattern syntax is regex based.  I'm looking for Event A, then Event B, then Event C. The Measures A as a, B as b means that my listener method can pull out the events using "a", "b" and "c".  Like this:

        HHBAlarmEvent  eventOne = (HHBAlarmEvent) newData[ 0 ].get( "a" );
        HHBAlarmEvent  eventTwo = (HHBAlarmEvent) newData[ 0 ].get( "b" );
        HHBAlarmEvent  eventThree = (HHBAlarmEvent) newData[ 0 ].get( "c" );
 

 And the DEFINE part tells the Engine how to recognize a match.  It defines the condition that triggers a match.  In my case, Event A is when the Garage Door Sensor (MAC Address '0B357') goes to device status OPEN.  Then Event B is when the Door to the Garage (MAC Address '12467' also goes to status OPEN.  And finally, when those two are followed by Event C, the Motion Detector (MAC Address '7AAAF) detects MOTION.

I'll post the results of this change from Esper EPL (A -> B -> C) to Match Recognize later, but it worked!

I started getting the results I thought I should get.

The syntax for Match Recognize looks a bit harder to master, but it's going to be worth mastering.

 

No comments :

Post a Comment