5.4 aXesターミナル・サーバー・アクティビティについて理解しておくべき事
aXesターミナル・サーバーのアクティビティを利用するLANSA Composerのソリューションは、他のLANSA Composerのソリューションと異なる重要な点がいくつかあります。この種のソリューションに最終決定する前に、この違いを理解しておくことが大切です。
重要な相違点に関しては、以下を参照してください。
処理シーケンスは通常のBPIソリューションよりも多いアプリケーション・データへのアクセスが必要
どのソリューションにおいても、LANSA ComposerのaXesターミナル・サーバーのアクティビティは、必要な作業のほんの一部分でしかなく、他の多くのLANSA Composerソリューションの場合と比較すると、処理シーケンスでより多くのアクティビティを実行する必要があります。
例えば、データ入力画面を操作して、いくつかの値を入力する簡単なアプリケーションの場合、次のような一連のアクティビティを実行する必要があります。
1. TS_CONNECT
2. 必要に応じて、データ入力画面を操作するためのTS_SETBYPOS、TS_SETBYNAMEやTS_SENDなどの一連のアクティビティ
3. それぞれの値、フィールドを埋めるためのTS_SETBYPOSやTS_SETBYNAME
4. 完成した画面をaXesターミナル・サーバーに送信するためのTS_SEND
5. セッションを順を追ってサインオフするまでの画面を操作するための一連のアクティビティ
6. TS_DISCONNECT
aXesターミナルのオペレーション・スクリプトを使用することで、この影響をある程度少なくすることは可能です。(詳細は、「aXesターミナル・オペレーション・スクリプトを利用する」を参照)。ただしこの方法は、ビジネス・プロセス統合(BPI)のソリューションはパフォーマンスを最適化するためにできるだけ少ないアクティビティと変換マップを使用する、という一般的な原理に反してしまいます。
ですから、ユーザーはaXesターミナル・サーバーのアクティビティを使用するソリューションのパフォーマンスとスループットを自身の条件に合わせて納得のいくものにする必要があります。
処理シーケンスは通常のBPIソリューションよりも多いアプリケーション・データへのアクセスが必要
多くの場合、処理シーケンス変数は使用された変数データを保持し、処理を結合するために使用されます。例えば、処理されたトランザクション・ドキュメントのパスなどです。典型的なBPIソリューションでは、トランザクションの内容(つまり、アプリケーション・データ)はアクティビティとその内容に作用する変換マップによって処理され、その内部でのみ認識されます。
しかし、aXesターミナル・サーバーのアクティビティを利用するLANSA Composerのソリューションでは、この規範から外れています。このソリューションの場合、処理シーケンスは5250アプリケーション画面で受信または送信されたデータにアクセスする必要があります。
例えば、ユーザーのソリューションが注文入力画面を入力する必要がある場合、そのデータ項目(例えば顧客番号、受注日、部品番号や量など)を含む処理シーケンス変数が適切なaXesターミナル・サーバーのアクティビティにパラメータとして引き渡されなければなりません。
LANSA Composerには、この作業を支援する機能が用意されています。しかしこの方法を利用する際は、追加作業が含まれ、その結果ユーザーのソリューションがより複雑になり、余分なオーバーヘッドも加わることを理解しておいてください。詳細については、以下を参照してください。
5250画面経由で別のアプリケーションとのやりとりを行うアプリケーションには（どのような方法であれ）リスクはつきものです。例えば、5250アプリケーションの画面が変更になったり、提供されたある入力が期待外れの結果である場合もあるでしょう。このリスクにより、予期せぬ対応不可能な処理シーケンスのエラーにつながる場合もあります。
ですので、最終決定する前に、自身のソリューションがどの程度こういった考慮事項に影響を受けるのか、許容範囲はどのくらいなのかを見極めておく必要があります。
LANSA Composerの処理シーケンスの実行がエラーで終了した場合、いったんこのエラーが修正されると、通常はエラーの場所からの再実行が可能です。これは、LANSA Composerの非常に優れた機能です。
しかし、aXesターミナル・サーバーのアクティビティを使用するLANSA Composerのソリューションでは、aXesターミナル・サーバー・セッション時、つまり、TS_DISCONNECTが実行される前の時点で、エラーが起きても、再実行はできません。
これは、LANSA Composerはエラーの時点での状態のターミナル・サーバー・セッションに戻ることができないからです。
LANSA Composerの再実行機能の利点を最大限に活用するには、できるだけ早い時点でaXesターミナル・サーバーとのやりとりを完了させ、TS_DISCONNECTアクティビティを実行することです。いったん全てのアクティブなaXesターミナル・セッションとの接続が切断されると、通常の再実行機能が可能になります。