https://blogs.oracle.com/ateamsoab2b/entry/bpm_11g_deployment_instance_migration
新しいバージョンのプロセスを管理する方法や、旧バージョンから現行バージョンへのインスタンスの移行を確認する方法に関して、多くの問い合わせを最近よく頂きます。このエントリでは以下の2件について取り上げます。
- プロセスへの変更が大きな変更と見なされず、プロセスインスタンスが自動的に移行する場合
- プロセスに加えた変更がより複雑で、手作業によるプロセスインスタンスの移行が必要な場合
[注意]
インスタンスの移行はBPM PS4FP以後で利用可能です。PS4以前のバージョンで作成されたインスタンスをPS4FP以後のバージョンのインスタンスに移行することはできません。
プロセスの理解
簡単なプロセスです。3個の異なるフォームを持つ3個のHumanTaskがあります。その後ファイルへの出力が続きます。
単純なXMLスキーマです。3個のフォームを表す3個のComplex型があります。
サンプルの入力メッセージです。個々の要素で全ての引用文を形成しています。
フォーム1
フォーム2
フォーム3
出力ファイル
いくつかのインスタンスを作成します。各インスタンスはプロセスフロー中の様々なポイントで待機中です。
既存のシングルフォームのXMLスキーマに少々変更を施した場合
これは非常に標準的なユースケースです。お客様がフォームの不イールドを間違えた場合、下位のXMLスキーマを変更してフォームをデプロイし直す必要があります。BPMプロジェクト内のXMLスキーマでフォーム2を変更し、新しい要素を含めるようにします。
ビジネスオブジェクトやデータオブジェクトに即座に反映されていることに注目して下さい。
フォームのペイロードに関連するXMLスキーマの中は…
データコントロールを更新して、フォームの変更を反映する必要があります。関連するデータコントロール上で右クリックし、[定義の編集]を選択します。
すると、データコントロールが変更されます。
実際のフォームにこの変更を反映させる必要があります。
フォームを見ると、そのフィールドをどこに配置すべきかわかります。
というわけで、”Field21”を右クリックして「入力テキスト（InputText）」フィールドを追加します。
そして、データコントロールから新しいフィールドにドラッグ＆ドロップします。
これでフォームは完成です。
通常の方法でこのフォームをWebLogic Serverにデプロイします。
テストを再実行してフォームが確かに変更されていることを確認しましょう。
BPMプロジェクトをデプロイします。実行中のインスタンスはそのまま生存させつつ、新しいバージョンにインスタンスを移行したと思っています。
BPMプロジェクトを同じRevision IDで「再デプロイ後にインスタンスの実行を続行します」を選択してデプロイしましょう（注意：PS5では、Revision IDが異なる場合にはインスタンスの移行はできません）。
BPM Workspaceの中では、[プロセストラッキング]タブの[保留中のコンポーネント]に、保留状態になっているプロセスインスタンスがないことに着目して下さい。
どうしてなのでしょうか？元のプロセスへの変更が手作業による移行が必要なほど顕著なものではないと判断されたため、すべてのインスタンスが新しいバージョンに自動的に移行されました。変更されたフォーム（フォーム2）を通過したインスタンス（つまりフォーム3で待機中のインスタンス）が正しいデータを持っているとどうやって確認するのでしょうか。そこで使えるのが、「Alter Flow」です。
[プロセストラッキング]タブで、フォーム3で待機中のインスタンスを選択します。
[Alter Flow & Suspend]アクションを選択します。
データオブジェクトに"Field20"がないことに注目して下さい。
表示されているXMLに直接値を追加して、現在のアクティビティを”Form3”として”再開”をクリックします（必要であれば、”Form2”にプロセスを戻し、データを再度入力することができます）。
関連するインスタンスに戻り、"Form3"を完成させます。ファイルの中身を見てみましょう。
新しいHumanTaskやスコープ内のフォームでXMLスキーマに大きな変更を加える
XMLスキーマに変更を加えます。
で、プロセスもこんな感じに変更します。
プロセスを作成して、このフォーム用に新しいUIプロジェクトを作成し、デプロイします。
BPMプロジェクトは以前と同様「再デプロイ後にインスタンスの実行を続行します」を選択します。
BPM Workspaceで、「保留中のコンポーネント」を見てみましょう。
新しくスコープを追加したので、インスタンスの自動移行はできません。移行するには2方法あります。
- インスタンス個々に移行するか、[プロセストラッキング]タブからまとめて移行する
- [保留中のコンポーネント]からまとめてインスタンスを移行する
個別に移行
フローもデータも変更できます。
グループで移行
フローのみ変更できます。データは変更できません。
保留しているコンポーネントから移行
フローの変更やデータの変更はできません。
スコープの削除
この場合、変更が重要なもので、インスタンスの移行が容易に実施できないとみなされます。Form0の周りのサブプロセスを取り除いて…
「実行中のインスタンスの保持」オプションを指定して再デプロイすると
以下のようなデプロイ時のログが出ます。
「回復できない非互換性」のためにデプロイが失敗しました。サブプロセス削除に伴う変更はかなり大きなものだった、という結果です。この事象が発生するプロセスへの変更内容の完全なリストは、以下の通りです（PS5現在）。
- 排他または包含ゲートウェイ・ペアが削除される
- 包含-複合ゲートウェイ・ペアが包含-包含ゲートウェイ・ペアに変更される
- サブプロセスが削除されるか、そのループ特性が変更される
- ユーザー・タスクがゲートウェイ・ペアの別のブランチまたはゲートウェイ・ペアの外部に移動される
- アクティビティ・レベルが変更される。たとえば、アクティビティがサブプロセス内またはゲートウェイ構造内で移動される
- サブプロセスまたはイベント・サブプロセスまたはコール・アクティビティが追加される
- イベント・サブプロセスが連続しないタイプから連続するタイプに変更される
- 境界イベントが連続しないタイプから連続するタイプに変更される
- 境界イベントが追加される
- ユーザー・タスクの実装が別のヒューマン・タスクを使用するように変更される
現実には、このような変化であれば新しいRevision IDを使うべきで、その場合すべての古いインスタンスは古いRevisionで完了まで継続させ、新しいインスタンスでは新しいRevisionを使うべきでしょう。
代替策として、"composite.xml"ファイルに以下のように追記することで、強制的にコンポジットをデプロイすることができます。
コンポジットレベル（つまりコンポジット内のすべてのBPMプロセスに適用される）でoracle.bpm.bpmn.force.deploy=trueを指定することもできますし、個々のBPMプロセスレベルで設定することもできます。詳細は「モデリングおよび実装ガイド」をご覧ください。
Oracle® Fusion Middleware Oracle Business Process Managementモデリングおよび実装ガイド 11g リリース1 (11.1.1.6.2)この設定で、先ほどと同様に「実行中のインスタンスの保持」オプションを指定してデプロイすると、以下のようなログが出てきます。
Oracle Business Process Management Workspaceでの実行中のプロセス・インスタンスの変更
http://docs.oracle.com/cd/E28389_01/doc.1111/b61409/alt_flw_mig_bpmpd.htm
Oracle® Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management 11g Release 1 (11.1.1.6.3)
Modifying Running Process Instances in Oracle Business Process Management Workspace
http://docs.oracle.com/cd/E23943_01/doc.1111/e15176/alt_flw_mig_bpmpd.htm
BPM Workspaceの[プロセストラッキング]タブをみると、以前にみたのと同じような状況を目の当たりにすることができます。つまり、先ほど述べた「保留中コンポーネント」という状態になっています。
0 件のコメント:
コメントを投稿