Browse Prior Art Database

Usage of Metadata Definitions for User Assistance on Rule Writing Disclosure Number: IPCOM000028518D
Original Publication Date: 2004-May-18
Included in the Prior Art Database: 2004-May-18
Document File: 3 page(s) / 76K

Publishing Venue



This article describes an automatic code generation mechanism that can reduce the amount of source code required to handle data inside events of different types.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 1 of 3

Usage of Metadata Definitions for User Assistance on Rule Writing

Event management solutions often benefit from correlation technologies that can relate a large number of events to a smaller number of more significant events, or root causes. The complexity of a typical IT infrastructure makes virtually impossible to pre-construct correlation rules that will work on any environment.

The complexity of the correlation logic often calls for a high-level programming language that allows a system administrator to represent such complexity. Several event management solutions in the market package rule processing engines using different programming languages, such as Prolog, Java, C/C++ and others.


The problem is that typical IT installations have dozens (sometimes thousands) of event definitions and only part of the event data is common across all the different event types.

Currently, the problem is addressed by defining the common fields for all events (called base fields) and allocating a generic container for all the other fields. When an event is used referenced inside a correlation rule, there are specific methods to access the data on the common fields but only a generic method to access all the other fields. Whenever the correlation rule has to reference these other fields, the code becomes verbose.

For instance, assuming an object oriented language, such as Java and a readily available event implementation (http://www.eclipse/org/hyades) , one would have the following code snippet to access a basic field 'message' on an event of type "order":

1 import;

3 CommonBaseEvent event = ...; // use some mechanism to build the
event, not relevant to this article
4 String msg = event.getMessage();

but the following code to access a generic field ' order_information/total_value ' of type 'float' on that same event:

1 import;
2 import;

4 CommonBaseEvent event = ...; // use some mechanism to build the
event, not relevant to this article
5 float value = 0;

6 if (event.getExtensionName(" order_type ")) {
7 ExtendedDataElement topLevelElement = event.getExtendedDataElement("
order_information ");

8 if (element != null) {
9 ExtendedDataElement secondLevelElement =
topLevelElement.getExtendedDataElement(" total_value ");
10 value = (Float)secondLevelElement.getValue().floatValue();
11 }
12 }

As one can see, the second example requires much more code, using 8 lines (from 5 to 12 on the second example) of code instead of 1 (line 4 on first example).

The invention is based on the presence of an event metadata repository on the event infrastructure. The event metadata repository contains a description for the generic fields for each event type.


Page 2 of 3

The event metadata can be typed manually or dynamically generated as event data arrives in the event infrastructure. At any rate, the...