A Filter System Object is a cohesive unit of functionality that performs a well-defined task on XML events flowing through the system. Filters are chained together inside Filter Stacks to solve specific parts of application problems. These filter stacks can then be replicated, reconfigured and reused to perform similar tasks inside Event Correlation Applications (ECA’s).
Most filters process events in a synchronous manner using a one-element queue and utilizing the thread of the calling object (the parent Filter Stack). This policy conserves valuable system resources, since the number of filters in a stack can be fairly significant for each individual filter to have its own thread.
Perform the following steps when writing a typical EventGnosis Filter:
com.eventgnosis.filters.FilterBase
, which itself extendscom.eventgnosis.system.SystemObject.
Since a Filter is a SystemObject
you inherit significant functionality, and your new object will be part of the startup and runtime object hierarchy automatically, given that this Filter is active and configured into an ECA. This behind-the-scenes work is automatically performed by the ECS framework.<filterType description="If event matches %Condition% route to %DestinationName%." objectId="RouteEventFilter" schema=""> <implement class="com.eventgnosis.filters.RouteEventFilter" source="ecs.jar" type="Java" /> </filterType>
This XML snippet should be added to the file EV_HOME/config/extra/emptyECA.xml, the configuration source for the GUI and the ECS. Note that this example has two parameters (Condition & DestinationName), which will be set and validated by the GUI when a user selects a “RouteEventFilter” Filter. You will also need to set the path to your implementation here
(com.eventgnosis.filter.RouteEventFilter
) and its jar. Typically, you could create an add-on jar that is separate from the ecs.jar and is specific to your company, and uses a specific package/class name such as com.yourcompany.filters.filterName. This new jar must, of course, be in the classpath of the ECS for it to be recognized.
com.eventgnosis.filters.RouteEventFilter.
String
. If the Filter’s class attribute is not of type java.lang.String
it must be converted (cast) to its requisite type. Conversion methods for the most common types can be found in com.eventgnosis.util.Util.java.
Furthermore, some parameter types set by the GUI are not primitives but are composite types, such as the type Condition. A composite type can be referred to in a SystemObject description, but it must then be defined with a parameterType XML snippet in ECA so that the GUI can understand the composition: <parameterType description="???" objectId="Condition" schema=""> <implement class="com.eventgnosis.filters.Condition" source="ecs.jar" type="Java" /> </parameterType>
If composite types are utilized, they must, of course, be implemented, and added into your jar and the usual information specified in the “implement” section so that the ECS can locate your code. Examples of such implementations are com.eventgnosis.filters.Condition,
and its use in setVars() in com.eventgnosis.filters.RouteEventFilter.
In summary, each Filter attribute must be carefully processed in setVars() using the following steps:
String
.com.eventgnosis.filters.RouteEventFilter.
Typically, a filter performs distinct operations on an event, depending on the preconfigured values of the Condition object. The superclass methods setCondition() and matchCondition() are very useful in this regard since your specific processing is usually contingent on the value of the condition, existing inside the matchCondition() if/else block. Significant utilities exist for adding/editing/deleting the fields of an event. Reference examples exhibiting this capability are com.eventgnosis.filters.AddFieldFilter, com.eventgnosis.filters.EditFieldFilter
and com.eventgnosis.filters.DeleteFieldFilter.
Very complex filter behavior is possible with advanced implementations. A separate thread for a given filter is added when independent time control/alarming is necessary (see com.eventgnosis.filters.DetectUniqueIncompleteSequenceFilter
). Complex correlation behavior can be localized to a single filter by providing database access, Java sub-objects and variable event routing, as in the com.eventgnosis.filters.RouteEventFilter.
Finally, the paradigm of firing a list of Actions dependent on certain conditions lends tremendous power to action-taking based on recognized event conditions inside a filter. This set of actions can be logically configured to initiate a set of actions dependent on the existence or non-existence of value, timing or other conditions recognized within a filter. This type of functionality makes ECS functionality pretty much up to the imagination, unlimited by the usual implementation barriers.