5.3 aXesターミナルサーバー・アクティビティをどのような場合に使用するのか
LANSA Composerと既存のIBM i アプリケーションを統合する場合、一般的には次の両方、またはいずれかが直接統合されていることが望ましい方法です。
- 変換マップを使用しているアプリケーション・データベース
- CALL_3GL、CALL_FUNCTIONまたはCALL_JAVA を利用するアプリケーション、または作成したカスタム・アクティビティにより提供される、アプリケーション・プログラム・インターフェイス
通常、この方法が最も回復力があり、パフォーマンスも良いソリューションで、同時に管理も簡単な方法です。
ただし、このような統合ができない場合もあるでしょう。例えば、必要なドメイン知識が入手できない、または技術的に不可能な以下のような場合です。
- 変換マップを使用しているアプリケーション・データベースに直接アクセスできない。
- アプリケーションのプログラム・インターフェイスが利用できない、またはそのようなインターフェイスが存在しない。
このような状況の場合、それまでは不可能だったアプリケーションとの統合が、5250画面が操作できるという機能により可能になりました。このような場合、LANSA ComposerのaXesターミナル・サーバーのアクティビティでソリューションを提供できます。
LANSA ComposerのaXesターミナル・サーバーのアクティビティを利用したソリューションは次のような場合に適しています。
- (上記に示されている)推奨の統合方法が不可能である。
- このソリューションでは、5250とのやりとりは比較的限定されます。
- このソリューションでは、パファーマンスや管理面への過度な負荷もなしに、ある程度の量の個別のデータ項目(5250画面から受信、または送信されたもの)を、LANSA Composerの処理シーケンス変数プールから、また変数プールへと伝送できます。
- 5250とのやりとりのパフォーマンスはソリューション全体にとって重要なことではありません。
自身のソリューションがこの条件に合うかどうか不明な場合、考慮に値する代替方法もあります。この方法は、aXesターミナル・サーバーとLANSA Composerの両方に恩恵をもたらすと同時に、複雑な処理がより少なくなります。ただし、プログラムのコーディングが必要となります。
例えば、LANSA Integratorの aXesTerminalServiceを使用するカスタムのアクティビティ、もしくはファンクションをコーディングし、あるトランザクションに関係する全ての5250のやりとりを、1回で完成させます。そして、このカスタム・アクティビティ、もしくはファンクションをLANSA Composerの処理に挿入し、必要に応じて関連する伝送、変換やその他のアクティビティや命令とともに使用します。
更に効果的で直接的なソリューションとしては、aXes APIに直接コーディングするという方法もあります。