ブローカー・スキーマ
ブローカー・スキーマは、その中で定義されたリソース名の固有性の有効範囲を定義するシンボル・スペースです。 リソースには、メッセージ・フローおよびその他のオプション・リソース (ESQL ファイル、Java™ ファイル、マッピング・ファイルなど) が含まれます。
ブローカー・スキーマは、プロジェクト・ソース・ディレクトリーからフロー名への相対パスとして定義されます。
新しいブローカー・スキーマを作成して、同じ 統合プロジェクト内に別個のシンボル・スペースを提供することができます。 ブローカー・スキーマはプロジェクト内のフォルダーまたはサブディレクトリーとしてインプリメントされ、そのプロジェクト内に組織を形成します。 複数のプロジェクトに渡って 1 つのブローカー・スキーマの有効範囲を広げ、アプリケーションの組と関連したすべてのリソースに有効範囲を提供するアプリケーションのシンボル・スペースを作成するためにプロジェクト参照を使用することもできます。
カテゴリー・モードで新規ブローカー・スキーマを作成する場合、空のスキーマは 「アプリケーション開発」ビューに表示されません。 「アプリケーション開発」ビューに空のスキーマを表示するには、ツールバーの カテゴリーを非表示 をクリックします。
ブローカー・スキーマ名は、先頭がユニコード文字でその後に 0 個以上のユニコード文字または数字、および下線が続く文字ストリングでなければなりません。 ピリオドを使用して、名前に構造を提供することができます。以下に例を示します。Stock.Common
. スキーマを表すディレクトリーがプロジェクト・ディレクトリーに作成されます。スキーマがピリオドを使用して構造化されている場合は、さらにサブディレクトリーが定義されます。 例えば、ブローカー・スキーマStock.Common
この結果、 統合プロジェクト ディレクトリー内のディレクトリー 在庫 内にディレクトリー 共通 が作成されます。
プロジェクト内のデフォルト・ブローカー・スキーマ内にリソース (メッセージ・フローなど) を作成した場合、そのリソースに関連した 1 つ以上のファイルがプロジェクトを表すディレクトリー内に作成されます。 他のブローカー・スキーマ内にリソースを作成した場合、ファイルはスキーマ・ディレクトリー内に作成されます。
例えば、 統合プロジェクト Project1のデフォルト・スキーマでメッセージ・フローを作成する場合、その関連ファイルは Project1 ディレクトリーに保管されます。 以下の場所に別のメッセージ・フローを作成するとします。Stock.Common
ブローカー・スキーマがプロジェクト Project1内に作成され、その関連ファイルがディレクトリー Project1\Stock\Commonに作成されます。
各ブローカー・スキーマは固有の名前範囲を表すので、2 つのブローカー・スキーマ内に同じ名前を共有する 2 つのメッセージ・フローを作成できます。 ブローカー・スキーマは、これら 2 つのメッセージ・フローが別個のリソースとして認識されることを保証します。 これら 2 つのメッセージ・フローは、名前は同じですがそれぞれ固有のものとして扱われます。
メッセージ・フローをプロジェクトからプロジェクトに移動する場合、ブローカー・スキーマを保存すれば移動元プロジェクト内のメッセージ・フローを使い続けることができます。 これを行う場合、移動元プロジェクトの個別プロジェクトのリストに移動先プロジェクトを追加してそのリストを更新する必要があります。 しかしブローカー・スキーマを保存しない場合は、スキーマ名は完全修飾メッセージ・フロー名の一部なので、そのフローは別のフローとなって他のプロジェクトから認識されなくなります。 これによりリンクが中断されるので、それを手動で訂正する必要が生じます。 メッセージ・フローを移動した後のエラーの修正について詳しくは、 メッセージ・フローまたはサブフローの移動を参照してください。
ファイル・システム内の関連ファイルを移動することによってリソースを移動しないでください。新しい編成を反映するようにすべての参照が修正されるようにするには、 IBM® Integration Toolkit を使用してリソースを移動する必要があります。
ブローカー・スキーマ内に関数、プロシージャー、および定数を作成する際、以下の有効範囲と再利用条件が適用されます。
関数またはプロシージャーをグローバルに再利用したい場合は、以下のようにします。
- 関数またはプロシージャーのパスを指定します。
- ESQL ファイル内の関数またはプロシージャーを再利用したい場合、完全修飾参照を提供するか、パスを定義する PATH ステートメントを組み込みます。
パスを定義する場合、関数がコーディングされているのと同じ ESQL ファイルに PATH ステートメントをコーディングします。ただし、どの MODULE ステートメント内にもコーディングしません。
- マッピング・ファイル内の関数を再利用する場合、以下のいずれかのステップを実行します。
- Composition Expression エディターで関数を修飾します。
- アウトライン・ビューの「スキーマ参照の編成」を選択します。 これにより従属 PATH が検出され、参照が自動的に更新されます。
- アウトライン・ビューの「スキーマ参照の変更」を選択します。 その後、関数が定義されているスキーマを選択できます。
- ESQL ファイル内の関数またはプロシージャーを再利用したい場合、完全修飾参照を提供するか、パスを定義する PATH ステートメントを組み込みます。
- 関数およびプロシージャーが定義され、使用されるプロジェクト間の参照をセットアップします。