5.4 Things you should understand about the aXes Terminal Server Activities
A LANSA Composer solution that uses the aXes terminal server activities differs from other LANSA Composer solutions in several important ways. It is important that you understand these differences before committing yourself to this type of solution.
For a discussion of the key differences, refer to the following:
The aXes terminal server activities are highly granular
The Processing Sequence requires greater access to application data than a typical BPI solution
The solution may be at risk of unanticipated 5250 application behavior
The solution has limited eligibility for restart in the event of failure
The aXes terminal server activities are highly granular
For any given solution, each of the LANSA Composer aXes terminal server activities will do a relatively small part of the necessary work and your Processing Sequence will need to execute a larger number of activities than would be the case with most other LANSA Composer solutions.
For example, a simple application that navigates to a data entry screen and enters some values might need to execute a sequence of activities along these lines:
1. TS_CONNECT
2. A series of activities including TS_SETBYPOS or TS_SETBYNAME and/or TS_SEND as required to navigate to the data entry screen
3. TS_SETBYPOS or TS_SETBYNAME for each of the values / fields to be filled
4. TS_SEND to send the completed screen to the aXes Terminal Server
5. A further series of activities to navigate to a screen at which the session can be signed off in a controlled fashion
6. TS_DISCONNECT
The effect of this may be reduced to some degree by using aXes terminal operations scripts (as described in 5.6 Using aXes Terminal Operations Scripts). However, this runs against the general rule that your Business Process Integration (BPI) solution should do most of its work in a smaller number of Activities and Transformation Maps in order to optimize performance of the solution.
Therefore you should satisfy yourself that a solution employing the aXes terminal server activities will give you the performance and throughput that meets your requirements.
The Processing Sequence requires greater access to application data than a typical BPI solution
Mostly, Processing Sequence variables hold the variable data that is used to orchestrate the process—for example, paths to transaction documents that are being processed. In the typical BPI solution, most of the transaction content (that is, the application data) is handled by and known only to the Activities and Transformation Maps that act upon it.
However, a LANSA Composer solution that uses the aXes terminal server activities must depart from this model. In such a solution, the Processing Sequence will need access to whatever data is sent to or received from the 5250 application screens.
For example, if your solution is required to fill an order entry screen, then it will need Processing Sequence variables that contain the data items (such as customer number, order date, part numbers and quantities) that must be passed as parameters to the appropriate aXes terminal server activities.
LANSA Composer provides features to facilitate this, but you should understand that this adds steps and consequent complexity and overhead to your solution. For more information refer to:
Saving, Loading and Transforming Processing Sequence Variables
The solution may be at risk of unanticipated 5250 application behavior
Any application that seeks to interact with another application via its 5250 screens (by any means) assumes risks—for example, the 5250 application's screens may change or certain inputs provided may yield results that were not anticipated. These risks may cause unanticipated and unhandled Processing Sequence failures.
You need to understand the extent to which your proposed solution may be affected by such considerations and the degree of exposure that is acceptable to you before committing yourself to this approach.
The solution has limited eligibility for restart in the event of failure
When a LANSA Composer Processing Sequence run ends in error, it is often possible to restart it from the point of failure—once the cause of the failure has been corrected. This is a very powerful feature of LANSA Composer.
However, a LANSA Composer solution using the aXes terminal server activities cannot be restarted if a failure occurs during the aXes terminal server session—that is, before the TS_DISCONNECT activity is executed.
This is because LANSA Composer is unable to return the terminal server session to the state it was in at the point of the failure.
To maximize the benefit of LANSA Composer's restart capability, you should complete your aXes terminal server interactions and execute the TS_DISCONNECT activity at the earliest opportunity. Once all active aXes terminal sessions have been disconnected, normal restart eligibility resumes.