| Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド 11g リリース1(11.1.1.7) B55916-08 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド 11g リリース1(11.1.1.7) B55916-08 |
|
前 |
次 |
この章では、SOAインフラストラクチャのプロパティ(監査レベル、コンポジット・インスタンスの状態、ペイロードの検証を含む)の構成方法について説明します。これらのプロパティ設定は、SOAインフラストラクチャで実行されているすべてのSOAコンポジット・アプリケーションに適用できます。また、ローカルの最適化の構成方法、管理対象サーバーとSOAインフラストラクチャの起動と停止方法、およびグローバル・トークン変数の作成方法についても説明します。
この章では、次の項目について説明します。
詳細は、第1.2.1項「SOAインフラストラクチャ・アプリケーションの概要」を参照してください。
SOAインフラストラクチャの次のプロパティを構成できます。
監査レベル
キャプチャするコンポジット・インスタンスの状態
ペイロードの検証
Universal Description, Discovery, and Integration(UDDI)レジストリ
コールバック・サーバーとサーバーURL
ページ上の最近のインスタンス数、フォルト数および件数のメトリックの表示
最新のインスタンスおよびフォルトの取得の検索基準
Java Naming and Directory Interface(JNDI)データソース
Webサービス・バインディング・プロパティ
このレベルで設定したプロパティは、コンポジット・アプリケーションまたはサービス・エンジン・レベルで異なる監査レベル値を明示的に設定したコンポジットを除いて、すべてのデプロイ済SOAコンポジット・アプリケーションに影響を与えます。
SOAインフラストラクチャの追加の拡張プロパティは、システムMBeanブラウザを使用して構成できます。これらのプロパティには、この項で説明するように、「共通プロパティ」ページの「詳細SOAインフラ拡張構成プロパティ」リンクからアクセスするか、または「SOAインフラストラクチャ」メニューから「管理」→「システムMBeanブラウザ」→「アプリケーション定義のMBean」→「oracle.as.soainfra.config」の順に選択してアクセスできます。
SOAインフラストラクチャ・プロパティは、SOAインフラストラクチャに関連付けられたOracle Metadata Services (MDS)リポジトリに格納されています。Oracle SOA Suiteの場合、MDSリポジトリはデフォルトでコンテンツがデータベースに格納されるように構成されています。
SOAインフラストラクチャ・プロパティを構成する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... | 「SOAコンポジット」メニューからアクセスする手順 |
|---|---|---|
|
|
|
「SOAインフラストラクチャの共通プロパティ」ページには、次のプロパティが表示されます。
次の表に、ページの上部に表示されるプロパティの説明を示します。
| 要素 | 説明 |
|---|---|
|
監査レベル |
メッセージ・トラッキング・インフラストラクチャによって収集する情報のレベルを選択します。この情報は、SOAインフラストラクチャに関連付けられたインスタンス・データ・ストア(データベース)に収集されます。この設定は、ログ・ファイルに書き込まれる内容には影響を与えません。
SOAコンポジット・アプリケーションの監査レベルを下げること、およびOracle SOA Suiteスキーマへの書込みの詳細は、第B.2.3項「監査レベルの低減」を参照してください。 |
|
コンポジット・インスタンスの状態をキャプチャ |
選択すると、SOAコンポジット・アプリケーション・インスタンス状態が取得されます。このオプションを有効化すると、インスタンス処理中に追加の実行時オーバーヘッドが発生する場合があります。このオプションでは、実行中のインスタンスのトラッキングが別々に実行されます。すべてのインスタンスは、実行中か未実行のいずれかとして取得されます。この情報は、後でSOAインフラストラクチャおよびSOAコンポジット・アプリケーションのコンポジット・インスタンス表の「状態」列に表示され、次のようになります。
有効な状態は「実行中」、「完了」、「失敗」、「リカバリが必要」、「失効」、「終了」および状態使用不可です。 「実行中」および「完了」状態は、このチェック・ボックスが選択されている場合のみキャプチャされます。選択されていない場合、状態は「不明」に設定されます。これらの状態を条件付きでキャプチャする主な理由は、SOAインフラストラクチャのランタイムにおけるパフォーマンス・オーバーヘッドを軽減するためです。 注意: このプロパティを無効にしてSOAコンポジット・アプリケーションの新規インスタンスを作成すると、新規インスタンスが作成されます。ただし、このインスタンスは、コンポジット・アプリケーションの「ダッシュボード」の表にページ実行中、フォルト、失効、終了、完了、またはリカバリが必要として表示されません。これは、インスタンスのコンポジット状態をキャプチャする処理がパフォーマンスに影響を与えるためです。 たとえば、このプロパティを有効にし、「Webサービスのテスト」ページでSOAコンポジット・アプリケーション・インスタンスを作成した場合、新規インスタンスはコンポジット・アプリケーションの「ダッシュボード」ページに表示されます。「ダッシュボード」ページで「実行中のインスタンスのみ表示」をクリックすると、インスタンスは「実行中」と表示されます。次に、このプロパティを無効にし、同じコンポジット・アプリケーションの別のインスタンスを作成した場合は、新規の実行中のインスタンスが作成されます。ただし、「実行中のインスタンスのみ表示」を選択すると、新規インスタンスは実行中のインスタンスの表にリストされません。 さらに、実行中のインスタンスを終了するには、インスタンスがある状態(実行中、失敗など)にあることが必要です。その結果、SOAコンポジット・アプリケーションの「インスタンス」ページで「中断」ボタンがアクティブになります。インスタンスを作成する前にこのチェック・ボックスを有効にしなかった場合、「中断」ボタンはアクティブにならないため、インスタンスを終了できません。 インスタンスの状態トラッキングを無効化して監査レベルを下げることの詳細は、第B.2.3項「監査レベルの低減」を参照してください。 |
|
ペイロードの検証 |
受信メッセージと送信メッセージの検証を有効にする場合に選択します。スキーマに準拠しないペイロード・データが捕捉され、フォルトとして表示されます。 |
使用環境に適した変更を行います。
「UDDIレジストリ・プロパティ」セクションには、次のプロパティが表示されます。SOAインフラストラクチャで実行されているSOAコンポジット・アプリケーションは、UDDIレジストリに統合できます。このUDDIレジストリでは、公開サービスの検索、およびサービスに関するメタデータの管理(セキュリティ、トランスポートまたはサービスのクオリティ)を実行するための標準ベースの基盤が提供されます。ニーズを満たす公開サービスを参照して選択できます。
「ユーザー」および「パスワード」プロパティは、UDDIレジストリが保護されている場合に適用できます。これらのプロパティは、Oracle Service Registry(OSR)のセキュアHTTP構成にのみ使用されます。「照会URL」プロパティはパブリックです。
| 要素 | 説明 | 例 |
|---|---|---|
|
照会URL |
問い合せるマスター・レジストリのURLを入力します。このURLでスレーブ・レジストリ自体を参照しないでください。参照すると、データの一部を失う可能性があります。照会URLによって、完全標準のUDDIバージョン3構造が取得されます。これは、UDDIレジストリ接続の作成ウィザードで指定したUDDI照会URLと同じです。 |
|
|
ユーザー |
レジストリ照会ユーザーを入力します。 |
|
|
パスワード |
マスター・レジストリ照会ユーザーのパスワードを入力します。 |
問題のないセキュリティ・プラクティスを使用したパスワードを入力してください。 |
エンドポイント参照とサービス・キーの設定の詳細は、第36.1.3項「Oracle Service Registryと統合している場合のエンドポイント参照およびサービス・キーの変更」を参照してください。
使用環境に適した変更を行います。
「サーバーURL」セクションには、次のプロパティが表示されます。ここでプロパティを明示的に設定しない場合、プロパティ値は実行時にOracle WebLogic Serverクラスタ、Webサーバーまたはローカル・サーバーのプロパティを問い合せて決定されます。
| 要素 | 説明 |
|---|---|
|
コールバック・サーバーURL |
コールバック・サーバーURLを入力します。この設定は、SOAコンポジット・アプリケーション・サービスおよび参照コールバックのすべてに適用されます。通常、この設定の書式は、 |
|
サーバーURL |
サーバーURLを入力します。このURLは、具体的なWSDLファイルでサービスのSOAPアドレスの一部として公開されます。 注意: 10.1.xリリースでは、 ローカルの最適化の詳細は、第3.7項「ローカルの最適化の構成」を参照してください。 |
「データ表示オプション」セクションには、ページのロードにかかる時間を短縮するための、次のプロパティが表示されます。
|
注意: これらのプロパティに対する変更は、このOracle Enterprise Managerインスタンスに関連付けられているすべてのSOAファームに影響します。 |
| 要素 | 説明 |
|---|---|
|
インスタンス数およびフォルト数をフェッチするメトリックを無効にします。この場合でも各メトリックは必要に応じて取得できます。 |
SOAインフラストラクチャ、SOAコンポジット・アプリケーション、サービス・エンジンおよびサービス・コンポーネントの「ダッシュボード」ページでインスタンス数およびフォルト数のメトリックの表示を無効にする場合に選択します。 これらのメトリックは、インスタンス数とフォルト数のメトリックが必要な場合にクリックしてこの情報を取得するためのリンクで置換されます。この設定により、ページのロードにかかる時間を短縮できます。 インスタンス数とフォルト数のメトリックを取得するリンクをクリックするとOracle Enterprise Manager Fusion Middleware Controlがタイムアウトする場合は、トランザクション・タイムアウト・プロパティを増やします。詳細は、第B.3.1項「接続タイムアウトの解決」および第B.7.1項「インスタンスおよびフォルトのメトリックのあるページのロードの最適化」を参照してください。 |
|
インスタンスとフォルトの表示を次に制限: 過去time_period |
このチェック・ボックスを選択し、次のページに表示する最近のインスタンス、フォルトおよび数のメトリックを取得する期間を指定します。
デフォルトで、このチェック・ボックスは選択済で、期間は24時間(1日)に設定されています。このチェック・ボックスが選択されていない場合は、最後のパージ以降のSOAインフラストラクチャにおけるインスタンスとフォルト(数のメトリックを含む)がすべて表示されます。 注意: Oracle Enterprise Manager Fusion Middleware Controlの複数のページおよび問合せのパフォーマンスに大きく影響するため、期間を設定することを強くお薦めします。 指定した期間は、フォルトを検索できるフォルト・ページの「フォルト時間の開始」フィールドおよびインスタンスを検索できる「インスタンス」ページの「開始時間: 自」フィールドにデフォルトで表示されます。 |
詳細は、第B.7.1項「インスタンスおよびフォルトのメトリックのあるページのロードの最適化」を参照してください。
「拡張」セクションを開きます。
「データソース」セクションには、次のプロパティが表示されます。データソースを使用すると、データベース・サーバーへの接続を取得できます。
「Webサービス・バインディング・プロパティ」セクションには、次のオプションが表示されます。
| 要素 | 説明 | 例 |
|---|---|---|
|
Oracle SSL暗号 |
Oracleでサポートされている暗号のリストを入力します。 暗号スイートは、データ送信に対してセキュリティを提供する一連のアルゴリズムです。SSL接続内でのデータの移動を可能にするには、使用する共通アルゴリズムについて、接続の両側がネゴシエーションする必要があります。 |
|
|
Oracle Walletパスワード |
キーストア用のウォレット・パスワードを入力します。 |
|
|
チャンクの使用 |
- - |
|
|
チャンク・サイズ |
チャンク・サイズを指定します。値は |
|
使用環境に適した変更を行います。
「適用」をクリックします。
プロパティを変更した後に元の値にリセットする場合は、「元に戻す」をクリックします。
拡張パラメータを変更するには、「詳細SOAインフラ拡張構成プロパティ」をクリックします。これにより、「システムMBeanブラウザ」が開きます。表示されるプロパティの一部を次に示します。各プロパティには説明が記載されています。
AuditConfig: BPELメッセージ・リカバリのステータス。このプロパティには、次のキーが含まれています。
bpelRecoveryStatusキー: BPELプロセス・サービス・エンジンの「リカバリ」ページにリカバリを必要とするBPELメッセージが存在する場合、この設定によって「必須のBPELメッセージ・リカバリ」インライン警告メッセージが有効化され、「フローのトレース」ページの「トレース」表、およびSOAインフラストラクチャ、およびSOAコンポジット・アプリケーションのホーム・ページの最上部にリカバリ・アイコンが表示されます。デフォルトでこのキーは「All」に設定されています。このキーをOffに設定すると、メッセージ・リカバリ情報は表示されません。詳細は、次の項を参照してください。
- 第4.3項「SOAインフラストラクチャの最新のインスタンスとフォルト、およびデプロイ済コンポジットの監視」
excludeBpelMaxCreationTimeキー: リカバリが必要なメッセージを除外する期間を設定できます。詳細は、第4.3項「SOAインフラストラクチャの最新のインスタンスとフォルト、およびデプロイ済コンポジットの監視」を参照してください。
bpelRecoveryAlertDurationInDaysキー: リカバリ可能BPELメッセージが最近7日間以内に作成されている場合にのみ、「必須のBPELメッセージ・リカバリ」インライン警告メッセージが表示されるように制限します。7日間のデフォルト設定は変更可能です。このプロパティは-1などの負の値や0に設定できません。このような場合、キーではデフォルト値(7日間)が使用されます。アラート・メッセージの無効化には、bpelRecoveryStatusキーを使用します。この期間値はフロー・トレース・アラート・メッセージには適用されません。
CreateWSCallTrackingMBean: Webサービス・コールの経過時間を追跡するMBeanの作成を制御します。経過時間のしきい値を超えると、インシデントが作成されます。trueに設定した場合は、監視を作成できます。この設定は、SOAインフラストラクチャ内のすべてのSOAコンポジット・アプリケーションに適用されます。詳細は、第12.5項「監視および通知の作成」を参照してください。
HttpServerURL: WSDLファイルでプロセスのSOAPアドレスの一部として公開されるHTTPプロトコルURL。
HttpsServerURL: WSDLファイルでプロセスのSOAPアドレスの一部として公開されるHTTPSプロトコルURL。
第3.1項「SOAインフラストラクチャ・プロパティの構成」で説明したように、「SOAインフラストラクチャの共通プロパティ」ページの「データ表示オプション」セクションでインスタンス数とフォルト数のメトリックの取得を無効にできます。「システムMBeanブラウザ」でこのプロパティを変更することもできます。
システムMBeanブラウザを使用して、インスタンス数とフォルト数のメトリックの取得を無効化する手順は、次のとおりです。
「アプリケーション定義のMBean」→「emom.props」→「サーバー: AdminServer」→「アプリケーション: em」→「プロパティ」→「emoms.properties」の順に選択します。
emoms.propertiesは、「SOAインフラストラクチャの共通プロパティ」ページの「データ表示オプション」セクションでインスタンス数とフォルト数のメトリックのフェッチの無効化オプションをすでに変更している場合にのみ選択可能になることに注意してください。
「属性」タブの「名前」列で「プロパティ」をクリックします。
「値」列で、「Element_20」を展開します。
「要素」列で、「false」と入力してメトリック取得を無効にします。
「適用」をクリックします。
SOAインフラストラクチャを再起動します。この方法ではなく、「SOAインフラストラクチャの共通プロパティ」ページの「データ表示オプション」セクションでインスタンス数とフォルト数のメトリックのフェッチの無効化オプションを変更した場合は、再起動が不要です。
メンテナンスまたは構成変更後の再起動のために、Oracle Enterprise Manager Fusion Middleware ControlでSOAインフラストラクチャを停止して起動できます。このことを行うには、SOAインフラストラクチャがインストールされている管理対象サーバーを停止して起動します。これにより、管理対象サーバーとSOAインフラストラクチャの両方が再起動されます。
|
注意:
|
サーバー起動時の問題の詳細は、第B.8項「サーバーのトラブルシューティング」を参照してください。
管理対象サーバーとSOAインフラストラクチャを起動および停止する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| 「WebLogic Server」メニューから | ナビゲータの「WebLogicドメイン」フォルダから |
|---|---|
|
|
管理対象サーバーとSOAインフラストラクチャを停止するには、「停止」を選択します。
管理対象サーバーとSOAインフラストラクチャの停止の確認が表示されたら、「OK」をクリックします。
停止の完了を待ちます。
管理対象サーバーとSOAインフラストラクチャを起動するには、「起動」を選択します。
ノード・マネージャを使用した管理対象サーバーの停止および起動の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』を参照してください。
WLSTコマンドを使用した管理対象サーバーの起動および停止の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
SOAインフラストラクチャは、起動後、すべてのデプロイ済コンポジットがロードされるまで受信リクエストを管理するために完全には初期化されない場合があります。そのため、Oracle Enterprise Manager Fusion Middleware Controlの一部のページに表示されるレスポンス・メトリックは、実際のステータスを反映していない可能性があります。このことは、SOAインフラストラクチャが複数の管理対象サーバーおよび多数のデプロイ済コンポジットを持つクラスタ内にある場合に最も顕著になります。
初期化ステージ中、Oracle Enterprise Manager Fusion Middleware Controlでは、コンポジット・デプロイメント、コンポジット・アンデプロイメントなどの操作を、これらの操作が正常に完了しなくても、実行することができます。かわりに、表3-1に示すOracle Enterprise Manager Fusion Middleware Controlのページの上部に警告メッセージが表示されます。このメッセージが表示されている間は、コンポジット・デプロイメント、コンポジット・アンデプロイメントなどの操作を実行しないでください。初期化が完了すると、メッセージは表示されなくなります。このことは、ページをリフレッシュするとわかります。その後、操作を実行できます。
表3-1 SOAインフラストラクチャの初期化メッセージ
| 表示される警告メッセージ | 上部にメッセージが表示されるページ |
|---|---|
Initializing SOA Even though the soa-infra target is up, some SOA Fabric components and composite applications are still loading. You may need to allow some time for the initialization to complete, and later click the Refresh Page icon. It is not adivsable to execute any operations on this soa-infra until this warning goes away. |
|
SOAインフラストラクチャの停止後、SOAコンポジット・アプリケーションの状態は、コンポジットが停止していることを示すように更新されません。コンポジットにアクセスしようとすると、コンポジット詳細を取得できない旨のエラー・メッセージが表示されます。
soa-infra runtime connection error An error happened while connecting to soa-infra runtime at t3://152.61.150.106:8001/soa-infra.
このメッセージによって、システム内で別の問題が発生していると考える可能性があります。しかし、この場合はそうではありません。
このメトリックは、コンポジットが有効かどうか、SOAインフラストラクチャの起動に依存しているかどうかを示すため、これらのコンポジットの状態は「稼働中」また、場合によっては「保留」と表示されます。さらに、クラスタ内の他の管理対象サーバーではコンポジットは依然としてアクティブで、リクエストを受信できます。
アダプタ・エンドポイントがあるSOAコンポジット・アプリケーションがリタイア状態にある場合は、次のアクションを実行した場合にエンドポイントはアクティブになりません。
SOAインフラストラクチャの再起動
SOAコンポジット・アプリケーションのアクティブ化
これは、ファイルやレコードなどがエンドポイント・アダプタによって取得されないためです。回避策として、SOAインフラストラクチャの再起動後にSOAコンポジット・アプリケーションを再デプロイします。
cwallet.ssoにSOAマップがある場合は、SOAインフラストラクチャの起動を試行すると、次のようなエラー・メッセージが表示されます。
Caused By: java.security.UnrecoverableKeyException: Password verification
failed
at
sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:769)
at
sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
at java.security.KeyStore.load(KeyStore.java:1185)
at oracle.j2ee.ws.saaj.util.SSLUtil.loadKeyStore(SSLUtil.java:73)
at
oracle.j2ee.ws.saaj.util.SSLUtil.getKeyManagerFactory(SSLUtil.java:88)
at oracle.j2ee.ws.saaj.util.SSLUtil.getKeyManagers(SSLUtil.java:97)
at
oracle.j2ee.ws.saaj.util.SSLUtil.createSSLSocketFactory(SSLUtil.java:50)
at
oracle.integration.platform.common.SSLSocketFactoryManagerImpl.getSSLSocketFac
tory(SSLSocketFactoryManagerImpl.java:58)
at oracle.fabric.common.wsdl.WSDLManager.init(WSDLManager.java:356)
at oracle.fabric.common.wsdl.WSDLManager.<init>(WSDLManager.java:101)
at
oracle.fabric.common.metadata.MetadataManagerImpl.getWSDLManager(MetadataManag
erImpl.java:283)
at
oracle.fabric.composite.model.CompositeModel.getWSDLManager(CompositeM
この問題を解決する手順は、次のとおりです。
次のいずれかのアクションを実行します。
cwallet.ssoでSOAマップを削除します。
$DOMAIN_HOME/config/fmwconfig/default-keystore.jksを削除します。Oracle Web Services Manager(OWSM)でこのファイルが使用されます。
SOAインフラストラクチャを再起動します。
第3.1項「SOAインフラストラクチャ・プロパティの構成」で説明されているように、「SOAインフラストラクチャの共通プロパティ」ページ以外に、Oracle Enterprise Manager Fusion Middleware Controlの「システムMBeanブラウザ」でSOAインフラストラクチャの「ServerURL」プロパティ・ポートを変更することもできます。
ポートを変更するときは、次の点に注意してください。
SOAインフラストラクチャと管理対象のOracle WebLogic Serverのポート番号が異なる場合は、Oracle BPM Worklistに接続しようとするとConnectExceptionエラーが発生します。これらのポート番号が一致していることを確認してください。
Oracle WebLogic Server管理コンソールからSOAインフラストラクチャのポートを変更することはできません。Oracle WebLogic Server管理コンソールからは、管理対象のOracle WebLogic Serverのポートのみを変更できます。
SOAインフラストラクチャのポートを変更する手順は、次のとおりです。
「SOAインフラストラクチャ」メニューから、「管理」→「システムMBeanブラウザ」の順に選択します。
「アプリケーション定義のMBean」で、「oracle.as.soainfra.config」→「サーバー: server_soa」→「SoaInfraConfig」→「soa-infra」の順に開きます。
server_soaは、インストール後の構成で指定したサーバーの名前です。デフォルトでは、この名前は「soa_server1」です。
「名前」列で「ServerURL」をクリックします。
「属性: ServerURL」ページが表示されます。
「値」フィールドで、ポートを変更します。
「適用」をクリックします。
Oracle WebLogic Server管理コンソールで、管理対象のOracle WebLogic Serverのポートを同じ値に変更します。
Oracle WebLogic Serverクラスタの前にロード・バランサを使用する環境では、「ServerURL」プロパティのホストとポートは、Oracle WebLogic Serverのホストとポートと異なっても構いません。これは、Oracle WebLogic Serverクラスタ内の管理対象サーバー間でロード・バランサがリクエストを分散するエンタープライズ・デプロイメント環境では一般的です。詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
Oracle SOA Suiteのコンポーネントではログ・ファイルが生成され、起動と停止情報、エラー、警告メッセージ、HTTPリクエストに関するアクセス情報および追加情報を含むすべてのタイプのイベントを記録するメッセージが格納されます。
ログ・ファイルを構成する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「ログ構成」ページに、次の詳細が表示されます。
「ビュー」リスト。情報を表示するロガーのタイプを選択します。
永続: コンポーネントが起動するとアクティブになるロガー。このログ出力の構成詳細はファイルに保存され、ログ・レベルはコンポーネントの再起動後も維持されます。
アクティブ・ランタイム: 実行時に自動的に作成され、特定の機能領域が実行されるとアクティブになるロガー(例: oracle.soa.b2b、oracle.soa.bpel)。このログ出力のログ・レベルはコンポーネントの再起動後は維持されません。
ロガー名およびOracle Diagnostic Logging(ODL)レベルが表示された表で、ログ・ファイルに書き込む情報の量とタイプ、ログ・ファイル、およびログ・レベル状態を設定します。
このページで次のログ・ファイル・タスクを実行します。
「ロガー名」列で、ロガー名を開きます。これによって、コンポーネント内の特定のロギング・レベルを指定できます。
「Oracle Diagnostic Loggingレベル(Javaレベル)」列で、ログ・ファイルに書き込む情報のレベルとタイプを選択します。
「ログ・ファイル」列で、ログ・ファイル構成を作成および編集する特定のログ・ファイルをクリックします。
ODLログ・ファイル、およびログ・ファイルに書き込むロギング情報のレベルとタイプの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
「ログ・ファイル」タブをクリックします。
このページを使用して、ログ・ファイル構成を作成および編集できます。ログ・ファイル構成には、ログ・メッセージが記録されるログ・ファイル、ログ・メッセージのフォーマット、使用されるローテーション・ポリシー、およびログ・ファイル構成クラスに基づく他のパラメータが含まれます。
ロギング・レベルおよび表示するOracle SOA Suiteログ・ファイルの設定の詳細は、B.1項「トラブルシューティングのためのロギング・レベルの設定」を参照してください。
soa-diagnostic.logファイルのoracle-soa-handlerログ・ハンドラ・プロパティには、SOA_Domain/config/fmwconfig/servers/server_soa/logging.xmlファイルに指定されるエンコーディング・プロパティがありません。かわりに、soa-diagnostic.logファイルにはオペレーティング・システムのデフォルトのエンコーディング・フォーマットで書き込まれます。このため、次の問題が発生する場合があります。
ロギング情報はsoa-diagnostic.logにサーバーのデフォルトのエンコーディング・フォーマットで書き込まれるため、ASCII以外のエラー・メッセージは読み取れなくなる場合があります。
Windowsオペレーティング・システムでは、デフォルトのエンコーディング・フォーマットで書き込むことによって、ASCII以外のデータが失われる場合があります。
この問題を回避するには、logging.xmlファイルで、oracle-soa-handlerログ・ハンドラ・プロパティに対して値UTF-8を指定します。
<?xml version='1.0'?> <logging_configuration> <log_handlers> <log_handler name='wls-domain' class='oracle.core.ojdl.weblogic.DomainLogHandler' level='WARNING'/> <log_handler name='oracle-soa-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory'> <property name='path' value='c:\soa1210.1411\user_ projects\domains\soa/servers/server_soa/logs/soa-diagnostic.log'/> <property name='maxFileSize' value='10485760'/> <property name='maxLogSize' value='104857600'/> <property name='supplementalAttributes' value='J2EE_APP.name,J2EE_ MODULE.name,WEBSERVICE.name,WEBSERVICE_PORT.name,composite_instance_id,component_ instance_id,composite_name,component_name'/> <property name='encoding' value='UTF-8'/> </log_handler> </log_handlers> ...
これで、ログ・ファイルはODLを使用して書き込まれます。ログ・ファイルの内容は、Oracle Enterprise Manager Fusion Middleware Controlから表示できます。
ロギングの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
Oracle SOA Suiteでは、APIコールのパフォーマンス・メトリックをログに記録できます。作成されたOracle Enterprise Manager Fusion Middleware Controlページに対する高コストのAPIコールのパフォーマンスをトレースできます。このトレースは、APIコールが効率的に実行されない場合に役立ちます。他の情報とともにview idが次のファイルにログとして記録されます。
FMW_HOME/user_projects/domains/domain_name/servers/weblogic_name/logs/weblogic_name-soa-tracking.trc
たとえば、weblogic_name-soa-tracking.trcファイルに関連付けられたルート・ロブ出力でFINEレベルのロギングを有効化して、診断対象の問題を再生してからロギング・レベルをSEVEREに戻すことができます。ログの内容を分析して、Oracle SOA Suiteで実行された元の操作を精密に指摘できます。
パフォーマンスの問題を診断するロギングを構成する手順は次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| 「SOAインフラストラクチャ」メニューからアクセスする手順 | ナビゲータの「SOA」フォルダからアクセスする手順 |
|---|---|
|
|
「ログ構成」ページが表示されます。
「ロガー名」列で、oracle.soa > oracle.soa.sql.trc.fabricを開きます。
ロギング・レベルをFINEに設定します。
「適用」をクリックします。
APIコールを生成したOracle Enterprise Manager Fusion Middleware Controlページは、weblogic_name-soa-tracking.trcファイルにログ記録されます。この例では、/ai/soa/composite (SOAコンポジット・アプリケーションのホーム・ページ)がページとして特定されます。
[2012-08-07T23:21:04.488-07:00] [soa_server1] [TRACE:32] []
[oracle.soa.sql.trc.fabric.toplink_session.tracking_session] [tid:
[ACTIVE].ExecuteThread: '1' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: weblogic] [ecid:
6fec0e67fbf81939:-7d87fd84:138e67064fb:-8000-0000000000000dd6,1:24469]
[SRC_CLASS: oracle.integration.platform.instance.store.ToplinkSessionLogger]
[APP: soa-infra] [SOA.toplink.session_name: tracking_session]
[SOA.logging.category: query] [SOA.call_origin_category: /ai/soa/composite]
[SOA.call_origin: em] [SRC_METHOD: log] execute_query
デフォルトのSOAインフラストラクチャのデータ・ソースは常にXAに対応しています。データ・ソースがカスタム・ドライバのサポートを必要とする場合は、Oracle WebLogic Serverでドライバ名を変更する必要があります。
次のいずれかの方法で、ドライバ名を変更する手順は、次のとおりです。
Oracle WebLogic Server管理コンソールで編集します。
Oracle WebLogic Server管理コンソールにログインします。
左側のペインで、「ドメイン構造」を選択します。
「サービス」→「JDBC」→「データ・ソース」→「SOADataSource」→「接続プール」の順に選択します。
「ドライバ・クラス名」で、値をカスタム・データ・ソース(例: oracle.jdbc.xa.client.myDataSource)に変更します。
サーバーを再起動します。
soaDataSource-jdbc.xmlファイルを編集します。
Oracle WebLogic ServerでsoaDataSource-jdbc.xmlファイルを開きます。
SOADataSourceドライバ名をoracle.jdbc.OracleDriverからoracle.jdbc.xa.client.myDataSourceに変更します。
<?xml version="1.0" encoding="UTF-8"?>
<jdbc-data-source
/. . .
. . .
/ <name>SOADataSource</name>
<jdbc-driver-params>
<url>jdbc:oracle:thin:myhost.us.example.com:1537:co0yd570</url>
<driver-name>*oracle.jdbc.xa.client.myDataSource*</driver-name>
<properties>
<property>
<name>user</name>
<value>fusion_soainfra</value>
</property>
</properties>
/ . . .
. . ./
</jdbc-driver-params>
/. . .
. . ./
</jdbc-data-source>
XAデータ・ソースのデフォルトのXAトランザクション・タイムアウト値は、0秒です。このデフォルト値はOracle WebLogic Server管理コンソールで変更できます。変更する場合は次の手順に従います。
XAデータ・ソースにデフォルト以外のXAトランザクション・タイムアウト値を指定する手順は、次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
ページの左側の「ドメイン構造」で、「サービス」→「JDBC」→「データ・ソース」の順に選択します。
「データ・ソース」表の「名前」列で、EDNDataSource (イベント配信ネットワーク・トランザクションの場合)、またはSOADataSource (その他のすべてのタイプのトランザクションの場合)を選択します。
上部にある「構成」タブで、「トランザクション」サブタブをクリックします。
「XAトランザクション・タイムアウト」フィールドに、値を秒単位で入力します。
「XAトランザクション・タイムアウトの設定」チェック・ボックスを選択します。このチェック・ボックスは、新しいXAトランザクション・タイムアウト値を有効にするために選択する必要があります。
「保存」をクリックします。
ローカルの最適化とは、2つのSOAコンポジット・アプリケーションが同じSOAサーバー(JVM)にある環境で、直接Java呼出しによってSOAコンポジット・アプリケーションが別のSOAコンポジット・アプリケーションを呼び出すプロセスです。
一般的に、直接Java呼出しはSOAP over HTTPコールより効率的です。したがって、直接Java呼出しの条件を満たしている場合は常に、Oracle SOA Suiteでは、同じ場所に存在するコンポジット間のサービス・コールを最適化します。
Oracle SOA Suiteでは、ローカルの最適化が可能かどうかを判断するために、次の条件チェックを実行します。
コンポジット間呼出しである必要があります。これは最も基本的な条件で、クライアント・サービスとターゲット・サービスの両方が同じSOAインフラストラクチャ(つまり、同じSOAサーバー)に基づいて実装されている場合に、直接Javaコールが可能になります。
参照(ターゲット)サービスを実装するコンポジットがアクティブである必要があります。この条件ではターゲット・コンポジットが起動して実行中であることが必要で、これにより、参照サービスが使用可能であることが保証されます。
|
注意: ターゲット・コンポジットの状態は「オン」および「アクティブ」である必要があります。状態が「停止済」または「リタイア」の場合は、ローカルの最適化の対象になりません。 |
クライアント・コンポジットとターゲット・コンポジットは同じサーバー上に存在する必要があります。これは、直接Java呼出しの明白な要件です。また、Oracle SOA Suiteで、(クライアント・コンポジットがデプロイされている)サーバーのホスト構成に対して、参照(ターゲット)サービス・エンドポイントURIで指定したホストとポート値を比較するのは重要なステップです。ホストとポート値が一致する場合は、クライアント・コンポジットとターゲット・コンポジットが同じサーバー上に存在すると判断できます。ただし、スタンドアロン・サーバー設定とクラスタ・サーバー設定の両方を使用し、ロード・バランサ構成が必要になる可能性がある場合、この比較は必ずしも単純ではありません。したがって、次に、すべてのプラットフォームでサーバー構成が正しいことを確認する条件チェックをステップごとに示します。
第3.1項「SOAインフラストラクチャ・プロパティの構成」で説明したように、「SOAインフラストラクチャの共通プロパティ」ページで「サーバーURL」構成プロパティ値をチェックします。
指定されていない場合は、クラスタMBeanのFrontendHostおよびFrontendHTTPPort (また、SSLが有効化されている場合はFrontendHTTPSPort)の構成プロパティ値をチェックします。
指定されていない場合は、Oracle WebLogic Server MBeanからFrontendHostおよびFrontendHTTPPort(または、SSLが有効な場合はFrontendHTTPSPort)構成プロパティ値をチェックします。
指定されていない場合は、DNS解決されたINETアドレスのlocalhostを使用します。
参照サービス・エンドポイントURLで指定したポート値が、構成されたサーバー・ポート値と一致するかどうかをチェックします。エンドポイントURLにポート値が指定されていない場合、Oracle SOA Suiteでは、HTTP URLの場合は80、HTTPS URLの場合は443を使用します。
ポート値が一致する場合、サーバーURL、つまり、http(s)://host:port(hostとportは前のチェックから取得)が、参照エンドポイント・アドレスのサーバーURLと比較されます。URLは正規値に解決され、エンドポイントURLホストがlocalhostまたは127.0.0.1の場合もこの比較が行われます。
Oracle SOA Suiteでは、サーバーURLの比較で値trueが返された場合、コンポジットは同じ場所に存在すると判断します。
セキュリティ・ポリシー構成は、クライアント・コンポジットとサーバー・コンポジットの一方または両方に適用されている場合、ローカルの最適化に対応している必要があります。ポリシー構成およびローカルの最適化については、第7.7.2項「コンポジット間呼出しでのポリシー・アタッチメントおよびローカルの最適化」を参照してください。
「フローのトレース」ページの「トレース」セクションで、コールによってローカルの最適化が行われたかどうかを確認できます。図3-1に示すように、呼出し元コンポジットと呼出し先コンポジットの参照とサービスに対して(ローカル呼出し)というテキストが表示されます。
図3-1 「フローのトレース」ページの「トレース」セクションに表示されるローカルの最適化の詳細
「フローのトレース」ページの詳細は、第14.1項「BPELプロセス・サービス・コンポーネントの監査証跡とプロセス・フローの監視」を参照してください。
ローカルの最適化を上書きまたは強制するために、2つの構成プロパティが用意されています。
oracle.webservices.local.optimization
デフォルトでは、Oracle SOA Suiteはローカルの最適化を実行します。ただし、composite.xmlファイルのoracle.webservices.local.optimizationバインディング・プロパティを使用してこの動作を上書きできます。このプロパティをfalseに設定すると、ローカルの最適化は実行されず、コンポジット間コールはSOAP and HTTPを介して実行されます。必要に応じて、このプロパティを使用してください。このプロパティの設定については、第7.7.2項「コンポジット間呼出しでのポリシー・アタッチメントおよびローカルの最適化」を参照してください。
oracle.soa.local.optimization.force
oracle.soa.local.optimization.forceプロパティをtrueに設定して、oracle.webservices.local.optimizationプロパティをオーバーライドすると、最適化を強制的に実行できます。このプロパティは、次のシナリオの場合に使用します。
サーバー構成がかなり複雑で(たとえば、イントラネットにファイアウォールやプロキシ設定がある場合)、第3.7.1項「ローカルの最適化を使用するための条件チェック」で説明した同じ場所に存在するかどうかのチェックで正しい結果が得られない可能性がある場合。
ユーザーがローカルの最適化のセマンティクスを十分に理解し、システム設定がローカルの最適化に適しており、ローカルの最適化が確実に効率的である場合。
この項で説明していないこれ以外のシナリオでも、最適化を強制する場合があります。
|
注意:
|
oracle.soa.local.optimization.forceプロパティのデフォルト値はfalseです。このプロパティをtrueに設定すると、Oracle SOA Suiteでは第3.7.1項「ローカルの最適化を使用するための条件チェック」で説明した条件チェックをスキップしますが、ポリシー構成チェックは例外で、このチェックはサービス・コールの整合性を確認して強制するために必要とされます。
Oracle SOA Suiteで常にこのプロパティの設定が優先されることは、このプロパティに関する重要事項の1つです(ポリシー・チェックによって最適化が可能になる場合)。ただし、ローカル呼出しがアプリケーション以外のフォルトまたは例外によって失敗した場合(多くの場合、直接Java呼出しに関連するランタイム・エラー)、構成されたエンドポイントでの後続の呼出し、およびエンドポイントに構成されたすべての有効なエンドポイント・アドレスで、この設定の値が無視されます。
oracle.soa.local.optimization.forceプロパティを有効にする手順は、次のとおりです。
呼び出されるコンポジットのreferenceセクションに、oracle.soa.local.optimization.forceをバインディング・コンポーネント・レベルのプロパティとして追加します。たとえば、コンポジットcomp_comp2がcomp_comp1を呼び出す場合は、comp_comp2のcomposite.xmlファイルのreferenceセクションでこのプロパティを定義します。
<reference name="Service1"
ui:wsdlLocation="http://localhost:8001/soa-infra/services/default/comp_
comp1!1.0/BPELProcess1.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/comp_comp/comp_
comp1/BPELProcess1#wsdl.interface(BPELProcess1)"
callbackInterface="http://xmlns.oracle.com/comp_
comp/comp_comp1/BPELProcess1#wsdl.interface(BPELProcess1Callback)"/>
<binding.ws port="http://xmlns.oracle.com/comp_comp/comp_
comp1/BPELProcess1#wsdl.endpoint(bpelprocess1_client_ep/BPELProcess1_pt)"
location="http://localhost:8001/soa-infra/services/default/comp_
comp1!1.0/bpelprocess1_client_ep?WSDL">
<property name="oracle.webservices.local.optimization">false</property>
<property name="oracle.soa.local.optimization.force">true</property>
</binding.ws>
参照サービス・コールバックに対してローカル最適化を強制する手順は次のとおりです。
対応する参照サービスの<service>定義で、<callback>要素にoracle.soa.local.optimization.forceプロパティを追加します。
たとえば、composite1がcomposite2を起動する場合は、次のようにcomposite2の<service>定義にoracle.soa.local.optimization.forceプロパティを追加し、composite2からcomposite1への非同期コールバックを強制してローカルで最適化されるようにします。
<service ui:wsdlLocation="composite2.wsdl"> . . . <callback> <binding.ws port="http://xmlns.oracle.com/example#wsdl.endpoint(FooService/FooPort)"> <property name="oracle.soa.local.optimization.force">true</property> </binding.ws> </callback> </service>
最適化、およびWS-AtomicTransaction (WS-AT)トランザクションの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の最適化有効時にサポートされないWS-ATトランザクションに関する項を参照してください。
Oracle SOA Suiteでは、ローカルの最適化かSOAP処理かを決定するたびにNOTIFICATION:1(INFO)レベルのロギングが実行されます。詳細またはデバッグ情報が必要な場合は、Oracle Enterprise Manager Fusion Middleware Controlでoracle.integration.platform.blocks.localおよびoracle.integration.platform.blocks.soapロガーをTRACE:1(FINE)レベルで設定します。
このローカル最適化コールのユースケースで説明する内容は次のとおりです。
コンポジットAが同じサーバー上にあり関連付けられているコンポジットBをコールする環境でコンポジットBに到達不能な場合にローカル最適化コールがどのように機能するか(表3-2)。
Oracle WebLogic Serversがリスニングするポートではないポート値でロード・バランサ・アドレスを作成した場合にどのようになるか(表3-3)。
表3-2 コンポジットに到達不能の場合のローカル最適化コール
| シナリオ | 説明 |
|---|---|
|
ローカル最適化コールの失敗時にどのようになるか。 |
ローカル最適化コールの試行前にコンポジットBのチェックが実行されます。 このチェックに失敗した場合(コンポジットBに到達不能)、SOAインフラストラクチャで例外がスローされBPELフォルトに変換されます。このBPELフォルトには、コンポジットBが到達不能であることに関する情報が組み込まれます。 |
|
関連付けられたコールの再試行が可能であるか。 |
基本チェックの実行後にローカル最適化コールが試行されます。このコールが失敗すると、SOAPを介して再起動されます。ただし、SOAPを介した再起動を行うには次の条件に合致している必要があります。
|
|
関連付けられたコールの再試行が可能な場合(たとえば、コンポジットまたはエンドポイントでフォルトのポリシーが再試行に設定されている場合など)、コールが再度最適化されるか、ローカル・コンテナの終了してロード・バランサへのアクセスを試行するか。 |
ローカルでの送信の試行時にコールが初めて失敗した場合は、その情報がキャッシュされます(つまり、ローカルでの失敗)。 その後のコールについては、コールがSOAPを介して送信されます(このときはローカル最適化コールの再試行は行われません)。 |
表3-3 Oracle WebLogic Serversがリスニングするポートではないポート値でのロード・バランサ・アドレスの作成
| シナリオ | 説明 |
|---|---|
|
Oracle WebLogic Serversがリスニングするポートではないポート値でロード・バランサ・アドレスを作成する場合に、ロード・バランサのアドレスとしてサーバーURL (SOAインフラストラクチャの「共通プロパティ」ページ)、およびフロントエンド・ホスト/ポート(Oracle WebLogic Serverの「HTTP」タブ内)を指定できますか。 |
可サーバーURL、またはフロントエンド・ホスト/ポートは、ローカル最適化ルールのアドレスの識別子としてネットワーク・リクエストの送信先の実際のアドレスより詳細度が高くなります。 |
|
コールを実行する際にローカル最適化でポートを使用しませんか(たとえば、ポート |
使用します。このポートは、ローカル・コールを実行するために、ターゲットが関連付けられているかどうかを調べる比較の実行のみに使用されます。 |
構成プランはコンポジット別です。このため、SOAコンポジット・アプリケーションを環境間で移動すると、構成プランのそれぞれで一部の値の置き換えが必要になります。各プランの値の置換を回避するため、Oracle Enterprise Manager Fusion Middleware ControlのSOAコンポジット・アプリケーションの特定のURIにグローバル・トークン変数を定義できます。
グローバル・トークン変数には、次の利点があります。
複数のSOAコンポジット・アプリケーションが特定のサーバー上でホストされる複数の異なるサービスを起動する場合は、単一のグローバル・トークン変数を使用して、コンポジット間でこのサーバーを参照できます。個別の構成プランが不要になり単一のトークン値セットを更新すれば済むため、開発作業が簡素化されます。たとえば、10個の異なる構成プランでサーバーのホスト名を更新するかわりに、グローバル・トークン変数を使用してこの名前をグローバルに設定します。この値は、デプロイされたSOAコンポジット・アプリケーションのcomposite.xmlファイルのbinding.ws要素内のホスト名のグローバル・トークン変数の値を取得および置換します。
グローバル・トークン変数を使用することは、実行時サーバーにデプロイされるOracle SOA Suiteメタデータには環境固有値が含まれていないことを意味します。
クラスタ環境では、グローバル・トークン変数の変更が管理サーバーで実行され、管理対象サーバーのすべてに伝播されます。
グローバル・トークン変数の管理には、次のオプションを使用できます。
Oracle Enterprise Manager Fusion Middleware Controlの「トークン構成」ページを使用して、グローバル・トークン変数の管理(作成、編集および削除)を行います。
トークンは、ws.bindingロケーションのホスト、ポート、プロトコル、およびreferenceタグ内のすべてのプロパティのみでサポートされます。
serverURLという名前の事前定義のグローバル・トークン変数を使用します。
|
注意:
|
トークン構成ページでは、グローバル・トークン変数を管理できます。このページでは、次の操作を実行できます。
ローカルmdm-url-resolver.xmlファイルからの変数をシステムのmdm-url-resolver.xmlファイルに追加して、必要に応じて編集します。
システムのmdm-url-resolver.xmlファイル内の変数を管理します。
「トークン構成」ページでトークン変数を管理する手順は次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「トークン構成」ページが表示されます。
実行するグローバル・トークン変数の構成アクションを選択します。
ローカル・ファイルの変数を追加するには、次の手順を実行します。
「トークンの一括追加」をクリックします。
「参照」をクリックして、ローカル・ファイル・システムからmdm-url-resolver.xmlファイルを選択します。アップロードを成功させるには、ローカル・ファイルが次の書式に従っている必要があります。この例では、ホスト名、ポートおよびプロトコルにグローバル・トークン変数が定義されています。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>
URL Resolver file used by the Metadata manager to resolve $<variable>
in URLs
</comment>
<entry key="host">mymachine.us.example.com</entry>
<entry key="port">8001</entry>
<entry key="protocol">http</entry>
</properties>
「追加」をクリックします。
ローカル・ファイルのコンテンツが、システムのmdm-url-resolver.xmlファイルのコンテンツに追加されます。システムのmdm-url-resolver.xmlファイルに既存のグローバル・トークン変数は上書きされません。
変数の編集が必要な場合は、「構成ファイルの変更」をクリックして、手順5に進みます。
システムのmdm-url-resolver.xmlファイル内の変数を管理するには、次の手順を実行します。
「構成ファイルの変更」をクリックします。
最初に「トークンの一括追加」を選択してファイルをアップロードした場合は、ローカルmdm-url-resolver.xmlファイルとシステムのmdm-url-resolver.xmlファイルのグローバル・トークン変数のトークン名と値が表書式で表示されます。変数に重複はなく、ローカル・ファイルの変数がシステム・ファイルに既存の場合は表示されません。
最初に「構成ファイルの変更」を選択した場合は、システムのmdm-url-resolver.xmlファイル内のグローバル・トークン変数がトークン名と変数が表書式で表示されます。
管理対象のグローバル・トークン変数を選択して、特定のタスクを実行します。
|
注意: 変更の実行後は、「トークンの一括追加」モードに切り替えたり、このページから移動する前に「コミット」をクリックする必要があります。これらのアクションを実行するとコミットされていない変更が失われます。 |
| 要素 | 説明 |
|---|---|
 |
|
 |
|
 |
|
 |
|
 |
|
トークン値の追加、変更、または削除の実行後は、SOAインフラストラクチャを再起動してください。詳細は、第3.2項「管理対象サーバーとSOAインフラストラクチャの停止と起動」を参照してください。
更新内容がクラスタ全体に伝播されます。
実行時にグローバル・トークン変数を置換する方法の詳細は、第3.8.2項「実行時にグローバル・トークン変数を置換する方法」を参照してください。
|
注意: Oracle Enterprise Manager Fusion Middleware Controlにグローバル・トークン変数を使用するSOAコンポジット・アプリケーションをデプロイすると、システムの |
トークン構成ページで指定したトークン名と置換値が、次のディレクトリにあるシステムのmdm-url-resolver.xmlファイルに追加されています。
$MIDDLEWARE_HOME/user_projects/domains/domain_name/config/fmwconfig/
mdm-url-resolver.xml
たとえば、トークン構成ページを使用して、4つのグローバル・トークン変数名と値が定義されているとします。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>
URL Resolver file used by the Metadata manager to resolve $<variable> in
URLs
</comment>
<entry key="myprotocol">http</entry>
<entry key="myhost">mymachine.us.example.com</entry>
<entry key="myport">8001</entry>
</properties>
デプロイされたSOAコンポジット・アプリケーションのcomposite.xmlが実行時にロードされ、ファイル内のURIによって指定されたリソースが取得されると、URI内のグローバル・トークン変数の値がトークン構成ページで指定された値に置き換えられます。
たとえば、次のcomposite.xmlファイルは、これらのトークンを使用してbinding.ws要素のURIを指定します。
<?xml version="1.0" encoding="UTF-8"?>
<composite...>
. . .
. . .
<reference name="Service" ui:wsdlLocation="...">
. . .
<binding.ws port="..."
location="${myprotocol}://${myhost}:${myport}/soa-infra/services/default/
mycomposite/bpelprocess1_client_ep?WSDL" soapVersion="1.1">
</binding.ws>
</reference>
. . .
</composite>
実行時にWSDL定義ファイルが取得される場合、トークンはmdm-url-resolver.xml構成ファイル内の値によって置き換えられ、次のURIが作成されます。
http://mymachine.us.example.com:8001/soa-infra/services/default/myComposite/ bpelprocess1_client_ep?WSDL
リソースURLではserverURLという名前の事前定義のグローバル・トークン変数を使用できます。このトークンは、実行時にOracle Enterprise Manager Fusion Middleware ControlのSOAインフラストラクチャの「共通プロパティ」ページの「サーバーURL」プロパティの設定によって置き換えられます。
事前定義のグローバル・トークン変数を使用する手順は次のとおりです。
SOAインフラストラクチャの「共通プロパティ」ページの「サーバーURL」フィールドに値(例: my.host.com:8080)を入力します。このプロパティを変更した場合は、サーバーの再起動が必要です。図3-2に詳細を示します。
composite.xmlファイルにserverURLトークンを入力します。
${serverURL}/somePath/someResource.xml
serverURLトークンには、プロトコル(http、また、SSLが有効化されている場合はhttps)が含まれています。
これで、デプロイメント時にトークンが置換された後に次のURIが生成されます。
http://my.host.com:8080/somePath/someResource.xml
「サーバーURL」プロパティ、およびSOAインフラストラクチャの「共通プロパティ」ページの詳細は、第3.1項「SOAインフラストラクチャ・プロパティの構成」を参照してください。
