はじめに
PEX フレームワークを使用して外部言語コンポーネントを相互運用プロダクションに組み込む処理は、以下の手順で構成されます。
-
好みの IDE で外部言語を使用してビジネス・ホストまたはアダプタを記述し、そのコードをコンパイルします。
-
管理ポータルで新しい PEX コンポーネントを登録します。その PEX コンポーネントに対して、ObjectScript プロキシ・クラスが自動的に作成されます。
-
PEX コンポーネントがビジネス・サービス、ビジネス・オペレーション、またはビジネス・プロセスの場合は、標準のウィザードを使用してビジネス・ホストをプロダクションに追加し、ObjectScript プロキシ・クラスをビジネス・ホストのクラスとして指定します。PEX コンポーネントがアダプタの場合は、そのアダプタのプロキシ・クラスを参照するようにビジネス・サービスまたはビジネス・オペレーションを変更します。
PEX ライブラリ
各外部言語には、プロダクション・コンポーネントのタイプごとにスーパークラスを格納する PEX ライブラリが含まれています。使用可能な PEX ライブラリは以下のとおりです。
外部言語 | PEX ライブラリ |
---|---|
Java | com.intersystems.enslib.pex |
.NET | InterSystems.EnsLib.PEX |
Python | iris.pex |
PEX コンポーネントを使用した作業
PEX コンポーネントは、外部言語で記述されたリモート・クラスと、そのリモート・クラスを操作するためにネイティブ・プロダクションで使用される ObjectScript プロキシ・クラスで構成されます。カスタムの PEX アダプタまたはビジネス・ホストをプロダクションに追加するには、PEX コンポーネントとして登録しておく必要があります。登録すると、プロダクションを構築するユーザが、そのコンポーネントの詳細を利用できるようになります。PEX コンポーネントを表示および登録するには、管理ポータルを使用して、[相互運用性] > [構成] > [Production EXtensions Components] に移動します。
環境上の考慮事項
InterSystems IRIS Interoperability は、特定の Web アプリケーションが属している相互運用対応ネームスペース内でしか使用できません。クラスの作成では、予約パッケージ名を使用しないようにする必要があります。以降の項で詳しく説明します。
プロダクション対応ネームスペース
相互運用対応ネームスペースは、プロダクションをサポートするクラス、データ、およびメニューをネームスペースで使用可能にするグローバル・マッピング、ルーチン・マッピング、およびパッケージ・マッピングで構成されたネームスペースです。マッピングの詳細は、“ネームスペースの構成” を参照してください (このセクションの情報を使用して、相互運用対応ネームスペースで行われる実際のマッピングを確認できます。詳細はリリースにより異なる場合がありますが、ユーザ側で特に作業する必要はありません)。
InterSystems IRIS のインストール時に作成されるシステム提供のネームスペースは、Community Edition で USER ネームスペースが相互運用対応ネームスペースである場合を除き、相互運用対応ではありません。ユーザが作成する新しいネームスペースはすべて、デフォルトで相互運用対応になります。ネームスペースを作成する際に [ネームスペースを相互運用プロダクション対応にする] チェック・ボックスのチェックを外すと、InterSystems IRIS は相互運用に対応しないネームスペースを作成します。
システム提供のネームスペースはすべて、再インストールまたはアップグレードの際に上書きされます。このため、常に、ユーザが作成した新規ネームスペースで作業することをお勧めします。新規ネームスペースの作成の詳細は、“データの構成” を参照してください。
Web アプリケーションの要件
また、プロダクションは、/csp/namespace (この場合の namespace はネームスペースの名前) と名付けられた Web アプリケーションが関連付けられている場合のみ、そのネームスペースで使用できます。(これは、ネームスペースに対するデフォルトの Web アプリケーション名です。)Web アプリケーションの定義の詳細は、"アプリケーション" を参照してください。
予約パッケージ名
相互運用対応ネームスペースでは、Ens、EnsLib、EnsPortal、または CSPX をパッケージ名として使用しないでください。これらのパッケージは、アップグレード・プロセス中に完全に置換されます。これらのパッケージ内でクラスを定義した場合は、アップグレード前にそれらのクラスをエクスポートして、アップグレード後にインポートする必要があります。
また、先頭に Ens (大文字と小文字の区別あり) が付くパッケージ名を使用しないことをお勧めします。これには次の 2 つの理由があります。
-
先頭に Ens が付く名前のパッケージにクラスをコンパイルすると、コンパイラは、生成されたルーチンを ENSLIB システム・データベースに書き込みます (コンパイラがそうするのは、名前の先頭に Ens が付くルーチンはすべて、そのデータベースにマッピングされるからです)。つまり、インスタンスをアップグレードすると、ENSLIB データベースが置換され、生成されたルーチンはアップグレードによって削除され、クラス定義のみが残ります。この時点で、クラスを使用するために、クラスのリコンパイルが必要になります。
これに対し、名前の先頭が Ens ではないパッケージ内のクラスは、インスタンスのアップグレード時にリコンパイルする必要はありません。
-
名前の先頭に Ens が付くパッケージ内のクラスを定義すると、それらのクラスは相互運用対応のすべてのネームスペースで使用可能になりますが、このことは望ましい場合も、望ましくない場合もあります。1 つ言えることとして、パッケージの名前の先頭に Ens が付いている場合、名前が同じでコンテンツが異なる 2 つのクラスを、異なる相互運用対応ネームスペースで使用することはできなくなります。