| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理 12c (12.1.3) E54311-05 |
|
 前へ |
 次へ |
| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理 12c (12.1.3) E54311-05 |
|
|
前へ |
次へ |
この章の内容は次のとおりです。
サービス・コンポーネントとサービス・エンジンの概念の詳細は、次の項を参照してください。
現在デプロイされているSOAコンポジット・アプリケーションのBPELプロセス・サービス・コンポーネントとの間で、ポリシーをアタッチおよびデタッチできます。ポリシーはメッセージの配信にセキュリティを適用します。Oracle Fusion Middlewareでは、ポリシー・ベースのモデルを使用してWebサービスを管理します。
注意:
ポリシーをアタッチする前に、使用可能なポリシーの定義およびユーザー環境で使用するポリシーの詳細は、Oracle Web Services ManagerによるWebサービスの保護およびポリシーの管理に関する項を参照してください。
BPELプロセス・サービス・コンポーネント・ポリシーを管理する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「コンポーネント」セクションでBPELプロセス・サービス・コンポーネントを選択します。
「ポリシー」をクリックします。
「ポリシー」ページを使用すると、BPELプロセス・サービス・コンポーネントとの間でポリシーをアタッチおよびデタッチできます。「ポリシー」表には、アタッチされたポリシーの名前、切替え可能なポリシー参照ステータス(有効または無効)、カテゴリ(「管理」、「信頼できるメッセージング」、「MTOMアタッチメント」、「セキュリティ」または「WSアドレス」など)、違反、およびSOAインフラストラクチャの最後の再起動以降の認証、認可、機密性および整合性の失敗が表示されます。
「アタッチ/デタッチ」をクリックします。
複数のコンポーネントが使用可能な場合は、アタッチまたはデタッチを実行するサービスまたはコンポーネントを選択するプロンプトが表示されます。
ポリシーのアタッチ先またはデタッチ先のサービスまたはコンポーネントを選択します。
ポリシーをアタッチまたはデタッチするためのダイアログが起動します。
「アタッチされたポリシー」セクションに、現在アタッチされているポリシーが表示されます。「使用可能なポリシー」セクションには、アタッチ可能な追加のポリシーが表示されます。
使用環境に適したポリシーを選択してアタッチします。
「アタッチ」をクリックします。
ポリシーのアタッチを終了した後は、「検証」をクリックします。
エラー・メッセージが表示された場合は、検証エラーがなくなるまで必要な修正を行います。
「OK」をクリックします。
アタッチしたポリシーが「ポリシー」表に表示されます。
詳細は、次のドキュメントを参照してください。
ポリシーのアタッチで表示されるダイアログについては、「SOAコンポジット・アプリケーションのポリシーの管理」を参照してください
使用可能なポリシーの定義およびユーザー環境で使用するポリシーの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。
リリース12.1.3では、BPELプロセス・メッセージ・リカバリを含むビジネス・フロー・インスタンスの問題が、フォルトとしてレポートされます。そのため、BPELプロセス・サービス・エンジンの「リカバリ」ページからまたは「エラー・ホスピタル」ページから、メッセージ・リカバリを実行できます。
ビジネス・フロー・インスタンスでのトランザクション・ロールバックによって配信されなかった起動メッセージまたはコールバック・メッセージのリカバリは、手動で実行できます。起動メッセージのリカバリは、非同期のBPELプロセスにのみ適用されます。同期BPELプロセスは、エラーをコール側クライアントに返すため、「リカバリ」ページからはリカバリできません。リカバリ可能アクティビティは失敗したアクティビティですが、リカバリが可能です。たとえば、ファイル・アダプタを使用して非同期BPELプロセスを起動しており、ビジネス・フロー・インスタンスの処理中にシステム障害が発生した場合は、すべてのメッセージ・レコードが確実にリカバリされるように、サーバーが再起動したときに手動でリカバリを実行できます。
BPELプロセス・サービス・エンジンによる自動リカバリの試行に失敗したメッセージを管理することもできます。これらのメッセージの自動リカバリが複数回試行されないようにするには、これらのメッセージを消耗済状態にします。その後、これらのメッセージに対して次のいずれかのアクションを実行できます。
自動リカバリ・キューに戻す
リカバリを試行しない
リカバリを即時に試行する
たとえば、データベース・アダプタに書き込むBPELプロセスがあるとします。データベースがダウンしている場合、これらのメッセージはリカバリ・キューに送信されます。これらのメッセージの自動リカバリは、データベースがダウンしている間は失敗します。これらのメッセージには、自動リカバリが再び試行されないように消耗済状態のマークが付けられます。データベースの実行が再び開始されたら、自動リカバリが再び試行されるように、これらのメッセージをリセットする(自動リカバリ・キューに戻す)ことができます。
BPELプロセス・サービス・エンジンのメッセージをリカバリする手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「リカバリ」をクリックします。
「リカバリ」ページに、次の詳細が表示されます。
「アラーム表のリフレッシュ」ボタンは、データベース内の消失したインメモリー・クォーツ・スケジュール済ジョブを再同期化する場合に選択します。たとえば、waitアクティビティ、またはpickアクティビティのonAlarmブランチでタイマーが起動され、そのトランザクションがロールバックされたと仮定します。データベースのwaitアクティビティまたはonAlarmブランチにあるビジネス・フロー・インスタンスを使用して、これらのジョブを再同期化できます。
特定のメッセージの失敗を検索するためのユーティリティ。基準を指定して「検索」をクリックします。詳細は、「ヘルプ」アイコンをクリックしてください。
サービス・エンジンでのメッセージの失敗。対話ID、メッセージの失敗のリカバリが可能かどうか、サービス・コンポーネント、失敗が発生したコンポジット・アプリケーション、およびフォルトの発生時間が表示されます。状態に応じて、これらのメッセージをただちにリカバリするか、これらのメッセージを取り消すか、または自動リカバリのためにこれらのメッセージをリセットできます。
注意:
解決済状態および未配信状態のコールバック・メッセージをリカバリできます。「タイプ」リストから「コールバック」を選択し、「メッセージの状態」リストから「解決」または「未配信」のいずれかを選択して検索条件を実行すると、これらのメッセージがリカバリ用に表示されます。コールバック・メッセージが最初にBPELプロセス・サービス・エンジンに入るとき、その状態は未配信状態です。対話IDの一致または相関のいずれかによって、このメッセージがターゲットのビジネス・フロー・インスタンスに解決されると、状態は「解決」に切り替ります。これらの両方の状態では、メッセージはまだ消費されていません。これらの2つの状態のメッセージはリカバリできます(消費のためにBPELプロセス・サービス・エンジンに再配信される)。他の状況では、コールバック・メッセージがこれらの両方の状態で残されている場合があります。これらの状態のメッセージもリカバリできます。ただし、残されているコールバック・メッセージが常に未配信状態のまま保たれる保証はありません。
「メッセージの状態」リストはコールバック・メッセージおよび起動メッセージのタイプのリカバリと、未配信、取消および消耗済状態の場合のアクティビティ・メッセージ・タイプのリカバリに適用されます。配信済および解決済メッセージ状態は、リリース12cのアクティビティ・メッセージには適用されません。
この表でフォルトを選択します。
次のいずれかのオプションを選択します。
| アクション | 説明 |
|---|---|
リカバリ |
フォルトが発生したメッセージを再試行します。 消耗済状態のメッセージを選択してこのボタンをクリックすると、メッセージのリカバリが即時に試行されます。このリカバリの試行も失敗となった場合、メッセージは消耗済状態に戻ります。メッセージを選択して「リセット」をクリックし、そのメッセージを自動リカバリ・キューに戻す必要があります。 関連する例外エラーが原因で、非同期BPELプロセスでトランザクション・ロールバック・シナリオが発生した場合は、最後のデハイドレーション・アクティビティにロールバックします。これが新しいインスタンスであり、かつ最初のデハイドレーション・アクティビティが受信アクティビティであった場合、BPELプロセス・サービス・エンジンはリカバリ可能な呼出しを作成します。呼出しをリカバリするために「リカバリ」をクリックすると、サービス・エンジンによって新しいインスタンスが作成されます。このインスタンスは、例外エラーなしで実行が完了する可能性があります。ただし、フォルトとして識別された古いインスタンスは引き続き表示されます。 |
中断 |
取消しとしてマークされているメッセージが含まれるフロー全体を終了できる確認メッセージを表示して、インスタンスの状態を更新する場合に選択します。メッセージ取消しは、フローIDのコンテキストで実行されます。このフローIDを使用してインスタンスがリンクされている場合は、すべてのインスタンスが終了します。フローIDを使用すると、様々なコンポジット・アプリケーション間のメッセージ・フローを追跡できます。 消耗済状態のメッセージを選択してこのボタンをクリックすると、そのメッセージのリカバリは試行されなくなります。 |
リセット |
消耗済メッセージを未配信状態にリセットする場合に選択します。これにより、メッセージは自動リカバリ・キューに戻されます。消耗済状態で表示されたメッセージは、メッセージ表に表示されなくなります。「メッセージの状態」リストで「未配信」を選択して「検索」をクリックすると、これらのメッセージが表示されます。消耗済状態のコールバック・メッセージを解決状態にリセットし、引き続きリカバリ可能にすることもできます。 |
リカバリのためにメッセージが送信されると、そのアクションがBPELプロセス・サービス・エンジンによって完了するのに時間がかかる場合があります。通常、この時間は数秒以内となります。この間、メッセージは「リカバリ」ページに表示されたままになります。この期間内に、同じメッセージのリカバリをもう1回実行しても、無視されます。最新のリカバリ・ステータスを受信するには、ページを数秒ごとに更新します。
注意:
ora-retryアクションを使用してBPELプロセスにフォルト・ポリシーを定義した場合は、フォルトが発生すると、BPELプロセスではフォルトからのリカバリをretryCountパラメータに指定した回数試行します。この期間の後、プロセスは実行中の状態のままになります。完了していないプロセスのアクティビティ(呼出し、受信など)のステータスは、保留中の手動リカバリとして表示されます。これは予想された動作です。
エラー・ホスピタルのフォルト・リカバリの詳細は、「エラー・ホスピタルでのフォルトからのリカバリ」を参照してください。
起動メッセージおよびコールバック・メッセージのリカバリを試行する最大回数を構成する方法の詳細は、「起動メッセージおよびコールバック・メッセージの自動リカバリ試行の構成」を参照してください。
フォルト・ポリシーの設計の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のFault Management Frameworkによるフォルトの処理に関する項を参照してください。
BPELプロセスを使用すると、各インスタンスで必要なデータベースの相互作用の回数によって、パフォーマンスの問題が発生する可能性があります。この要因が、非同期の永続フローよりも同期の一時フローのパフォーマンスが優れている主な原因になっています。この問題に対応するために、レスポンス時間の短縮が必要な状況では同期の一時フローを利用するように設計できます。ただし、ビジネス上の理由で、このタイプのフローを設計できない場合があります。
Oracle ExalogicプラットフォームでOracle SOA Suiteを実行している場合は、Oracle Coherenceの分散キャッシュ機能を使用して、BPELプロセスからインスタンスとメッセージ・データを格納できます。これによってデータベースの読取り回数が減るため、データベースの相互作用の回数が減ります。
Oracle Coherenceは、頻繁に使用されるデータへのアクセスを提供することによって、企業がミッションクリティカルなアプリケーションを拡張することを可能にするOracle Fusion Middlewareのコンポーネントです。Oracle Coherenceに含まれる分散キャッシュ機能によって、読取りアクセスと書込みアクセスの両方のスケーラビリティが向上します。データはノード間で自動的、動的および透過的にパーティション化されます。分散アルゴリズムがネットワーク・トラフィックを最小化し、データが徐々に移動されることでサービスの停止が回避されます。
Oracle Exalogicは、幅広いアプリケーション・タイプと様々なワークロードに対応するプラットフォームを提供するように設計された、ハードウェアとソフトウェアの統合システムです。Oracle Exalogicは、大規模で、パフォーマンスの影響を受けやすく、ミッションクリティカルなアプリケーションのデプロイを対象にしています。
注意:
使用している環境でOracle Exalogicを使用していない場合、Oracle Coherenceの分散キャッシュは使用できません。
BPELプロセスに対して分散キャッシュを使用すると、次のようなパフォーマンスの向上を期待できます。
メッセージ(起動およびコールバック)が最初に配信された後に、データベースからそのメッセージを読み取る操作がなくなります。
デハイドレーション・ポイントの後にキューブ・インスタンスに必要な読取り操作がなくなります。
Oracle Coherenceの詳細は、Oracle Coherenceスタート・ガイドおよびOracle Coherenceでのアプリケーションの開発を参照してください。
デハイドレーション時に、インスタンス・オブジェクトは、コンテナ管理のEnterprise JavaBeans (EJB)トランザクションでJava永続性API (JPA)を使用してデータベースに格納されます。BPELプロセス・サービス・エンジンでは、トランザクション後の処理用にトランザクションのafterCompletionリスナーを登録します。トランザクション中に変更されたインスタンス・オブジェクトは、追跡されてafterCompletionリスナーに対して使用可能になり、このリスナーによってキャッシュが更新されます。図17-1に、デハイドレーション・プロセスの詳細を示します。
リハイドレーション時に、インスタンス・オブジェクトはキャッシュから読み取られます。実装では、トランザクション完了通知のXA保証は提供されず、キャッシュの削除によってオブジェクトがキャッシュから削除されます。実装では、これら2つの事項を考慮して、オブジェクトが返されない、または古いバージョンのオブジェクトが返されるというキャッシュの問題に対処します。
通常は、キャッシュの参照によって有効なオブジェクトが返されます。この場合、直接書込み(デフォルト)によるキャッシュの使用によって、デハイドレーションおよびリハイドレーションのパフォーマンスは次に示すように向上します。
(database read time + relational to object mapping) minus (Object serialization + reading from serialized form + Coherence network overhead + query to database for reading CACHE_VERSION)
また、データベース・サーバーでのアクティビティも減少します。
ネットワーク障害によってOracle Coherenceのキャッシュが使用できない場合でも、BPELプロセス・サービス・エンジンは稼働し続けます。エラーが発生しない場合、ビジネス・プロセス・インスタンスは処理を続行します。
BPELプロセス・キャッシュは、Oracle SOA Suiteクラスタ・ノードに作成されません。「BPELプロセス・キャッシュ・サーバーの起動」の説明に従って、BPELキャッシュをホストするBPELキャッシュ・サーバーを起動する必要があります。少なくとも4つのサーバーを起動して、パフォーマンスが向上することを確認します。Oracle SOA SuiteクラスタとBPELキャッシュ・サーバーの順序に決まりはありません。Oracle Enterprise Manager Fusion Middleware ControlでQualityOfServiceプロパティがCacheEnabledに設定されている場合でも、BPELプロセス・サービス・エンジンはBPELキャッシュ・サーバーがなくても稼働し続けます。
Oracle Coherenceの詳細は、Oracle Coherenceスタート・ガイドおよびOracle Coherenceでのアプリケーションの開発を参照してください。
システムMBeanブラウザのQualityOfServiceプロパティを使用して、Oracle Coherenceをデハイドレーション用に構成できます。このプロパティは、SOAクラスタ内のいずれかのノードで構成できます。
Oracle Coherenceキャッシングをデハイドレーション用に構成する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「BPELサービス・エンジン・プロパティ」が表示されます。
「詳細BPEL構成プロパティ」をクリックします。
「属性」タブで、「QualityOfService」をクリックします。
「値」フィールドに、環境に適した値を入力します。この変更によってSOAインフラストラクチャを再起動する必要はありません。
表17-1 QualityOfServiceの値
| 値 | 説明 |
|---|---|
|
デハイドレーションおよびリハイドレーションでキャッシュを使用しません。読取りおよび書込み操作はデータベースに対して行われます。これがデフォルトの設定です。 |
|
デハイドレーション時は、インスタンス・データがXAデータ・ソース接続を使用してデータベースに格納され、トランザクション後の処理でオブジェクトがキャッシュに挿入されます。 リハイドレーション時は、データがキャッシュからフェッチされます。データが見つからない場合(たとえば、BPELプロセス・キャッシュ・サーバーが使用できない場合)、またはバージョンが中断している場合、データはデータベースから読み取られます。 |
「適用」をクリックします。
非同期フローの場合、複数の監査証跡メッセージを単一トランザクションに格納すると、パフォーマンスが向上します。パフォーマンスを向上させるために(複数のインスタンスの)複数の監査証跡メッセージを単一トランザクションに格納するには、Oracle Enterprise Manager Fusion Middleware ControlでシステムMBeanブラウザのAsynchAuditBatchSizeプロパティを設定します。
このプロパティを適切な値に設定すると、監査証跡トランザクション・コミット数が減ります。かわりに、指定した制限に達した場合のみコミットが実行されます。
複数の監査証跡メッセージが単一トランザクションに格納されるように構成する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「BPELサービス・エンジン・プロパティ」が表示されます。
「詳細BPEL構成プロパティ」をクリックします。
「属性」タブで、「AsynchAuditBatchSize」をクリックします。
「値」フィールドに、環境に適した値を入力します。デフォルト値の-1は、バッチ対象の監査証跡メッセージがないことを示します。各監査メッセージは、それぞれのトランザクションに保持されます。
推奨される値の範囲は5から25です。たとえば、このプロパティを8に設定した場合、8つの監査証跡メッセージが蓄積されると、これらのメッセージに対して1つのトランザクションが作成され、デハイドレーション・ストアにコミットされます。
このパラメータは、Oracle Exalogic環境にのみ影響します。その他の環境では使用できません。
この変更によってSOAインフラストラクチャを再起動する必要はありません。
「適用」をクリックします。
Oracle Coherenceキャッシュに監査証跡を格納できます。これを行うには、Oracle Enterprise Manager Fusion Middleware ControlでシステムMBeanブラウザの次のプロパティをそれぞれの値に設定します。
「AuditStorePolicy」をasyncに設定します。このプロパティは、SOAインフラストラクチャ・レベルのAuditConfig属性から設定するようになりました。
「QualityOfServiceOneWayDeliveryPolicyUseDistributedCache」をtrueに設定します。
「QualityOfService」をCacheEnabledに設定します。このプロパティは、「BPELサービス・エンジン・プロパティ」で設定します。手順の詳細は、「Oracle Coherenceのキャッシュ機能の構成」を参照してください。
これらの設定によって、次の動作が可能になります。
Oracle Coherenceキャッシュがキューとして動作して、データベースに監査証跡を書き込みます。
SOAサーバー・ノードのヒープとスレッドは、監査証跡を処理しません。
これらのプロパティのいずれかが異なる値に設定されていると、ヒープおよびディスパッチャ・スレッドがデータベースへの書込みに使用されます。
Oracle Coherenceキャッシュへの監査証跡の格納を構成する手順は次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「BPELサービス・エンジン・プロパティ」が表示されます。
「詳細BPEL構成プロパティ」をクリックします。
「属性」タブで、「AuditStorePolicy」をクリックします。
「値」フィールドに、asyncと入力します。
注意:
サーバーがキャッシュする場合は(SOA/BPELキャッシュ・サーバー)、一部の監査証跡メッセージはデータベースに永続化されません。この結果、監査ログが失われることになります。フェイルオーバーはサポートされません。これはOracle Coherenceの場合とメモリーまたはヒープ・キャッシュの場合の両方に適用されます。
「適用」をクリックします。
「戻る」をクリックします。
「属性」タブで、「QualityOfService.AuditStorePolicy.UseDistributedCache」をクリックします。
「値」リストから「True」を選択します。
「適用」をクリックします。
Oracle Enterprise Manager Fusion Middleware ControlでシステムMBeanブラウザの次のプロパティをそれぞれの値に設定することで、Oracle Coherenceキャッシュに呼出しメッセージを格納できます。
「OneWayDeliveryPolicy」をasync.cacheに設定します。
「QualityOfServiceOneWayDeliveryPolicyUseDistributedCache」をtrueに設定します。
「QualityOfService」をCacheEnabledに設定します。手順の詳細は、「Oracle Coherenceのキャッシュ機能の構成」を参照してください。
これらのプロパティのいずれかが異なる値に設定されていると、Oracle Coherenceキャッシュではなく、ローカル・メモリーがキャッシュに使用されます。
注意:
サーバー(SOAおよびBPELプロセス・キャッシュ・サーバーの両方)のクラッシュ時に実行中の呼出しメッセージは損失または複製される可能性があります。フェイルオーバーはサポートされません。これはOracle Coherenceの場合とメモリーまたはヒープ・キャッシュの場合の両方に適用されます。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「BPELサービス・エンジン・プロパティ」が表示されます。
「詳細BPEL構成プロパティ」をクリックします。
「属性」タブで、「OneWayDeliveryPolicy」をクリックします。
「値」フィールドに、async.cacheと入力します。
「適用」をクリックします。
「戻る」をクリックします。
「属性」タブで、「QualityOfServiceOneWayDeliveryPolicyUseDistributedCache」をクリックします。
「値」リストから「True」を選択します。
「適用」をクリックします。
start-bpel-cache.shスクリプトを実行して、Oracle SOA SuiteがインストールされているUNIXマシン上でBPELプロセス・キャッシュ・サーバーを起動します。
要件はネットワーク接続性のみです。Oracle SOA Suiteノードには、BPELプロセス・キャッシュ・サーバーがインストールされているホストからアクセスできる必要があります。
このスクリプトによって、Oracle SOA Suiteクラスタがマルチキャストのデフォルトのアドレスとポートに結合されます。これらの値は、$FMW_HOME/user_projects/domains/domain_name/bin/setDomainEnv.shファイルの対応する値と一致します。
クラスタに対してマルチキャストを選択したが、別のアドレスとポートを使用する場合は、環境変数を使用するか、またはshell変数を設定して、bpelCacheEnv.shファイル内の値をオーバーライドできます。同じ値をSOA管理対象サーバーに対して使用します(setDomainEnv.sh内)。
Oracle SOA Suiteクラスタのデフォルトのキャッシュ構成は、マルチキャストではなくユニキャストである必要があります。Oracle CoherenceのOracle SOA Suiteクラスタに対して推奨されるキャッシュ構成の詳細は、『高可用性ガイド』または『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
BPELプロセス・キャッシュ・サーバーを起動する手順は、次のとおりです。
