This chapter is devoted to the client side of the In the client-server architecture of BEA TUXEDO there are two modes of communication:
A Look at bankapp Client Programs
bankapp
sample application.
Variations of the two modes above can be constructed by taking advantage of the BEA TUXEDO features that allow requests to be forwarded from one server to another, that permit requests to be chained and that permit requests to be queued in stable storage for later processing. One form of client access to Figure 3-1 shows the hierarchy of masks for
Taking one of the shorter masks for illustration, in Listing 3-1 we show how the source code of a mask looks in the Once a mask has been created, it is converted into binary form and is used under the control of bankapp
is not set up to demonstrate any of these variations, but once you have the application running you might want to try these as extensions to the example.
System Client Programs
bankapp
is through the resources of the BEA TUXEDO Data Entry System (DES), a character-oriented interface. With DES, data entry forms (also called masks or screens) are created to provide a template that can be used by application users to formulate requests. The masks can be organized into a hierarchy by means of MENU
statements of the form definition language, UFORM
. They are managed by the system client, mio
(1).
bankapp
. The top-level mask is a menu that leads the user to select one of the six service request masks. The oval shapes in the illustration represent application services. The six rectangles across the bottom of Figure 3-1 represent confirmation masks that give feedback about the results of the service request.
Figure 3-1 The bankapp Input/Output Mask Hierarchy
Mask Source Code
UFORM
syntax. This mask (indicated as number 6 in Figure 3-1) is used to close an account. It calls the CLOSE_ACCT
service and has a single variable field for the number of the account to be closed.
mio
.
Listing 3-1
Source Code for the CLOSE.m Mask
#
#
#SERVICE NAME=CLOSE_ACCT
#FORM FLAGS=Umrv TRANMODE=TRAN TRANTIME=30
#PAGE STATUSLINE=24 FLAGS=Pmrv
*ROW COL MIN LINES WIDTH FLAGS VALUE
*--- --- --- ----- ----- ----- -----
2 C - 1 - L "TUXEDO (R) System"
+1 C - 1 - L "Banking Services"
+2 C - 1 - L "Close Account"
+6 25 - 1 - L "Account Number To Close:"
- 51 5 1 7 UmN7IHrv ACCOUNT_ID
HELP="Enter account number"
ERR="Account number must be 7 digit number"
VAL=IR:[1-9999999]
FORMEXIT F0=FC:HELP,F11=S:CLOSE_ACCT
+3 24 - 1 - L "Hit CTRL-v to complete trans."
+1 C - 1 - L "or ESC 0 for keystroke help"
mio
(1) is a forms handling program supplied by the BEA TUXEDO system that gathers the data from a binary data entry mask into a buffer and sends the buffer to a service. bankapp
has a set of masks (shown above in Figure 3-1) that mio
uses for calling the OPEN_ACCT
, CLOSE_ACCT
, WITHDRAWAL
, DEPOSIT
, INQUIRY
, and TRANSFER
services. mio
joins the application as a client and when the user enters the key sequence to transmit the mask, the BEA TUXEDO software adds the service request to the queue of a server that advertises the desired service. If the application is using an application password, mio
prompts the user to enter the password before allowing any of the service request screens to be used.
If mio
is invoked with no arguments, it presents a generic initial mask that prompts the user to name the mask to bring up. In bankapp
, the shell script named run
invokes mio
with the initial menu for bankapp
. If you look at run.sh
, you will see that it contains one command line:
mio -i MENU
Of course, you can also get into the mask system by invoking mio
directly rather than through run
.
It was mentioned in the preceding section that mio
gathers the data from a data entry mask into a buffer before sending it to a service. Message buffers are an essential part of BEA TUXEDO, as is the concept of typed buffers. In BEA TUXEDO a typed buffer is a buffer designed to hold a specific data type. Nine types are defined: FML
, FML32
, VIEW
, VIEW32
, STRING
and CARRAY
plus three versions for X/OPEN compatibility. Applications have the ability to define additional types. An FML
buffer is a fielded buffer in which each field carries its own identifying information. mio
and other BEA TUXEDO client programs use FML
buffers.
Another system client program used by bankapp
is ud
(1). ud
is supplied by the BEA TUXEDO System to allow fielded buffers to be read from standard input and sent to a service. In the sample application, ud
is used by both the populate
and driver
programs. In populate
, a program called gendata
passes service requests to ud
with customer account information to be entered in the bankapp
database; in driver
, the data flow is similar, but the program is gentran
and the purpose is to throw transactions at the application to simulate an active system.
audit.c
is an example of a client program that does not use the BEA TUXEDO DES. It makes branch-wide or bank-wide balance inquiries that call on the services ABAL
, TBAL
, ABAL_BID
and TBAL_BID
. As an executable, it is invoked in one of two ways:
audit [-a | -t]
-a
or -t
must be specified to control whether account balances or teller balances are to be tallied.
audit [-a | -t}
branch_ID
branch_ID
. Option -a
or -t
must be specified to control whether account balances or teller balances are to be tallied.
The algorithm for the program is shown in Listing 3-2.
Listing 3-2 Audit Algorithm
main()
{
Parse command line options with getopt();
Join application with tpinit();
Begin global transaction with tpbegin();
If (branch_id specified) {
Allocate buffer for service requests with tpalloc();
Place branch_id into the aud structure;
Do tpcall() to "ABAL_BID" or "TBAL_BID";
Print balance for branch_id;
Free buffer with tpfree();
}
else /* branch_id not specified */
call subroutine sum_bal();
Commit global transaction with tpcommit();
Leave application with tpterm();
}
sum_bal()
}
Allocate buffer for service requests with tpalloc();
For (each of several representative branch_id's,
one for each site)
Do tpacall() to "ABAL" or "TBAL";
For (each representative branch_id) {
Do tpgetrply() wtith TPGETANY flag set
to retrieve replies;
Add balance to total;
Print total balance;
}
Free buffer with tpfree();
}
Because of space constraints we are not going to print the entire source code of audit.c
, but we want to call your attention to the following sections.
In the program's main():
/* Join application */
/* Start global transaction */
/* Create buffer and set data pointer */
/* Do tpcall */
/* Commit global transaction */
/* Leave application /*
In the subroutine sum_bal:
/* Create buffer and set data pointer */
/* Do tpacall */
/* Do tpgetrplys to retrieve answers to questions */
The indicated sections contain all of the places in audit.c
where BEA TUXEDO ATMI calls are used. Note also that audit.c
is an example of a program that uses a VIEW
typed buffer and a structure that is defined in the aud.h
header file. The source code for the structure can be found in the view description file, aud.v
.
auditcon.c
is the source code for a conversational version of audit.c
. After the client is built, the program is started when a user enters auditcon
.
The algorithm for the program is shown in Listing 3-3.
Listing 3-3 Algorithm for Conversational Audit
main()
{
Join the application
Begin a transaction
Open a connection to conversational service AUDITC
Do until user says to quit: {
Query user for input
Send service request
Receive response
Print response on user's terminal
Prompt for further input
}
Commit transaction
Leave the application
}
The source code for auditcon
uses the ATMI calls for conversational communication: tpconnect()
, to establish the connection between the client and service, tpsend()
, to send a message, and tprecv()
to receive a message.
bankmgr.c
is included with bankapp
as a demonstration of a client that is designed to run constantly. It subscribes to application-defined events of special interest such as the opening of a new account or a withdrawal above $10,000.
DES masks must be compiled before they can be used by mio
. If the mask is created using vuform
(1), the BEA TUXEDO visual form editor, it is automatically converted to binary format (indicated by an .M
suffix). If it is created by editing a file of UFORM statements, the file must be run through the BEA TUXEDO mask compiler, mc
(1), which also creates an .M
file. Masks created with vuform
should be unloaded to ASCII .m
files for backup. This was formerly done with mcdis
(1).
View description files, of which aud.v
is an example, are processed by the view compiler. viewc
(1). viewc
has two output files: a binary view description file, aud.V
, and a header file, aud.h
.
The client programs, audit.c
and audconv.c
are processed by buildclient
(1) to compile them and/or link edit them with the necessary BEA TUXEDO libraries.
You can use any of these commands individually, if you choose, but rules for all these steps are included in bankapp.mk
.
The use of ATMI calls in client programs is covered in the BEA TUXEDO Programmer's Guide.
The creation of masks, the operation of mio
and a tutorial on vuform
are all included in the BEA TUXEDO Data Entry System Guide.
The subject of typed buffers is covered in both the BEA TUXEDO Programmer's Guide and the Administering the BEA TUXEDO System.
All commands and ATMI calls are described in Sections 1 and 3c of the BEA TUXEDO Reference Manual. The bankmgr.c
client is more fully described in the README2
file of bankapp
and in the bankmgr.c
code itself. The Event Broker/Monitor feature, which is what bankmgr.c
demonstrates, is described in Administering the BEA TUXEDO System.