|
|
The BEA TUXEDO Event Broker/Monitor is a tool that enhances the tracking of events in a running application.
Note:
This chapter is specific to the BEA TUXEDO system. However, WLE administrators should know that each WLE application relies on the BEA TUXEDO System Event Broker. This event broker must be started before any servers providing the NameManager service in a WLE application's UBBCONFIG
file are started. For details, see the section Required Order in Which to Boot Servers (WLE Servers) in Creating a Configuration File.
The BEA TUXEDO Event Broker/Monitor extends the usefulness of the USERLOG
(in which the BEA TUXEDO system records system events) by providing the following:
The BEA TUXEDO Event Broker/Monitor is built on the AdminAPI, the administrative programming interface to the BEA TUXEDO system. It is an example of administration through programming.
The chapter discusses the following topics:
Note: This chapter demonstrates how you can use the BEA TUXEDO AdminAPI to enhance your application. For an actual example that you can run as a demo and copy from, see the bankapp application (distributed with the BEA TUXEDO system) and the BEA TUXEDO Application Development Guide.
An event is a change in a component of a running application. This change may be harmless or it may cause a problem that requires work by the operator or administrator (and, in some cases, particular software) to be resolved.
The BEA TUXEDO Event Monitor keeps track of events in a running application and classifies them on the basis of severity. The Event Monitor uses the same three severity classifications used by the BEA TUXEDO system to sort system messages sent to the USERLOG
: information (INFO
), warnings (WARN
), and errors (ERROR
).
Events
Event Classifications
Events affecting objects in the classes defined in TM_MIB
(5) are tracked. The list is published in EVENTS
(5).
The designers of an Event Broker/Monitor need to decide which events to track. Users of the system need to know the list of events being tracked.
You can set the BEA TUXEDO system event detection logic to do two things:
List of Events
Setting Up Event Detection
To activate event detection logic, set and export TMSYSLOGD_FACILITY
to a numeric value from 0 to 7.
For details, see syslogd
(3c) in a UNIX system reference manual.
Clients subscribe to events by calls to tpsubscribe
(3c). A call to tpsubscribe
has a required argument, eventexpr
, that points to a wildcard string. This string, in turn, identifies the events about which the user wants to know. The wildcard string makes use of the syntax described in recomp
(3c) to apply the subscription to more than one type of event. The wildcard string is used to match the message distributed when the event is detected.
In the BEA TUXEDO System Monitor the message includes the severity level, so a user can subscribe accordingly. Here are two examples:
Subscribing to Events
\.SysNetwork.*
\.*(ERR|err)\.*
When a client leaves an application (by calling tpterm
) all of its subscriptions are "canceled." If the client later rejoins the application and wants those subscriptions, it must subscribe again. A well-behaved client unsubscribes before calling tpterm
. A client that accepts notification via unsolicited messages should issue a tpunsubscribe
(3c) call before leaving the application.
Another argument of the tpsubscribe
call (in addition to eventexpr
) is a pointer to a structure of type TPEVCTL
(defined in atmi.h
). Through the use of the TPEVCTL
structure (or non-use, if the argument is NULL), the user can select the notification method to be used for sending information about subscribed events. If the argument is NULL, the event broker sends an unsolicited message to the subscriber. The subscriber can alternatively elect to have the notification sent to a service or to a queue in stable storage. If a client wants to enter such a subscription, it must invoke a service routine to subscribe on its behalf.
As a BEA TUXEDO system administrator, you can enter subscription requests on behalf of a client or server process through calls to the EVENT_MIB
(5). You may also use two notification methods that are specified in entries in the EVENT_MIB
(besides the three available in tpsubscribe
):
By "application-specific Event Broker/Monitor" we mean a monitor customized to recognize events generated by application code. For example, a stock brokerage system could be programmed to post an event when a stock trades at or above a certain price. A banking application might be programmed to post an event when a withdrawal or deposit above a specified amount is detected.
The function of an application-specific Event Broker/Monitor is similar to that of the BEA TUXEDO System Event Broker/Monitor: when an event is posted, subscribers are notified (or an action specified by the subscriber is initiated). This section describes the same three areas that were described above, pointing out how the customized monitor resembles and differs from the BEA TUXEDO system monitor.
Application-specific Event Broker/Monitors
Note: For the BEA TUXEDO System Event Monitor, EVENTS (5) lists the notification message generated by an event, as well as the event name. The event name is used as an argument when tppost is called. Subscribers, on the other hand, can take advantage of the wildcard capability of regular expressions to make a single call to tpsubscribe to cover a whole category of events. We strongly recommend using the same format for the published event list for an application-specific Event Monitor/Broker.
The client interfaces with the Event Broker/Monitor through either of two servers provided by the BEA TUXEDO system:
These servers introduce the concept of a principal server and zero or more secondary servers. Both types (principal and secondary) process events and trigger notification actions.
To install the BEA TUXEDO system Event Broker/Monitor, configure:
With an application-specific Event Broker/Monitor, the primary server may be on any machine other than the MASTER
; secondary servers may be located around your network.
The reason for locating secondary servers on other nodes of your network is to reduce the amount of network traffic caused by posting events and by distributing event notifications to subscribers. The secondary server periodically polls the primary server to get the latest version of the subscription list, which stores filtering and notification rules.
You can configure the polling interval as needed. There may be a perception that event messages are lost during this period between the time at which subscriptions are initially added and the time at which all secondary servers are updated. If the application cannot "lose" messages, the programs must wait, at least until the end of the polling period, before tppost
is called for the new event.
The BEA TUXEDO Event Broker/Monitor is built with the following AdminAPI components:
How the Event Broker/Monitor Works
These three functions appear in both the C library and the COBOL library. (See Sections (3c
) and (3cbl) in the BEA TUXEDO Reference Manual for details.)
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|