Events Framework

Why Event Framework?

Automate different business scenarios which have events incorporated. Some of these scenarios are:

• Waiting for a document to get updated

• On creation of a document

• On receiving an email

• On receiving a SMS

Event Framework allows users to create their own event provider which optionally can be hosted inside the Engine. It has different interfaces which will help to handle different event scenarios very easily.

Event Framework Components

The following are the main components of Event Framework.

EventProviders

This is the main component of Event Framework. These are the component which is handling a specific event. Users need to create different event providers to handle their events. All event providers need to implement an interface called IEventClientServiceProvider

There are two types of Event Providers First type is hosted inside the Engine. To create these kind of providers you need to implement an additional interface called IEventServiceProvider. If your event provider handles load balancing you need to implement another interface called IEventSupportsLoadBalancing

EventPorts

EventPorts can be considered as an endpoint for EventProviders. For example, for a wait for email event provider, need to get email from different sources like POP3 or forwarding from an Exchange server etc. Each of these sources can implement as EventPorts. For a file watcher event provider, there will be different EventPorts which are watching different Folders.

The user can use IEventPort interface to implement EventPort.

EventBinding

This client side component is responsible for consuming events and alert workflow. You need to create an EventBinding for each interested events.

EventBindings are stored in SKEventBinding table.

EventParameter

This is the correlation parameter which filters events and its interested EventBindings. Every Event Provider has a set of EventParameters. Using these parameters, it will filter eventbindings interested to the specific provider events.

EventItem

This is an event message container component.

The Event Framework is designed to support any type of events such as, file system event provider, share point event provider, email event provider. The following are the interfaces and class for the implementation of the Framework. These interfaces and classes implemented in file event provider class file.

Interfaces and Classes

The following are the interfaces and classes used in the Event Framework. All the interfaces need to be implemented in the event service class files.

Interfaces:

• IEventPort:- This interface represents a port used by the event service provider

Properties:-

portname

port guid

event name

port xml string

Port generally contains the information about event listener. For e.g. Incase it is FileSystemEventProvider, the port contains name of directories which file system event provider is going to monitor.

• IEventClientServiceProvider:- This interface need to be implemented in the event handler class file and returns a new event port and set its values. The read only property Event name is hard coded in each event provider.

  Methods	Functionality
  GetNewEventPort()	Returns new empty port object
  LoadEventPort()	Creates new port and set its values.
  GetAllEventParameters()	Returns all event parameters which would be available whenever an event is raised by the event service provider.  This is useful to give event notification to appropriate consumer.
  IsEventValidForTheTarget()	Changes the event message before it reaches the work flow engine.  This is like additional preprocessing on the event message before it delivered.

• IEventServiceProvider:- This interface will start the events and need to be implemented in the event handler class file.

  Methods	Functionality
  StartListeningPort()	Starts listening to a specified port
  StopListeningPort()	Stops listening to a specified port
  RefreshListeningPort()	Refreshes the port to which it is listening.

Classes:

• EventBinding:- This class file is used to set the event parameters such as event name, Portguid, Application name etc. and saving to the SKEventbinding table. This file is inherited from Skelta.Core.DS.SingleTableObject class file. This base class has the method save for saving the data to the event binding table. This converts the parameters as in XML format and save the data to the event binding table. After raising the events, the specified record is deleted from the table by calling the delete method.

• EventBindingCollection:- This will retrieve the matching event item record from the eventbinding table. This generates the select query and set all sql parameters and retrieve the corresponding event record.

• EventItem:- This class file is used to create a new event object. Here the parameters are event provider name, event port, event parameters and event message.

• EventParameter:- This class file holds parameters used for correlation between an event and an eventbinding.

• EventServiceManager:- Methods of this class will be called from the engine to start the events, stop the events etc. This file called the StartListeningPort method which is implemented in the event handler class file. This contains other important methods such as GetAllEventProviders and GetAllEventPorts. First will retrieve the event providers from the table and second will retrieve the event ports from the table.

• EventServicePort:- This class file will set event service port details and save to the SKEventServicePorts table. This class file inherited from the Skelta.Core.DS.SingleTableObject file. This base class facilitated the saving option and represents a particular port record.

• EventServicePortCollection:- This will retrieve the event port details for a specific event type. This retrieves collection of ports for the event from the table SKEventServiceports table.