LANSA Composerリクエスト・サーバーで処理される要求
LANSA Composerリクエスト・サーバーを通じて処理される要求に関しては、理解しておくべき重要事項があります。 この中にはLANSA Composerリクエスト・サーバーを使用したソリューションを設計する上で大きな影響を与える可能性があるものも含まれます。
1. ファンクション"呼び出し"が別の処理やジョブ内、または異なるコンピュータで行われる
通常はあるLANSAシステムや区画で実行されているLANSAアプリケーションが、別のLANSAシステムや区画で実行されているLANSAファンクションを直接呼び出すことはできません。 この機能を実現させるため、LANSA Composerリクエスト・サーバーは別の処理またはジョブあるいは別のサーバー・システムに要求を送り、要求そして必要に応じてそのジョブの応答データを交換します。
多くの場合、要求側のアプリケーションにとってこの処理は透過的です。 ユーザーのアプリケーション設計にもよりますが、機能的には何の影響も与えません。 しかし、ファンクション呼び出しの実行状況が想定と異なる場合も考えられます。
この点を理解しておくことが基本となります。このセクションの残りの部分は主にこれに関して起こりうる結果についての説明です。
2. IBM i サーバーでは、ファンクションの"呼び出し"はリクエスト・サーバー・ジョブのユーザー認証情報を使用して実行される
IBM i のLANSA Compopserリクエスト・サーバーは、要求を行うリクエスト・サーバー・ジョブとユーザー認証情報を交換せず、ユーザーの状況を変更しません。 リクエスト・サーバー・ジョブ内で実行される要求はリクエスト・サーバー・ジョブのユーザー認証情報を使って実行されます。 必要であれば、異なったユーザー・プロファイルを使用するように、リクエスト・サーバー・ジョブの開始方法を変更することができます。 詳細は「ユーザーの状況に合わせたIBM i のLANSA Composerリクエスト・サーバーの構成」を参照してください。
3. ファンクション"呼び出し"は、リクエスト・サーバー・ジョブの実行環境で起こる
要求は別の処理やジョブ内で実行されるので、その要求は、要求が行われたジョブではなく、リクエスト・サーバー・ジョブの実行環境に依存します。 特にIBM i サーバー上では、以下の通り（これでけではありませんが）ジョブ属性の範囲に非常に重要な意味があります。
- 要求側のジョブのファイル上書きはこの要求には適用されません。
- 要求側のジョブのオープンのデータパスはこの要求と共用されません。
- 要求側のジョブのQTEMPライブラリの内容はこの要求では入手できません。
- この要求は、（要求側のジョブではなく）リクエスト・サーバー・ジョブのライブラリ・リストを使用して実行されます。
4. リクエスト・サーバー・ジョブの実行環境は１つの呼び出しから別の呼び出しへと継続されない
ユーザーの要求を処理したリクエスト・サーバー・ジョブの実行環境が１つの呼び出しから別の呼び出しへと継続されると仮定することはできません。 例えば、あるIBM i サーバー上で呼び出されたLANSAファンクションが、QTEMP内でライブラリ・リストを変更したり、オブジェクトを作成した場合、次に呼び出したファンクションでもその変更がまだ有効との想定でソリューションを設計することはできません。 これには主に、次のような2つの理由があります。
- 同じ処理またはジョブではない可能性があります。
Windowsサーバーでは、LANSAリクエスト・サーバーから送られるすべての要求は新しい処理内で実行されます。
IBM i サーバーでは、与えられた仕事量を処理するために複数のリスエスト・サーバー・ジョブがアクティブな状態で特定のLANSAシステムの要求を処理している場合があります。 例えば、LANSA Composerの処理シーケンス内の連続するCALL_FUNCTIONアクティビティの要求が同じジョブ内で実行されるという保証はありません。
- それぞれのリクエスト・サーバー・ジョブは要求の合間にその状態を初期化します。
IBM i サーバーでは、要求ごとのLANSA実行環境の状態のインテグリティを確実にするため、リクエスト・サーバー・ジョブは要求ごとに再初期化を行います。