Skip to main content

This documentation is for an older version of this product. See the latest version of this content.Opens in a new tab

アプリケーション・アクセスの構成

このページでは、InterSystems IRIS® Web ゲートウェイの接続先アプリケーションを構成する方法について説明します。このような構成タスクでは、Web ゲートウェイの管理ページを使用します。既定の設定およびサーバの構成方法については、別の項目で説明します。

Web アプリケーションごとに、CSP ファイルへのパスを構成する必要があります。各パスの構成によって、アプリケーションの実行を扱う InterSystems IRIS サーバが識別されます。フェイルオーバーや負荷分散を指定するオプションの指示文を、アプリケーション・パスの構成で指定します。既定のアプリケーション・パス、root (/) は、Web ゲートウェイを初めて起動するときに自動的に構成されます。継承がアプリケーション・パスに適用されます。例えば、CSP 要求が /Accounts/Invoices 内のファイルを要求したとき、/Accounts/Invoices の構成が存在しない場合、Web ゲートウェイは /Accounts に定義された構成を使用します。これが定義されていない場合は、既定のパスである / に対する構成が使用されます。

アプリケーション・パスの追加

アプリケーションへのパスを構成するには、以下の手順を実行します。

  1. Web ゲートウェイ管理ページのメイン・メニューで、[アプリケーションアクセス] を選択します。

  2. [アプリケーション追加] を選択します。多くのパラメータには既定の設定が入力されています。

  3. [アプリケーションパス] テキスト・ボックスに、アプリケーションの一意のパスを入力します。このパスは、アプリケーションの URL に表示されるパスです。

    Note:

    InterSystems IRIS インストールにより、新しい /csp 構成が作成されます。/csp をアプリケーションとして構成した場合、InterSystems IRIS の新しいビルドをインストールすると、その構成は上書きされます。アプリケーション構成を維持するには、/csp 以外のパスを入力します。

    /csp/myapplication のように /csp にあるディレクトリであればどれでもかまいませんが、パスの指定にドット (ピリオド) は使用できません。これにより Web ゲートウェイであいまいさが発生するためです。/csp/samples/menu.csp/csp/aaa/bbb/ccc.cls を例として考えると、Web ゲートウェイでは、これを /csp/samples/menu.csp/csp/aaa/bbb/ccc.cls への要求とも、/csp/samples/menu.csp への REST 要求 (この場合、PATH_INFO は /csp/aaa/bbb/ccc.cls) とも解釈できます。Web サーバ環境で動作している Web ゲートウェイには、このようなあいまいさを解決する手段がありません。

    CSP は、大文字と小文字を区別します。CSP を構成している場合、整合性を確保しながらパス名を指定してください。

  4. このアプリケーションで使用されるもう 1 つの構成パスとサーバ・パラメータ (下の表を参照) を入力します。

  5. 入力を終えたら、[設定を保存] を選択します。アプリケーション構成に加える変更は、そのアプリケーション・パスに対して新しいユーザ・セッションが作成されると有効になります。既存のユーザへの影響はありません。

アプリケーション・パスの構成パラメータ

基本パラメータは以下のとおりです。

パラメータ 機能
[サービス状態] アプリケーションのパスを使用して、アプリケーションへのアクセスを有効および無効にします (既定は [有効])。
[ウェブサーバ物理パス] Web サーバ上の対応するディレクトリのパスです。この設定は、構成した各パスを、Web サーバ構成の仮想ディレクトリとして設定する必要がある Microsoft IIS システムでは特に重要です。IIS 内で定義される各仮想ディレクトリに、物理パスを関連付ける必要があります。IIS 用のこの追加構成手順の目的は、InterSystems IRIS (特に CSP エンジン) によって使用されるパスが、実行許可で定義できるようにすることです。既定では、実行が拒否される (CSP エンジンにアクセスする) ようになっています。
[追加のCGI環境変数] 要求が行われるたびに InterSystems IRIS 環境に返される、追加の CGI 環境変数のコンマ区切りリストです。共通で使用される CGI 環境変数は、要求が行われるたびに自動的に送信されます。ワイルドカード文字 (*) を入力すると、要求があるたびに、Web サーバから提供されるすべての環境変数が Web ゲートウェイから InterSystems IRIS サーバに送信されるようになります。
[このクラスで処理する] 指定したクラスでこのパス内のファイルを処理します。これにより、専用の要求ハンドラを CSP に構築できます。
[GZIP圧縮] このパスで返されるすべての CSP ページの GZIP 圧縮を有効または無効にします (既定は [無効])。
[GZIP 最小ファイル・サイズ] GZIP 圧縮が呼び出される最小応答サイズ。単位はバイトです。既定は 500 バイトです。
[GZIP 除外ファイルの種類]

GZIP 圧縮の除外対象とするファイルの種類のリストです。 除外対象とするファイルは、MIME タイプ (image/jpeg など) または一般的な拡張子 (jpeg など) を使用してリストできます。

既定では、これらの一般的な (標準で圧縮されている) イメージ・ファイルは除外されます。GZIP Exclude File Types: jpeg gif ico png gz zip mp3 mp4 tiff

追加の種類または拡張子をスペースで区切ります。

[応答サイズの通知]

このパラメータでは、それぞれの応答に含まれるデータの量をクライアントに通知するときに Web ゲートウェイで使用されるメソッドの制御を構成できます。

HTTP キープアライブ接続が使用されている場合、通常、Web クライアントには応答サイズを通知する何らかのフォームが必要になります。このような状況では、HTTP v1.1 が使用されている場合、Web ゲートウェイは既定でチャンク転送エンコーディングを使用します。 これよりも前の HTTP プロトコルが使用されている場合は、InterSystems IRIS からの応答データはバッファされ、代わりに Content-Length ヘッダが生成されます。 また、全体の応答が 1 つの出力バッファに収まる場合には、チャンク転送を使用する代わりに Content-Length ヘッダが生成されます。

どちらのメソッドを使用するかを具体的に Web ゲートウェイに指示する方が望ましい場合もあります。 例えば、HTTP v1.1 が使用されているにもかかわらず、媒体 (プロキシなど) がチャンク転送を適切にサポートできない場合です。 また、すべての Web クライアントで、いずれのフォームのサイズ通知も送信しない (応答のターミネータとして 接続の切断 イベントが使用される場合など) ようにできる必要がありますが、適切な方法としては、すべての応答に何らかのフォームのサイズ通知を付随させることをお勧めします。 実際に、一部のクライアントにはこの方法が必要になります。

以下のオプションが用意されています。

  • チャンク転送エンコーディングと Content-Length (既定)

  • チャンク転送エンコーディング

  • Content-Length

このパラメータには、キープアライブを使用するかどうかにかかわらず、常にすべての要求に対してサイズ通知を生成するよう Web ゲートウェイに指示するためのチェック・ボックスが用意されています。

チャンク応答とは異なり、Content-Length ヘッダを指定する HTTP 応答のサイズには 500 キロバイトの制限があります。この制限を超えると、CSP のログに警告メッセージが表示されます。

WARNING: Unable to generate a 'Content-Length' header directive for this oversize response (Current size: size; Maximum buffer size allowed: 500000)

[キープアライブ] このパスの HTTP [キープアライブ] 接続を有効または無効にします。既定値は [アクションなし] です。この場合、[キープアライブ] ステータスは、各要求の HTTP 応答ヘッダにより決定されます。
[非解析ヘッダ] このパスの [非解析ヘッダ] プロトコルを有効または無効にします。既定値は [有効] です。この場合、HTTP 応答ヘッダはクライアントに直接返送されます。このプロパティが無効化されている場合、応答ヘッダはホスト Web サーバに返送されます。これにより、ヘッダを解析し、指定されている出力フィルタがあれば、それを呼び出す機会が Web サーバに与えられます(例 : Apache グループの mod_deflate 機能)。Apache Web サーバでキープ・アライブが有効になっている場合、非解析ヘッダの設定に関係なく、応答ヘッダは Apache に返送されます。

サーバ・パラメータ

アプリケーションに対して使用する InterSystems IRIS サーバと、それらの使用目的のリストを定義できます。

パラメータ 機能
代替サーバの使用目的

リストされている最初のサーバ [サーバ 0] は、既定の InterSystems IRIS サーバです。これが最初に使用されます。リストされている他のサーバは、チェックが付いているオプションに応じて、負荷分散またはフェイルオーバーに使用できます。

  • フェイルオーバー : 最初のサーバに障害が発生した (使用不能になった) 場合に、代替を使用します。

  • 負荷分散とフェイルオーバー :最初のサーバで障害が発生した場合、フェイルオーバーまたは負荷分散のいずれかとして構成されているサーバを使用します。

サーバの数 : サーバのリスト。構成画面には、最初は 3 つのサーバ・スロットのみが表示されていますが、追加のスロットが表示され、任意の数の代替サーバを定義できます。各サーバに [有効] または [無効] としてチェックを付けることができます。既定値は常に [有効] です。詳細は、複数の InterSystems IRIS サーバ・インスタンス間の負荷分散とフェイルオーバーを参照してください。

アプリケーション・パス構成のコピー

新しいアプリケーション・パスを簡単に構成するには、既存のパスの構成エントリをコピーして編集します。

Tip:

この機能は、構成を適切に調整する場合にも有用です。アプリケーション・パスの一時的な構成を別に作成することにより、元の構成を失うことなくパラメータの変更をテストできます。

既存のアプリケーション・パス構成をコピーするには、以下の手順を実行します。

  1. Web ゲートウェイ管理ページのメイン・メニューから、[アプリケーションアクセス] を選択します。

  2. [アプリケーションアクセス] の画面で、既存のアプリケーション・パスを選択します。

  3. [アプリケーションコピー] を選択します。

  4. [実行] を選択します。

  5. [アプリケーションパス] テキスト・ボックスに、新しい一意のアプリケーション・パスを入力します。

  6. [設定を保存] を選択します。新しいアプリケーション構成は、新しいユーザ・セッションが新しいアプリケーション・パスに対して作成されると有効になります。既存のユーザへの影響はありません。

アプリケーション・パスによるアクセスの無効化

この機能を使用すると、ユーザは構成したアプリケーションにこの Web ゲートウェイを介してアクセスできなくなります。

アプリケーション・パスを介したアクセスを無効にするには、以下の手順を実行します。

  1. Web ゲートウェイ管理ページのメイン・メニューから、[アプリケーションアクセス] を選択します。

  2. [アプリケーションアクセス] の画面で、アプリケーション・パスを選択します。

  3. [アプリケーション編集] を選択します。

  4. [実行] を選択します。アプリケーション・パスの構成画面が表示されます。

  5. [サービス状態] パラメータで、[無効] を選択します。

  6. [設定を保存] を選択します。

アクセスを再度有効にするには、上記の手順を繰り返して、手順 5 で [有効] を選択します。

アプリケーション・パス構成の削除

構成したアプリケーション・パスを削除するには、以下の手順を実行します。

  1. Web ゲートウェイ管理ページのメイン・メニューから、[アプリケーションアクセス] を選択します。

  2. [アプリケーションアクセス] の画面で、アプリケーション・パスを選択します。

  3. [アプリケーション削除] オプションを選択します。

  4. [実行] を選択します。

  5. Web サーバを再起動して、すべてのアプリケーションを強制的に再起動します。

FeedbackOpens in a new tab