The following sections describe the BEA Tuxedo administration processes available to users for managing Tuxedo applications:
As shown in the following figure, the BEA Tuxedo administration processes used to manage a Tuxedo application encompass a variety of tools constructed around the BEA Tuxedo management information base (MIB).
The BEA Tuxedo MIB contains all the information necessary for the operation of a Tuxedo application. It contains the, which is common to all applications, and the following component MIBs, each of which describes a subsystem of the BEA Tuxedo system:
The MIB reference pages (TM_
The BEA Tuxedo administration tools, briefly described in the following list, provide different types of interfaces to the MIB:
The MIB accesses the following BEA Tuxedo system components:
TUXCONFIGfile. The MIB updates the
TUXCONFIGfile and reads information from the
Based on Java and Web technology, the BEA Tuxedo Administration Console lets you operate your BEA Tuxedo applications from virtually anywhere—even from home, given security authorization. The Administration Console is a Java-based applet that you can download into your Web browser and use to remotely manage Tuxedo applications.
The Administration Console simplifies many of the system administration tasks required for managing multiple-tier systems. It lets you monitor system events, manage system resources, create and configure administration objects, and view system statistics.
Each release of the BEA Tuxedo system supports the currently available browsers. For information about browsers currently supported by the BEA Tuxedo Administration Console, seein Installing the BEA Tuxedo System.
The BEA Tuxedo Administration Console has not been updated to support any new features introduced after BEA Tuxedo release 7.1.
When you first bring up the Web and invoke the BEA Tuxedo Administration Console, the following main window appears.
The main window is divided into four major areas:
The Tree View pane appears in the left column of the main GUI window. The tree is a hierarchical representation of the administrative objects in a single BEA Tuxedo application. The GUI graphically depicts the relationship between each object and the others by showing its nesting level and parent objects. You can choose to view a complete tree (comprising all configurable objects of all types in the Tuxedo application) or a subset of objects.
After you have set up and activated an application, the Tree is populated with labeled icons, representing the administrative class objects in your application.
The Tree View contains multiple roots, one root for each administrative object. The first root consists of the Tuxedo application. The next root displays the object classes defined in the BEA Tuxedo TM_MIB. Each set of object classes is a part of a Tuxedo application. The third level represents an instance of an object belonging to an object class.
For example, suppose your application includes two machines (both at SITE1) named
juliet. Since both machines are objects, they are listed in the Tree below the name of the object class to which they belong:
Machines. Therefore, they will be listed as follows:
The name of each object in the Tree View is preceded by an icon. Each machine, for example, is represented by a computer; each client, by a human figure.
The Configuration Tool is a utility that lets you set or change the attributes for a selected class of BEA Tuxedo system objects. When you select an object in the Tree, the Configuration Tool Pane for that object is displayed on the right side of the main window.
The tabbed pages in the Configuration Tool area are electronic forms that display and solicit information about the attributes of an administrative object. A set of tabbed pages is provided for each administrative class of objects (such as machines and servers). The number of attributes associated with a class varies greatly, depending on the class. Therefore, anywhere from one to eight folders may be displayed when you invoke the Configuration Tool by selecting an object in the tree.
When the Configuration Tool area is populated, another row of buttons is displayed below the tabbed pages. These four buttons allow you to control the configuration work done in the pages.
The toolbar is a row of 12 buttons that allow you to invoke tools for frequently performed administrative operations. They are labeled with both icons and names. The following table describes each button.
BEA Tuxedo provides a set of commands for managing different parts of an application built on the BEA Tuxedo system. The commands enable you to access common administrative utilities. These utilities can be used for the following tasks:
You can configure your application by using command-line utilities. Specifically, you can use a text editor to create and edit the configuration file (UBBCONFIG) for your application, and then use the command-line utility named
tmloadcf to translate the text file (
UBBCONFIG) to a binary file (TUXCONFIG). You are then ready to boot your application.
The following list identifies common command-line utilities that you can use to configure your application:
tmloadcf(1)—a command, run on the , that allows you to compile your application's
UBBCONFIGfile into the binary
tmloadcfcommand loads the binary file to the location defined by the TUXCONFIG environment variable.
tmunloadcf(1)—a command, run on the master machine, that allows you to translate the binary
TUXCONFIGfile back to a text version, so that the
TUXCONFIGfiles can be synchronized. The
tmunloadcfcommand prints the text version to standard output.
|Note:||Dynamically updating the binary
tpusrmod(1)—a set of commands that allow you to create and manage a user database for authorization purposes.
tpgrpmod(1)—a set of commands that allow you to create and manage user groups by using access control lists to authorize access to services, queues, and events.
tpaclmod(1)—a set of commands that allow you to create or manage access control lists for applications. These commands enable the use of security-related authorization features.
After you have configured your application successfully, you can use the following command-line utilities to operate your application:
tmboot(1)—a command, run on the , that allows you to centrally start up your application servers. The
tmbootcommand reads the TUXCONFIG environment variable to locate your application's TUXCONFIG file. The
TUXCONFIGinto shared memory to establish the , propagating the changes to the remote server machines in a multiple-machine domain.
tmadmin(1)—an interactive meta-command, typically run on the master machine, that enables you to run subcommands to configure, monitor, and tune your application. You can use the
tmadmincommand before your application is booted (in configuration mode) or when your application is running.
tmconfig(1)—another interactive meta-command, typically run on the master machine, that enables you to run subcommands to configure, monitor, and tune your application. You can use the
tmconfigcommand only when your application is running. The
tmconfigcommand is more powerful but less user friendly than the
tmshutdown(1)—a command, run on the master machine, that allows you to centrally shut down your application servers. The
tmshutdowncommand reads the
TUXCONFIGenvironment variable to locate your application's
You use the command-line utility
qmadmin(1) to perform all administration functions for the application queues in your application. Like the
qmadmin is an interactive meta-command that enables you to run many subcommands.
In a BEA Tuxedo application, you can have multiple application queue devices, and you can run application queues on multiple server machines. Each machine has its own queue device, so you can run
qmadmin to monitor and manage a particular application queue device on each server machine.
To build a BEA Tuxedo Domains (multiple-domain) application, you integrate your existing BEA Tuxedo application with other domains. To do so, you must add a domain gateway group of system servers (
GWTDOMAIN) to your
UBBCONFIG file. These servers are described in BEA Tuxedo Domains (Multiple-Domain) Servers.
All Domains configuration information for a BEA Tuxedo application involved in a Domains configuration is stored in a file known as
DMCONFIG. Similar to the
UBBCONFIG file, the
DMCONFIG file may have any name as long as the content of the file conforms to the format described on reference page DMC
DMCONFIG file, and then use the command-line utility named
dmloadcf to translate the text file (
DMCONFIG) to a binary file (
BDMCONFIG file must reside on the machine that will run the
The following list identifies the command-line utilities that you can use to configure and operate the domain gateway group of system servers for a BEA Tuxedo application involved in a Domains configuration:
dmloadcf(1)—a command, run on the same machine as the
DMADMserver, that allows you to compile an application's
DMCONFIGfile into the binary
dmloadcfcommand loads the binary file to the location defined by the
dmunloadcf(1)—a command, run on the same machine as the
DMADMserver, that allows you to translate the binary
BDMCONFIGfile back to a text version, so that the
BDMCONFIGfiles can be synchronized. The
dmunloadcfcommand prints the text version to standard output.
|Note:||Dynamically updating the binary
dmadmin(1)—an interactive meta-command, typically run on the same machine as the
DMADMserver, that enables you to run subcommands to configure, monitor, and tune domain gateway groups. You can use the
dmadmincommand before your application is booted (in configuration mode) or when your application is running.
, and UBBCO
in BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
The BEA Tuxedo MIB is used to administer a Tuxedo application. It defines the parts of an application that are required in every Tuxedo domain. MIB defines a Tuxedo application as a set of classes (for example, servers, groups, machines, domains), each of which is made up of objects that are characterized by various attributes (for example, identity and state).
When a Tuxedo server machine becomes active, it advertises the names of its services in the bulletin board (BB), which is the run-time (dynamic) representation of the MIB. (The bulletin board is where global and local state changes to the MIB are posted.) The Tuxedo system uses the binary
TUXCONFIG file on the master machine to construct the bulletin board, and propagates a copy of the
TUXCONFIG to the non-master machines in the application to set up the bulletin board on those machines. A bulletin board runs on each server machine in a Tuxedo application.
The following figure presents a high-level view of BEA Tuxedo MIB operation.
The AdminAPI is an application programming interface for directly accessing and manipulating system settings in the BEA Tuxedo MIB. You can use the AdminAPI to automate administrative tasks, such as monitoring log files and dynamically reconfiguring an application, thus eliminating the need for human intervention. This advantage can be crucially important in mission-critical, real-time applications. Using the MIB programming interface, you can manage operations in the BEA Tuxedo system easily. Specifically, you can monitor, configure, and tune your application through your own programs. The MIB can be defined as:
getoperation) or to update the BEA Tuxedo system (that is, to change information in the system through a
setoperation) at any time using a set of ATMI functions. Examples of these functions include
The MIB defines three types of users: system (or application) administrators, system operators, and others. The following table describes each type.
Person responsible for monitoring and reacting to the daily operation of a production application. An operator monitors statistics about a running application, sometimes reacting to events and alerts by taking actions such as booting servers or shutting down machines. An operator does not reconfigure an application, add servers or machines, or delete machines.
Classes are the types of entities such as servers and machines that make up a BEA Tuxedo application. Attributes are characteristics of the objects in a class: identity, state, configuration parameters, run-time statistics, and so on. There are a number of attributes that are common to MIB operations and replies and common to individual classes. Every class has a state attribute that indicates the state of the object.
Independent of classes is a set of common attributes that are defined in the
MIB(5) reference page. These attributes control the input operations, communicate to the MIB what the user is trying to do, and/or identify to the programmer some of the characteristics of the output buffer that are independent of a particular class.
An event is a state change or other occurrence in an application program or the BEA Tuxedo system that may be of interest to an administrator, an operator, or the software. Examples of events are "a stock traded at or above a specified price" or "a network failure occurred."
BEA Tuxedo EventBroker provides asynchronous routing of application and system events among the processes running in a BEA Tuxedo ATMI application. Application events are occurrences of application-defined events. System events are occurrences of system-defined events.
Application-defined events are defined by application designers and are therefore application specific. Any of the events defined for an application may be tracked by the client and server processes running in the application.
System-defined events are defined by the BEA Tuxedo system code and are generally associated with objects defined in
TM_MIB(5). A complete list of system-defined events is published on the
EVENTS(5) reference page in BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference. Any of these events may be tracked by users of the BEA Tuxedo system.
The following table presents the basic tasks for preparing a BEA Tuxedo application for event monitoring.
Application programs are written to (a) detect when an event of interest has occurred and (b) post the event to the EventBroker through
A list of the application event subscriptions is made available to interested users, just as the BEA Tuxedo system provides a list of system events available to users with EVEN
As the administrator for your BEA Tuxedo application, you can enter subscription requests on behalf of a client or server process by making calls to
tpsubscribe(3c) using the published list of application-defined or system-defined events. EVEN
tppost(3c) is called). Subscribers can use the wildcard capability of regular expressions to make a single call to
tpsubscribe that covers a whole category of events.
Each subscription for a system-defined event specifies one of several notification methods. One such method is placing messages in the ULOG: using the
T_EVENT_USERLOG class of
EVENT_MIB, subscribers can write system
USERLOG messages. When events are detected and matched, they are written to the ULOG.
The EventBroker recognizes over 100 meaningful state transitions in a MIB object as system events. The postings for system events include the current MIB representation of the object on which the event has occurred.
, and tpunsub
in BEA Tuxedo ATMI C Function Reference
, and UBBCON
in BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference