Event Router

About the Event Router

The Event Router collects messages from one or more tracked applications, and then routes them to one or more target servers or to WebSphere MQ applications.

In this documentation:

Applications that create and send event messages using the Sentinel Tracking API are referred to as source applications
Target Sentinel servers and target WebSphere MQ applications are referred to as targets

The routing services provided by the Event Router benefit your Sentinel architecture. Via these services, you can:

Send the same message to more than one target
Without the Event Router, tracked applications can only send messages to a single Sentinel Server.
Reduce the number of input connections that targets must maintain
Rather than maintaining one input connection for each source application, Event Router targets maintain only one input connection for each Event Router.
Link tracked applications to targets that are not part of the basic Sentinel architecture
The current version of the Event Router can route messages from the XFB Scope Agent to the Sentinel Server and the XFB Scope Server
Place your Event Router in a secured architecture
The current version of the Event Router includes features that enable you to configure it to perform securely from the interior of a DMZ
Integrate the queuing services of WebSphere MQ in the Sentinel architecture
The Event Router can pass messages through a WebSphere MQ queue manager

The following is an example of one possible Event Router scenario. As this example illustrates, each target maintains only one input connection for each Event Router:

Event Router in a DMZ

When you place one or more Sentinel-monitored applications in a DMZ, and set DMZ rules to block the initialization of connections to elements situated outside the DMZ, you require a particular Event Router configuration to insure data flow to Event Router targets. This DMZ configuration requires at least:

One serving Event Router
One requesting Event Router

Serving Event Router (situated in the DMZ)

A serving Event Router is an Event Router that you configure to operate in QLTSRV mode.

To configure a serving Event Router:

In the General Parameters File, set the sap attribute in the Sentinel section to the listen port for connections with a requesting Event Router.
Note: When you define the requesting Event Router, you enter this same listen port number in the Target/Access element of the Target Parameters file for that Event Router.
In the Target Parameters File, set the mode attribute in the Target/Access element to QLdefine TSRV.

The following is an example of Target Parameters File values that define a serving Event Router:

Where: the target name is the same name you enter in the "ident" parameter of the requesting Event Router (see following example)

Requesting Event Router (situated outside of the DMZ and physically connected to the serving Event Router)

A requesting Event Router is an Event Router that you configure to operate in QLTREQ mode and for which you enter the identity of the related serving Event Router and sending criteria.

To configure a requesting Event Router, in the Target Parameters File:

In the Target/Access element, set the mode attribute element to QLTREQ. In the port attribute, enter the listen port that you defined in the sap attribute of the General Parameters file for the serving Event Router.
In the same Target/Access element, enter the name of the targeted serving Event Router in the ident attribute.
In corresponding the Target/Sendif element, set the parameters to define the frequency at which the Event Router connects to the serving Event Router.

The following is an example of Target Parameters File values that define a requesting Event Router:

Where:

port = the listen port number. This is the listen port that you defined in the sap attribute of the General Parameters file for the serving Event Router.

ident = the name of the target serving Event Router you defined in the serving Event Router Target Parameters File (see previous example)

Additionally, if your Event Router configuration includes one or more proxy servers, or if you want to define an originating port other than the default port, in the General Parameters File of the serving Event Router, set the TCPSource parameters:

tcp_org_port_file
tcp_proxi_file

If you use WebSphere MQ...

If you use WebSphere MQ (formerly MQSeries) to transfer messages, you can integrate this product in the Sentinel architecture, as illustrated below:

The rest of this topic introduces the key concepts and features of the Event Router. Before you configure and manage the Event Router, familiarize yourself with the following concepts and features:

Event Router Processes
Event Router Overflow and Batch Files

About processes and entities

Functionally, the Event Router comprises a set of physical Event Router processes. These are the units of binary executable code that provide Event Router services.

Each physical Process supports one or more logical processes. In this documentation, Event Router logical processes are referred to as Entities. Entities provide a logical structure that facilitates the management of Event Router functions. Via Entities, the Event Router provides you with information about the operational events that occur on your system.

The following table introduces the role of each Event Router entity.

Entity	Function
DISP	Dispatches incoming messages to the appropriate Event Router entity. To perform this task, DISP: loads the Target Parameters File. receives messages from one or more source applications. identifies the relevant targets. dispatches the messages to the Processes (SNTL, MQOUT) that then route them to the relevant targets.
LOG	Records traces in the log file
MQIN	Transfers messages from WebSphere MQ to an Event Router. To perform this task, this entity does the following: MQIN retrieves messages from a WebSphere queue. MQIN sends the retrieved messages to DISP. If DISP: Can dispatch the messages, MQIN deletes the messages from the queue in WebSphere MQ Cannot dispatch the messages, MQIN routes the messages to a retry queue in WebSphere MQ
MQOUT	Routes messages to WebSphere MQ. To perform this task, MQOUT: Receives the relevant target configuration from DISP. Receives messages from DISP. Stores received messages in an overflow file or a batch file when appropriate. Inserts messages in the relevant WebSphere queues.
NET, NETS	Manages the TCP/IP connections to source applications and targets. On some platforms, two entities NET and NETS are defined, one for the source application and one for the targets.
SNTL	Routes messages to one or more: Sentinel Servers Scope Servers To perform this task, the SNTL entity: Receives the relevant target configuration from DISP. Receives messages from DISP. Stores received messages in an overflow file or a batch file when appropriate. Sends messages to the relevant targets.

About overflow and batch files

When you configure the Event Router, you define the following files for each target:

Overflow – This file stores only the messages that the Event Router cannot send to the relevant target.
Batch – This file stores messages that the Event Router will send in batches to the relevant target. You specify the conditions under which the Event Router sends batches of messages from this file.

On MVS platforms

The Event Router can run on OS/390 and z/OS platforms. On these MVS platforms, MQOUT and SNTL entities are associated with a single file that combines the features of both the overflow file and the batch file. Each file is referred to as an overflow/batch file. When you configure targets on an OS/390 platform, you can only identify the overflow/batch files that you created during installation. For more information, refer to the Sentinel installation documentation.