| Oracle Fusion Middleware Oracle SOA Suite管理者ガイド 11g リリース1（11.1.1） B55916-01 |
|
 戻る |
 次へ |
この章では、SOAコンポジット・アプリケーションの管理方法について説明します。これには、アプリケーションのテスト・インスタンスの起動、フォルト管理、ポリシー管理、インスタンスの状態管理、およびSOAコンポジット・アプリケーションのテストが含まれます。
この章の内容は、次のとおりです。
|
注意: このガイドでは、「SOAインフラストラクチャ」メニュー、ナビゲータの「soa-infra」アイコン、および「SOAコンポジット」メニューからOracle Enterprise Manager Fusion Middleware Controlコンソールの各ページにアクセスする手順について説明しています。 また、ファーム・ホーム・ページからも多くのページにアクセスできます。 詳細は、第2.2.5項「SOAインフラストラクチャまたはSOAコンポジット・アプリケーションのホーム・ページへの移動」を参照してください。 |
この章では、デプロイ済SOAコンポジット・アプリケーションのテスト・インスタンスを起動する方法について説明します。
SOAコンポジット・アプリケーションのテスト・インスタンスを起動する手順は、次のとおりです
ページには、次のいずれかの手順でアクセスします。
| 「SOAインフラストラクチャ」メニューからアクセスする手順 | ナビゲータの「SOA」フォルダからアクセスする手順 | 「コンポジット」メニューからアクセスする手順 |
|---|---|---|
|
|
|
コンポジットに複数のサービスが含まれる場合は、「テスト」ボタンにドロップダウン・リストが表示され、テストするサービスを選択できます。
インスタンスを起動するための「Webサービスのテスト」ページが表示されます。
このページには、インスタンスを起動するための様々なオプションが用意されています。「引数を入力」セクションでは、少なくとも、使用するXMLペイロード・データを指定する必要があります。
テスト対象として選択したサービスに基づいて、WSDLファイルおよびエンドポイントURLが自動的に移入されます。 エンドポイントURLはWSDLから導出され、そのサービスを異なる場所で起動する場合は上書きできます。 選択したサービスに複数のポートがある場合は、ドロップダウン・リストが表示されます。 そうでない場合は、現在のサービスのポートが表示されます。
次の各フィールドではデフォルト値をそのまま使用するか、使用するテスト環境に適した値を入力します。
WSDLファイルを変更する場合は、「WSDL解析」をクリックしてWSDLファイルをリロードします。
リビジョン番号が含まれていないWSDL URLは、デフォルトのコンポジット・アプリケーションによって処理されます。 たとえば、HelloWorldという名前のコンポジット・アプリケーションにリビジョンが2つ存在する場合は、次のエンドポイントが公開されます。
http://host:port/soa-infra/services/default/HelloWorld!1.0/client
http://host:port/soa-infra/services/default/HelloWorld!2.0/client
ただし、Webサービスの起動用に指定したWSDLにリビジョンの詳細が含まれていない場合（たとえば、http://host:port/soa-infra/services/default/HelloWorld/client）は、デフォルトとして設定されたコンポジット・リビジョンによって処理されます。
エンドポイントURLを編集する場合は、「エンドポイントURLの編集」をクリックして適切に変更します。
「Webサービスのテスト」ページの下部には、「リクエスト」タブがあります。 このタブでは、セキュリティ、サービスのクオリティ、HTTPトランスポート、ストレス・テスト・オプションおよびXML入力引数を指定できます。
「セキュリティ」セクションには、メッセージを使用してセキュリティ・プロパティを渡すための次のフィールドがあります。
| フィールド | 説明 |
|---|---|
| WSSユーザー名トークン | WSセキュリティのSOAPヘッダーを挿入します。 「ユーザー名」フィールドは必須で、「パスワード」フィールドはオプションです。 |
| HTTP Basic認証 | ユーザー名とパスワード資格証明をHTTPトランスポート・ヘッダーに挿入します。 「ユーザー名」および「パスワード」フィールドは両方とも必須です。 |
| カスタム・ポリシー | カスタム・ポリシーを使用してユーザーを認証します（カスタム・ポリシーのURIを指定します）。 「ユーザー名」および「パスワード」フィールドはオプションです。 |
| なし | セキュリティ資格証明を指定しない場合に選択します。これがデフォルトの選択です。 |
次の各フィールドではデフォルト値をそのまま使用するか、使用するテスト環境に適した値を入力します。
「サービスのクオリティ」セクションには、次のフィールドがあります。Oracle Fusion Middlewareでは、ポリシー・ベースのモデルを使用してWebサービスを管理します。 ポリシーでは、メッセージ配信に対して動作要件が適用されます。 「Webサービスのテスト」ページの使用方法の詳細は、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』を参照してください。
| フィールド | 説明 |
|---|---|
| WS-RM | 次のオプションのいずれかを選択して、WS信頼できるメッセージング（RM）プロトコル・ポリシーをテストします。 信頼できるメッセージング・ポリシーによって、このプロトコルがサポートされ、メッセージのエンドツーエンド配信が保証されます。
|
| MTOM | 次のオプションのいずれかを選択して、メッセージ転送最適化メカニズム（MTOM）ポリシーをテストします。MTOMポリシーによって、添付がMTOMフォーマットであることが保証されます。このフォーマットは、Webサービスとの間でバイナリ・データを効率的に送受信するためのフォーマットです。
|
| WSアドレス | 次のオプションのいずれかを選択して、WSアドレス・ポリシーをテストします。WSアドレス・ポリシーによって、WSアドレス仕様に準拠したWS-AddressingヘッダーがSOAPメッセージに含まれていることが検証されます。
|
次の各フィールドではデフォルト値をそのまま使用するか、使用するテスト環境に適した値を入力します。
「HTTPトランスポート・オプション」セクションには、次のフィールドがあります。
| フィールド | 説明 |
|---|---|
| SOAPアクションの有効化 | WSDL soap:operationにsoapAction属性があるかどうかを指定します。 このフラグは、soapAction属性が存在する場合に有効になります。 SOAPアクションのHTTPヘッダーを使用してリクエストを送信しない場合は、このチェック・ボックスの選択を解除します。 |
| SOAPアクション | WSDL soap:operationのsoapAction属性が表示されます（存在する場合）。 このテキスト・ボックスで別のSOAPアクションを指定することもできます。 |
次の各フィールドではデフォルト値をそのまま使用するか、使用するテスト環境に適した値を入力します。
「追加テスト・オプション」セクションには、次のフィールドがあります。このセクションでは、複数インスタンスを同時に起動する簡単なストレス・テストを指定します。
| フィールド | 説明 |
|---|---|
| ストレス・テストの有効化 | 「有効化」をクリックして、簡単なストレス・テストを作成します。 このオプションを有効にすると、対話IDは表示されません。 |
| 同時スレッド | 起動が送信される同時スレッドの数を入力します。 デフォルトは5スレッドです。 |
| スレッドごとのループ | 操作を起動する回数を入力します。 デフォルトは10回です。 |
| ミリ秒単位の遅延 | 次の操作を起動するまでの遅延をミリ秒単位で指定します。 デフォルトは1000ミリ秒（1秒）です。 |
次の各フィールドではデフォルト値をそのまま使用するか、使用するテスト環境に適した値を入力します。
「引数を入力」セクションには、XMLペイロード・データを入力するための次のオプションがあります。
| フィールド | 説明 |
|---|---|
| ツリー表示 | 情報を入力するテキスト・フィールドのグラフィカル・インタフェースが表示されます。このオプションを選択すると、必要なヘッダーとXML構造が自動的に生成されます。 |
| XML表示 | 値の挿入のためのXMLファイル・フォーマットが表示されます。このフィールドには、メッセージのraw XMLペイロードを貼り付けることができます。 |
「Webサービスのテスト」をクリックします。
テストを終了すると、「レスポンス」タブに結果が表示されます。
「メッセージ・フロー・トレースの起動」をクリックして、インスタンスのフローのトレースにアクセスします。
コンポジットのホーム・ページに戻るには、ページの上部に表示されるコンポジット名をクリックするか、コンポジット・ターゲット・メニューから「ホーム」を選択します。
SOAコンポジット・アプリケーションの「ダッシュボード」ページに戻ります。
「最新のインスタンス」表に、最新のSOAコンポジット・アプリケーションのインスタンスがリストされます。 作成された各インスタンスには、固有のIDが付いています。
詳細は、次の各項を参照してください。
インスタンスの概念の詳細は、第1.2.3項「SOAコンポジット・アプリケーション・インスタンスの理解」を参照してください。
ポリシーの概要については、第1.3.3.2項「ポリシーの理解」を参照してください。
「Webサービスのテスト」ページからのWebサービスのテスト、およびポリシーに関する具体的な詳細は、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』を参照してください。
デプロイ済SOAコンポジット・アプリケーションのライフ・サイクルの状態は、次の2つのページのいずれかで管理できます。
SOAインフラストラクチャの「デプロイ済コンポジット」ページ。このページには、SOAインフラストラクチャにデプロイされたすべてのSOAコンポジット・アプリケーションがリストされます。
特定のSOAコンポジット・アプリケーションのアプリケーション・ホーム・ページ（すべてのタブ）。
実行できる管理タスクは、使用しているページによって異なります。表8-1に詳細を示します。
表8-1 アプリケーションの状態に関するアクション
| アクション | SOAインフラストラクチャの「デプロイ済コンポジット」ページでの実行の可否 | アプリケーションのホーム・ページ（すべてのタブ）での実行の可否 |
|---|---|---|
|
停止と起動 |
可 |
可 |
|
リタイアとアクティブ化 |
可 |
可 |
|
デフォルトとして設定 |
可 |
|
|
デプロイ |
可 |
可（「コンポジット」メニューから「SOAデプロイ」→「別のコンポジットをデプロイ」の順に選択） |
|
アンデプロイ |
可 |
可（「コンポジット」メニューから「SOAデプロイ」→「アンデプロイ」の順に選択） |
|
再デプロイ |
可 |
可（「コンポジット」メニューから「SOAデプロイ」→「再デプロイ」の順に選択） |
|
テスト |
不可 |
可 |
|
コンポジットの監査レベル |
不可 |
可 |
|
ペイロードの検証 |
不可 |
可 |
|
WSDLおよびエンドポイントURIの表示（アイコン） |
不可 |
可 |
|
XML定義の表示（アイコン） |
不可 |
可 |
実行するアクションに応じて、次の各項を参照してください。
詳細は、第1.2.2項「SOAコンポジット・アプリケーションの理解」を参照してください。
すべてのSOAコンポジット・アプリケーションの状態は、SOAインフラストラクチャ・レベルで、「デプロイ済コンポジット」ページから管理できます。
SOAインフラストラクチャ・レベルですべてのアプリケーションの状態を管理する手順は、次のとおりです。
ページには、次のいずれかの手順でアクセスします。
| 「SOAインフラストラクチャ」メニューからアクセスする手順 | ナビゲータの「SOA」フォルダからアクセスする手順 | 「SOAコンポジット」メニューからアクセスする手順 |
|---|---|---|
|
|
|
「デプロイ済コンポジット」タブをクリックします。
「デプロイ済コンポジット」ページに、次の詳細が表示されます。
特定のSOAコンポジット・アプリケーションを検索するためのユーティリティ。コンポジット名の全部または一部を指定して「検索」をクリックします。
SOAインフラストラクチャにデプロイされたすべてのSOAコンポジット・アプリケーションのリスト。現在のモード（「アクティブ」または「リタイア）、インスタンスの数、失敗したインスタンスの数、および最終更新日時（デプロイメント時間、再デプロイメント時間、またはコンポジットの構成変更）が表示されます。 名前の左にある緑色の丸印は、それがアプリケーションのデフォルトのリビジョンであることを示しています。
|
注意: デプロイ済SOAコンポジット・アプリケーションに関する最新の詳細を表示するには、右上隅にある「リフレッシュ」アイコンをクリックするか、他のページに移動してこのページに戻ります。 |
「デプロイ」をクリックして新しいアプリケーションをデプロイします。 「コンポジット」セクションの上にリストされている他のすべてのオプションについては、最初にコンポジット・アプリケーション名の左の列をクリックしてコンポジット・アプリケーションを選択し、次に実行する特定のオプションを選択します。
次の表に、使用可能なオプションを示します。
| アクション | 説明 |
|---|---|
| 停止 | 実行中のSOAコンポジット・アプリケーション・リビジョンを停止します。 コンポジットが停止している場合、コンポジットへのリクエスト（開始リクエストまたはコールバック・リクエスト）はすべて拒否されます。
注意: 使用するバインディング・コンポーネントに応じて動作が異なります。 たとえば、Webサービス・リクエストの場合は、拒否されてコール元に戻されます。 同様の場合でも、JCAアダプタ・バインディング・コンポーネントでは動作が異なります（たとえば、リクエストを拒否表に格納します）。 このオプションは、コンポジット・アプリケーションが開始されると表示されます。 |
| 起動 | 停止したコンポジット・アプリケーション・リビジョンを再起動します。 このアクションによって、新規リクエストが処理されます（拒否されません）。 メッセージのリカバリは発生しません。
このオプションは、コンポジット・アプリケーションが停止されると表示されます。 |
| リタイア | 選択したコンポジット・リビジョンをリタイア状態にします。プロセスのライフ・サイクルがリタイア状態の場合、新しいインスタンスは作成できません。 既存のインスタンスは正常に完了できます。
コンポジット・アプリケーションへの開始リクエストは拒否されてコール元に戻されます。 バインディング・コンポーネントが異なる場合の拒否の動作については、前述の「停止」オプションで説明しています。 起動したコンポジット・アプリケーション・インスタンスへのコールバックは適切に配信されます。 このオプションは、コンポジット・アプリケーションがアクティブのときに表示されます。 |
| アクティブ化 | リタイア状態のコンポジット・アプリケーション・リビジョンをアクティブにします。 このオプションを選択した場合の動作は次のとおりです。
このオプションは、アプリケーションがリタイア状態のときに表示されます。 |
| デフォルトとして設定 | 選択したコンポジット・アプリケーション・リビジョンをデフォルトとして設定します。 「コンポジット」表では、デフォルトのリビジョンに緑色の丸印が付いています。 特定のコンポジット・アプリケーション・リビジョンに対する新規リクエストを受信すると、そのコンポジット・アプリケーション・リビジョンが起動します。 リビジョンが指定されていない新規リクエストを受信すると、デフォルトのリビジョンが起動します。 コンポジット・アプリケーションがリタイア状態の場合は、デフォルトのリビジョンを変更できません。 デフォルトのコンポジット・アプリケーション・リビジョンがアンデプロイされると、デフォルトのリビジョンは自動的に変更されます。
コンポジットを再デプロイした場合も、デフォルトのコンポジット・リビジョンは自動的に変更されます。 再デプロイメント時に以前のデフォルトのリビジョンをデフォルトのままにするように指定しないかぎり、新規に再デプロイしたリビジョンが自動的にデフォルトのリビジョンになります。 デフォルトのリビジョンでアクティブ化されるのはインバウンド・アダプタのみであることに注意してください。 |
| デプロイ | リビジョンをデプロイします。 デプロイメントによって、SOAインフラストラクチャのコンポジット・アプリケーションがアクティブ化されます。 デプロイする場合は次の内容を選択します。
すでに存在するリビジョンを指定すると、エラーが発生します。 このリビジョンは、SOAコンポジットのデプロイ・ウィザードを使用して変更できません。 注意: 複数のSOAコンポジット・アプリケーションを同時にデプロイする機能がサポートされています。 詳細は、第5.1項「アプリケーションのデプロイ」を参照してください。 |
| アンデプロイ | 選択したコンポジット・アプリケーション・リビジョンをアンデプロイします。 このアクションを実行すると、次のような結果になります。
注意: 複数のSOAコンポジット・アプリケーションを同時にアンデプロイする機能がサポートされています。 詳細は、第5.3項「アプリケーションのアンデプロイ」を参照してください。 |
| 再デプロイ | SOAコンポジット・アプリケーションの既存のリビジョンを再デプロイします。 このアクションを実行すると、次のような結果になります。
詳細は、第5.2項「アプリケーションの再デプロイ」を参照してください。 |
詳細は、第1.3.3.3項「SOAコンポジット・アプリケーションのライフ・サイクルの状態の理解」を参照してください。
個々のSOAコンポジット・アプリケーションの状態は、アプリケーションのホーム・ページで管理できます。
SOAコンポジット・アプリケーションのホーム・ページでアプリケーションの状態を管理する手順は、次のとおりです。
ページには、次のいずれかの手順でアクセスします。
| 「SOAインフラストラクチャ」メニューからアクセスする手順 | ナビゲータの「SOA」フォルダからアクセスする手順 |
|---|---|
|
|
選択したSOAコンポジット・アプリケーションのダッシュボードが表示されます（この例では、AutoLoanComposite）。
|
注意: 「最新のインスタンス」セクションの「合計」フィールドには、インスタンスが正常に完了している場合でも、正しい合計インスタンス数が表示されない場合があります。 その場合は、右上隅の「リフレッシュ」アイコンをクリックすると、実際の合計インスタンス数が表示されます。 |
ページの上部にあるオプションのリストから、実行するアクションを選択します。 これらのオプションは、SOAコンポジット・アプリケーションの「インスタンス」、「フォルト・メッセージと拒否メッセージ」、「ユニット・テスト」および「ポリシー」ページの上部にも表示されます。
| アクション | 説明 |
|---|---|
| 停止 | このオプションの説明は、手順3の表を参照してください。 |
| 起動 | このオプションの説明は、手順3の表を参照してください。 |
| リタイア | このオプションの説明は、手順3の表を参照してください。 |
| アクティブ化 | このオプションの説明は、手順3の表を参照してください。 |
| 設定: コンポジットの監査レベル | SOAコンポジット・アプリケーション・レベルで実行される監査トラッキングのレベルを設定します。 この設定によって、SOAインフラストラクチャ・レベルで定義した監査レベルを上書きできます。 デフォルト値は「継承」で、SOAインフラストラクチャ・レベルの設定は上書きされません。
監査トラッキングのレベルを設定する場合は、次のオプションが選択可能です。
SOAコンポジット・アプリケーション・レベルで監査レベル・トラッキングを設定すると、SOAインフラストラクチャ・レベルで設定した同じトラッキングが上書きされます。 デフォルトでは、SOAコンポジット・アプリケーション・レベルとSOAインフラストラクチャ・レベルの設定は同じです。 グローバルなSOAインフラストラクチャの設定が変更されると、SOAコンポジット・アプリケーションの設定も自動的に変更されます。 ただし、SOAコンポジット・アプリケーション・レベルで別の設定を選択すると、継承された設定を上書きできます。 現在のグローバル値と同じローカル・コンポジット値を明示的に選択した場合も、設定が上書きされます。 この場合、SOAインフラストラクチャの設定が変更されても、そのコンポジットは新しい値を継承しません。 たとえば、SOAインフラストラクチャの設定が「オフ」であるとします。 これによって、すべてのコンポジットは監査トラッキングが「オフ」に設定されます。 ここで、コンポジットXYZを明示的に「オフ」に設定したとします。 次に、SOAインフラストラクチャに移動して、その設定を「本番」に変更します。 その結果、コンポジットXYZを除くすべてのコンポジットのトラッキング・レベルは「本番」に変更されますが、コンポジットXYZの設定は「オフ」のままです。 複数のSOAコンポジット・アプリケーションにわたるメッセージ・フローでは、インスタンス・トラッキングの設定によって次のように表示が変わることに注意してください。 たとえば、参照バインディング・コンポーネントを介して別のコンポジットを起動するコンポジット、または、あるコンポジットで公開されて別のコンポジットでサブスクライブされたイベントの場合です。
|
| 設定: ペイロードの検証 | コンポジット・リビジョンのインバウンド・ポイントとアウトバウンド・ポイントで、XMLスキーマ・ベースのペイロードを検証します。 ペイロードの検証を有効にし、無効なペイロード（スキーマに準拠しない）がある場合は、そのメッセージに対してフォルトが生成されます。
ただし、同期サービスのレスポンス・メッセージは例外です。 このメッセージは、ペイロードの検証が有効な場合でも検証されません。 検証されないのはアウトバウンド・メッセージのみで、インバウンド・メッセージは検証されることに注意してください。 |
| テスト | 「Webサービスのテスト」ページからテスト・インスタンスを起動できます。
注意: SOAコンポジット・アプリケーションが停止状態またはリタイア状態の場合、このボタンは無効です。 これは、停止状態またはリタイア状態のアプリケーションのインスタンスは作成できないためです。 このボタンは、アプリケーションに対して使用可能なWebサービスがない場合も無効です。 このページからテストできるのは、Webサービス・バインディングがあるサービスを含むコンポジットのみです。 詳細は、第8.1項「SOAコンポジット・アプリケーションのテスト・インスタンスの起動」を参照してください。 |
| WSDLおよびエンドポイントURIの表示（アイコン） | クリックすると、このSOAコンポジット・アプリケーションに対するすべての外部サービスのエンドポイント・アドレスおよびWSDLが表示されます。 |
| コンポジットXML定義の表示（アイコン） | クリックすると、SOAコンポジット・アプリケーションのXML定義が表示されます。 |
詳細は、次の各項を参照してください。
SOAコンポジット・アプリケーションでのBPELプロセスの途中で、SOAインフラストラクチャがデプロイされている管理対象のOracle WebLogic Serverを起動および停止する場合は、次の問題に注意してください。
同期BPELプロセスの場合
シナリオ全体が同期され、実行中の状態（サーバーの再起動後）のインスタンスはBPELのwaitアクティビティで保留されます。 このため、フロー・スレッドはサーバーで終了します（waitアクティビティで保留中）。 サーバーが再起動しても、フローは同期であるため、同じインスタンスは再起動されません。 したがって、サーバーの再起動後もインスタンスで処理が発生しないため、これらのインスタンスは常に実行中の状態です。
非同期BPELプロセスの場合
BPELのinvokeアクティビティの途中でサーバーが停止すると、BPELが受信したメッセージは処理されません。 BPELは再起動時にこれらのメッセージを自動的にリカバリしないため、Facade APIコールを使用してメッセージを手動でリカバリする必要があります。
第8.2項「デプロイ済SOAコンポジット・アプリケーションの状態管理」では、SOAコンポジット・アプリケーションのライフ・サイクルの状態を管理する方法を説明しました。 アプリケーションのホーム・ページの「インスタンス」ページでは、特定のSOAコンポジット・アプリケーションのインスタンスを監視および削除することもできます。
アプリケーションのホーム・ページからSOAコンポジット・アプリケーションのインスタンスを監視および削除する手順は、次のとおりです。
ページには、次のいずれかの手順でアクセスします。
| 「SOAインフラストラクチャ」メニューからアクセスする手順 | ナビゲータの「SOA」フォルダからアクセスする手順 |
|---|---|
|
|
「インスタンス」タブをクリックします。
「インスタンス」ページに、次の詳細が表示されます。
特定のインスタンスを検索するためのユーティリティ。基準を指定して「検索」をクリックします。
SOAコンポジット・アプリケーションのインスタンスID、名前、対話ID、ページの最終データ・リフレッシュ以降の各インスタンスの最新状態（正常完了、実行中、不明など）、インスタンスの開始時間、フォルトが記述されているログ・ファイル。 SOAコンポジット・アプリケーションの新しいインスタンスが起動されるたびに、一意のインスタンスIDが作成されます。インスタンスは、アプリケーションの外部コンシューマによって自動的に起動されるか、管理者が「Webサービスのテスト」ページから手動で起動します。
「?」アイコンが表示される場合は、SOAインフラストラクチャの「共有プロパティ」ページで「コンポジット・インスタンスの状態をキャプチャ」チェック・ボックスが選択されていません。 このため、インスタンスの状態が評価されません。 コンポジット・インスタンスの状態を判別するには、基礎となるコンポーネントの状態を評価する必要があります。パフォーマンスを向上させるには、このチェック・ボックスを選択しません。
|
注意: 孤立したサービス・コンポーネント・インスタンスが生成される可能性があります。 このようなインスタンスは、関連するコンポジット・アプリケーション・インスタンスなしで生成されます。 孤立したコンポーネント・インスタンスは、次の状況で生成されます。
孤立したインスタンスまたは大量のインスタンスを削除するには、第8.9項「大量のインスタンスの削除」で説明するように、PL/SQLのpurgeスクリプトを使用します。 「オプションを指定して削除」ダイアログで「すべてのインスタンスを削除」オプションを選択しても、孤立したコンポーネント・インスタンスを削除できます。 ただし、大量（たとえば、数千）のインスタンスを削除する場合は、操作がタイムアウトになるため、この方法はお薦めできません。 |
コンポジット・センサーがSOAコンポジット・アプリケーションに組み込まれている場合は、「インスタンス」タブの表示が次のように異なります。
検索ユーティリティにある「検索」および「リセット」ボタンの横に、「フィールドの追加」ボタンが表示されます。 このボタンを使用して、センサー値を検索基準に追加できます。
「インスタンス」表に「コンポジット・センサー」列が表示されます。 この列のセンサー・アイコンをクリックすると、コンポジットの指定のインスタンスで使用可能なセンサー値の詳細が表示されます。
「フィールドの追加」リストから、検索基準に追加するコンポジット・センサーを選択します。 次の例では、4つのフィールドが選択されています（CustomerDetails、NameSensor、DatesensorおよびYearsensor）。
各センサーが検索する特定の値を入力します。 指定した基準とセンサー値が一致するコンポジット・インスタンスのみ返されます。
検索基準からすべてのコンポジット・センサー・フィールドを削除するには、「リセット」をクリックします。センサーを個別に削除するには、フィールドの右側にある「削除」アイコンをクリックします。
「インスタンス」表の行をクリックして、削除する特定のインスタンスを選択します。 複数のインスタンスを選択する場合は、[Ctrl]キーまたは[Shift]キーを押しながら、選択する行をクリックします。
実行する特定のアクションを選択します。
| アクション | 説明 |
|---|---|
| 選択項目の削除 | 選択したインスタンスを削除します。
インスタンスを削除すると、インスタンス詳細は確認できなくなります。 |
| オプションを指定して削除 | 選択したインスタンスをデータベースから直接削除するための基準を最初に指定するように、プロンプトが表示されます。
この操作では、「インスタンス」ページで選択した内容（検索基準の指定や実行など）は無視されます。 |
| 中断 | 選択したインスタンスを終了します。 ただし、インスタンス詳細は確認できます。 |
「インスタンス」表で、次の追加タスクを実行します。
「インスタンスID」列で、特定のインスタンスIDをクリックし、様々なサービス・コンポーネントやバインディング・コンポーネント間のメッセージ・フローを表示します。 インスタンスIDが使用不可能と表示される場合は、「使用不可能」リンクをクリックすると詳細を表示できます。
「状態」列にインスタンスの状態が「不明」と表示される場合は、クリックすると詳細が表示されます。
「コンポジット・センサー」列が表示されている場合は、センサー・アイコンをクリックすると、インスタンスに組み込まれているコンポジット・センサーの詳細（名前、場所、値など）が表示されます。
「ログ」列で、特定のログをクリックし、「ログ・メッセージ」ページにアクセスします。このページには、そのインスタンスに固有のメッセージがフィルタされて表示されます。
詳細は、次の各項を参照してください。
Oracle MediatorおよびOracle BPEL Process Managerで、設計時にSOAコンポジット・アプリケーションのインスタンス名を設定できます。 このインスタンス名は、SOAコンポジット・アプリケーションの「インスタンス」ページにある「名前」列に表示されます。 SOAコンポジット・アプリケーションまたはSOAインフラストラクチャの「インスタンス」ページに検索基準を指定するときに、この名前を「名前」フィールドに指定できます。
次のいずれかの方法で、コンポジット・インスタンス名を設定します。
「値の割当て」ダイアログで、setCompositeInstanceTitle(title) XPath式関数をソースとして使用し、tracking.compositeInstanceTitleをターゲット・プロパティ名として使用します。
XSLTマッパーで、setCompositeInstanceTitle(title) XPath式関数を使用します。
第8.2項「デプロイ済SOAコンポジット・アプリケーションの状態管理」では、特定のSOAコンポジット・アプリケーションの全インスタンスのライフ・サイクルの状態を管理する方法を説明しました。 SOAインフラストラクチャのホーム・ページの「インスタンス」ページでは、デプロイされたすべてのSOAコンポジット・アプリケーションから任意の数のインスタンスを監視および削除することもできます。このページには、SOAインフラストラクチャにデプロイされたすべてのSOAコンポジット・アプリケーション・インスタンスがリストされます。
SOAインフラストラクチャ・レベルでSOAコンポジット・アプリケーションのインスタンスを監視および削除する手順は、次のとおりです。
ページには、次のいずれかの手順でアクセスします。
| 「SOAインフラストラクチャ」メニューからアクセスする手順 | ナビゲータの「SOA」フォルダからアクセスする手順 | 「SOAコンポジット」メニューからアクセスする手順 |
|---|---|---|
|
|
|
「インスタンス」タブをクリックします。
「インスタンス」ページに、次の詳細が表示されます。
特定のインスタンスを検索するためのユーティリティ。基準を指定して「検索」をクリックします。
SOAインフラストラクチャのすべてのSOAコンポジット・アプリケーション・インスタンス。インスタンスID、対話ID、コンポジットの名前とリビジョン、SOAコンポジット・アプリケーション・インスタンスの状態、およびインスタンスの開始時間が表示されます。
このページからインスタンスの終了および削除も実行できます。
「インスタンス」表の行をクリックして、特定のインスタンスを選択します。 複数のインスタンスを選択する場合は、[Ctrl]キーまたは[Shift]キーを押しながら、選択する行をクリックします。
実行する特定のアクションを選択します。
| アクション | 説明 |
|---|---|
| 選択項目の削除 | 選択したインスタンスを削除します。 |
| オプションを指定して削除 | 選択したインスタンスをデータベースから直接削除するための基準を最初に指定するように、プロンプトが表示されます。
この操作では、「インスタンス」ページの上部で選択したインスタンスの状態は無視されます。 注意:
|
| 中断 | 選択したインスタンスを終了します。 ただし、インスタンス詳細は確認できます。
注意: フォルトが発生したインスタンスを削除すると、そのフォルトは「フォルト・メッセージと拒否メッセージ」ページに表示されなくなります。 さらに、終了したインスタンス（「中断」と表示）にフォルトがある場合、そのフォルトはフォルト件数に含まれません。 |
「インスタンスID」列で、特定のインスタンスIDをクリックし、様々なサービス・コンポーネントやバインディング・コンポーネント間のメッセージ・フローを表示します。 インスタンスIDが使用不可能の場合は、メッセージ・フローにアクセスできません。 ただし、リンクをクリックして詳細を確認することはできます。
「コンポジット」列で、特定のSOAコンポジット・アプリケーションをクリックし、そのホーム・ページにアクセスします。
「ログ」列で、特定のログをクリックし、「ログ・メッセージ」ページにアクセスします。このページには、そのインスタンスに固有のメッセージがフィルタされて表示されます。
複数のSOAコンポジット・アプリケーションでBPELプロセスとOracle Mediatorサービス・コンポーネントを監視し、個別のフォルト・リカバリと一括のフォルト・リカバリを実行できます。 リカバリ可能として識別されたBPELプロセス・フォルトについては、（fault-bindings.xmlファイルを介して）フォルトにバインドされ、アクションora-human-interventionをトリガーするフォルト・ポリシーが定義されている必要があります。 ただし、フォルト・ポリシーが定義されていない場合、フォルトは、リカバリ可能またはリカバリ不可のフォルトとして通常どおり処理されます。この項では、個別リカバリと一括リカバリの両方の実行例を示します。 ヒューマン・タスク・サービス・コンポーネントまたはヒューマン・ワークフロー・サービス・エンジンのフォルトは、Oracle BPM Worklistからリカバリされます。
SOAインフラストラクチャ・レベルでSOAコンポジット・アプリケーション・フォルトをリカバリする手順は、次のとおりです。
ページには、次のいずれかの手順でアクセスします。
| 「SOAインフラストラクチャ」メニューからアクセスする手順 | ナビゲータの「SOA」フォルダからアクセスする手順 | 「SOAコンポジット」メニューからアクセスする手順 |
|---|---|---|
|
|
|
「フォルト・メッセージと拒否メッセージ」タブをクリックします。
「フォルト・メッセージと拒否メッセージ」ページに、すべてのSOAコンポジット・アプリケーション・フォルトについて、次の詳細が表示されます。
特定のフォルトを検索するためのユーティリティ。基準を指定して「検索」をクリックします。 詳細は、「ヘルプ」アイコンをクリックしてください。
フォルト・メッセージと拒否メッセージ。エラー・メッセージ、フォルトのリカバリが可能かどうか、フォルトの発生時間、フォルトが発生したSOAコンポジット・アプリケーション、フォルトの場所、およびインスタンスIDが表示されます。
リカバリ可能として識別されたフォルトはリカバリできます。
次のいずれかのオプションを使用して、リカバリ対象のフォルトを選択します。 SOAインフラストラクチャ・レベルでフォルト・リカバリ対象を選択することは、SOAコンポジット・アプリケーション・レベル、およびBPELプロセスとOracle Mediatorサービス・コンポーネント・レベルで選択するのと同じです。
| 対象 | 操作 |
|---|---|
| 単一フォルト・リカバリ | 単一フォルト・リカバリの対象を選択するには、次の3つの方法があります。
|
| 一括フォルト・リカバリ | 一括フォルト・リカバリの対象を選択するには、次の2つの方法があります。
|
| すべてのフォルトのリカバリ |
|
「リカバリ・アクション」リストからアクションを選択します。
| アクション | 説明 | アクションの対象 |
|---|---|---|
| 再試行 | インスタンスを直接再試行します。このリカバリ・アクションを使用するシナリオ例は、ネットワーク・エラーのためにサービス・プロバイダにアクセスできないことが原因でフォルトが発生した場合の例です。ネットワーク・エラーは現在解決しています。 | BPELプロセスとOracle Mediator |
| 中断 | インスタンス全体を終了します。 | BPELプロセスとOracle Mediator |
| リプレイ | フォルトが発生したスコープ全体を再度リプレイします。 | BPELプロセス |
| 再スロー | 現在のフォルトを再スローします。フォルトの処理に、BPELフォルト・ハンドラ（catchブランチ）が使用されます。デフォルトでは、再スロー・フォルト・ポリシーが明示的に指定されていない場合、すべての例外がフォルト管理フレームワークによって捕捉されます。 | BPELプロセス |
| 続行 | フォルトを無視して処理を続行します（フォルト・アクティビティには成功のマークが付けられます）。 | BPELプロセス |
拒否メッセージを削除する場合は、「拒否メッセージの削除」をクリックします。
すべてのコンポジットの拒否メッセージを削除するための基準を指定するダイアログが表示されます。
基準を指定して、「削除」をクリックします。
フォルト表内から次の追加タスクを実行します。
「ビュー」リストから、「列」→「フォルトID」の順に選択し、各エラー・メッセージのフォルトIDを表示します。 フォルトIDは自動的に生成され、フォルトを一意に識別します。 フォルトIDは、エラー・メッセージをクリックしたときも表示されます。
「コンポジット」列で、特定のSOAコンポジット・アプリケーションをクリックし、そのホーム・ページにアクセスします。
「フォルトの場所」列で、特定の場所をクリックし、フォルトの場所に関するフォルト・ページにアクセスします。 フォルトの場所は、サービス、サービス・コンポーネントまたは参照です。
「コンポジット・インスタンスID」列で、特定のIDをクリックし、インスタンスのフローのトレースにアクセスします。
「ログ」列で、特定のログをクリックし、「ログ・メッセージ」ページにアクセスします。このページには、そのインスタンスに固有のメッセージがフィルタされて表示されます。
BPELプロセスとOracle Mediatorでの単一および一括フォルト・リカバリの例については、次の各項を参照してください。
フォルト・ポリシーの概念と設計方法の詳細は、次のドキュメントを参照してください。
この項では、BPELプロセスのフォルトに対して管理者操作を可能にするフォルト・ポリシーを定義し、BPELプロセス・サービス・コンポーネントで単一フォルト・リカバリおよび一括フォルト・リカバリを実行する方法の例を示します。
この例では、管理者操作によってフォルトを手動でリカバリするフォルト・ポリシーを定義します。無効な社会保障番号が、融資ブローカBPELプロセスから信用格付けサービスに発行されると、信用格付けサービスはネガティブ情報フォルトを返します。この例の管理者操作によるアクションは、fault-policies.xmlファイルのora-human-interventionアクションで定義します。 フォルト・ポリシーが定義されていない場合、BPELインスタンスではリカバリ可能なフォルトを生成しません（フォルトはリカバリ不可になります）。この場合は、ora-human-interventionアクションを使用してフォルトをリカバリ可能にします。
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
<faultPolicy version="2.0.1"
id="CRM_ServiceFaults"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Conditions>
<faultName xmlns:credit="http://services.otn.com"
name="credit:NegativeCredit">
<!-- we get this fault when SSN starts with 0-->
<condition>
<test>$fault.payload="Bankruptcy Report"</test>
<action ref="ora-human-intervention"/>
</condition>
</faultName>
</Conditions>
</faultPolicy>
</faultPolicies>
fault-bindings.xmlファイルによって、fault-policies.xmlで定義されたフォルト・ポリシーがCRM_ServiceFaultsコンポジットと関連付けられます。
<faultPolicyBindings version="2.0.1"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<composite faultPolicy="CRM_ServiceFaults"/>
</faultPolicyBindings>
管理者操作はアクションとして定義されているため、BPELプロセスに対するフォルト・リカバリはOracle Enterprise Manager Fusion Middleware Controlコンソールで実行します。
fault-policies.xmlファイルおよびfault-bindings.xmlファイルの作成と設計の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。
この例の前提は次のとおりです。
インスタンスが、第8.1項「SOAコンポジット・アプリケーションのテスト・インスタンスの起動」で示した「Webサービスのテスト」ページで起動されました。
0で始まる無効な社会保障番号が入力されました。
BPELプロセスに対して単一フォルト・リカバリを実行する手順は、次のとおりです。
「SOAインフラストラクチャ」メニューから、「ホーム」を選択します。
「フォルト・メッセージと拒否メッセージ」タブをクリックします。
フォルト表で、リカバリ可能として識別されたフォルトを検索します。 検索ユーティリティを使用して、特定のフォルトを検索できます。
「リカバリ」列で、「リカバリ」をクリックします。 最初にフォルトの詳細を表示する場合は、エラー・メッセージをクリックします。 次に、「ここでリカバリ」をクリックします。
BPELプロセス・インスタンスの「フォルト」ページが表示されます。
「リカバリ」列で、「リカバリ可能」をクリックします。
ページがリフレッシュされ、ページの下部にフォルト・リカバリ・セクションが表示されます。
「リカバリ・アクション」リストから「再試行」を選択します。
「再試行成功時のチェーン・アクション」リストから「なし」を選択します。このリストでは、Javaコールアウト・リカバリ・アクションを選択できます。 詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。
「変数」リストから変数を選択します。 この変数の内容が「値」フィールドに表示されます。この例では、変数crInputが選択されています。この変数は、invokeアクティビティで使用され、不適切な社会保障番号の値を含んでいます。
「値」フィールドに適切な値を入力します。この例では、社会保障番号を1で始まるように編集します。
<ssn xmlns="http://service.otn.com">123456789</ssn>
「設定値」をクリックし、プロンプトが表示されたら「はい」をクリックして続行します。
「リカバリ」をクリックしてフォルトをリカバリし、プロンプトが表示されたら「はい」をクリックして続行します。
ページがリフレッシュされ、フォルトが発生していないことが示されます。
社会保障番号の例の場合、「再試行」の選択は、一括リカバリを実行するためのオプションではありません。これは、社会保障番号の値が不適切で、修正が必要になるためです。 「再試行」オプションを使用して一括リカバリを実行する例としては、社会保障番号は適切であるが、信用格付けサービスを提供するシステムが一時的に使用不可になったために、コンポジット参照のフォルトが発生した場合などがあります。この場合は、メッセージが配信されません。 信用格付けサービスが再度使用可能になったときに、「再試行」を選択すると、コンポジット参照を介した信用格付けサービスの起動が再試行されます。
BPELプロセスに対して一括フォルト・リカバリを実行する手順は、次のとおりです。
第8.5.1.1項「例: BPELプロセスに対する単一フォルト・リカバリ」の手順1から2を実行します。
検索ユーティリティで、判明しているフォルト・パラメータ（時間の範囲、コンポジット名、コンポーネント・タイプ（BPELプロセス）など）に基づいて基準を入力します。
検索結果が多数返される場合は、「リカバリ可能なフォルトのみ表示」チェック・ボックスを選択して表示を制限します。
「選択」リストから「すべてのリカバリ可能な値を選択」を選択します。
「リカバリ・アクション」リストから「中断」を選択します。
選択したすべてのフォルトを手動で停止します。
この項では、Oracle Mediatorサービス・コンポーネントで単一および一括フォルト・リカバリを実行する方法の例を示します。
この例では、インバウンドSiebelアダプタ・サービス・バインディング・コンポーネントによって、変換のためにOracle Mediatorにペイロード・メッセージが発行されます。 次に、処理されたペイロード・メッセージが、アウトバウンド・ファイル・アダプタ参照バインディング・コンポーネントに配信されます。ただし、ペイロード・メッセージの書込み先のアウトバウンド・ディレクトリが、書込み権限で構成されていません。この結果、フォルトが発生します。設計時に定義されたフォルト・ポリシーでは、フォルトは管理者操作によって手動でリカバリされることが指定されています。retryCount属性で定義されているように、再試行は3回行われることに注意してください。条件およびアクションは、fault-policies.xmlファイルで次のように定義されています。
Oracle Mediatorのリカバリ可能なフォルトに対して、フォルト・ポリシーは必要ありません（ただし、ora-human-interventionアクションで説明したように、フォルト・ポリシーはフォルトをリカバリ可能にする1つの方法です）。 また、アウトバウンド・エンドポイントからリモート・フォルトを受信するパラレル・ルーティング・ルールによっても、リカバリ可能なフォルトが作成されます（この例では、Oracle Mediatorがパラレル・ルーティング・ルールを使用してアウトバウンド・ファイル・アダプタを起動する場合、フォルト・ポリシーは必要ありません）。
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
<faultPolicy version="2.0.1"
id="ConnectionFaults"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Conditions>
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults"
name="medns:mediatorFault">
<condition>
<test>contains($fault.mediatorErrorCode, "TYPE_FATAL_
MESH")</test>
<action ref="ora-retry"/>
</condition>
</faultName>
</Conditions>
. . .
. . . <Action id="ora-retry">
<retry>
<retryCount>3</retryCount>
<retryInterval>5</retryInterval>
<retryFailureAction ref="ora-human-intervention"/>
<retrySuccessAction ref="ora-terminate"/>
</retry>
</Action>
</Actions>
</faultPolicy>
</faultPolicies>
終了する前に、処理を3回再試行するように設定されていることに注意してください。
フォルト・ポリシーは、fault-bindings.xmlファイルでConnectionFaultsコンポジットと関連付けられます。
<faultPolicyBindings version="2.0.1" xmlns="http://schemas.oracle.com/bpel/fault
policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<composite faultPolicy="ConnectionFaults"/>
</faultPolicyBindings>
この例では、sap出力ディレクトリが読取り専用になっています。 インバウンド・ファイル・アダプタはsiebelディレクトリからsender.xmlファイルを取得し、ファイルをsapディレクトリに格納するために、メッセージがOracle Mediatorを介してアウトバウンド・ファイル・アダプタ参照にルーティングされます。
Oracle Mediatorに対して単一フォルト・リカバリを実行する手順は、次のとおりです。
オペレーティング・システムのコマンド・プロンプトで、ディレクトリの権限を変更します。
chmod 000 sap cp sender.xml siebel/
「SOAインフラストラクチャ」メニューから、「ホーム」を選択します。
「フォルト・メッセージと拒否メッセージ」タブをクリックします。
3回の再試行の結果、3つのフォルトが表示されることに注意してください。 この場合、再試行は3回のみです。これは、アウトバウンド・ファイル・アダプタとOracle Mediatorの相互作用に関するフォルト・ポリシーで、再試行が3回と定義されているためです。 フォルト・ポリシーがない場合、フォルトは1つのみです（自動的な再試行はありません）。
「コンポジット・インスタンスID」列で、特定のインスタンスIDをクリックします。
「フローのトレース」が表示されます。 ページの上部にあるフォルト表には、フォルト・メッセージが表示されます。 メッセージ・フロー内で失敗したOracle Mediatorインスタンスの位置を確認するには、フォルト表でフォルトを選択します。 選択すると、トレース表内の関連するインスタンスが強調表示されます。 次に、インスタンスをクリックしてその監査証跡にアクセスすると、失敗したフローの詳細を確認できます。
「フォルト」表で、リカバリするOracle Mediatorコンポーネント・インスタンスのフォルトを検索し、「リカバリ」列で「リカバリ」をクリックします。
「ペイロード・パート」リストから「送信者」を選択します。
「ペイロード」フィールドに、ペイロードが自動的に表示されます。必要な場合は、このフィールドでペイロードの変更を実行できます。この例では、ペイロードの変更は必要ありません。
オペレーティング・システムのコマンド・プロンプトで、sapディレクトリを書込み可能に変更します。
chmod 777 sap
「フォルト」タブに戻り、ページの右上隅にある「リフレッシュ」アイコンをクリックします。
「再試行」をクリックします。
プロンプトが表示されたら「はい」をクリックして、選択したフォルトをリカバリのために再発行します。
ページがリフレッシュされ、フォルトが発生していないことが示されます。
「監査証跡」タブをクリックします。
最終メッセージで、手動リカバリが成功し、メッセージ・ペイロードがsapディレクトリに書き込まれたことが示されます。
この例でも、sender.xmlペイロード・メッセージの書込み先のsapディレクトリが、読取り専用権限でオペレーティング・システムのコマンド・プロンプトで構成されているとします。sender.xmlファイルの3つのコピーが、インバウンドSiebelアダプタ・サービス・バインディング・コンポーネントのsiebelディレクトリにあります。この結果、3つのインスタンスが作成されます。
chmod 000 sap cp sender.xml siebel/ cp sender.xml siebel/ cp sender.xml siebel/
Oracle Mediatorに対して一括フォルト・リカバリを実行する手順は、次のとおりです。
sapディレクトリを書込み可能に変更します。
「SOAインフラストラクチャ」メニューから、「ホーム」を選択します。
「フォルト・メッセージと拒否メッセージ」タブをクリックします。
検索ユーティリティで、判明しているフォルト・パラメータ（時間の範囲、コンポジット名など）に基づいて基準を入力します。
検索結果が多数返される場合は、「リカバリ可能なフォルトのみ表示」チェック・ボックスを選択して表示を制限します。
オペレーティング・システムのコマンド・プロンプトで、sapディレクトリを書込み可能に変更します。
chmod 777 sap
リカバリするすべてのフォルトを選択します。
「リカバリ・アクション」リストから「再試行」を選択します。
プロンプトが表示されたら「はい」を選択して、フォルト・リカバリを実行します。
「監査証跡」タブをクリックします。
最終メッセージで、手動リカバリが成功し、メッセージ・ペイロードがsapディレクトリに正常に書き込まれたことが示されます。
SOAコンポジット・アプリケーションを監視して、単一および一括のフォルト・リカバリを実行できます。 リカバリ可能として識別されたBPELプロセス・フォルトについては、（fault-bindings.xmlファイルを介して）フォルトにバインドされ、アクションora-human-interventionをトリガーするフォルト・ポリシーが定義されている必要があります。 ただし、フォルト・ポリシーが定義されていない場合、フォルトは、リカバリ可能またはリカバリ不可のフォルトとして通常どおり処理されます。 ヒューマン・ワークフローのフォルトもリカバリできますが、Oracle Enterprise Manager Fusion Middleware Controlコンソールからは直接リカバリできません。 かわりに、監査証跡にOracle BPM Worklistへのリンクが表示され、このリンクからフォルトを処理できます。
アプリケーションのホーム・ページでSOAコンポジット・アプリケーション・フォルトをリカバリする手順は、次のとおりです。
ページには、次のいずれかの手順でアクセスします。
| 「SOAインフラストラクチャ」メニューからアクセスする手順 | ナビゲータの「SOA」フォルダからアクセスする手順 |
|---|---|
|
|
「フォルト・メッセージと拒否メッセージ」タブをクリックします。
「フォルト・メッセージと拒否メッセージ」ページに、選択したSOAコンポジット・アプリケーションに関する次の詳細が表示されます。
特定のフォルトを検索するためのユーティリティ。基準を指定して「検索」をクリックします。 詳細は、「ヘルプ」アイコンをクリックしてください。
SOAコンポジット・アプリケーション・インスタンスのフォルト・メッセージと拒否メッセージ。エラー・メッセージ、フォルトのリカバリが可能かどうか、フォルトの発生時間、フォルトの場所、コンポジット・インスタンスID、およびフォルトが記述されているログ・ファイルへのリンクが表示されます。
|
注意: ヒューマン・ワークフローのフォルトはデハイドレーション・ストアに保持されないため、ヒューマン・ワークフローのエラー・メッセージは「エラー・メッセージの内容」フィールドに詳細を入力しても検索できません。 |
リカバリ可能として識別されたフォルトはリカバリできます。
リカバリ対象のフォルトを選択します。 SOAインフラストラクチャ・レベル、およびBPELプロセスとOracle Mediatorサービス・コンポーネント・レベルでのフォルト・リカバリと同様に、単一フォルト・リカバリ、一括フォルト・リカバリ、およびすべてのフォルトのリカバリを実行できます。 フォルトを選択してこれらのタイプのリカバリを実行する手順については、第8.5項「SOAインフラストラクチャ・レベルでの、SOAコンポジット・アプリケーションのフォルトのリカバリ」の手順3を参照してください。
「リカバリ・アクション」リストからアクションを選択します。
| アクション | 説明 | アクションの対象 |
|---|---|---|
| 再試行 | インスタンスを直接再試行します。このリカバリ・アクションを使用するシナリオ例は、ネットワーク・エラーのためにサービス・プロバイダにアクセスできないことが原因でフォルトが発生した場合の例です。ネットワーク・エラーは現在解決しています。 | BPELプロセスとOracle Mediator |
| 中断 | インスタンス全体を終了します。 | BPELプロセスとOracle Mediator |
| リプレイ | フォルトが発生したスコープ全体を再度リプレイします。 | BPELプロセス |
| 再スロー | 現在のフォルトを再スローします。フォルトの処理に、BPELフォルト・ハンドラ（catchブランチ）が使用されます。デフォルトでは、再スロー・フォルト・ポリシーが明示的に指定されていない場合、すべての例外がフォルト管理フレームワークによって捕捉されます。 | BPELプロセス |
| 続行 | フォルトを無視して処理を続行します（フォルト・アクティビティには成功のマークが付けられます）。 | BPELプロセス |
拒否メッセージを削除する場合は、「拒否メッセージの削除」をクリックします。
現在のコンポジットの拒否メッセージを削除するための基準を指定するダイアログが表示されます。
基準を指定して、「削除」をクリックします。
フォルト表内から次の追加監視タスクを実行します。
「ビュー」リストから、「列」→「フォルトID」の順に選択し、各エラー・メッセージのフォルトIDを表示します。 フォルトIDは自動的に生成され、フォルトを一意に識別します。 フォルトIDは、エラー・メッセージをクリックしたときも表示されます。
「フォルトの場所」列で、特定の場所をクリックし、フォルトの場所に関するフォルト・ページにアクセスします。 フォルトの場所は、サービス、コンポーネントまたは参照です。
「コンポーネント・インスタンスID」列で、特定のサービス・コンポーネントIDをクリックし、インスタンスに関するタスク詳細（たとえば、タスクの現在の状態）にアクセスします。 拒否メッセージにはコンポーネント・インスタンスIDがないことに注意してください。
「ログ」列で、特定のログをクリックし、「ログ・メッセージ」ページにアクセスします。このページには、そのインスタンスに固有のメッセージがフィルタされて表示されます。
詳細は、次の各項を参照してください。
SOAコンポジット・アプリケーションのテストを自動化するテスト・ケースを作成、デプロイおよび実行できます。 テスト・ケースを使用すると、SOAコンポジット・アプリケーションとそのWebサービス・パートナの間の相互作用を、本番環境へのデプロイメント前にシミュレートできます。この機能によって、本番環境へのデプロイメント準備が整うまでに、プロセスがWebサービス・パートナと予想どおりに相互作用することを確認できます。Oracle JDeveloperでテスト・ケースを作成し、SOAコンポジット・アプリケーションに組み込みます。このアプリケーションは、その後、Oracle Enterprise Manager Fusion Middleware Controlコンソールからデプロイされて管理されます。
SOAコンポジット・アプリケーションをテストする手順は、次のとおりです。
ページには、次のいずれかの手順でアクセスします。
| 「SOAインフラストラクチャ」メニューからアクセスする手順 | ナビゲータの「SOA」フォルダからアクセスする手順 | 「SOAコンポジット」メニューからアクセスする手順 |
|---|---|---|
|
|
|
表示されるテスト・ケースは、Oracle JDeveloperで設計され、デプロイ済のSOAコンポジット・アプリケーションに組み込まれたテスト・ケースです。
テスト・スイート全体を選択するか、実行するスイートの個々のテストを選択して、「実行」をクリックします。
テストの作成プロンプトが表示されます。
次の値を入力し、「OK」をクリックします。
| フィールド | 説明 |
|---|---|
| テスト実行名 | テスト・インスタンスの名前を入力します。テストの終了時に、レポート詳細がこの名前で取得されます。 |
| タイムアウト | テストを終了させる値（秒単位）を入力します。この時間内にテストが完了しない場合、テストは終了されます。 |
| 同時テスト・インスタンスの数 | 作成するテスト・インスタンスの数を入力します。 |
実行中のテストを追跡するための「テスト実行」ページが自動的に表示されます。
「テスト実行」ページを使用して、実行中のテスト・ケースを追跡し、テスト結果を表示できます。テスト・スイートは、1つ以上のテスト・ケースの論理的な集合で構成されます。各テスト・ケースには、テスト・インスタンスの実行時に実行される一連のコマンドが含まれています。テスト・スイートの実行は、テスト実行と呼ばれます。
「テスト実行名」列で特定のテスト実行をクリックして、「テスト実行の結果」セクションに詳細を表示します。 追加のテスト実行を作成する場合は、「テスト・ケース」ページにいつでも戻ることができます。
「テスト実行の結果」セクションには、実行されたテスト実行の詳細（テスト・サマリー、成功率など）が表示されます。 追加の詳細は、「ヘルプ」アイコンをクリックしてください。
ページの下部にアサーション詳細が表示されます。アサーションを使用すると、変数データやプロセス・フローを検証できます。
コンポジット・インスタンス番号をクリックして、特定のテスト詳細を表示します。
SOAコンポジット・アプリケーションの「インスタンス」ページ、およびSOAインフラストラクチャとSOAコンポジット・アプリケーションの「最新のインスタンス」表では、ユニット・テスト実行を実行して作成されたコンポジット・インスタンスのインスタンスIDの横に黄色のボックスが表示されます。 これらのインスタンスは、この黄色のボックスによって、「Webサービスのテスト」ページで作成されたり、アプリケーションの外部コンシューマによって自動的に作成されたテスト・インスタンスと区別されます。
詳細は、次のドキュメントを参照してください。
現在デプロイされているSOAコンポジット・アプリケーションとの間で、セキュリティ・ポリシーをアタッチまたはデタッチできます。 ポリシーでは、メッセージ配信に対してセキュリティが適用されます。
SOAコンポジット・アプリケーション・ポリシーを管理する手順は、次のとおりです。
ページには、次のいずれかの手順でアクセスします。
| 「SOAインフラストラクチャ」メニューからアクセスする手順 | ナビゲータの「SOA」フォルダからアクセスする手順 | 「SOAコンポジット」メニューからアクセスする手順 |
|---|---|---|
|
|
|
「ポリシー」ページを使用すると、BPELプロセス・サービス・コンポーネントとの間でポリシーをアタッチおよびデタッチできます。 ポリシー表には、アタッチされたポリシーの名前、ポリシーがアタッチされたコンポーネント、切替可能なポリシー参照ステータス（有効または無効）、カテゴリ（「管理」、「信頼できるメッセージング」、「MTOMアタッチメント」、「セキュリティ」または「WSアドレス」）、違反、およびSOAインフラストラクチャの最後の再起動以降の認証、認可、機密性および整合性の失敗が表示されます。
「アタッチ/デタッチ先」をクリックします。
複数のサービスまたはコンポーネントが使用可能な場合は、アタッチまたはデタッチを実行するサービスまたはコンポーネントを選択するプロンプトが表示されます。
ポリシーのアタッチまたはデタッチ先のコンポーネントを選択します。
ポリシーをアタッチまたはデタッチするためのダイアログが起動します。
「アタッチされたポリシー」セクションに、現在アタッチされているポリシーが表示されます。 「使用可能なポリシー」セクションには、アタッチ可能な追加のポリシーが表示されます。
使用環境に適した、アタッチ対象のポリシーを選択します。
「アタッチ」をクリックします。
「アタッチされたポリシー」セクションに、アタッチされたポリシーが表示されます。
必要に応じて、追加のポリシーをアタッチします。
ポリシーのアタッチを終了した後は、「検証」をクリックします。
エラー・メッセージが表示された場合は、検証エラーがなくなるまで必要な修正を行います。
「OK」をクリックします。
アタッチしたポリシーがポリシー表に表示されます。
ポリシーの詳細は、次のドキュメントを参照してください。
SOAコンポジット・アプリケーションの「インスタンス」ページにある「オプションを指定して削除」ボタンを使用して大量（数千）のインスタンスを削除すると、処理時間がかかり、トランザクション・タイムアウトになる可能性があります。 このため、かわりにfabric-purge.sql PL/SQLスクリプトを使用します。 詳細は、Oracle MetaLinkでテクニカル・ノート815896.1を参照してください。
http://metalink.oracle.com
fabric-purge.sqlスクリプトを使用して、次の機能を実行できます。
コンポジット・インスタンスを削除します。
procedure delete_composite_instances(a_composite_dn in varchar2, a_composite_state in integer, a_composite_min_creation_date in timestamp, a_composite_max_creation_date in timestamp, max_instances in integer);
次のタスクを実行します。
すべてのコンポジットにわたり、システム内の全インスタンスを削除します。
特定のコンポジットの全インスタンスを削除します。
特定の日付範囲内または特定の状態にある、複数のコンポジットまたは特定のコンポジットのインスタンスを削除します。
コンポジット・レベルで監査レベル・トラッキングが無効になったためにインスタンスを持たないコンポジット内から、サービス・コンポーネント・インスタンスを削除します。 このようなインスタンスは孤立したインスタンスと呼ばれます。
procedure delete_orphaned_component_instances(a_composite_dn in varchar2, a_component_state in integer, a_component_min_creation_date in timestamp, a_component_max_creation_date in timestamp, max_instances in integer);
実行するタスクは、コンポジット・インスタンスの削除で説明したタスクと同じです。
拒否メッセージを削除します。
procedure delete_rejected_messages(a_composite_dn in varchar2,); // may add in the max instances and date range if feasible
現在は、インバウンド・アダプタからメッセージが再試行されるたびに、新しいコンポジット・インスタンスが作成されます。 インバウンド・アダプタの再試行に関するデフォルト動作では再試行が無限に繰り返されるため、このスクリプトは、同じ再試行によって表示される大量のコンポジット・インスタンス・エラーを処理します。
