Business Rules Manager For WSO2 Stream Processor : A Brainstorm

Real time data analytics is now becoming a “MUST” have feature in business. However, design and deploying streaming analytic solutions is yet a bit complex task. Hence most of the time, it requires the user to have a good knowledge in underlying tech stuff in addition to the knowledge in business process.

Focusing on this issue, we have developed business rules manager for WSO2 Stream Processor.

Since WSO2 documentation has provided a detailed user guide on this feature, in this article I am going to discuss about its underlying design.

The Idea And The Plan..

The primary objective of this feature is to hide the complexity of designing analytical processes to the user and let him to customize the pre-built templates of business processes according to his use case.

In this scenario, we identified two levels of users.

1. Developer : A person who has a better understanding in the programming and design of business processes.
2. Business User : A person who does not need to have a good technical knowledge about the underlying analytical solution, but who needs to use streaming analytics for his business use case.

Theses customized processes are called the business-rules :)

So the task was to allow both types of users to design the process and then deploy it by customizing according to the use case. Stepping one step further, business user should be able to derive his own logic instead of providing some set of values for some predefined variables. Therefore, this feature supports user to define the logic from scratch as well as creating a business rule from a template.

Obviously, WSO2 Stream Processor is powered by Siddhi. Therefore business rules manager should have supported to get SiddhiApps templated, and then derive business rules out of it. (i.e. A business process would be modeled as a SiddhiApp)

An Example..

Suppose there is a business which is spread across different geographical locations and tightly bounded with the weather conditions. Based on the location, it is required to have alerts on temperature fluctuations.

• Operation center A should trigger an alert if the temperature drops below 20 degrees.
• Operation center B should trigger an alert if the temperature drops below 15 degrees.

It’s clear that all the operation centers are executing the same process with different variables.

If you are the one who design this process, you can do it in two ways.

1. Design the process for each station separately.
   Even though the logic needs to be changed by a little bit, you will need change the execution plan in each and every station, ONE BY ONE. Wouldn’t it be troublesome?
2. Design the process in an abstract manner and let it get customized for each station.
   Instead of re-visiting the whole process, you only have to change some variables.

Business Rules Manager is based on the second solution given above.

How It’s Designed..?

When performing a stream analysis on a business use case, the process can be modeled with one or more Siddhi apps. So it should be possible to template multiple Siddhi apps and expose them to the user as a single template to the business user.

Basic Flow in Business Rules Manager

Developer is allowed create the templates for business rules and save them in the file system. Then business user is able to access them through business rules manager web app, and create business rules out of them. A business rule is consisted of one or many Siddhi apps.

Deriving Business Rules From Rule Templates

Then another requirement arrives. It should be possible to deploy Siddhi app not only on a single node, but also on multiple nodes. Developer is given the option to to define which business rule should be deployed on which node.

SiddhiApps REST API is used for operations related with Siddhi apps of a business rule such as deploying, updating and deleting.

When deploying multiple Siddhi apps in the same machine, there can be conflicts due to the lack of resources such as ports. If a rule template has such possibility, it should be instantiated only once. Therefore the developer is given the chance to define whether the rule template can be instantiated only once or many times.

User Experience..

After all, business user should be able to monitor the state of the business rules he created.

In this case, the UI plays a major roles in hiding the complexity from the business users. So it should have been designed so that user can simply create, edit , delete business rules and monitor the state of them with few simple clicks.

Also, Business Rules REST API is publicly available. So if anyone wants to build a custom dashboard for business rules, he can easily connect the front end with the core of business rules manager through that API.

So give it a try!! ;)