Target Release: Service Preview 

Context

When building event-driven applications one of the core capabilities required is the ability to filter the events based on business requirements.The main goal is to streamline the definition of events of interest and to make sure that the mechanisms to configure such definitions are flexible and easy to change at any time. In the future governance over these changes would be required for our enterprise customers.

One of the most important mechanisms for filtering is based on rules. There isn’t a standard for rules definition that we can leverage, so some of our competitors have designed and implemented their own DSL to define rules in a human readable way but aligned with cloud native formats like YAML and JSON. The challenge is not to turn this into yet another YAML hell but to keep it as simple and human-friendly as possible.

Stakeholders

• ENG
• BU
• PM
• UX

Job Stories

• When events from my infrastructure arrive I want to have a filter based on rules where I can configure the event selection criteria so I can  discard  the events that are not important for my applications .
• I want to be able to use all the fields of data available in my event as criteria for my rule filter so I can be very specific about the type of events I am interested in.
• I want to apply AND and OR logic operators to my rules for filter processing so I have more options to specify the events I am interested in.
• If the schema of the events is known, I want to see in my UI the data definition for rules prefilled in the wizard of the filter so I can more easily configure the criteria for filtering.
• I want to be able to tag events that meet the filtering criteria as part of the processing pipeline.
• I want to have in the same UI a mechanism to test my rules configured for filtering so I can be sure that I configured everything correctly.
• I want to have visibility over the events that meet my criteria, at a certain point and on an ongoing basis so I can audit the information later on. 
• I want to have an API to configure my processing pipeline where the syntax for filters based on rules is the same as the one I used in the UI so I have multiple mechanisms to achieve the same result 
• After I  have filtered out the events of not  interest based on rules I want to have an option  to send the discarded events to a sink destination for further processing or auditing 
• I want to have the option to just copy and paste my rule definition in YAML or JSON into my UI and not have to configure everything on the wizard so I can be more productive if I feel more comfortable using YAML or JSON.

User Narrative

• As a customer of Red Hat Smart Events, I want to classify events using rules, this rules will be defined in a human readable way and I will have a UI to guide me through the process, I will like to have a mechanism to test my rules so I can be sure that I did everything correctly before putting my pipeline in production. 

Goals

• To have a filter based on rules 
• To filter out the irrelevant events from my processing pipeline
• To  have some auditability mechanisms on my processing pipeline
• To have a UI to define the rules and test them.
• To have compatibility between all the mechanisms to develop applications in RHOSE 
• To be sure that I can process continuously the events coming from my customers and applications without worrying about scalability or availability issues

Non-goals

• Replay 
• Durable events support 

Current Approach

Proposed Solution

…

….

Architecture

The source diagram for the proposed architecture is available here:

• link

Rejected Proposals

….

….