原文:
Migration Tips - moving projects from JBoss BRMS 5 to JBoss BPM Suite 6 by Eric D. Schabell
 |
| マイグレーションの準備はでていますか？ |
この記事では、開発者がマイグレーション作業を見積もる際に直面する困難な作業についてお話します。
はじめに
近日リリース予定である Red Hat JBoss BPM Suite 6 へ、あなたのプロジェクトをマイグレーションする際に発生する作業内容を評価できるよう、注意点を紹介します。
JBoss BPM Suite 6 は、JBoss BRMS 6 のスーーパーセットであることをご理解ください。なので、BPMを取り扱ったサンプルプロジェクトを紹介することは、ルールを取り扱ったプロジェクトについて紹介したことになります。
この後、私たちは JBoss BPM Suite 6 へのマイグレーションを実施した、JBoss BRMS 5 プロジェクトを使います。マイグレーション前後のソースコードは、下記リンクから参照いただけます。
リンク先のプロジェクトファイルの中身をそれぞれご確認ください。IDE や 製品の UIコンポーネント上でデモをどのようにインストールし、実行させるか記述されています。現時点では、マイグレーション前のプロジェクトがより豊富なドキュメントを揃えています。マイグレーション後のプロジェクトは徐々に良くなっていきます。何か修正を希望される場合は、ぜひプルリクエストを送ってください。
基盤
これからリリースされる JBoss BRMS / BPM Suite 6 は、ルールやプロセスのリポジトリーのベースに GIT を利用します。現行製品である JBoss BRMS 5 は Jackrabbit をベースとする JCRリポジトリーを利用しています。既存のプロジェクトを新しいリポジトリーに push すればマイグレーションは終わりそうに見えますよね。
それとも、シンプルにはいかないものでしょうか？
残念ながら、それほど簡単にはいきません。まず、GIT をサポートするすべてのツールからアクセス可能であることを理解してください。例えば GIT の CLIツールにより、あなたが愛用されているシェルからリポジトリーにアクセスできます。理解していただく必要のある重要事項ですが、リリース予定である JBoss BRMS / BPM Suite が提供する UI は、完全に GIT の持つ機能を提供するわけではありません。現時点ではとても単純化された方法でリポジトリと連携しており、連携がうまくいかなかった場合、空のリポジトリーを表示することが度々あります。
製品を正しく動作させる為には、あなたの GIT リポジトリーが要求されるディレクトリー構成に準拠している必要があります。製品が持つ素晴らしいグラフィカルインターフェイスでプロジェクトを利用する為には、UI 上であなたが必要とするプロセスやルールなどの空ファイルを一旦作成しておく必要があります。そうすることで作成されたプロジェクトを git clone し、あなたの好きな IDE を使いマイグレーション作業を開始することができます。
プロジェクトのクローンが完了したら、先程作成した空ファイルを目印に、アセットをプロジェクトに追加してください。例えば、customer.bpmn2 という空ファイルを作成していたとします。customereval.bpmn2 をマイグレートする場合、customer.bpmn2 と同じ階層に customereval.bpmn2 を追加してください。追加作業が終わったら空ファイルを削除し、編集したプロジェクトをリポジトリーへ push してください。製品の UI は、自動的に変更内容を検知し、追加されたプロセスやアセットはデザイナーで利用可能になります。
同様にルールファイルを取り込むことが可能です。パッケージ名が、新しいプロジェクトの構造と合致していることをご確認ください。製品の UI はよりビジネスユーザー向けに新調されています。よって、マイグレーション前に利用していた古いパッケージ名 "
org.jbpm.customer.evaluation" をより簡略化しました。よりシンプルになったパッケージ名は、"
customer.evaluation" です。
プロジェクトには、
Request と
Person という2つの Javaクラス(POJO)がモデルとしてあります。フォームモデラー コンポーネントが認識できるように、これらは正しい場所にインポートされる必要があります。すでに説明しましたが、パッケージ名と階層が一致しなければ、これらは表示されません。
プロジェクトのアセットへのアクセス方法が抜本的に変わります。BRMS / BPM Suite でルール、ビジネスプロセス、モデルなどを取り扱う場合、それらは jar アーカイブとしてビルドされ、Mavenリポジトリー経由で取り扱う方法が主流になります。詳細については
Maven と題したセクションでお話します。
これにより、あなたはプロジェクトを ルール、イベント、ビジネスプロセスなどを活用するコードプロジェクトとアーティファクトに2分割することができます。アプリケーションコードでアーティファクトを利用したい場合、jarアーカイブとしてプロジェクトに含まれます。ユニットテストはコードプロジェクトに用意され、jar の依存関係を利用して必要なアーティファクトを使用します。
API
製品のコアAPIは、全面的にリファクタリングされました。ルール、イベント、ビジネスプロセスと相互作用する為に書かれたコードは、すべてマイグレートする必要があります。
最終的には。
今は下位互換用に用意された knowledge-api.jar をご利用いただくことで、既存のプロジェクトを使い続けることは可能です。それは、新しい全面的に刷新されたAPIの恩恵を受けることができません。現在、deployable-generic.zip に含まれていますが、general availability(GA)版がでるまでに変更される可能性があります。
業務用コードの残り半分とも言えるユニットテストについては、jbpm-test.jar を利用しているコードをリファクタリングする必要があります。この jar ファイルに関しては下位互換性が用意されていません。私たちも既存のユニットテストを書き直す必要がありました。良いニュースと言えば、コードをシンプルに書けるようになったので、あなたのユニットテストは見通しがよくなり、理解し易いものになるはずです。
jar アーカイブが利用可能になった段階で、maven の依存関係に追記していただくことが可能です。マイグレーション後の顧客満足度調査のデモプロジェクトでは、参考までにインターナルリポジトリーのサンプルを含めました。mavenの依存関係をご確認いただけます。
Rest API も変更されました。もしお客様がインターフェースをカスタマイズされている場合、再設計する為にある程度の作業が要求されます。Rest API は、以下の領域に対するアクセスを提供します。
- ジョブ(Jobs)
- リポジトリー
- 組織ユニット(Organizational units)
- プロジェクト
- プロセスインスタンス(start, variables, details, abort, signal) : 変数を含めることも可能です
- ワークアイテム(Work items)
- プロセスインスタンスが終了したか確認する為の履歴
- 総合的なタスクインターフェース
ドキュメントは、
カスタマーポータル にから入手可能です。
JCR から GIT への移行ツール
既存のJCRリポジトリーから GITリポジトリーフォーマットへ変換するツールはコミュニティーにあります。現時点では使われていませんが、これから製品化に向けてテストされるはずです。
マイグレーションツールは、まるでハンマーで叩かれる爪のような状態なんでしょうか？
ぜひこのツールにも注目していてください。初期のベータリリースにはまだ含まれていないようです。
Maven に関する詳細
JBoss BRMS / BPM Suite は、maven リポジトリーを利用します。プロジェクトにこのリポジトリーを加えることで、プロジェクトが依存する ルール、イベント、ビジネスプロセスにアクセスすることができます。以下の内容をプロジェクトの pomファイルに追加するだけで、依存関係を定義することができます。
guvnor-m2-repo
Guvnor M2 Repo
http://localhost:8080/business-central/maven2/
例えば、顧客満足度調査プロジェクトのプロパティ GAV(Group ID, Artifact ID, Version)を設定していたとします。私達は version 1.0 jar への依存関係をこのように追加することができます。
customer
evaluation
1.0
最後にもっとも重要な注意事項ですが、GITリポジトリをファイルシステムから直接コピーしないでください。必ず git URI を利用してクローンしてください。顧客満足度調査のデモを例にあげるならばCLI か、ご利用されている IDE でいかのうようにクローンしていただきます。
# ファイルシステムから直接コピーしないでください。製品により監視されません。
# これは悪い例です
#
# git clone file://{path-to-repo}/.niogit/customer.git
#
# これは良い例です。shell から git を利用している例です:
#
$ git clone git://localhost/customer
Cloning into 'customer'...
remote: Counting objects: 562, done
remote: Finding sources: 100% (562/562)
remote: Getting sizes: 100% (435/435)
remote: Compressing objects: 89% (388/432)
remote: Total 562 (delta 24), reused 72 (delta 21)
Receiving objects: 100% (562/562), 59.21 KiB, done.
Resolving deltas: 100% (198/198), done.
Taskに関する変更事項
JBoss BRMS 5 では、一般的には HornetQによるメッセージングシステムを使用して、コアエンジンからブリッジされた Taskサーバーを提供していました。
リリース予定の JBoss BPM Suite では、ローカル Taskサーバーのみ提供します。その為、メッセージングシステムの構築が不要になります。このアーキテクチャー変更の溝を埋めるべく、いくつかのヘルパー/ユーティリティメソッド
LocalHTWorkItemHandler が用意されます。下記ソースコードをご確認いただくことで、機能の詳細がわかります。
bpm-human-task/jbpm-human-task-workitems/src/main/java/org/jbpm/services/task/wih/util/LocalHTWorkItemHandlerUtil.java
その他、TaskService API は public API に含まれておりますので、いくつかマイグレーション時にご留意いだく点があります
- パッケージ名の変更がある為、import文の修正が発生する可能性があります
- いくつかの API が変更される為、メソッドの修正が発生する可能性があります
 |
| 顧客満足調査のデモ |
ビジネスプロセスに User Task を利用されている場合、殆どのお客様がカスタムインターフェースを開発され、Human Task コンポーネントと連携されていました。新しいアーキテクチャーに対しても同様の作業をされるのではないかと思います。
マイグレーションの実戦
顧客満足調査のデモを具体的に振り返ると、私達はルール、モデル、ユニットテスト、ビジネスプロセスを含むシンプルなアプリケーションをマイグレートしたかったのです。このマイグレーションは、作業の容易性を評価していただける作業でした。
顧客満足度調査のデモをマイグレートした結果(今も改善され続けています)を、ぜひご確認ください。
ユニットテスト
ユニットテストのマイグレーション作業については、製品が利用するローカル maven リポジトリーを使用するように pom.xml を修正するところから始めました。そして、knowledge-api と jbpm-test.jar に対する依存関係を定義しました。このコードスニペットは、一般的なエントリーが必要最低限 定義されています。現在のリリースバージョンが設定されているプロパティは除外しています。また、製品の依存関係が定義されているエントリーも除外しています。
org.jbpm
jbpm-test
${bpm-suite-version}
test
org.drools
knowledge-api
${bpm-suite-version}
compile
 |
| マイグレーションされたユニットテストの実行結果 |
依存関係の定義が終了したら、ユニットテストのリファクタリングを始めます。現行のユニットテストから、projectsディレクトリ配下に確認できるものへ修正していきます。
ここには製品が提供するアーティファクトが含まれた jar から取得する為のエントリーが含まれます。pom.xml のインラインコメントをご確認ください。
イニシャルセットアップは、KnowledgeBase と StatefulKnowledgeSession を実行する為に使われていました。
これは、セッションストラテジーとランタイムエンジンを設定するだけに省略されます。
# The createRuntimeManager() method and getRuntimeEngine() method are
# both part of the provided testing harness found in JbpmJUnitBaseTestCase
# class that you can extend all unit tests off of.
#
createRuntimeManager(Strategy.SINGLETON, resources);
RuntimeEngine runtime = getRuntimeEngine(ProcessInstanceIdContext.get());
現行のユニットテストではセッションを操作する必要がありましたが、これからは合理化されたケースがそれぞれのユニットテストに用意されます。
@Test
public void underagedCustomerEvaluationTest() {
// setup of a Person and Request.
Person underagedEval = getUnderagedCustomer();
Request richEval = getRichCustomer();
// Map to be passed to the startProcess.
Map params = new HashMap();
params.put("person", underagedEval);
params.put("request", richEval);
// Fire it up!
System.out.println("=========================================");
System.out.println("= Starting Process Underaged Test Case. =");
System.out.println("=========================================");
KieSession ksession = runtime.getKieSession();
ksession.insert(underagedEval);
ProcessInstance pi = ksession.startProcess("org.jbpm.customer-evaluation", params);
ksession.fireAllRules();
// Finished.
assertProcessInstanceCompleted(pi.getId(), ksession);
assertNodeTriggered(pi.getId(), "Underaged");
ksession.dispose();
System.out.println("======================================");
System.out.println("= Ended Process Underaged Test Case. =");
System.out.println("======================================");
}
完全にマイグレートされたユニットテストは、以下のファイルからご確認いただけます。JUnit テストを実行することもできます。
src/test/java/CustomerEvaluationTest.java
IDE から UI
最後の作業は、既存のルール、ドメインモデルとなる 2つの Javaクラス、それとビジネスプロセスをインポートすることです。
 |
| インポートされたビジネスプロセスが表示されたデザイナー |
作業を実施する為、JBoss BPM Suite を起動し、新規のリポジトリーとプロジェクトを作成しました。また空のビジネスプロセスとルールを作成しました。
IDEでの作業を振り返ると、
git clone git://localhost/customer と実行してクローンし、追加したいファイルの設置場所を見つける為に空ファイルを用意しました。既存のルールやビジネスプロセスファイルを追加した後、空ファイルを削除しました。プロジェクトに作業結果を戻すと、UI のプロジェクトエクスプローラに表示されます。修正点としては、今まで使われた長いパッケージ名が、
customer.evaluation とシンプルになったことです。
モデルのインポートも同じ作業です。まずモデラーコンポーネントを利用して空ファイルを作り、それら空ファイルと 2つの javaクラスを入れ替えます。プロジェクトの構成とパッケージ名が一致したら、それらは UI に表示されます。
 |
| インポートされたモデルを表示するフォームモデラー |
フォームモデラーは、アノテーションがついたオブジェクトを作成します。私達のオブジェクトには現時点ではアノテーションが付いていません。これは、ビジネスプロセスを実行する際にいくつかの問題を引き起す原因となります。JBoss BPM Suite はプロセスの初期変数値を入力するようユーザータスクフォームを生成しますが、私達が意図する StringフィールドではなくObject である為にこの処理が失敗します。
まとめ
リリース予定の JBoss BRMS / BPM Suite はまだ初期段階の製品です。あくまでも、マイグレーションの可能性を早い段階で確認しているとご理解ください。これは完全なマイグレーションガイドではありせん。小規模なサンプルアプリケーションを通し、どの分野が影響を受け、何を期待していただけるかをまとめたものです。
モデルのインポート、パッケージングパス、アノテーションに起因する問題は今後さらに調査する価値のあるトピックだと思います。製品へのドキュメントが提供された際には、カバーされるべきトピックでしょう。
projects/customer-evaluation-demo は、JBoss Developer Studio にインポートされ、BPM Suite で実行されているプロジェクトと相互作用することを意図しています。現在開発段階の状況ですが、ぜひ製品リリースの進捗状況と同様、こちらのプロジェクトにもご注目ください。
私達は今後、他のデモに関しても同様にマイグレーションを実施し、作業内容や成果をご紹介していきます。製品の機能、統合性、使い易さを試すべく、個々のプロジェクトはこれからさらに複雑になります。
原文:
Migration Tips - moving projects from JBoss BRMS 5 to JBoss BPM Suite 6 by Eric D. Schabell
.png)
