Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

For a discussion of the key differences, refer to the following:

Anchor
The aXes terminal server activities are highly granular
The aXes terminal server activities are highly granular
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 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.

Anchor
The Processing Sequence requires greater access to application data than a typical BPI solution
The Processing Sequence requires greater access to application data than a typical BPI solution
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.

...

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:

Anchor
The solution may be at risk of unanticipated 5250 application behavior
The solution may be at risk of unanticipated 5250 application behavior
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.

Anchor
The solution has limited eligibility for restart in the event of failure
The solution has limited eligibility for restart in the event of failure
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.

...