Although the Oracle Complex Event Processor version 11.1 is a very powerful  tool, it doesn’t come with a mechanism for testing CQL statements in isolation to the rest of the application.

A while ago a client wanted me to implement an application to leverage the CQL language shipped with the Oracle Complex Event processor version 11.1.1.7 for routing important financial messages around an internal business domain.

This meant that there was a lot of emphasis placed on the routing rules themselves, therefore there was a need to perform  rules testing.  Naturally, common sense dictated that a semi-automated test harness was the best was forward – quick, robotic therefore reliable, robotic therefore deterministic, robotic therefore executable at any time, robotic therefore … you get the picture.

Naturally the rest of the application’s java code was covered by unit and unit integration tests which were easy to write and exercised, well, robotically.

The wrinkle in our robotic CQL testing concept was that it required a fully operational Oracle Complex Event Processor to be running,  in order for the rules to be fired in something that approximates production. As we all know from TDD and other testing approaches, our CQL testing  concept is well beyond the unit test scope where mocking resources is the norm.

The solution? Hack a running CEP, replacing the internal publishers and consumers around each CQL processor within the EPN with dummy producers and consumers.  The  dummy producer then injects a pre-constructed canonical object into the feed channel to the CQL processor in question while multiple consumers are attached to the outbound consumers after the CQL processor.

The stage is then set to inject and  retrieve crafted canonical objects designed probe a particular CQL rule.

Easy, right?

Well, in fact its not as hard as you think.  Dynamically changing the behaviour of an application by INJECTING new code during runtime is not a new idea (see aspect oriented programming and ilk), being able to do code injection through a web interface by dropping in another application into an application container is new indeed. And I suspect, may be useful in AI operations – more on this in a later blog.

OSGi with resource sharing is the key here . For those unfamiliar with OCEP, it is based on a standard weblogic application container, but is flavoured with an OSGi application management layer.

What is this OSGi thing? Wikipedia tells us it is “OSGi (Open Service Gateway Initiative) is a Java framework for developing and deploying modular software programs and libraries“. Not a very useful explanation.  Practically, OSGi allows multiple programs to share resources through public interfaces, meaning that an app can be sand-boxed for all intents an purposes, except when you don’t want it to be. This is “advertising” in OCEP/OSGi speak.

In this case, when you set a channel to be “advertised”, another application via a discovery mechanism which leverages the subscription mechanism in the OSGI BundleContext, get access to that channel and reprogram the channel to use a set of publishers and consumers different from that which was originally deployed.

OK. Baffling. Here is the howto:

1. within the META-INF/spring/[myapplicationcontext.xml] set all channels around your CQL processors in your application using the wlevs:channel attribute setting “advertise=true”
2. create a new application, the one which contains all of the testing artefacts – dummy publishers and consumers, test canonical object construction code, test data that is converted into the test canonical objects
3. finally write a utility in the new application which gets references to all live channels, reconfigures them to use new publishers and listeners, injects the test canonical objects and grades the routing outcome by detecting which listener should and should not have received the canonical object.

Again, easy right?

In my code repository you can find code snippets which you can use, free, to reconstruct the test harness. Sadly I can’t give you cut and paste code, as the implementation is customised to your real application test cases.  But you will get the idea.

The client took some convincing that it was worth spending the 5 or so days building this test harness, but the results speak for themselves 4 years on. Given the 150+ routing pathways through the application and the many corner cases associated, being able to prove and re-prove the rule behaviour during each release has eliminated hundreds of hours troubleshooting and thousands of dollars in commercial side effects by avoiding production incidents when compared to the previous non-OCEP implementation.

Happy testing!