HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW
Administration | TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC | INDEX
|
|
|
BEA WebLogic Enterprise 4.2 Developer Center |
|
HOME | SITE MAP | SEARCH | CONTACT | GLOSSARY | PDF FILES | WHAT'S NEW |
||
|
Administration | TABLE OF CONTENTS | PREVIOUS TOPIC | NEXT TOPIC | INDEX |
||
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 The BEA TUXEDO Event Broker/Monitor extends the usefulness of the UBBCONFIG file are started. For details, see the section "Required Order in Which to Boot Servers (WLE Servers)" in Chapter 3, "Creating a Configuration File."
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:
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 Events
Event Classifications
USERLOG: information (INFO), warnings (WARN), and errors (ERROR).
INFO event is one of the following:
WARN event is a configuration change that threatens the performance of the application.
ERROR event is an abnormal occurrence, such as:
Events affecting objects in the classes defined in 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
TM_MIB(5) are tracked. The list is published in EVENTS(5).
Setting Up Event Detection
syslogd)
To activate event detection logic, set and export For details, see Clients subscribe to events by calls to In the BEA TUXEDO System Monitor the message includes the severity level, so a user can subscribe accordingly. Here are two examples:
TMSYSLOGD_FACILITY to a numeric value from 0 to 7.
syslogd(3c) in a UNIX system reference manual.
Subscribing to Events
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.
eventexpr to the following:
\.SysNetwork.*ERROR sets the value of eventexpr to the following:
When a client leaves an application (by calling Another argument of the As a BEA TUXEDO system administrator, you can enter subscription requests on behalf of a client or server process through calls to the 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.
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.
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):
system(2) command.
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
tppost.
EVENTS(5) in the BEA TUXEDO Reference Manual.) In the same way, when an application-specific Event Broker/Monitor is being used, interested users should have access to a list of monitored events. The names of system events begin with a dot ( . ); application-specific event names may not begin with a dot ( . ).
tpsubscribe using the published list of events, so the application can identify the events to which you are subscribing.
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:
TMSYSEVT(5)
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:
MASTER site
With an application-specific Event Broker/Monitor, the primary server may be on any machine other than the 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 The BEA TUXEDO Event Broker/Monitor is built with the following AdminAPI components:
MASTER; secondary servers may be located around your network.
tppost is called for the new event.
How the Event Broker/Monitor Works
tppost
EVENT_MIB management information base is the control file in which you can store subscription information and filtering rules. In your own application, you cannot define new events for the BEA TUXEDO system Event Broker/Monitor, but you can customize the Event Broker/Monitor to do the following:
