Making event type definitions available to monitors

A monitor must have information about the type definitions of the events that it processes. You can provide this information in several ways:

Define the event type in the monitor. Only instances of that monitor can process events of that type. Also, events of that type cannot be sent into the correlator from outside. When you define an event type inside a monitor it has a fully qualified name. For example:

The fully qualified name for the Example event type is Test.Example and the toString() output for the event name is "Test.Example()".

After the optional package specification, define the event type at the beginning of an EPL file that also defines monitors. All event type declarations must be before the monitor declarations. After you inject this file into the correlator, the following monitors can process events of that type:

All monitors that you inject after you inject the file that contains the event definition.

Define the event type in a separate file that contains only event definitions. An event type definition file has a .mon extension. It is still an EPL file even though it contains only event type declarations.

You can define any number of event types in a single file. A common practice is to define the event interface to a service in a file that is separate from the implementation of that service. You might have a single event interface file and multiple implementations of services that process those event types.

You might have a need for different event type definitions to have the same event type name. In this situation, define each event type in a different package and then use one of the following ways to bring the appropriate event type definition into your monitor:

In your monitor, specify the fully qualified name of the event type, for example:

com.apamax.test.Status

In your EPL file, after any package declaration and before any other declarations, specify a using declaration. For example:

using com.apamax.test.Status;

In your code, you can then simply refer to the Status event type.

Do not create EPL structures in the com.apama namespace. This namespace is reserved for future Apama features. If you do inadvertently create an EPL structure in the com.apama namespace, the correlator might not flag it as an error in this release, but it might flag it as an error in a future release.

See also Name Precedence in the Lexical Elements section of the Apama EPL Reference.

An event type definition must be injected into the correlator before a monitor that processes events of that type. After you inject an event type definition into the correlator, any monitor that you inject after that can process events of that type.

During development, when you use Apama Studio to launch a project, it ensures that files are injected in the right order. When more than one project requires the same event definition file, do one of the following:

In each project, declare an external dependency on the common event definition file:

1. In Apama Studio, in the Apama Developer perspective, in the Developer Project View, select the project name.

6. Navigate to the event type definition file, and select it.

Create a project that contains the common event definition file. In each project that requires these event definitions, declare a dependency on the project that contains the common event definition file.

1. Create the project that contains the common event type definition file and keep that project open in Apama Studio.

2. In the Developer Project View, select the name of a project that needs to use the common event definition file.

7. Select the project that contains the event definition file, and click OK.