Web ゲートウェイの構成の基本

Web ゲートウェイと連携するように Web サーバを構成したら、必要に応じて Web ゲートウェイを構成します。管理ページを使用して、既定のパラメータ、個々のサーバ、および Web アプリケーションを構成できます。

ここでは、いくつかの一般的な構成トピックに関する追加情報を提供します。

Web ゲートウェイの構成ファイルとログ・ファイル

Web ゲートウェイでは、それぞれ CSP.ini、CSP.log という名前の構成ファイルとログ・ファイルを作成し、使用します。便宜のため、管理ページに、これらのファイルの場所が示されています。

Tip:

通常は管理ページを介して構成を行うため、構成ファイルを直接編集する必要はほとんどありません。ドキュメントでは、必要に応じてその構成内の指示文について説明します。直接構成ファイルを編集する必要がある場合は、%CSP.Mgr.GatewayMgrOpens in a new tab のクラス・リファレンスを参照してください。メソッド SetApplicationParams、SetDefaultParms、および SetServerParams には、パラメータの簡単な説明が示されています。

自動的に InterSystems IRIS にルーティングされるファイル・タイプ

インターシステムズのファイル・タイプは、InterSystems IRIS で (特に、CSP エンジンによって) 処理されます。その他のファイル (静的ファイル) はすべて Web サーバまたは CSP エンジンによって処理されます。CSP エンジンは Web アプリケーションのパスに配置されているあらゆる種類のファイルを処理できます (静的ファイルを含む)。静的ファイルを処理するための CSP エンジンの設定により、アプリケーションの静的ファイルが存在する場所を表すために Web サーバ構成にエイリアスを作成する必要がなくなるので、Web アプリケーションの Web サーバ構成はより単純化されます。静的ファイルを提供するように CSP エンジンを設定することで、単一 (共通) の Web サーバで 2 つの異なるバージョンの InterSystems IRIS を提供する場合に、それぞれで異なるバージョンの特定の静的ファイル (例えば、ハイパーイベントのブローカ・コンポーネント) を必要とするといった競合上の問題を解決できます。

特定の Web アプリケーションの静的ファイルを CSP エンジンで処理するには、静的ファイルを (Web サーバ独自のドキュメント・ファイル・システムではなく) Web アプリケーションのファイル・システム内の、アプリケーションを構成する CSP ファイルに関する適正位置に配置します。

Note:

Zen をベースとしたアプリケーションを実行するには、[ファイルの提供] オプションを有効にし、Web サーバを適切に構成することが必要です。

InterSystems IRIS からの静的ファイルの提供

InterSystems IRIS が静的ファイルを提供できるように Web サーバおよび Web ゲートウェイのインストールを構成できます。InterSystems IRIS がすべてのコンポーネントをアプリケーションに提供するように、管理ポータルが構成されています。ただし、Web サーバが静的ファイルを処理する役割を保持するように Web サーバを構成することも可能です。

InterSystems IRIS データベース・サーバはすべての CSP を処理します。また、Web ゲートウェイ経由で、Web アプリケーションにあらゆる種類の静的ファイルを処理することもできます。標準の Web アプリケーションでは、通常、Web サーバ (データベース・サーバではない) が静的コンテンツを処理します。

文字エンコードの指定

CSP エンジンは、ストリーム・サーバを介して、JavaScript ファイルの文字エンコードの決定に関して、主要な Web サーバと同じ方法で静的ファイルを処理します。最近の慣例では、すべての JavaScript ファイルが application/javascript の Content-Type としてマークされるため、ページで使用されるすべての JavaScript がこのとおりであることを確認してください。

JavaScript ファイルがこのようにマークされている場合、

ファイルに BOM (バイト・オーダー・マーク) が含まれていれば、これをブラウザが自動的に検出し、適切な文字セットを利用してこれを読み取ります。
ファイルに BOM が含まれていなければ、ブラウザはこのファイルを UTF-8 と見なします。

この動作をオーバーライドして、JavaScript ファイルに文字セットを指定する必要がある場合は、グローバル ^%SYS("CSP","MimeFileClassify","JS") をリスト値 $listbuild(contenttype, binary, charset) に設定します。以下に例を示します。

SET ^%SYS("CSP", "MimeFileClassify", "JS") = $listbuild("text/javascript", 0 ,"ISO-8859-1")

これにより、古い Content-Type が設定され、ISO-8859-1 文字セットが使用されます。また、Caché 変換テーブルが空の文字列以外に定義されている場合、またはグローバル・ノード ^%SYS("CSP","DefaultFileCharset") が NULL 値に設定されている場合、Caché はすべての JavaScript およびその他のテキスト・ファイルにこの文字セットを使用します。既定では、これらのグローバル・ノードはどちらも設定されていません。

[静的ファイルの提供] オプションの有効化

Web アプリケーションの [静的ファイルの提供] オプションには、以下の値を指定できます。

常に — [静的ファイルの提供] はオンです。
いいえ — [静的ファイルの提供] はオフです。
常時かつキャッシュ — Web ゲートウェイは Web サーバ上で静的ファイルをキャッシュできます。この設定を使用すると、システムは InterSystems IRIS サーバに戻ることなく、キャッシュされた静的ページを提供できるため、効率が向上します。
インターシステムズのセキュリティを使用 — InterSystems IRIS インスタンスが Web アプリケーションの一部として機能する動的な .csp または .cls ページにアクセスするための適切な承認をユーザが持っている場合、そのインスタンスの CSP エンジンは、その Web アプリケーションの場所にある静的ファイルに対する要求を処理します。ユーザに適切な承認がない場合、CSP サーバは HTTP 404 応答を返します。

InterSystems IRIS が静的ファイルを処理できるようにするための Web サーバの構成

既定では、インターシステムズが提供するインストール・スクリプトは、外部 Web サーバを検索または構成しません。カスタム・インストールを実行する場合は、以前にインストールされた IIS または Apache Web サーバを構成して CSP エンジンのサポートを有効にするオプションを選択できます。インストール・スクリプトは、/csp 仮想ディレクトリを作成して、Web ゲートウェイによって処理されるインターシステムズのファイル・タイプのマッピングを作成します。CSP エンジンがその Web サーバを使用して正常に機能するには、これで十分です。[静的ファイルの提供] 機能のサポートは有効になりません。Web サーバを手動で構成して、Web ゲートウェイで処理される特定のファイル拡張子をマップする必要があります。このように設計されている理由は、このメカニズムによってデータベース・サーバを開いて公開するのはセキュリティ上のリスクであり、バックグラウンドで実行されてはならないからです。

Web サーバの手順については、"追加ファイル・タイプのマッピング" を参照してください

Web サーバからの静的ファイルの処理

Web サーバから静的ページを提供する従来の構成を使用できます。この場合、 [静的ファイル] オプションの設定は関係ありません。これにより、共通の Web サーバで 2 つの異なるバージョンの InterSystems IRIS を提供する場合に、それぞれが異なるバージョンの特定の静的ファイル (例えば、ハイパーイベントのブローカ・コンポーネント) を必要とするといった競合上の問題を解決できます。

Web サーバ自体で静的ファイルを提供するように構成する場合は、その静的コンテンツがすべての Web サーバに存在するようにしてください。

高可用性ソリューションのハードウェア・ロード・バランサでのスティッキー・セッションの有効化

CSP 上で実行している高可用性ソリューションについては、ハードウェア・ロード・バランサを使用して負荷分散とフェイルオーバーを行うことをお勧めします。この場合のロード・バランサでは、スティッキー・セッションのサポートを有効にする必要があります。これにより、Web ゲートウェイの指定したインスタンスと指定のアプリケーション・サーバとの間でセッションを確立しておけば、そのユーザがそれ以降に発行するすべての要求は、必ず同じインスタンスとサーバの組み合わせで処理されるようになります。この構成では、セッション ID とサーバ側のセッション・コンテキストが常に同期していることが保証されます。この構成を使用しない場合は、セッションがあるサーバ上で生成されたにもかかわらず、そのユーザからの次の要求はこのセッションが存在しない別のシステムで処理される可能性があり、その結果として実行時エラーが発生します (特に、要求を復号化するためにセッション・キーを必要とするハイパーイベントを使用している場合)。スティッキー・セッションのサポートを有効にする方法については、使用しているロード・バランサのドキュメントを参照してください。

Note:

スティッキー・セッションを使用しなくてもシステムが動作するように構成することは可能ですが、そのためには、Web セッション・グローバルを企業内のすべてのシステムにわたってマップする必要があります。その結果、重大なロック競合が発生する可能性があるので、このような構成はお勧めできません。

Web ゲートウェイ構成を再起動するスクリプトの有効化

InterSystems IRIS の外部にあるスクリプトを有効にして、Web ゲートウェイの構成を再起動することができます。

スクリプトでは、Web ゲートウェイの構成ファイルの SYSTEM セクションに次の行 (大文字と小文字が区別される) を追加する必要があります。

   [SYSTEM]
   RELOAD=1

Web ゲートウェイ・ケアテイカー・デーモンは、ほぼ 1 分おきに RELOAD フラグを確認し、正しく設定されていれば、その構成を再ロードおよび再起動して、ファイルからフラグを削除します。再ロード操作が成功すると、以下のメッセージが Web ゲートウェイ・イベント・ログに書き込まれます。

   Gateway Management
   Gateway Configuration Reloaded and Reactivated

マルチプロセス/マルチスレッドのハイブリッド型 Web サーバ・アーキテクチャ

Web ゲートウェイには、マルチプロセス/マルチスレッドのハイブリッド型 Web サーバ・アーキテクチャの拡張サポートが含まれています。 UNIX® の Apache バージョン 2.4 は、このアーキテクチャに従って実装された Web サーバの例です。

コア Web ゲートウェイ・リソースは、共有メモリ・セクタに保持されるようになりました。すべての Web サーバのワーカ・プロセスは、共通の実行中構成、接続テーブルおよびフォーム・キャッシュを共有します。 Web ゲートウェイ・システム・ステータス・フォームには、単一のワーカ・プロセスのステータスのみではなく、Web サーバのインストール全体のステータスが表示されます。ステータス・フォームの接続テーブルには、InterSystems IRIS への各接続に対応する Web サーバ・プロセス ID を含む追加の列が含まれます。

最後に、ステート認識セッションはマルチプロセス・アーキテクチャでサポートされます。(InterSystems IRIS への) 接続プールはいくつかの Web サーバ・プロセス間で配布されますが、Web ゲートウェイは IPC (InterProcess Communications) プロトコルを使用して、ステート認識セッションの要求を Web サーバ環境の正しいホスティング・プロセスにルーティングします。

Web ゲートウェイ管理ページの概要

Nginx の構築と構成 (UNIX®/Linux/macOS)