This is an old revision of the document!
Source SystemObjects
receive events external to the system, often in an asynchronous manner. Due to the unpredictable arrival rate of events, a source must be threaded, depending on the input parameter for the setEventProcessor() call you make in the SystemObject’s setVars() method. A source is responsible for converting a given protocol to EventGnosis’ proprietary, normalized Event format (basically a small XML document or property sheet). This document is then routed successively to the next SystemObject
in the ECA component topology, perhaps modified and finally sent out of the system.
The following steps need to be performed when writing a typical EventGnosis Source. It is assumed that you do understand, in detail, the protocol for the Source you are writing.
EventSourceListenerBase
, which itself extends SystemObject
and implements the InputEvents
interface. Since a Source 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 source is active and configured into an ECA. This behind-the-scenes work is performed by the framework and your job is to attach it correctly.XMLTCPIPSocketListenerSlave
and XmlTCPIPSocketListener
). This parent object will be responsible for receiving the connection requests and instantiating a new slave object for each new connection running on the same port. It must also have its own thread started in doWork(), implement the Runnable interface and a run() method. Its getNextEvent() method should return null and actual event processing is deferred to the slave implementation.FromLogListener
which may have multiple instances, each listening to a different file based on different configuration). In this (typical) case, the getNextEvent() method from the InputEvents
interface must be implemented, and a ThreadedEventGenerator
must be set as the event processor in setVars().<sourceType description="Receive EventGnosis ECS events on network interface %Host% using %Port%." objectId="EcsTcpEventReceiver" schema=""> <implement class="com.eventgnosis.sources.XmlTCPIPSocketListener" source="ecs.jar" type="Java" /> </sourceType>
This XML snippet should be placed in EV_HOME/config/extra/emptyECA.xml, the source of configuration information for the GUI and the ECS. Note that this example has two parameters (host & port), which will be set and validated by the GUI when a user selects an “EcsTcpEventReceiver” source. You will also need to set the path to your implementation
(here com.eventgnosis.sources.XmlTCPIPSocketListener
) and its jar. Typically, you could create an addon jar that is separate from the ecs.jar and is specific to your company. This new jar must, of course, be in the classpath of the ECS for it to be recognized.
com.eventgnosis.sources.XmlTCPIPSocketListener.java.
com.eventgnosis.util.Util.java.
Furthermore, some types set by the GUI are not mere primitives but are composite types, such as the type LoginInfo, which includes user name and password. 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="%Login%" objectId="Login"> <implement class="com.eventgnosis.sources.LoginInfo" source="ecs.jar" type="Java" /> </parameterType>
If composite types are utilized, they must of course be implemented, 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.sources.LoginInfo
, and its use in setVars() in com.eventgnosis.sources.EmailSlave.
In summary, each Source attribute must be carefully processed in setVars() using the following steps:
if( connection == null ) { connection = {…do connection logic } }
com.eventgnosis.sources.XMLTCPIPSocketListenerSlave.java.