[Top] [Prev] [Next] [Bottom]

3. bankapp Client Programs


A Look at bankapp Client Programs

This chapter is devoted to the client side of the bankapp sample application.

In the client-server architecture of BEA TUXEDO there are two modes of communication:

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. 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

One form of client access to 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).

Figure 3-1 shows the hierarchy of masks for 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

Taking one of the shorter masks for illustration, in Listing 3-1 we show how the source code of a mask looks in the 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.

Once a mask has been created, it is converted into binary form and is used under the control of 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"

Using mio(1)

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.

Buffer Types

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.

Using ud(1)

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: A Request/Response Client

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]
Prints the bank-wide total value of all accounts, or bank-wide cash supply of all tellers. Option -a or -t must be specified to control whether account balances or teller balances are to be tallied.

audit [-a | -t} branch_ID
Prints branch-wide total value of all accounts, or branch-wide cash supply of all tellers, for branch denoted by 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();
}

audit.c Source Code

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: A Conversational Client

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
}

auditcon.c Source Code

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: A Client that Monitors Events

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.

Building Client Programs

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.

References

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.



[Top] [Prev] [Next] [Bottom]