IoT prototype – low level thoughts on Oracle CEP Embedded (part 3)

In our prototype we used an Oracle CEP Embedded application running on a separate Raspberry Pi to scan the network for arriving / leaving devices and link them to our users. We could have left this logic in our Spring server and have it running in our service layer but we wanted to learn more about Oracle CEP and this seemed a good way to start. What needed to be done:

  • Notice new devices on the network
  • link networks to users already created in the system (on the spring server / in its DB)
  • send the server a notification about an arrived user or one that left the premises
  • allow for short states of users missing (e.g. a phone rebooting or short connection loss)
  • send all found network nodes to the server on a regular base so we can link users to existing network devices in our frontend application

Okay so once we had these necessities settled we started checking out a few tutorials about CEP. There’s an Eclipse plugin that one uses to build the CEP application and its all about event flows. There are three central files (plus your code that is) that one needs to look at:

Oracle CEP imporant files

The context.xml file is all about defining all sorts of beans and is where the framework generates the Event Processing Network graphic from. This is how the two look like (code & generated design)

context.xml

EPN

 

What we then do is this:

  1. We scan the network every 15 seconds for all network nodes (phones, tablets, pc, laptop,…) and stream them along. Each of the nodes is considered an event
  2. The networkNodeOutputAdapter sends those nodes to the server every few minutes as a bulk list, containing when it was last seen etc.
  3. The UserNodeBean gets a HashMap from our Spring server that links users to devices (which one has to configure of course. Basically it is „this iPhone XY is mine“)
  4. The UserDeviceProcessingBean then filters all events to only pass along those nodes that actually belong to a user
  5. the stateCalculatingBean then compares those found nodes with the users and sees if any user has a changed state. If a node was found that hasn’t been seen in a while the state changes from offline to online. of course this also applies the other way around but with a certain delay (2-5 minutes depending on the preferences)

States

 

Java vs. CQL

CQL (Continuous Query Language) is something that Oracle uses to filter events. While this is surely a great tool for people that are used to sql, it wasn’t anything for me, so I stuck to my java beans, which do the same job just fine. But I bet for database specialists this is a welcome tool.

Notable things about OCEP:

Though I am usually a big fan of open source projects and prefer them over proprietary products, I was rather fond of this one. The installation was very easy and even though I’m usually a big fan of IntelliJ, if I must use something else I prefer Eclipse over jDeveloper, so this was a welcome change. Also the trial and error round cycles are really short, since one doesn’t need to redeploy a whole lot, it only takes a few seconds to republish changes on the code to the CEP server. Also once it works in the VM (there is a VM created by Oracle that I used which had everything already set up for SOA development) one can almost directly pull the .jar onto the Pi, start the server there and see it take off. No difficult configuration necessary. Having an ssh connection to both Pi’s lets me still work on one Computer and not have to switch between things.

Also I found this really easy to learn, since it doesn’t have as many components as e.g. BPM frameworks of these days. I was able to model my process with the EPN tool but could still keep all my actual logic and magic within my java code.

If you’d like to check the sourcecode, look on Github for my project.

To keep on reading check the other posts about our prototype:

Dieser Beitrag wurde unter IoT & Industry 4.0, Uncategorized abgelegt und mit , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Eine Antwort zu IoT prototype – low level thoughts on Oracle CEP Embedded (part 3)

  1. Pingback: IoT prototype – low-level thoughts about camunda BPM and Drools Expert (part 6) | The Cattle Crew

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s