|
|
BEA Tuxedo is a fundamental component of the BEA WebLogic Enterprise Platform for enabling transactions between front-end applications and back-office processes. BEA Tuxedo can be used as a workstation and a server. The service/server must be started before using the workstation/client.
 |
Before BEA Tuxedo can be used, it must be properly configured. See Configuring BEA Tuxedo as a Server. |
You can start and stop Tuxedo normally. For example, tmboot -y should start Tuxedo and load the Attachmate DemoService, and tmshutdown -y should stop Tuxedo and all services.
To be robust your application should check for exceptions on a number of the e-Vantage SDK class methods. A number of error conditions (timeouts, protected fields, not enough space, input inhibited, etc.) are thrown from the class methods as exceptions. The example only partially handles these error conditions. You will have to determine which are important for your environment. Illogical calling sequences (like opening the same Webview consecutive times without a close) also may cause exceptions to be thrown.
The Open and Close methods are used to open and close a presentation space session (for example, a Webview). In this example the predefined Webview was opened during service initialization. So you should close it before exiting. In a different architecture, you might want to open and close sessions at other times.
When your application is finished using the e-Vantage SDK, such as when you exit your the service, you can release the evSDK resources it is using by calling the "ReleaseDispatch" method for each of the classes you are using (SessionLoader and ScreenUts, in this example, via the sldisp and utsdisp global variables).
C:\Program Files\Attachmate\evSDK\Samples\Tuxedo
|
The sample code is provided for example only, and it may need to be modified to work in your environment. It is provided "as is," without warranty of any kind, or support from Attachmate Corporation. |
The tpsvrinit procedure contains the global initialization of the service. The calls necessary to initialize and load the e-Vantage SDK are: CoInitialize, CLSIDFromProgID, CoCreateInstance. This sets the global variable sldisp, which is used to access the SessionLoader class. The sample service then opens a predefined WebView UTSView with the requestScreen call. This sets the global variable utsdisp, which is used to access the ScreenUts class. Lastly, the Open method is called in the ScreenUts class. Once these steps are completed you can access the WebView fully with the ScreenUts methods.
|
The UTSView WebView is assumed to able to auto-connect to your mainframe. |
Depending on your application requirements, you may want to open a number of WebViews (individual connections to the mainframe computer) during service initialization or you may wish to open the WebViews at a later time.
|
The WebViews referred to here are the same WebViews that you can open from the Host Access Server Management Console. You could move the e-Vantage SDK initialization calls (CoInitialize, CLSIDFromProgID, and CoCreateInstance) to another part of the service, but they must be performed before you can access the various e-Vantage SDK classes. |
The DEMOSERVICE procedure is the only entry point that workstations can access in this example. A fielded buffer (Tuxedo Data Storage Structure) is used to receive data from the workstation, and return results back to it. The ATM_DataIn field contains the data entered at the workstation that is intended for the host. The input data is extracted from the fielded buffer with the Tuxedo Fvals32 function. The GetHostData procedure will do the actual communications work with the e-Vantage SDK. Once the host response is received, it is placed in the ATM_Screen field, and returned to the workstation.
|
FML/fielded buffers is a BEA Tuxedo mechanism of passing data between cooperating processes. The ATM_FML.h file was generated by using the Tuxedo mkfldhdr32 utility (type mkfldhdr32 ATM_FML). |
It is not necessary to use a fielded buffer to exchange data with the workstation. It is also not necessary to use the Tuxedo tpcall function (which synchronously waits for a reply). So you might choose to implement a conversational client and server, or provide multiple entry points.
The assumption made in this example is that the workstation will always access the preopened Webview. You may want to pass in information from the workstation in order to select a particular communications session. Alternatively, you might want to open a series of sessions at startup, logon each to the host, and then pick any available session when a workstation passes in data.
The GetHostData procedure comes in two forms, one to take a screen capture, and other to capture raw host data. Just choose the appropriate procedure (see the TuxDemoSDK.cpp source file for details), depending on which type of data you would prefer to work with. In either case, the user input is entered into the WebView as keystrokes, with the sendKeys method, and then transmitted to the Host System (with a second sendKeys call). Then it waits for the host response, which is determined by waiting for a predefined period without receiving more host data (with the waitHostQuiet method). To retrieve what is received, either getText or getCapturedData is called. The getText method will get the contents of the presentation space (24x80 screen). The getCapturedData method will get the currently captured data. The procedure then returns this data to the DEMOSERVICE routine, which passes the data back to the workstation via a Tuxedo tpreturn function (the data is first placed into the fielded buffer with the Tuxedo FChg32 function).
Additional Information can be found in the BEA Tuxedo Reference Manual.
 |
|
 |
Using the Airlines SDK with BEA Tuxedo as a Workstation |
|
Development Tools Supported |
 |
Sample Applications Overview |
 |