| 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コンポジット・アプリケーションのBPMNプロセス・サービス・コンポーネントとの間で、ポリシーをアタッチおよびデタッチできます。ポリシーはメッセージの配信にセキュリティを適用します。Oracle Fusion Middlewareでは、ポリシー・ベースのモデルを使用してWebサービスを管理します。
注意:
ポリシーをアタッチする前に、使用可能なポリシーの定義およびユーザー環境で使用するポリシーの詳細について、Webサービスの管理を参照してください。
BPMNプロセス・サービス・コンポーネント・ポリシーを管理する手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
「サービス・エンジン」→「BPMN」の順に選択します。 |
|
「ビュー」表の「コンポジット」列に移動し、特定のSOAコンポジット・アプリケーションを選択して「ダッシュボード」ページにアクセスします。
「ポリシー」をクリックします。
「ポリシー」ページを使用すると、BPMNプロセス・サービス・コンポーネントとの間でポリシーをアタッチおよびデタッチできます。ポリシー表には、アタッチされたポリシーの名前、切替え可能なポリシー参照ステータス(有効または無効)、カテゴリ(「管理」、「信頼できるメッセージング」、「MTOMアタッチメント」、「セキュリティ」または「WSアドレス」)、違反、およびSOAインフラストラクチャの最後の再起動以降の認証、認可、機密性および整合性の失敗が表示されます。
「アタッチ/デタッチ」をクリックします。
複数のコンポーネントが使用可能な場合は、アタッチまたはデタッチを実行するサービスまたはコンポーネントを選択するプロンプトが表示されます。
ポリシーのアタッチ先またはデタッチ先のサービスまたはコンポーネントを選択します。
ポリシーをアタッチまたはデタッチするためのダイアログが起動します。
「アタッチされたポリシー」セクションに、現在アタッチされているポリシーが表示されます。「使用可能なポリシー」セクションには、アタッチ可能な追加のポリシーが表示されます。
使用環境に適したポリシーを選択してアタッチします。
「アタッチ」をクリックします。
ポリシーのアタッチを終了した後は、「検証」をクリックします。
エラー・メッセージが表示された場合は、検証エラーがなくなるまで必要な修正を行います。
「OK」をクリックします。
アタッチしたポリシーがポリシー表に表示されます。
詳細は、次のドキュメントを参照してください。
ポリシーのアタッチで表示されるダイアログについては、「SOAコンポジット・アプリケーションのポリシーの管理」を参照してください。
使用可能なポリシーの定義およびユーザー環境で使用するポリシーの詳細は、Webサービスの管理を参照してください。
プロセス・インスタンスのトランザクション・ロールバックによって配信されなかった起動メッセージまたはコールバック・メッセージのリカバリは、手動で実行できます。起動メッセージのリカバリは、非同期のBPMNプロセスにのみ適用されます。同期BPMNプロセスは、エラーをコール側クライアントに返すため、このページからはリカバリできません。リカバリ可能アクティビティは失敗したアクティビティですが、リカバリが可能です。たとえば、非同期BPMNプロセスを起動するファイル・アダプタを使用しているときに、システムがインスタンスの処理中にクラッシュした場合は、すべてのメッセージ・レコードが確実にリカバリされるように、サーバーが再起動したときに手動でリカバリを実行できます。
注意:
エラー・メッセージORA-01000: maximum open cursors exceededが表示された場合、次を実行します。
Oracleデータベースを停止します。
OPEN_CURSORSの値を1500に増やします。
Oracleデータベースを再起動します。
BPMNプロセス・サービス・エンジンのメッセージをリカバリする手順は、次のとおりです。
次のいずれかのオプションを使用して、このページにアクセスします。
| SOAインフラストラクチャのメニューから... | ナビゲータのSOAフォルダから... |
|---|---|
|
|
「リカバリ」をクリックします。
「リカバリ」ページに、次の詳細が表示されます。
特定のメッセージの失敗を検索するためのユーティリティ。基準を指定して「検索」をクリックします。詳細は、「ヘルプ」アイコンをクリックしてください。
サービス・エンジンでのメッセージの失敗。対話ID、メッセージの失敗のリカバリが可能かどうか、サービス・コンポーネント、失敗が発生したコンポジット・アプリケーション、およびフォルトの発生時間が表示されます。
この表でフォルトを選択します。
次のいずれかのオプションを選択します。
| アクション | 説明 |
|---|---|
リカバリ |
フォルトが発生したメッセージを再試行します。 関連する例外エラーが原因で、非同期BPMNプロセスでトランザクション・ロールバック・シナリオが発生した場合は、最後のデハイドレーション・アクティビティにロールバックします。これが新しいインスタンスであり、かつ最初のデハイドレーション・アクティビティが受信アクティビティであった場合、BPMNプロセス・サービス・エンジンはリカバリ可能な呼出しを作成します。呼出しをリカバリするために「リカバリ」をクリックすると、サービス・エンジンによって新しいインスタンスが作成されます。このインスタンスは、例外エラーなしで実行が完了する可能性があります。ただし、フォルトとして識別された古いインスタンスは引き続き表示されます。 |
取消としてマーク |
メッセージが配信されないようにマークを付けます。 |
リカバリのためにメッセージが送信されると、そのアクションがBPMNプロセス・サービス・エンジンによって完了するのに時間がかかる場合があります。通常、この時間は数秒以内となります。この間、メッセージは「リカバリ」ページに表示されたままになります。この期間内に、同じメッセージのリカバリをもう1回実行しても、無視されます。最新のリカバリ・ステータスを受信するには、ページを数秒ごとに更新します。
注意:
この機能は、非同期BPELプロセスを含まないOracle BPMNプロジェクトにのみ適用されます。
リリース12.1.3では、リビジョン間でのインスタンスの移行は、コンポジット・インスタンスではなくフロー・インスタンスに基づきます。一連のフロー・インスタンスと1つのコンポジット・タイプの場合、各フロー内のコンポジットのすべてのインスタンスが移行されます。フローの移行では、まずコンポジットの関連付けられたサービス・エンジンのそれぞれから、フロー・インスタンスおよびコンポジット・タイプのコンポーネント・インスタンスが取得されます。次に、サービス・エンジンはこれらのコンポーネント・インスタンスを一度に1つずつ移行するよう要求されます。
フロー・インスタンス移行には次のような理由があります。
プロセスの初期リビジョンで設計または実装エラーが発見されたり、外部サービスから提供される無効データがプロセスの状態を不良にする可能性がある。
プロセスの完了までの所要時間が長すぎる。たとえば、月単位または年単位で実行するフロー・インスタンスがあるとします。これが原因で次のようになります。
フロー・インスタンスの進行中に変更を適用する必要が生じることがあります。
事前には変更が不明のため、常にルールまたは短期間のサブプロセスとしてモデル化できるとはかぎりません。
規制またはポリシーの変更(新規ポリシーまたは変更ポリシーの強制の適用)により、すべてのプロセスにステップを追加することが必要になります。
フロー・インスタンスの移行には次の制限が適用されます。
双方のコンポジット・リビジョンをデプロイする必要があります。
実行中のフロー・インスタンスのみ移行が可能です。フォルト状態でも移行が成功するOracle Mediatorを除き、完了、中断、フォルトのフロー・インスタンスは移行できません。
互換性のあるフロー・インスタンスのみ、正常に移行できます。互換性は、コンポジット内の関連サービス・コンポーネントの互換性に依存します。重要な変更は移行できません。
フロー・インスタンスごとにトランザクション境界が存在します。一般に、特定のコンポジットに関連するフロー・インスタンスはバッチで操作されます。フロー・インスタンスのそれぞれは、単一トランザクションにバインドされます。バッチ全体が失敗していなくても、1つ以上のフロー・インスタンスの移行が失敗する場合があります。
次の2つの移行方法がサポートされます。
自動移行: リビジョン間の変更が些少の場合。フロー・インスタンスのそれぞれは、単一トランザクションにバインドされます。フロー・インスタンスのバッチを移行できます。
移行計画を使用した手動移行(Oracle BPMのみ): リビジョン間で重要な変更がある場合に使用されます。移行計画には、移行の実行方法が記載されます。
コンポジット移行の互換性は、アプリケーション内で定義されているサービス・コンポーネントに依存します。サービス・コンポーネントに対する変更に互換性がない場合は、そのフロー・インスタンス全体が移行に不適格になります。SOAコンポジット・アプリケーション・フロー・インスタンスは、関連するサービス・コンポーネント・フロー・インスタンスが移行可能な場合のみ移行されます。
次のサービス・コンポーネントは移行できます。
非永続的BPELプロセス
Oracle Mediator
ヒューマン・ワークフロー
ビジネス・ルール
Oracle BPMN
関与するサービス・エンジンはそれぞれのフロー・インスタンスを移行するために調整されます。フロー・インスタンス追跡データは、新しいリビジョンに移行されます。
フロー・インスタンスには、次の状態のアクティブなコンポーネント・インスタンスが少なくとも1つ必要です。
実行中
リカバリが必要
一時停止
表36-1は、各サービス・コンポーネント・フロー・インスタンスが新しいフロー・インスタンスにどのように移行されるかを示しています。互換性がない場合は、フロー・インスタンスの移行全体が非互換とレポートされ、移行はできません。
表36-1 サービス・コンポーネント・フロー・インスタンスの移行の詳細
| サービス・コンポーネント | サポートされる移行タイプ | 移行制限 |
|---|---|---|
BPELプロセス |
BPELプロセス・フロー・インスタンスの新規リビジョンへの自動移行 |
|
Oracle Mediator |
Oracle Mediatorフロー・インスタンスの新規リビジョンへの自動移行 |
サポートされるメッセージ・パターンは、リクエストのみ、リクエスト-レスポンス、および順次ルーティング・ルールのみです。これは、一方向および同期のOracle Mediatorコンポーネントのみ移行できることを意味します。 インスタンスは、「正常完了」、「失敗」または「ユーザーにより終了」のいずれかの状態である必要があります。 |
ヒューマン・ワークフロー |
ヒューマン・ワークフロー・フロー・インスタンスの新規リビジョンへの自動移行 |
なし(すべての実行中および完了済インスタンスが移行されます)。 |
ビジネス・ルール |
ビジネス・ルールの新規リビジョンへの自動移行(ルール・フロー・インスタンスの概念なし) |
なし。 |
Oracle BPM |
Oracle BPMフロー・インスタンスの新規リビジョンへの手動移行(移行計画を使用)、および自動移行 |
互換性のないモデル間ではフロー・インスタンスを移行できません。互換性のないフロー・インスタンスの例には次のものが含まれます。
アクティビティの追加や削除は、移行計画を使用して手動で移行する必要があることを意味します。 |
注意:
パラレル・ルーティング・ルールのあるOracle Mediatorサービス・コンポーネントおよびOracle BPMNサービス・コンポーネントを含むインスタンスでは、フロー・インスタンスの移行が失敗します。
移行を実行するantスクリプトを作成する必要があります。スクリプトは、$Middleware_Home/soa/bin/ant-flow-instance-migration.xmlスクリプトをインポートする必要があります。
次のコマンドを使用して、antスクリプトを作成するためのヘルプを表示できます。
ant -f $Middleware_Home/soa/bin/ant-flow-instance-migration.xml help
次の要素がサポートされています。
locatorConfig: ロケータの構成を定義します。
locatorSession: ロケータ・セッションを表します。
flowInstanceFilterDef: 移行するフロー・インスタンスを選択するフィルタ。この要素でサポートされる属性は、次のとおりです。
id (必須)
compositeDN (必須)
flowId
pageStart
pageSize
tenantId
maxCreationDate
minCreationDate
maxModifyDate
minModifyDate
like
ecid
conversationId
compositeName
domainName
label
revision
title
generateFlowMigrationReport: フロー移行レポートを同期に生成します。
migrateFlowInstances: フロー・インスタンスを同期に移行します。
次のコード・サンプルでは、ant-flow-instance-migration.xmlスクリプトの例を示します。
<?xml version="1.0" encoding="iso-8859-1"?>
<project name="migration-test1" basedir="." default="test">
<property name="env" environment="env" value="env"/>
<property name="mw.ora.home" value="${env.MW_ORA_HOME}"/>
<import file="${mw.ora.home}/bin/ant-flow-instance-migration.xml"/>
<property name="reports.dir" value="${baseDir}/reports"/>
<locatorConfig id="c1" host="localhost" port="7001" user="weblogic"
password="weblogic1"/>
<target name="test">
<flowInstanceFilterDef
id="f3"
compositeDN="default/SubProcess!1.0"/>
<locatorSession configId="c1">
<generateFlowMigrationReport filterId="f3"
revision="2.0"
outputFile="${reports.dir}/
migrationReport.html"/>
<migrateFlowInstances filterId="f3"
revision="2.0"
migrationPlan="${basedir}/
TaskRemovedInSubprocess-plan.xml"
outputFile="${reports.dir}/
migrationResult.html"/>
</locatorSession>
</target>
</project>
ここでは、Oracle BPMを含むReviewProcessコンポジットのリビジョン・インスタンスを移行する例を紹介します。この例ではヒューマン・ワークフローの承認タスクが削除されているため、移行計画が必要になります。
図36-1に、コンポジットのリビジョン1.0のインスタンス・フローを示します。このコンポジットのリビジョンには、時間を消費するユーザー承認タスクであるVeryExpensiveUserReviewを含め、2つのヒューマン・タスクが存在します。
図36-2は、SOAコンポジット・エディタ内でリビジョン1.0のコンポジットを表示しています。
図36-3は、リビジョン2.0のコンポジット・アプリケーションの改善されたインスタンス・フローを示しています。
時間を消費するVeryExpensiveUserReviewヒューマン承認タスクが削除されています。かわりに、サービス・タスクによる自動確認が使用されています。このサービス・タスクは、確認承認を外部のWebサービスに委譲します。
図36-4は、SOAコンポジット・エディタ内でリビジョン2.0のコンポジット・アプリケーションを表示しています。
移行時は、次のタスクが発生します。
ReviewProcessの定義が改善された新しい2.0リビジョンがデプロイされます。
この新しい2.0リビジョンは、古い1.0リビジョンとサイドバイサイドで実行されます。
進行中のインスタンスは、必要に応じてリビジョンが移行されます。
Oracle BPMのリビジョン・インスタンスを移行する手順は次のとおりです。
データ・オブジェクトの更新。
インスタンス・タイトル値の更新。
VeryExpensiveUserReviewタスク・フローのLegacyReviewタスク・フローへの置換。
移行計画は任意のディレクトリの場所に配置できます。
サンプルを使用することも、XSDに基づいて独自の移行計画を作成することもできます。build.xmlファイルを実行してインスタンスを移行する際に、ファイルへのパスを指定します。
フローのリビジョン1.0が表示されます。インスタンスは、2つのインスタンス・タスクのパラレル承認で待機しています。
antスクリプトを実行します。
