Overview

References are made throughout these pages to demand-driven and event-driven UEM Servers. Both types of UEM Servers execute from the same application file, uemsrv.exe, (uemsrv on UNIX), and both types monitor events in essentially the same way.

However, the factors that distinguish a demand-driven Server from an event-driven Server include the following:

Method in which the UEM Server component is defined
Method used to initiate the startup of the UEM Server process
Ability to recover previously monitored events during startup
Method used to provide the UEM Server with event definitions and event handlers
Destination of output for event monitoring activity
Ability to refresh an active UEM Server's configuration
Duration of the UEM Server process

Component Definitions

The values of certain parameters in the component definitions for a demand-driven UEM Server and event-driven UEM Server is one way to distinguish between them.

One parameter in particular, component_type, always can be relied upon to identify a demand-driven and an event-driven UEM Server:

Demand-driven Server has a component type of uemd.
Event-driven Server's component type is uems.

A demand-driven UEM Server also relies upon a command line argument, -demand yes, to know whether it should run in demand-driven or event-driven mode. This argument is supplied to the UEM Server process via the start_command parameter of the component definition. This value is set at installation time, and should not be changed.

Server Startup

As a Universal Agent component, both types of UEM Server only can be started by a Universal Broker.

Demand-Driven Server

A demand-driven UEM Server is started by Universal Broker when the Universal Broker receives a request to do so from one of the UEM client applications (that is, the UEM Manager or UEMLoad). Since a user request drives the startup of the UEM Server process, the process is said to be executed on demand; hence the term demand-driven Server.

Event-Driven Server

An event-driven UEM Server typically is started automatically during Universal Broker startup. A UEM client application is not required to start an event-driven Server.

The Universal Control utility can be used to initiate the startup of an event-driven UEM Server. While it may appear that Universal Control is starting the UEM Server, it merely is, in fact, providing an interface from which the start request can be sent to the Universal Broker. The Universal Broker still is solely responsible for starting the UEM Server.

Event Recovery

All event monitoring activity conducted by a demand-driven or event-driven UEM Server is recorded in the event spool database, uems.db. An event spool record is created when an occurrence of an event is detected, or when an event expires. This record also is used to track the status of any event handlers that are executed for the event.

Demand-Driven Server

When a demand-driven UEM Server ends, no association is maintained between the Server component and the event spool records it created. If an event occurrence is being tracked when a demand-driven Server ends, the processing state of the record is set to REJECTED (or CANCELLED if the UEM Manager was terminated forcefully). If a handler is being executed for an event or event occurrence, the handler status is set to SHUTDOWN. Unless the spool records are being retained by the Universal Broker (see the Stonebranch Tip, below), they are deleted when the UEM Server process ends.

Event-Driven Server

When an event-driven UEM Server ends, any event spool records with a processing state of TRACKING or EXECUTING are retained automatically. Event spool records with all other processing states are only retained under the condition described in the Stonebranch Tip, below.

When the event-driven UEM Server is re-started, it will retrieve (based on component name) all event spool records that it retained from its previous run.

If it finds any event occurrences whose processing state is TRACKING, it will resume tracking that occurrence.

If the record indicates that an event handler process was EXECUTING when the UEM Server was brought down, that record's handler status will be set to UNRECOVERABLE. This is necessary because the only way to retrieve the handler process's status is via a process ID that could very likely no longer exist in the system.

Further, if the process ID does exist, there is no way of knowing whether it belongs to the same process recorded in the event spool record.

A Stonebranch Tip

An option can be set in the Universal Broker's configuration to prevent it from deleting any event spool records when the UEM Server component completes. Setting the comp_info_retention option to a value greater than 0 causes the event spool record to be preserved.

Because there is currently no database cleanup routine available, this option should be set only following a recommendation from, and with the assistance of, Stonebranch Inc. Customer Support.

Spool Records

Currently, event spool records only can be viewed with the Universal Spool List utility, uslist.

The following illustrates the syntax used for viewing event spool records.

uslist -list uems [-id recid]

An optional event spool record ID, specified by recid, can be provided to obtain complete detail for a singe record.

The following figure illustrates a sample summary and detailed output listing of event spool records.

uslist -list uems
SERIAL NO	EVENT ID	PRC STATE	HANDLER ID	EXIT CODE	EXIT STATUS	HANDLER STATUS
1		uemsam1 	Triggered	uemsam_t1	0		Normal		Successful 
2		uemsam2		Triggered	uemsam_t2	0		Normal		Successful 
3		uemsam3		Expired		uemsam_x3	0		Normal		Successful 
4		uemsam2		Tracking	N/A		0		Default		Default 
5		uemsam1		Triggered	uemsam_t1	0		Default		Executing 

> uslist -list uems -id 2
Serial No...............: 2
Event ID................: uemsam2
Component Name..........: uems
Component Description...: Universal Event Monitor Server
Component Version.......: 5.2.0 Level 0 Release Build 109
Component ID............: 1116252422
Event Type..............: FILE
System Object...........: C:\UEMFiles\uemsam2.dat
Processing State........: Triggered
Handler ID..............: uemsam_t2
User Cmd................: N/A
Process ID..............: 2572
User ID.................: sparkie
Start Time..............: 5/16/2011 10:08:52 AM
End Time................: 5/16/2011 10:08:55 AM
Exit Code...............: 0
Exit Status.............: Normal
Handler Status..........: Successful
Last Modified On........: 5/16/2011 10:08:55 AM

For additional information on all utilities provided with Universal Agent, see the Universal Agent Utilities 7.6.x Reference Guide.

Source of Event Parameters

A demand-driven UEM Server relies upon its associated UEM Manager for event definition and event handler information. All the information needed to define the event and describe event handlers come from the command options used to invoke the UEM Manager. While these command options may reference the ID of an event definition or event handler stored in their respective database, the existence of such a record is not required.

Conversely, an event-driven UEM Server relies completely upon these stored event definition and event handler records for its input. One of the first things an event-driven UEM Server component does upon startup is retrieve a list of event definitions that are assigned to it. It then determines which events are active, and begins monitoring them.

Reporting of Monitoring Activity

Demand-driven and event-driven UEM Servers record all significant monitoring activity in the Universal Broker log.

This activity includes:

Detection of event occurrences
State changes for events and event occurrences
Results of event handler execution
Recovery of outstanding event occurrences during process startup

This activity only is viewable on the system where the UEM Server executes. To allow monitoring activity to be followed from the system where the monitoring request was issued, a demand-driven UEM Server also provides feedback to a waiting UEM Manager.

Monitoring activity for demand-driven and event-driven UEM Servers is also captured in the event spool database.

See #Event Recovery, above, and Universal Agent Databases for more information on the event spool database.

Configuration Refresh

Because an event-driven UEM Server typically is a long-running process, the ability to refresh an active UEM Server's configuration and list of assigned event definitions is provided. Automatic refresh of configuration and event information for a demand-driven UEM Server is not supported; the values it obtains at start-up are the ones it uses throughout its lifetime.

When a change is made to the stored UEM Server configuration settings, active event-driven UEM Servers must be notified that a change has taken place. This is done with Universal Control, using the REFRESH_CMD option, along with a component type value that identifies the component to refresh.

Command Syntax

The following illustrates the command syntax that demonstrates how to use Universal Control to refresh an event-driven UEM Server's configuration.

uctl -host myhost -refresh uems

Windows

A request to update the configuration of local event-driven UEM Servers is issued automatically whenever a change is made to a UEM Server's configuration through the Universal Configuration Manager.

When Universal Control or the Universal Configuration Manager (Windows only) instructs an active event-driven UEM Server to refresh its cached configuration, the event-driven Server processes the request immediately.

The UEMLoad utility automatically notifies an event-driven UEM Server of an event definition change via a flag that resides in the local Universal Broker. UEM Server checks this flag every two minutes and updates its cached list of event definitions whenever UEMLoad updates them. This eliminates the need to refresh UEM Server with Universal Control following a database change.

Process Lifetime

A demand-driven Server is responsible only for monitoring a single event. When that event's inactive date/time has elapsed, or the maximum number of event occurrences has been detected, the event will be made inactive and the UEM Server process will end.

Conversely, an event-driven UEM Server executes until it receives a shutdown request from the Universal Broker that started it. This shutdown request typically is sent during Universal Broker shutdown, when it forces the termination of all active components.

Universal Control can be used to initiate the shutdown of an event-driven UEM Server. While it may appear that Universal Control is stopping the UEM Server component, it is, in fact, merely providing an interface from which the stop request may be sent to the Universal Broker. The UEM Server will stop only after it receives the shutdown request from the Universal Broker.

Browser not supported