| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド 11gリリース1 (11.1.1.7) B55916-10 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド 11gリリース1 (11.1.1.7) B55916-10 |
|
前 |
次 |
この章では、アプリケーションのテスト・インスタンスの開始、インスタンスの監視と削除、フォルトからのリカバリ、拒否メッセージの削除、複数のSOAコンポジット・アプリケーション・リビジョン間のインスタンスの移行など、SOAコンポジット・アプリケーション・インスタンスの管理方法について説明します。
この章では、次の項目について説明します。
|
注意: このガイドでは、「SOAインフラストラクチャ」メニュー、ナビゲータの「soa-infra」アイコン、「SOAコンポジット」メニュー、および「SOAパーティション」メニューからOracle Enterprise Manager Fusion Middleware Controlの各ページにアクセスする手順について説明しています。また、ファーム・ホーム・ページからも多くのページにアクセスできます。詳細は、第2.2.6章「ファーム・ホーム・ページから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)は、デフォルトとして設定されたコンポジット・リビジョンによって処理されます。
「操作」メニューからテストする操作を選択します。使用可能なオプションはWSDLにより決定されます。
エンドポイントURLを編集する場合は、「エンドポイントURLの編集」をクリックして適切に変更します。
「Webサービスのテスト」ページの下部には、「リクエスト」タブがあります。このタブでは、セキュリティ、サービスのクオリティ、HTTPトランスポート、ストレス・テスト・オプションおよびXML入力引数を指定できます。
「セキュリティ」セクションには、メッセージを使用してセキュリティ・プロパティを渡すための次のフィールドがあります。
| フィールド | 説明 |
|---|---|
|
OWSMセキュリティ・ポリシー |
WS-SecurityのSOAPヘッダーを挿入します。「ユーザー名」フィールドは必須で、「パスワード」フィールドはオプションです。 |
|
HTTP Basic認証 |
ユーザー名とパスワード資格証明をHTTPトランスポート・ヘッダーに挿入します。「ユーザー名」および「パスワード」フィールドは両方とも必須です。 |
|
拡張 |
カスタム・ポリシーを使用してユーザーを認証します(カスタム・ポリシーのURIを指定します)。「ユーザー名」および「パスワード」フィールドはオプションです。 |
|
なし |
セキュリティ資格証明を指定しない場合に選択します。これがデフォルトの選択です。 |
RESTful Webサービスのテスト時には、SOAPプロトコルは使用されないため、セキュリティ・オプションはHTTP Basic認証またはなしのみです。
次の各フィールドではデフォルト値をそのまま使用するか、使用するテスト環境に適した値を入力します。
「サービスのクオリティ」セクションには、次のフィールドがあります。Oracle Fusion Middlewareでは、ポリシー・ベースのモデルを使用してWebサービスを管理します。ポリシーでは、メッセージ配信に対して動作要件が適用されます。この項の内容は、RESTful Webサービスのテスト時には使用できません。「Webサービスのテスト」ページの使用方法の詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。
| フィールド | 説明 |
|---|---|
|
WS-RM |
次のオプションのいずれかを選択して、WS信頼できるメッセージング(RM)プロトコル・ポリシーをテストします。信頼できるメッセージング・ポリシーによって、このプロトコルがサポートされ、メッセージのエンドツーエンド配信が保証されます。
|
|
MTOM |
次のオプションのいずれかを選択して、メッセージ転送最適化メカニズム(MTOM)ポリシーをテストします。MTOMポリシーによって、添付がMTOMフォーマットであることが保証されます。このフォーマットは、Webサービスとの間でバイナリ・データを効率的に送受信するためのフォーマットです。
|
|
WSアドレス |
次のオプションのいずれかを選択して、WS-Addressingポリシーをテストします。WS-Addressingポリシーによって、WS-Addressing仕様に準拠したWS-AddressingヘッダーがSOAPメッセージに含まれていることが検証されます。
|
次の各フィールドではデフォルト値をそのまま使用するか、使用するテスト環境に適した値を入力します。
「HTTPトランスポート・オプション」セクションには、次のフィールドがあります。
| フィールド | 説明 |
|---|---|
|
SOAPアクションの有効化 |
WSDL |
|
SOAPアクション |
WSDL |
この項の内容は、RESTful Webサービスのテスト時には使用できません。
次の各フィールドではデフォルト値をそのまま使用するか、使用するテスト環境に適した値を入力します。
「追加テスト・オプション」セクションには、次のフィールドがあります。このセクションでは、複数インスタンスを同時に起動する簡単なストレス・テストを指定します。
| フィールド | 説明 |
|---|---|
|
ストレス・テストの有効化 |
「有効化」をクリックして、簡単なストレス・テストを作成します。このオプションを有効にすると、対話IDは表示されません。 |
|
同時スレッド |
起動を送信する同時スレッドの数を入力します。デフォルトは |
|
スレッドごとのループ |
操作を起動する回数を入力します。デフォルトは |
|
ミリ秒単位の遅延 |
次の操作を起動するまでの遅延をミリ秒単位で指定します。デフォルトは |
次の各フィールドではデフォルト値をそのまま使用するか、使用するテスト環境に適した値を入力します。
「引数を入力」セクションには、XMLペイロード・データを入力するための次のフィールドがあります。
| フィールド | 説明 |
|---|---|
|
ツリー表示 |
情報を入力するテキスト・フィールドのグラフィカル・インタフェースが表示されます。このフィールドを選択すると、必要なヘッダーとXML構造が自動的に生成されます。 |
|
XML表示 |
値の挿入のためのXMLファイル形式が表示されます。このフィールドには、メッセージのraw XMLペイロードを貼り付けることができます。 |
「Webサービスのテスト」をクリックします。
テストを終了すると、「レスポンス」タブに結果が表示されます。
「メッセージ・フロー・トレースの起動」をクリックして、インスタンスのフローのトレースにアクセスします。
コンポジットのホーム・ページに戻るには、ページの上部に表示されるコンポジット名をクリックするか、コンポジット・ターゲット・メニューから「ホーム」を選択します。
SOAコンポジット・アプリケーションの「ダッシュボード」ページに戻ります。
「最新のインスタンス」表に、最新のSOAコンポジット・アプリケーションのインスタンスがリストされます。作成された各インスタンスには、固有のIDが付いています。
詳細は、次の項を参照してください。
インスタンスの概念の詳細は、第1.2.3項「SOAコンポジット・アプリケーション・インスタンスの概要」を参照してください。
ポリシーの概要については、第1.4.3.2項「ポリシーの概要」を参照してください。
「Webサービスのテスト」ページからのWebサービスのテスト、およびポリシーに関する具体的な詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』を参照してください。
"element="によって定義されたメッセージを持つRPC/リテラル・スタイルのWSDLファイルを指定する場合、Oracle Enterprise Manager Fusion Middleware Controlの「Webサービスのテスト」ページで、「引数の入力」セクションの「XML表示」オプションを使用して、SOAPメッセージを変更します。SOAP本文は、例8-1に示されるようになります。
例8-1 SOAP本文
<soap:Body>
<ns:initiate>
<payload>
<value xmlns="...">3</value>
</payload>
</ns:initiate>
</soap:Body>
ここで、initiateは操作名、payloadはパーツ名、およびvalueはWSDLメッセージ/部分に定義されている要素です。
第7.5項「デプロイ済SOAコンポジット・アプリケーションの状態管理」では、SOAコンポジット・アプリケーションのライフサイクルの状態を管理する方法を説明しました。アプリケーションのホーム・ページの「インスタンス」ページでは、特定のSOAコンポジット・アプリケーションのインスタンスを監視および削除することもできます。
アプリケーションのホーム・ページからSOAコンポジット・アプリケーションのインスタンスを監視および削除する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「インスタンス」タブをクリックします。
「インスタンス」ページに、次の詳細が表示されます。
特定のインスタンスを検索するためのユーティリティ。基準を指定して「検索」をクリックします。デフォルトでは、このページに初めてアクセスしたときにはインスタンスは表示されません。インスタンスを表示するには、「検索」をクリックする必要があります。
SOAコンポジット・アプリケーションのインスタンスID、名前、対話ID、ページの最終データ・リフレッシュ以降の各インスタンスの最新状態(正常完了、実行中、不明など)、インスタンスの開始時間、フォルトが記述されているログ・ファイル。SOAコンポジット・アプリケーションの新しいインスタンスが起動されるたびに、一意のインスタンスIDが作成されます。インスタンスは、アプリケーションの外部コンシューマによって自動的に起動されるか、管理者が「Webサービスのテスト」ページから手動で起動します。
「?」アイコンが表示される場合は、SOAインフラストラクチャの「共通プロパティ」ページで「コンポジット・インスタンスの状態をキャプチャ」チェック・ボックスが選択されていません。このため、インスタンスの状態が評価されません。コンポジット・インスタンスの状態の判定には、基礎となるコンポーネントの状態の評価が必要です。したがって、このオプションを無効にするとパフォーマンスを向上できます。
|
注意: 孤立したサービス・コンポーネント・インスタンスが生成される可能性があります。このようなインスタンスは、関連するコンポジット・アプリケーション・インスタンスなしで生成されます。孤立したコンポーネント・インスタンスは、次の状況で生成されます。
孤立したインスタンス、または大量のインスタンスを削除するには、第10.3項「パージ・スクリプトを使用した大量のインスタンスの削除」で説明されているパージ・スクリプトを使用します。「オプションを指定して削除」ダイアログの「すべてのインスタンスを削除」オプションを選択しても、孤立したコンポーネント・インスタンスは削除されません。 |
コンポジット・センサーがSOAコンポジット・アプリケーションに組み込まれている場合は、「インスタンス」タブの表示が次のように異なります。
検索ユーティリティにある「検索」および「リセット」ボタンの横に、「フィールドの追加」ボタンが表示されます。このボタンを使用して、センサー値を検索基準に追加できます。
「インスタンス」表に「コンポジット・センサー」列が表示されます。この列のセンサー・アイコンをクリックすると、コンポジットの指定のインスタンスで使用可能なセンサー値の詳細が表示されます。
「フィールドの追加」リストから、検索基準に追加するコンポジット・センサーを選択します。この例では、CustomerForOrder、OrderProcessingStart、およびCreditCardAuthResultSensorの3つが選択されています。
各センサーが検索する特定の値を入力します。指定した基準とセンサー値が一致するコンポジット・インスタンスのみ返されます。
「コンポジット・センサー」列は、このSOAコンポジット・アプリケーションにコンポジット・センサーが含まれていることを示します。
検索基準からすべてのコンポジット・センサー・フィールドを削除するには、「リセット」をクリックします。センサーを個別に削除するには、フィールドの右側にある「削除」アイコンをクリックします。
また、SOAインフラストラクチャ内のSOAコンポジット・アプリケーションのインスタンスでコンポジット・センサーを検索することもできます。書式[sensor name]=[sensor value]を使用して、センサー名と検索対象の値を指定します。詳細は、第8.3項「SOAインフラストラクチャ・レベルでの、SOAコンポジット・アプリケーション・インスタンスの監視と削除」を参照してください。
「インスタンス」表の行をクリックして、削除する特定のインスタンスを選択します。複数のインスタンスを選択する場合は、[Ctrl]キーまたは[Shift]キーを押しながら、選択する行をクリックします。
実行する特定のアクションを選択します。
| アクション | 説明 |
|---|---|
|
フィルタ条件 |
コンポジット・インスタンスの状態を表示するための基準を指定します。
|
|
選択項目の削除 |
インスタンスを削除すると、インスタンス詳細は確認できなくなります。 |
|
オプションを指定して削除 |
選択したインスタンスをデータベースから直接削除するための基準を最初に指定するように、プロンプトが表示されます。 このオプションは、実行中のロールバックされたインスタンスを削除する場合に使用します。ただし、このオプションでは、リカバリ待機中の関連する呼出しメッセージは削除されません。その結果、BPELメッセージ・リカバリで保留される孤立したメッセージが発生します。これらのメッセージを削除するには、BPELプロセス・サービス・エンジンの「リカバリ」ページに移動します。
この操作では、「インスタンス」ページで選択した内容(検索基準の指定や実行など)は無視されます。 インスタンスの削除の進行状況を監視するには、ログ・ファイルを確認する必要があります。ログ・ファイルの詳細は、第3.4項「ログ・ファイルの構成」を参照してください。 |
|
中断 |
「ビュー」リストから、「列」→「パーティション」の順に選択し、SOAコンポジット・アプリケーション・リビジョンのインスタンスが含まれているパーティションを表示します。
「ビュー」リストから、「列」→「ECID」の順に選択して、実行コンテキストID (ECID)を表示します。ECIDを使用すると、様々なコンポジットのインスタンス間のメッセージ・フローを追跡できます。
「インスタンス」表で、次の追加タスクを実行します。
「インスタンスID」列で、特定のインスタンスIDをクリックし、様々なサービス・コンポーネントやバインディング・コンポーネント間のメッセージ・フローを表示します。インスタンスIDが使用不可能と表示される場合は、「使用不可能」リンクをクリックすると詳細を表示できます。
「状態」列にインスタンスの状態が「不明」と表示される場合は、クリックすると詳細が表示されます。
「コンポジット・センサー」列が表示されている場合は、センサー・アイコンをクリックすると、インスタンスに組み込まれているコンポジット・センサーの詳細(名前、場所、値など)が表示されます。
「ログ」列で、特定のログをクリックし、「ログ・メッセージ」ページにアクセスします。このページには、そのインスタンスに固有のメッセージがフィルタされて表示されます。
詳細は、次の項を参照してください。
ログ・ファイルの表示および検索については、『Oracle Fusion Middleware管理者ガイド』を参照してください
SOAコンポジット・アプリケーション・インスタンス数は、必ずしもOracle Enterprise Manager Fusion Middleware Controlに表示されるサービス・コンポーネント・インスタンス数と一致しません。
SOAコンポジット・アプリケーション・インスタンスは、最初はコンポジットの起動時に作成されます。コンポジット内のサービス・コンポーネントが後続の起動を受信すると、前に作成されたコンポジット・インスタンスIDを参照する、対応するサービス・コンポーネント・インスタンスが作成されます。
コンポジット・インスタンスが作成され、基礎となるサービス・コンポーネント・インスタンスが作成されていない状況が発生することがあります。例:
コンポジット・インスタンスが作成されたが、システム障害により、起動がまだサービス・コンポーネントに到達していない場合。
コンポジット・インスタンスが作成されたが、起動でペイロード検証に失敗し、拒否された場合。この場合、起動は基礎となるサービス・コンポーネントに到達しません。
また、SOAコンポジット・アプリケーション・インスタンスが作成されていない、孤立したサービス・コンポーネント・インスタンスがある場合もあります。
複数のサービス・コンポーネント(たとえば、2つのBPELプロセス・サービス・コンポーネント)を持つSOAコンポジット・アプリケーションがあるとします。これらのサービス・コンポーネントは、インスタンスの状態が次のようにマークされています。
この場合、コンポジット・インスタンス全体の状態はフォルトとしてマークされます。この動作は、同じシナリオでコンポジット・インスタンス全体の状態が完了としてマークされる11g リリース1 (11.1.1.2)と異なります。
子SOAコンポジット・アプリケーションをコールする親SOAコンポジット・アプリケーションがあり、子コンポジットでフォルトが発生した(そして、親コンポジットによって処理された)とします。この場合、インスタンスの状態は次のようになります。
子コンポジットのインスタンスの状態は、フォルトとしてマークされます。
親コンポジットのインスタンスの状態は、完了としてマークされます。
第7.5項「デプロイ済SOAコンポジット・アプリケーションの状態管理」では、特定のSOAコンポジット・アプリケーションのすべてのインスタンスのライフサイクルの状態を管理する方法を説明しました。「SOAインフラストラクチャ」のホーム・ページの「インスタンス」ページでは、デプロイ済のすべてのSOAコンポジット・アプリケーションの中から任意の数のインスタンスを監視および削除できます。また、すべてのSOAコンポジット・アプリケーションのインスタンスでコンポジット・センサーを検索することもできます。このページには、SOAインフラストラクチャにデプロイされているすべてのSOAコンポジット・アプリケーション・インスタンスがリストされます。
SOAインフラストラクチャ・レベルでSOAコンポジット・アプリケーションのインスタンスを監視および削除する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... | SOAコンポジットのメニューから... |
|---|---|---|
|
|
|
「インスタンス」タブをクリックします。
「インスタンス」ページに、次の詳細が表示されます。
特定のインスタンスを検索するためのユーティリティ。基準を指定して「検索」をクリックします。デフォルトでは、このページに初めてアクセスしたときにはインスタンスは表示されません。インスタンスを表示するには、「検索」をクリックする必要があります。
SOAインフラストラクチャのすべてのSOAコンポジット・アプリケーション・インスタンス。インスタンスID、対話ID、コンポジットの名前とリビジョン、SOAコンポジット・アプリケーション・インスタンスの状態、およびインスタンスの開始時間が表示されます。
このページからインスタンスの終了および削除も実行できます。
「インスタンス」表の行をクリックして、特定のインスタンスを選択します。複数のインスタンスを選択する場合は、[Ctrl]キーまたは[Shift]キーを押しながら、選択する行をクリックします。
実行する特定のアクションを選択します。
| アクション | 説明 |
|---|---|
|
検索ユーティリティでのコンポジット・センサーの検索 |
SOAインフラストラクチャ内のSOAコンポジット・アプリケーションのインスタンスでコンポジット・センサーを検索できます。書式 指定されたセンサー・パターンがSOAコンポジット・アプリケーションのどのコンポジット・センサーとも一致しない場合、インスタンスは表示されません。一致が見つかった場合は、コンポジットのインスタンスが表示されます。 次のコンポジット・センサー検索の表記規則に注意してください。
SOAコンポジット・アプリケーション・レベルでのセンサー名と値の取得の詳細は、第8.2項「アプリケーションのホーム・ページからのSOAコンポジット・プ・インスタンスの監視と削除」および第14.1項「BPELプロセス・サービス・コンポーネントの監査証跡とプロセス・フローの監視」を参照してください。 |
|
フィルタ条件 |
コンポジット・インスタンスの状態を表示するための基準を指定します。
|
|
選択項目の削除 |
|
|
オプションを指定して削除 |
選択したインスタンスをデータベースから直接削除するための基準を最初に指定するように、プロンプトが表示されます。 このオプションは、実行中のロールバックされたインスタンスを削除する場合に使用します。ただし、このオプションでは、リカバリ待機中の関連する呼出しメッセージは削除されません。その結果、BPELメッセージ・リカバリで保留される孤立したメッセージが発生します。これらのメッセージを削除するには、BPELプロセス・サービス・エンジンの「リカバリ」ページに移動します。
この操作では、「インスタンス」ページの上部で選択したインスタンスの状態は無視されます。 インスタンスの削除の進行状況を監視するには、ログ・ファイルを確認する必要があります。ログ・ファイルの詳細は、第3.4項「ログ・ファイルの構成」を参照してください。 注意:
|
|
中断 |
選択したインスタンスを終了します。ただし、インスタンス詳細は確認できます。 注意: フォルトが発生したインスタンスを削除すると、そのフォルトは「フォルト・メッセージと拒否メッセージ」ページに表示されなくなります。さらに、終了したインスタンス(「中断」と表示)にフォルトがある場合、そのフォルトはフォルト件数に含まれません。 |
「インスタンス」表で、次の追加タスクを実行します。
「ビュー」リストから、「列」→「パーティション」の順に選択し、SOAコンポジット・アプリケーション・リビジョンのインスタンスが含まれているパーティションを表示します。
「ビュー」リストから、「列」→「ECID」を選択して、ECIDを表示します。ECIDを使用すると、様々なコンポジットのインスタンス間のメッセージ・フローを追跡できます。
「インスタンスID」列で、特定のインスタンスIDをクリックし、様々なサービス・コンポーネントやバインディング・コンポーネント間のメッセージ・フローを表示します。インスタンスIDが使用不可能の場合は、メッセージ・フローにアクセスできません。ただし、リンクをクリックして詳細を確認することはできます。
「コンポジット」列で、特定のSOAコンポジット・アプリケーションをクリックし、そのホーム・ページにアクセスします。
「インスタンスの状態」列で、「リカバリ」アイコンをクリックし、コンポジット・インスタンスIDに基づいてフォルトがフィルタリングされている「フォルトと拒否メッセージ」ページにアクセスします。1つのコンポジット・インスタンスIDに対して複数のフォルトが存在する場合があります。
「ログ」列で、特定のログをクリックし、「ログ・メッセージ」ページにアクセスします。このページには、そのインスタンスに固有のメッセージがフィルタされて表示されます。
複数のSOAコンポジット・アプリケーションでBPELプロセスとOracle Mediatorサービス・コンポーネントを監視し、個別のフォルト・リカバリと一括のフォルト・リカバリを実行できます。リカバリ可能として識別されたBPELプロセス・フォルトについては、(fault-bindings.xmlファイルを介して)フォルトにバインドされ、アクションora-human-interventionをトリガーするフォルト・ポリシーが定義されている必要があります。ただし、フォルト・ポリシーが定義されていない場合、フォルトは、リカバリ可能またはリカバリ不可のフォルトとして通常どおり処理されます。この項では、個別リカバリと一括リカバリの両方の実行例を示します。ヒューマン・タスク・サービス・コンポーネントまたはヒューマン・ワークフロー・サービス・エンジンのフォルトは、Oracle BPM Worklistからリカバリされます。
また、未配信BPELプロセスの起動またはコールバック・メッセージの手動リカバリも実行できます。詳細は、第15.4項「BPELプロセス・サービス・エンジンのメッセージ・リカバリの実行」を参照してください。
SOAインフラストラクチャ・レベルでSOAコンポジット・アプリケーション・フォルトをリカバリする手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... | SOAコンポジットのメニューから... |
|---|---|---|
|
|
|
「フォルト・メッセージと拒否メッセージ」タブをクリックします。
「フォルト・メッセージと拒否メッセージ」ページに、すべてのSOAコンポジット・アプリケーション・フォルトについて、次の詳細が表示されます。
特定のフォルトを検索するためのユーティリティ。基準を指定して「検索」をクリックします。詳細は、「ヘルプ」アイコンをクリックしてください。デフォルトでは、このページに初めてアクセスしたときにはフォルトは表示されません。フォルトを表示するには、「検索」をクリックする必要があります。
インスタンス・リカバリ・アクション(再試行、中断、リプレイなど)、拒否メッセージの削除および一括メッセージ・リカバリの実行を選択するオプション。
フォルト・メッセージと拒否メッセージ。エラー・メッセージ、フォルトのリカバリが可能かどうか、フォルトの発生時間、フォルト・メッセージが拒否されたメッセージとして分類されているかどうか(その場合はチェックマークが表示されます)、フォルトが発生したSOAコンポジット・アプリケーション、フォルトの場所、インスタンスID、およびフォルトが記述されているログ・ファイルへのリンクが表示されます。
リカバリ可能として識別されたフォルトはリカバリできます。
次のいずれかのオプションを使用して、リカバリ対象のフォルトを選択します。SOAインフラストラクチャ・レベルでフォルト・リカバリを選択することは、SOAコンポジット・アプリケーション・レベル、およびBPELプロセスとOracle Mediatorサービス・コンポーネント・レベルでの選択と同等です。
| 対象 | 操作 |
|---|---|
|
単一フォルト・リカバリ |
|
|
一括フォルト・リカバリ |
|
|
すべてのフォルトのリカバリ |
|
| アクション | 説明 | アクションの対象 |
|---|---|---|
|
インスタンスを直接再試行します。このリカバリ・アクションを使用するシナリオ例は、ネットワーク・エラーのためにサービス・プロバイダにアクセスできないことが原因でフォルトが発生した場合の例です。ネットワーク・エラーは現在解決しています。 |
BPELプロセスとOracle Mediator |
|
|
インスタンス全体を終了します。 |
BPELプロセスとOracle Mediator |
|
|
フォルトが発生したスコープ全体を再度リプレイします。 |
BPELプロセス |
|
|
現在のフォルトを再スローします。フォルトの処理に、BPELフォルト・ハンドラ(catchブランチ)が使用されます。デフォルトでは、再スロー・フォルト・ポリシーが明示的に指定されていない場合、すべての例外がフォルト管理フレームワークによって捕捉されます。 |
BPELプロセス |
|
|
フォルトを無視して処理を続行します(フォルト・アクティビティには成功のマークが付けられます)。 |
BPELプロセス |
SOAインフラストラクチャのすべてのコンポジットの拒否メッセージを削除する場合は、第8.6項「SOAインフラストラクチャ・レベルでの拒否メッセージの削除」を参照してください。
メッセージの一括リカバリを実行する場合は、「オプションを指定してリカバリ」をクリックします。
すべてのコンポジットのBPELメッセージとOracle Mediatorメッセージをデータベースから直接リカバリする基準を指定する「オプションを指定してリカバリ」ダイアログが表示されます。ヒューマン・ワークフロー・メッセージは、Oracle BPM Worklistから手動でリカバリできます。ビジネス・イベントとビジネス・ルール・メッセージはリカバリできません。
条件を指定します。許可されるリカバリ・アクションは、「再試行」と「中断」のみです。
「リカバリ」をクリックします。メッセージの数に応じて、リカバリにかかる時間は異なります。
フォルト表内から次の追加タスクを実行します。
「ビュー」リストから、「列」→「フォルトID」の順に選択し、各エラー・メッセージのフォルトIDを表示します。フォルトIDは自動的に生成され、フォルトを一意に識別します。フォルトIDは、エラー・メッセージをクリックしたときも表示されます。
「コンポジット」列で、特定のSOAコンポジット・アプリケーションをクリックし、そのホーム・ページにアクセスします。
「フォルトの場所」列で、特定の場所をクリックし、フォルトの場所に関するフォルト・ページにアクセスします。フォルトの場所は、サービス、サービス・コンポーネントまたは参照です。
「コンポジット・インスタンスID」列で、特定のIDをクリックし、インスタンスのフローのトレースにアクセスします。
「ログ」列で、特定のログをクリックし、「ログ・メッセージ」ページにアクセスします。このページには、そのインスタンスに固有のメッセージがフィルタされて表示されます。
BPELプロセスとOracle Mediatorでの単一および一括フォルト・リカバリの例については、次の各項を参照してください。
フォルト・ポリシーの概念と設計方法の詳細は、次のドキュメントを参照してください。
『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のフォルト管理フレームワークによるフォルトの処理に関する項
この項では、BPELプロセスのフォルトに対して管理者操作を可能にするフォルト・ポリシーを定義し、BPELプロセス・サービス・コンポーネントで単一フォルト・リカバリおよび一括フォルト・リカバリを実行する方法の例を示します。
この例では、管理者操作によってフォルトを手動でリカバリできるフォルト・ポリシーを定義します。無効な社会保障番号が、融資ブローカBPELプロセスから信用格付けサービスに発行されると、信用格付けサービスはネガティブ情報フォルトを返します。この例の管理者操作によるアクションは、fault-policies.xmlファイルのora-human-interventionアクションで定義します。フォルト・ポリシーが定義されていない場合、BPELインスタンスではリカバリ可能なフォルトを生成しません(フォルトはリカバリ不可になります)。この場合は、ora-human-interventionアクションを使用してフォルトをリカバリ可能にします。例8-2は、フォルト・ポリシー・ファイルを示しています。
例8-2 フォルト・ポリシー・ファイル
<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">
<!-- 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>
例8-3に示されるfault-bindings.xmlファイルは、fault-policies.xmlファイルで定義されたフォルト・ポリシーをCRM_ServiceFaultsコンポジット・アプリケーションと関連付けます。
例8-3 フォルト・ポリシー・バインディング・ファイル
<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開発者ガイド』を参照してください。
BPELプロセス・メッセージ・リカバリの詳細は、第15.4項「BPELプロセス・サービス・エンジンのメッセージ・リカバリの実行」を参照してください。
この例の前提は次のとおりです。
インスタンスが、第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.4.1.1項「例: BPELプロセスに対する単一フォルト・リカバリ」の手順1および手順2を実行します。
検索ユーティリティで、判明しているフォルト・パラメータ(時間の範囲、コンポジット名、コンポーネント・タイプ(BPELプロセス)など)に基づいて基準を入力します。
検索結果が多数返される場合は、「リカバリ可能なフォルトのみ表示」チェック・ボックスを選択して表示を制限します。
「選択」リストから「すべてのリカバリ可能な値を選択」を選択します。
「リカバリ・アクション」リストから「中断」を選択します。
選択したすべてのフォルトを手動で停止します。
この項では、BPMNプロセスのフォルトに対して管理者操作を可能にするフォルト・ポリシーを定義し、BPMNプロセス・サービス・コンポーネントで単一フォルト・リカバリおよび一括フォルト・リカバリを実行する方法の例を示します。
|
注意: 複数インスタンス・プロセスがその完了の条件を満たした場合は、(残りのインスタンスを取り消すために)リカバリできないシステム・フォルトが発生します。このフォルトはOracle Enterprise Manager Fusion Middleware Controlに表示されますが、アクションを実行する必要はありません。条件が完了したため複数インスタンス・プロセスが確定したことを通知するために表示されます。 |
この例では、管理者操作によってフォルトを手動でリカバリするフォルト・ポリシーを定義します。無効な社会保障番号が、融資ブローカBPMNプロセスから信用格付けサービスに発行されると、信用格付けサービスはネガティブ情報フォルトを返します。この例の管理者操作によるアクションは、fault-policies.xmlファイルのora-human-interventionアクションで定義します。フォルト・ポリシーが定義されていない場合、BPMNインスタンスではリカバリ可能なフォルトを生成しません(フォルトはリカバリ不可になります)。この場合は、ora-human-interventionアクションを使用してフォルトをリカバリ可能にします。例8-4は、フォルト・ポリシー・ファイルを示しています。
例8-4 フォルト・ポリシー・ファイル
<faultPolicies xmlns="http://schemas.oracle.com/bpmn/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/bpmn/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Conditions>
<faultName xmlns:credit="http://services.otn.com"
name="credit:NegativeCredit">
<!-- 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>
例8-5に示されるfault-bindings.xmlファイルは、fault-policies.xmlファイルで定義されたフォルト・ポリシーをCRM_ServiceFaultsコンポジットと関連付けます。
例8-5 フォルト・ポリシー・バインディング・ファイル
<faultPolicyBindings version="2.0.1"
xmlns="http://schemas.oracle.com/bpmn/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<composite faultPolicy="CRM_ServiceFaults"/>
</faultPolicyBindings>
管理者操作はアクションとして定義されているため、BPMNプロセスに対するフォルト・リカバリはOracle Enterprise Manager Fusion Middleware Controlで実行します。
fault-policies.xmlファイルおよびfault-bindings.xmlファイルの作成と設計の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。
この例の前提は次のとおりです。
インスタンスが、第8.1項「SOAコンポジット・アプリケーションのテスト・インスタンスの起動」で示した「Webサービスのテスト」ページで起動されました。
0で始まる無効な社会保障番号が入力されました。
BPMNプロセスに対して単一フォルト・リカバリを実行する手順は、次のとおりです。
「SOAインフラストラクチャ」メニューから、「ホーム」を選択します。
「フォルト・メッセージと拒否メッセージ」タブをクリックします。
フォルト表で、リカバリ可能として識別されたフォルトを検索します。検索ユーティリティを使用して、特定のフォルトを検索できます。
「リカバリ」列で、「リカバリ」をクリックします。最初にフォルトの詳細を表示する場合は、エラー・メッセージをクリックします。次に、「ここでリカバリ」をクリックします。
BPMNプロセス・インスタンスの「フォルト」ページが表示されます。
「リカバリ」列で、「リカバリ可能」をクリックします。
ページがリフレッシュされ、ページの下部にフォルト・リカバリ・セクションが表示されます。
「リカバリ・アクション」リストから「再試行」を選択します。
「再試行成功時のチェーン・アクション」リストから「なし」を選択します。このリストでは、Javaコールアウト・リカバリ・アクションを選択できます。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。
「変数」リストから変数を選択します。この変数の内容が「値」フィールドに表示されます。この例では、変数crInputが選択されています。この変数は、invokeアクティビティで使用され、不適切な社会保障番号の値を含んでいます。
「値」フィールドに適切な値を入力します。この例では、社会保障番号を1で始まるように編集します。
<ssn xmlns="http://service.otn.com">123456789</ssn>
「設定値」をクリックし、プロンプトが表示されたら「はい」をクリックして続行します。
「リカバリ」をクリックしてフォルトをリカバリし、プロンプトが表示されたら「はい」をクリックして続行します。
ページがリフレッシュされ、フォルトが発生していないことが示されます。
社会保障番号の例の場合、「再試行」の選択は、一括リカバリを実行するためのオプションではありません。これは、社会保障番号の値が不適切で、修正が必要になるためです。「再試行」オプションを使用して一括リカバリを実行する例としては、社会保障番号は適切であるが、信用格付けサービスを提供するシステムが一時的に使用不可になったために、コンポジット参照のフォルトが発生した場合などがあります。この場合は、メッセージが配信されません。信用格付けサービスが再度使用可能になったときに、「再試行」を選択すると、コンポジット参照を介した信用格付けサービスの起動が再試行されます。
BPMNプロセスに対して一括フォルト・リカバリを実行する手順は、次のとおりです。
第8.4.2.1項「例: BPMNプロセスに対する単一フォルト・リカバリ」の手順1から2を実行します。
検索ユーティリティで、判明しているフォルト・パラメータ(時間の範囲、コンポジット名、コンポーネント・タイプ(BPMNプロセス)など)に基づいて基準を入力します。
検索結果が多数返される場合は、「リカバリ可能なフォルトのみ表示」チェック・ボックスを選択して表示を制限します。
「選択」リストから「すべてのリカバリ可能な値を選択」を選択します。
「リカバリ・アクション」リストから「中断」を選択します。
選択したすべてのフォルトを手動で停止します。
この項では、Oracle Mediatorサービス・コンポーネントで単一および一括フォルト・リカバリを実行する方法の例を示します。
この例では、インバウンドSiebelアダプタのサービス・バインディング・コンポーネントによって、変換のためにOracle Mediatorにペイロード・メッセージが発行されます。次に、処理されたペイロード・メッセージが、アウトバウンド・ファイル・アダプタの参照バインディング・コンポーネントに配信されます。ただし、ペイロード・メッセージの書込み先のアウトバウンド・ディレクトリが、書込み権限で構成されていません。この結果、フォルトが発生します。設計時に定義されたフォルト・ポリシーでは、フォルトは管理者操作によって手動でリカバリされることが指定されています。retryCount属性の定義に従って、再試行は3回行われます。条件およびアクションは、fault-policies.xmlファイルで次のように定義されています。
Oracle Mediatorのリカバリ可能なフォルトに対して、フォルト・ポリシーは必要ありません(ただし、ora-human-interventionアクションで説明したように、フォルト・ポリシーはフォルトをリカバリ可能にする1つの方法です)。また、アウトバウンド・エンドポイントからリモート・フォルトを受信するパラレル・ルーティング・ルールによっても、リカバリ可能なフォルトが作成されます(この例では、Oracle Mediatorがパラレル・ルーティング・ルールを使用してアウトバウンド・ファイル・アダプタを起動する場合、フォルト・ポリシーは必要ありません)。例8-6は、フォルト・ポリシー・ファイルを示しています。
例8-6 フォルト・ポリシー・ファイル
<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回再試行されるように設定されています。
例8-7に示されるように、フォルト・ポリシーは、fault-bindings.xmlファイルでConnectionFaultsコンポジット・アプリケーションと関連付けられています。
例8-7 フォルト・ポリシー・バインディング・ファイル
<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.4項「SOAインフラストラクチャ・レベルでの、SOAコンポジット・アプリケーションのフォルトのリカバリ」の手順3を参照してください。
| アクション | 説明 | アクションの対象 |
|---|---|---|
|
インスタンスを直接再試行します。このリカバリ・アクションを使用するシナリオ例は、ネットワーク・エラーのためにサービス・プロバイダにアクセスできないことが原因でフォルトが発生した場合の例です。ネットワーク・エラーは現在解決しています。 |
BPELプロセスとOracle Mediator |
|
|
インスタンス全体を終了します。 |
BPELプロセスとOracle Mediator |
|
|
フォルトが発生したスコープ全体を再度リプレイします。 |
BPELプロセス |
|
|
現在のフォルトを再スローします。フォルトの処理に、BPELフォルト・ハンドラ(catchブランチ)が使用されます。デフォルトでは、再スロー・フォルト・ポリシーが明示的に指定されていない場合、すべての例外がフォルト管理フレームワークによって捕捉されます。 |
BPELプロセス |
|
|
フォルトを無視して処理を続行します(フォルト・アクティビティには成功のマークが付けられます)。 |
BPELプロセス |
現在のSOAコンポジット・アプリケーションの拒否メッセージを削除する場合は、第8.7項「アプリケーションのホーム・ページからの拒否メッセージの削除」を参照してください。
メッセージの一括リカバリを実行する場合は、「オプションを指定してリカバリ」をクリックします。
現在のコンポジットのBPELメッセージとOracle Mediatorメッセージをデータベースから直接リカバリする基準を指定する「オプションを指定してリカバリ」ダイアログが表示されます。ヒューマン・ワークフロー・メッセージは、Oracle BPM Worklistから手動でリカバリできます。ビジネス・イベントとビジネス・ルール・メッセージはリカバリできません。
条件を指定します。許可されるリカバリ・アクションは、「再試行」と「中断」のみです。
|
注意: SOAコンポジット・アプリケーション・レベルの一括フォルト・リカバリでは、コンポジットの状態のチェックが実行されます。コンポジットの状態がオフに設定されている場合は、リカバリを実行できないことを警告するメッセージが表示されます。 なんらかの理由(たとえば、サポートされていないサービス・エンジンやリカバリできないフォルトなど)でリカバリ中にフォルトがスキップされた場合は通知されません。 |
「リカバリ」をクリックします。メッセージの数に応じて、リカバリにかかる時間は異なります。
「フォルト」表内から次の追加監視タスクを実行します。
「ビュー」リストから、「列」→「フォルトID」の順に選択し、各エラー・メッセージのフォルトIDを表示します。フォルトIDは自動的に生成され、フォルトを一意に識別します。フォルトIDは、エラー・メッセージをクリックしたときも表示されます。
「フォルトの場所」列で、特定の場所をクリックし、フォルトの場所に関するフォルト・ページにアクセスします。フォルトの場所は、サービス、コンポーネントまたは参照です。
「コンポーネント・インスタンスID」列で、特定のサービス・コンポーネントIDをクリックし、インスタンスに関するタスク詳細(たとえば、タスクの現在の状態)にアクセスします。拒否メッセージにはコンポーネント・インスタンスIDがありません。
「ログ」列で、特定のログをクリックし、「ログ・メッセージ」ページにアクセスします。このページには、そのインスタンスに固有のメッセージがフィルタされて表示されます。
詳細は、次の項を参照してください。
SOAインフラストラクチャのすべてのコンポジットの拒否メッセージは、「削除: 拒否メッセージ」ダイアログで基準を指定することによって、データベースから直接削除できます。
SOAインフラストラクチャ・レベルですべてのコンポジットの拒否メッセージを削除する手順は次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... | SOAコンポジットのメニューから... |
|---|---|---|
|
|
|
「フォルト・メッセージと拒否メッセージ」タブをクリックします。
「フォルト・メッセージと拒否メッセージ」ページに、すべてのSOAコンポジット・アプリケーション・フォルトについて、次の詳細が表示されます。
特定のフォルトを検索するためのユーティリティ。基準を指定して「検索」をクリックします。詳細は、「ヘルプ」アイコンをクリックしてください。デフォルトでは、このページに初めてアクセスしたときにはフォルトは表示されません。フォルトを表示するには、「検索」をクリックする必要があります。
インスタンス・リカバリ・アクション(再試行、中断、リプレイなど)、拒否メッセージの削除および一括メッセージ・リカバリの実行を選択するオプション。
フォルト・メッセージと拒否メッセージ。エラー・メッセージ、フォルトのリカバリが可能かどうか、フォルトの発生時間、フォルト・メッセージが拒否されたメッセージとして分類されているかどうか(その場合はチェックマークが表示されます)、フォルトが発生したSOAコンポジット・アプリケーション、フォルトの場所、インスタンスID、およびフォルトが記述されているログ・ファイルへのリンクが表示されます。
「拒否メッセージの削除」をクリックします。
|
注意: 本番環境でコンポジット・インスタンスを削除するには、パージ・スクリプトの実行をお薦めします。パージ・スクリプトはパフォーマンスとスケーラビリティが優れています。「拒否メッセージの削除」オプションは、パージ・スクリプトの対象に含まれない例外の管理のみに使用してください。パージ・スクリプトの詳細は、第10.3項「パージ・スクリプトを使用した大量のインスタンスの削除」を参照してください。 |
すべてのコンポジットの拒否メッセージをデータベースから直接削除するための基準を指定する「削除: 拒否メッセージ」ダイアログが表示されます。
基準を指定して、「削除」をクリックします。
SOAインフラストラクチャ・レベルでのフォルトのリカバリの詳細は、第8.4項「SOAインフラストラクチャ・レベルでの、SOAコンポジット・アプリケーションのフォルトのリカバリ」を参照してください。
現在のSOAコンポジット・アプリケーションの拒否メッセージは、「削除: 拒否メッセージ」ダイアログで基準を指定することによってデータベースから直接削除できます。
現在のSOAコンポジット・アプリケーションの拒否メッセージを削除する手順は次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「フォルト・メッセージと拒否メッセージ」タブをクリックします。
「フォルト・メッセージと拒否メッセージ」ページに、すべてのSOAコンポジット・アプリケーション・フォルトについて、次の詳細が表示されます。
特定のフォルトを検索するためのユーティリティ。基準を指定して「検索」をクリックします。詳細は、「ヘルプ」アイコンをクリックしてください。デフォルトでは、このページに初めてアクセスしたときにはフォルトは表示されません。フォルトを表示するには、「検索」をクリックする必要があります。
インスタンス・リカバリ・アクション(再試行、中断、リプレイなど)、拒否メッセージの削除および一括メッセージ・リカバリの実行を選択するオプション。
フォルト・メッセージと拒否メッセージ。エラー・メッセージ、フォルトのリカバリが可能かどうか、フォルトの発生時間、フォルト・メッセージが拒否されたメッセージとして分類されているかどうか(その場合はチェックマークが表示されます)、フォルトが発生したSOAコンポジット・アプリケーション、フォルトの場所、インスタンスID、およびフォルトが記述されているログ・ファイルへのリンクが表示されます。
「拒否メッセージの削除」をクリックします。
|
注意: 本番環境でコンポジット・インスタンスを削除するには、パージ・スクリプトの実行をお薦めします。パージ・スクリプトはパフォーマンスとスケーラビリティが優れています。「拒否メッセージの削除」オプションは、パージ・スクリプトの対象に含まれない例外の管理のみに使用してください。パージ・スクリプトの詳細は、第10.3項「パージ・スクリプトを使用した大量のインスタンスの削除」を参照してください。 |
現在のコンポジットの拒否メッセージをデータベースから直接削除するための基準を指定する「削除: 拒否メッセージ」ダイアログが表示されます。
基準を指定して、「削除」をクリックします。
SOAコンポジット・アプリケーションのホーム・ページでのフォルトのリカバリの詳細は、第8.5項「アプリケーションのホーム・ページでの、SOAコンポジット・アプリケーションのフォルトのリカバリ」を参照してください。
実行中のSOAコンポジット・アプリケーション・インスタンスは、コンポジットのあるリビジョンから別のリビジョンに移行できます(たとえば、デプロイ済のCreditRatingServiceリビジョン1.0コンポジットのCreditRatingServiceリビジョン2.0コンポジットへの移行)。このアクションは、元のリビジョンに影響を及ぼすことなく、インスタンスを移行し、両リビジョンのインスタンスのサイドバイサイドでの実行を可能にします。移行されたインスタンスは、SOAコンポジット・アプリケーションのターゲット・リビジョンで表示されます。SOAコンポジット・アプリケーション・インスタンスのサービス・コンポーネント・インスタンスもすべて移行されます。
インスタンス移行には次のような理由があります。
プロセスの初期リビジョンで設計または実装エラーが発見されたり、外部サービスから提供される無効データがプロセスの状態を不良にする可能性がある。
プロセスの完了までの所要時間が長すぎる。たとえば、月単位または年単位で実行するインスタンスがあるとします。これが原因で次のようになります。
インスタンスの進行中に変更を適用する必要が生じることがあります。
事前には変更が不明のため、常にルールまたは短期間のサブプロセスとしてモデル化できるとはかぎりません。
規制またはポリシーの変更(新規ポリシーまたは変更ポリシーの強制の適用)により、すべてのプロセスにステップを追加することが必要になります。
インスタンスの移行には次の制限が適用されます。
双方のコンポジット・リビジョンをデプロイする必要があります。
実行中のインスタンスのみ移行が可能です。フォルト状態でも移行が成功するOracle Mediatorを除き、完了、中断、フォルトのインスタンスは移行できません。
互換性のあるインスタンスのみ、正常に移行できます。互換性は、コンポジット内の関連サービス・コンポーネントの互換性に依存します。重要な変更は移行できません。
コンポジット・インスタンスごとにトランザクション境界が存在します。一般に、特定のコンポジットに関連するインスタンスはバッチで操作されます。コンポジット・インスタンスのそれぞれは、単一トランザクションにバインドされます。バッチ全体が失敗していなくても、1つ以上のコンポジット・インスタンスの移行が失敗する場合があります。
次の2つの移行方法がサポートされます。
自動移行: リビジョン間の変更が些少の場合。コンポジット・インスタンスのそれぞれは、単一トランザクションにバインドされます。コンポジット・インスタンスのバッチを移行できます。
移行計画を使用した手動移行(Oracle BPMのみ): リビジョン間で重要な変更がある場合に使用されます。移行計画には、移行の実行方法が記載されます。
コンポジット移行の互換性は、アプリケーション内で定義されているサービス・コンポーネントに依存します。サービス・コンポーネントに対する変更に互換性がない場合は、そのインスタンス全体が移行に不適格になります。SOAコンポジット・アプリケーション・インスタンスは、関連するサービス・コンポーネント・インスタンスが移行可能な場合のみ移行されます。
次のサービス・コンポーネントは移行できます。
非永続的BPELプロセス
Oracle Mediator
ヒューマン・ワークフロー
ビジネス・ルール
Oracle BPMN
関与するサービス・エンジンはそれぞれのインスタンスを移行するために調整されます。インスタンス追跡データは、新しいリビジョンに移行されます。
表8-1は、各サービス・コンポーネント・インスタンスが新しいインスタンスにどのように移行されるかを示しています。互換性がない場合は、コンポジット・インスタンスの移行全体が非互換とレポートされ、移行はできません。
表8-1 サービス・コンポーネント・インスタンスの移行の詳細
|
注意: パラレル・ルーティング・ルールのあるOracle Mediatorサービス・コンポーネントおよびOracle BPMNサービス・コンポーネントを含むコンポジット・インスタンスではインスタンスの移行が失敗します。次の値が返されます。
ただし、Oracle BPMNサービス・コンポーネントの場合は、移行が成功しなかった場合でも |
次の2つのインスタンス移行方法があります。
Facade APIを使用してインスタンスを移行できます。
次の2つの基本APIカテゴリが提供されます。
次の情報を提供する移行レポートの生成
移行の実行前のコンポジット・インスタンスの一部セットの移行の実行可能性
移行するコンポジット・インスタンスの数および実行可能性
移行する関連サービス・コンポーネント・インスタンスの数および実行可能性
インスタンス移行の全体的な実行可能性: 手動移行の必要性、自動移行の必要性、または移行が非互換であるか
手動移行の必要性、または移行が非互換である理由
インスタンス移行の結果の提供
移行実行の結果: 移行が成功または失敗したコンポジットおよびサービス・コンポジット・インスタンス
失敗原因
Facade APIでは、同期バージョンと非同期バージョンの両方が提供されます。
Facade APIの詳細は、Oracle Fusion Middleware Infrastructure Management Oracle SOA Suite Java APIリファレンスおよび第11章「Facade APIを使用したSOAコンポジット・アプリケーションのプログラムによる管理」を参照してください。
例8-8は、コンポジット・インスタンス・移行サマリーを取得するFaçade APIを示しています。このサマリーは、指定されたフィルタ基準と一致するコンポジット・インスタンスの移行の可能性を示します。
例8-8 一括移行の評価
/** * Synchronously generates a migration report. The results would be limited to some * fixed number of composite instances to avoid EJB time-outs. * We should probably provide a way for the client to specify an even smaller * maximum number of instances. * * @param filter - The composite instance selection criteria * @param targetRevision - The revision to which the composite instances should be * migrated * * @return A MigrationReport */ MigrationReport generateMigrationReport(CompositeInstanceFilter filter, String targetRevision); /** * Asynchronously generates a migration report. There is no limit on the number of * composite instances included in the result. * * @param filter - The composite instance selection criteria * @param targetRevision - The revision to which the composite instances should be * migrated * @return A unique report identifier, which can be used to subsequently retrieve * the report. */ String initiateMigrationReport(CompositeInstanceFilter filter, String targetRevision); /** * Retrieves an asynchronously-generated migration report. * * @param reportId - A unique report identifier; the result of the * initiateMigrationReport method. * * @return The MigrationReport for the specified report identifier */ MigrationReport getMigrationReport(String reportId);
このレポートに含まれる情報は次のとおりです。
コンポジット・インスタンスの詳細:
コンポジット・インスタンス名
コンポーネント・インスタンスID
コンポーネント・インスタンスの状態
移行ステータス: 自動か、移行計画が必要か(また、該当する場合は必要な変更計画)
コンポーネント・インスタンス・データの詳細:
サマリー・データ:
ターゲットのリビジョン
一致するコンポジット・インスタンスの合計数
自動的に移行可能なコンポジット・インスタンスの数
自動的に移行不可能なコンポジット・インスタンスの数
結果が切り捨てられた場合は、その事実を示す記載が必要
移行レポートは、コンポジット・インスタンスの移行の実現可能性が記載されます。例8-9に詳細を示します。
例8-9 移行レポート
package oracle.soa.management.facade;
public interface MigrationReport {
/**
* @return The detailed migration feasibility description
*/
MigrationFeasibility getFeasibility();
/**
* @return The revision to which the composite(s) will be migrated.
*/
String getTargetRevision();
/**
* @return The number of composite instances matching the criteria for which
* this report was generated.
*/
long getCompositeInstanceCount();
/**
* @return The composite instances matching the criteria for which this
* report was generated.
*/
List<CompositeInstanceMigrationReport> getCompositeInstances();
Façade APIは、インスタンス(構成可能なバッチ・サイズ)を移行します。例8-10に詳細を示します。
例8-10 移行の一括実行
/** * Asynchronously attempt to migrate the composite instances described in the * specified migration report. * @param report - A MigrationReport, describing which composite instances should * be migrated. * @param plan - A MigrationPlan, specifying how those instances that cannot be * automatically migrated should be handled. * * @return A unique migration result identifier, which can be used to subsequently retrieve the migration result. */ String migrateCompositeInstances(MigrationReport report, MigrationPlan plan). /** * Retrieves the migration result for the specified migration attempt. * * @param resultId - The unique identifier for a particular migration attempt; the * result of invoking migrateCompositeInstances * @return A MigrationResult, describing the results of the migration attempt. */ MigrationResult getMigrationResult(String resultId); /** * Synchronously attempts to migrate those composite instances that match the * specified filter criteria * to the specified target revision, applying the specified migration plan. * * The number of composite instances for which migration is attempted will be * limited to some fixed number, * unless a lesser maximum is otherwise specified. (TBD, can this be specified via * the filter?) * * @param filter - The composite instance selection criteria * @param targetRevision - The revision to which the composite instances should be * migrated * @param plan - The plan for handling those composites that cannot be * automatically migrated * * @return A MigrationResult, describing the results of the migration attempt. */ MigrationResult migrateCompositeInstances(CompositeInstanceFilter filter, String targetRevision,MigrationPlan plan);
MigrationResultインタフェースは、コンポジット・インスタンスの移行の実行結果を記述します。例8-11に詳細を示します。
例8-11 移行の結果
package oracle.soa.management.facade;
public interface MigrationResult extends Serializable {
/**
* @return The revision to which the composite instances were to be migrated.
*/
String getTargetRevision();
/**
* @return The total number of composite instances included in the migration
* attempt.
*/
long getCompositeCount();
/**
* @return The number of composite instances for which migration succeeded.
*/
long getMigratedCount();
/**
* @return The number of composite instances for which migration failed.
*/
long getFailedCount();
/**
* @return The list of composite instances that were successfully migrated.
*/
List<CompositeInstanceMigrationResult> getMigratedInstances();
/**
* @return The list of composite instances for which migration failed.
*/
List<CompositeInstanceMigrationResult> getFailedInstances();
}
MigrationPlanインタフェースは、重要なコンポジットまたはコンポーネントの変更をどのように処理するかに関するXMLの記述を提供します。例8-12に詳細を示します。
例8-12 移行計画
public interface MigrationPlan extends Serializable {
/**
* @param componentDN A component distinguished name (less any label)
*
* @return The migration plan element for the specified componentDN
*/
org.w3c.dom.Element getComponentPlan(String componentDN);
/**
* @return The migration plan for the composite instances
*/
org.w3c.dom.Element getCompositePlan();
}
CompositeInstance Facadeタイプには、単一コンポジット・インスタンスの移行をサポートするメソッドが含まれています。一括操作は、個別のコンポジット・インスタンスでメソッドを起動するLocatorインタフェースから直接使用できます。例8-13に詳細を示します。
例8-13 移行API
CompositeInstanceMigrationReport checkCompatibility(String revision);
/**
* Calls suspend on all the associated component instances
* Calls migrate for those same component instances
* Calls resume on all those same component instances
* The migration plan may contain component-specific directives.
*/
CompositeInstanceMigrationResult migrate(MigrationPlan plan);
public interface CompositeInstanceMigrationReport extends Serializable {
String getPartition();
String getCompositeName();
String getCompositeId();
String getRevision();
String getTargetRevision();
MigrationFeasibility getFeasibility();
long getComponentInstanceCount();
List<ComponentInstanceMigrationReport> getComponentInstances();
String getIncompatibilityReason();
}
public interface ComponentInstanceMigrationReport extends Serializable {
String getComponentName();
String getComponentId();
MigrationFeasibility getMigrationFeasibility();
String getIncompatibilityReason();
}
public class MigrationFeasibility implements Serializable {
public static MigrationFeasibility Automatic;
public static MigrationFeasibility MigrationPlanRequired;
public static MigrationFeasibility Incompatible;
public boolean isAutomatic();
public boolean isMigrationPlanRequired();
public boolean isIncompatible();
}
public interface CompositeInstanceMigrationResult extends Serializable {
/**
* @return true, if the composite instance and all its components were
* successfully migrated; otherwise, false.
*/
boolean migrated();
/**
*
* @return The name of the partition to which the composite is deployed
*/
String getPartition();
/**
* @return The composite name
*/
String getName();
/**
* @return The composite instance identifier
*/
String getId();
/**
* @return The previous revision
*/
String getRevision();
/**
* @return The revision to which the instance was to be migrated
*/
String getTargetRevision();
/**
* @return The migration results for the associated component instances
*/
List<ComponentInstanceMigrationResult> getComponentInstances();
/**
* @return The reason why the migration failed, if it failed; otherwise, null
*/
String getFailureReason();
}
public interface ComponentInstanceMigrationResult extends Serializable {
/**
* @return true, if the component instance was successfully migrated; otherwise,
* false.
*/
boolean migrated();
/**
* @return The component name
*/
String getName();
/**
* @return The component instance identifier
*/
String getId();
/**
* @return The reason why the migration failed, if it failed; otherwise, null
*/
String getFailureReason();
}
移行が失敗した場合は、例8-14に示されるJavaコードを使用して失敗したコンポーネントのリストを取得します。コンポジット・インスタンスの状態が完了または失敗としてマークされ、コンポジット・インスタンスの別のリビジョンへの移行が失敗している場合、f.getComponentInstances()は、コンポーネント・インスタンスに関する詳細の取得が可能なComponentInstanceMigrationResultオブジェクトのリストを返します。
例8-14 失敗した移行コンポーネントのリストの取得
private static void validateMigrationResult(MigrationResult mr)
{
if (mr != null)
{
List<CompositeInstanceMigrationResult> failed =
mr.getFailedInstances();
for (CompositeInstanceMigrationResult f: failed)
{
List<ComponentInstanceMigrationResult> failedComponents =
f.getComponentInstances();
System.out.println("Failed components list size: " +
failedComponents.size() + " Failed components list: " +
failedComponents);
}
}
}
インスタンスは、例8-15に示される$Middleware_Home/SOA_Suite_Home/bin/ant-bpm-migration.xmlスクリプトを使用して移行できます。
例8-15 ant-bpm-migration.xmlスクリプト
<?xml version="1.0" encoding="iso-8859-1"?>
<project name="ant-migration" basedir=".">
<property environment="env"/>
<property name="name" value="${ant.project.name}"/>
<dirname property="imported.basedir" file="${ant.file.ant-migration}"/>
<property name="mw.ora.home" location="${imported.basedir}/.."/>
<property name="mw.home" location="${imported.basedir}/../.."/>
<!--
<path id="ant-extensions.classpath">
<pathelement
path="${bpm.home}/generated/lib/oracle.bpm.runtime.public-tools.jar"/>
<pathelement path="${bpm.home}/../pcbpel/fabric/lib/soa-infra-mgmt.jar"/>
<pathelement path="${bpm.home}/../pcbpel/fabric/lib/fabric-common.jar"/>
<pathelement path="${bpm.home}/../pcbpel/fabric/lib/xmlparserv2.jar"/>
<pathelement path="${bpm.home}/main/libraries/batik-1.7/lib/xerces_2_5_
0.jar"/> <pathelement
path="${bpm.home}/../pcbpel/fabric/lib/fabric-runtime.jar"/>
<pathelement path="${bpm.home}/tools/lib/apb-ext/wlfullclient.jar"/>
<pathelement path="${bpm.home}/../pcbpel/generated/jrf/wsclient_
extended.jar"/>
</path>
-->
<path id="ant-extensions.classpath">
<pathelement
path="${mw.ora.home}/soa/modules/oracle.bpm.runtime.public-tools.jar"/>
<pathelement path="${mw.home}/oracle_common/soa/modules/oracle.soa.mgmt_
11.1.1/soa-infra-mgmt.jar"/>
<pathelement path="${mw.home}/oracle_common/modules/oracle.fabriccommon_
11.1.1/fabric-common.jar"/>
<pathelement path="${mw.home}/oracle_common/modules/oracle.xdk_
11.1.0/xmlparserv2.jar"/>
<pathelement path="${mw.ora.home}/soa/modules/oracle.soa.fabric_
11.1.1/fabric-runtime.jar"/>
<pathelement path="${mw.home}/wlserver_10.3/server/lib/wlfullclient.jar"/>
<pathelement path="${mw.home}/oracle_common/webservices/wsclient_
extended.jar"/>
</path>
<!--
================================================================== -->
<typedef name="locatorConfig"
classname="oracle.bpmn.engine.tools.pub.migration.LocatorConfig"
loaderRef="soa-infra-tools-loader">
<classpath refid="ant-extensions.classpath"/>
</typedef>
<taskdef name="locatorSession"
classname="oracle.bpmn.engine.tools.pub.migration.LocatorSession"
loaderRef="soa-infra-tools-loader">
<classpath refid="ant-extensions.classpath"/>
</taskdef>
<typedef name="compositeInstanceFilterDef"
classname="oracle.bpmn.engine.tools.pub.migration.CompositeInstanceFilterDef"
loaderRef="soa-infra-tools-loader">
<classpath refid="ant-extensions.classpath"/>
</typedef>
<typedef name="generateMigrationReport"
classname="oracle.bpmn.engine.tools.pub.migration.GenerateMigrationReport"
loaderRef="soa-infra-tools-loader">
<classpath refid="ant-extensions.classpath"/>
</typedef>
<typedef name="migrateCompositeInstances"
classname="oracle.bpmn.engine.tools.pub.migration.MigrateCompositeInstances"
loaderRef="soa-infra-tools-loader">
<classpath refid="ant-extensions.classpath"/>
</typedef>
<!--<taskdef name="secure-input"
classname="oracle.fabric.management.deployedcomposites.ant.TempInputTask">-->
<!--<classpath>-->
<!--<pathelement path="${handler.class.path}"/>-->
<!--</classpath>-->
<!--</taskdef>-->
<!--<target name="...">-->
<!--<secure-input message="Please enter password:"
addproperty="password">-->
<!--<handler
classname="oracle.fabric.management.deployedcomposites.ant.SecureInputHandler">-->
<!--<classpath refid="handler.class.path"/>-->
<!--</handler>-->
<!--</secure-input>-->
<!--</target>-->
<!-- -->
<!--
=============================================================-->
<target name="help">
<echo message="res=${myresource}"/>
<echo
message="mw=${mw.ora.home}/soa/modules/oracle.bpm.runtime.public-tools.jar"/>
<echo message="
============================================================================="/>
<echo message="Usage : "/>
<echo message="===================================================================="/> </target>
</project>
ant-bpm-migration.xmlスクリプトは、$Middleware_Home/wlserver_10.3/server/libディレクトリ内のwlfullclient.jarファイルを必要とします。このクライアント・ライブラリJARは、次のタスクを実行することによって生成できます。
次のディレクトリに変更します。
cd $fmw.home/wlserver_10.3/server/lib
次のコマンドを実行して、クライアント・ライブラリJARを構築します。
java -jar wljarbuilder.jar
ここでは、Oracle BPMを含むReviewProcessコンポジットのリビジョン・インスタンスを移行する例を紹介します。この例ではヒューマン・ワークフローの承認タスクが削除されているため、移行計画が必要になります。
図8-1は、コンポジットのリビジョン1.0のインスタンス・フローを示しています。このコンポジットのリビジョンには、時間を消費するユーザー承認タスクであるVeryExpensiveUserReviewを含め、2つのヒューマン・タスクが存在します。
図8-2は、SOAコンポジット・エディタ内でリビジョン1.0のコンポジットを表示しています。
図8-3は、リビジョン2.0のコンポジット・アプリケーションの改善されたインスタンス・フローを示しています。
時間を消費するVeryExpensiveUserReviewヒューマン承認タスクが削除されています。かわりに、サービス・タスクによる自動確認が使用されています。このサービス・タスクは、確認承認を外部のWebサービスに委譲します。
図8-4は、SOAコンポジット・エディタ内でリビジョン2.0のコンポジット・アプリケーションを表示しています。
移行時は、次のタスクが発生します。
ReviewProcessの定義が改善された新しい2.0リビジョンがデプロイされます。
この新しい2.0リビジョンは、古い1.0リビジョンとサイドバイサイドで実行されます。
進行中のインスタンスは、必要に応じてリビジョンが移行されます。
Oracle BPMのリビジョン・インスタンスを移行する手順は次のとおりです。
以下を判定する移行実行可能性レポートを生成します。
選択したコンポジット・インスタンスの移行が実行可能であるかどうか。
移行が自動であるか、移行計画を使用した手動であるか。アクティビティで実行中のインスタンスが削除されるため、移行計画が必要です。
移行計画では以下が指定されます。
古いリビジョンのVeryExpensiveUserReviewタスクから新しいコンポーネントのLegacyReviewタスクへのフロー更新。
後でLegacyReviewタスク・タイトルで使用される新しい値でのインスタンス・データの更新。
次のタスクが実行される移行計画を作成します。
データ・オブジェクトの更新。
インスタンス・タイトル値の更新。
VeryExpensiveUserReviewタスク・フローのLegacyReviewタスク・フローへの置換。
移行計画は任意のディレクトリの場所に配置できます。移行計画のサンプルは、次のURLで提供されています。
http://java.net/projects/oraclebpmsuite11g/pages/Samples
サンプルを使用することも、XSDに基づいて独自の移行計画を作成することもできます。build.xmlファイルを実行してインスタンスを移行する際に、ファイルへのパスを指定します。
次の2つの方法のいずれかを使用してFacade APIを実行します。
Facade APIを直接実行します。詳細は、第8.8.2項「Facade APIによるインスタンスの移行」を参照してください。
antで使用するbuild.xmlファイルを作成します。この例では、antが使用されます。build.xmlファイルは、ディレクトリ構造の任意の場所に配置できます。antを同じディレクトリから実行するか、ant -fを実行し、build.xmlのディレクトリ・パスの場所を指定する必要があります。
<property name="migrationPlanPath" value="${basedir}/migration_plan.xml"/>
locatorConfig id="c1" host="${wls.host}" port=${wls.port}"
user="{wls.user}" password="${wls.password}"/>
compositeInstanceFilterDef id="f1" domainName="default"
compositeName="Project3" compositeInstanceId="40001"/>
<target name="test">
<locatorSession configId="c1">
<generateMigrationReport filterId="f1" revision="2.0">
<migrateReportedCompositeInstances migrationPlanPath=
"${migrationPlanPath}"/>
</generateMigrationReport>
</locatorSession>
</target>
SOAコンポジット・アプリケーションのリビジョン1.0のインスタンスを作成します。インスタンスを移行するには、リビジョン1.0と2.0の両方がデプロイされている必要があります。インスタンスの作成の詳細は、第8.1項「SOAコンポジット・アプリケーションのテスト・インスタンスの起動」を参照してください。
リビジョン1.0のインスタンスID(この例では40007)をクリックします。
ReviewProcessインスタンスをクリックします。
「フロー」タブをクリックします。
フローのリビジョン1.0が表示されます。インスタンスは、2つのインスタンス・タスクのパラレル承認で待機しています。
build.xmlファイルの場所に移動します。
移行するcompositeInstanceId値を40007に変更します。
右上隅で、antスクリプトを実行します。
antビルド・レポートを表示して、移行が成功したことを確認します。
Oracle Enterprise Manager Fusion Middleware Controlの「インスタンス」ページに戻ります。
「リフレッシュ」アイコンをクリックして、古いインスタンスが表示されなくなっていることに注目します。これは、新しいインスタンスに移行されたためです。
ナビゲータでリビジョン2.0をクリックします。
リビジョンに移行後のインスタンスが表示されていることがわかります。
インスタンスをクリックします。
「トレース」表で、ReviewProcessをクリックします。
LegacyReviewヒューマン・ワークフロー・コンポーネントは実行中と表示され、VeryExpensiveUserReviewヒューマン・ワークフロー・コンポーネントは、取消し済として表示されます。
「フロー」タブをクリックします。
LegacyReviewのある新しいフローを表示します。
Oracle Business Process Workspaceにログインします。
「プロセス・トラッキング」をクリックして、ページをリフレッシュします。
バージョンReviewProcess 2.0が実行中であることがわかります。
承認するタスクに移動して、「承認」を選択します。
Oracle Enterprise Manager Fusion Middleware Control内のインスタンスに戻ります。
「フロー」タブをクリックします。
アクティビティが承認済と表示されていることがわかります。
この例では、多様なサービス・コンポーネントとともにリビジョンを移行する方法を説明します。
Oracle Mediator
BPELプロセス
ヒューマン・ワークフロー
ビジネス・ルール
Oracle BPM
すべてのサービス・コンポーネントとともにリビジョン・インスタンスを移行する手順は次のとおりです。
Oracle Enterprise Manager Fusion Middleware Controlの「インスタンス」ページに移動します。この例では、コンポジットのデプロイ済リビジョンが3つ存在します。リビジョン1.0にはインスタンスが1つあります(この例では40005)。
インスタンスIDをクリックすると、リビジョンに複数のサービス・コンポーネントがあることがわかります。
Facade APIを起動して、次のタスクを実行します。
リビジョン1.0から2.0へのインスタンスの移行の移行レポートを生成します。
実際の移行を実行します。
この例では、単純なJavaServer Page (JSP)インタフェースを使用して、Facade APIを起動します。独自のJSPインタフェースを作成できます。Facade APIの詳細は、第8.8.2項「Facade APIによるインスタンスの移行」を参照してください。
「ターゲット・リビジョン」フィールドに移行するリビジョンを入力します(この例では2.0)。
「発行」をクリックします。
レポートが完了し、次のセクションに表示されます。
「移行レポート」セクションは、すべてのサービス・コンポーネントが自動移行できることを示します。
移行結果セクションは、すべてのサービス・コンポーネントの移行が成功したことを示します。
Oracle Enterprise Manager Fusion Middleware Controlの「インスタンス」ページに戻ります。
ページをリフレッシュすると、リビジョン1.0のインスタンスが使用できなくなっていることがわかります。
コンポジットのリビジョン2.0をクリックすると、インスタンス4005が実行中であることがわかります。
インスタンスIDをクリックすると、すべてのサービス・コンポーネントが移行されたことがわかります。Oracle BPMNサービス・コンポーネントは承認を待っています。
Oracle Business Process Workspaceにログインします。
「アクション」リストから、「承認」を選択します。
Oracle Enterprise Manager Fusion Middleware Controlのインスタンスに戻ると、サービス・コンポーネント・インスタンスが完了していることがわかります。
この例は、BPELプロセスが永続的なwaitアクティビティを使用していることが原因で移行がどのように不可能になるかを示しています。
Facade APIを使用して、リビジョン3.0のインスタンスの1.0への移行を試行します。この例でも、第8.8.5項「すべてのサービス・コンポーネントとともにリビジョン・インスタンスを移行する例」で使用されたJSPページを使用します。
「ターゲット・リビジョン」フィールドにリビジョン番号を入力します(この例では1.0)。
「発行」をクリックします。
レポートが完了し、次のセクションに表示されます。
「移行レポート」セクションに、サポートされない永続BPELプロセスが原因で、移行に互換性がないことが示されます。
移行結果に、その後の移行の試行が失敗したことが示されます。
Oracle Enterprise Manager Fusion Middleware Controlの「インスタンス」ページに戻ります。
「リフレッシュ」アイコンをクリックすると、古いインスタンスが新しいインスタンスに移行されていないことがわかります。
