jBPM5 Developer Guide メモ

jBPM

今 jBPM5 を学ぶにはベストの書籍だと思います。
http://www.packtpub.com/jboss-business-process-management-5-jave-developer-guide/book

とりあえず、個人的に重要な chapter 8 と 11 のメモ。

8. Persistence and Transactions

Localの話はちゃんと書いてある。BRMS 5.3.x ではまだ LocalHTWorkItemHandler はないので、SyncWSHumanTaskHandler が同等です。

This configuration―which uses LocalTaskService plus LocalHTWorkItemHandler 
and just one persistence unit (containing the session's and the tasks' tables)― 
is referred to as Persistent Session with Local HT Configuration. Using this 
configuration, the transactions will be shared by the mechanisms that persist the knowledge session and the mechanisms that persist the human task interactions.
  • Advanced jBPM5 persistence and transactions configuration

以下はexternal system ありきの話なので、Localでできるなら上記LocalTaskService+LocalHTWorkItemHandler の話になる。ってところ強調した方がよかったのでは。

    • How much robustness do we need?

HumanTaskで考えると、processとJMSのXAの話とか小っせえ！て思う(Local or not が最重要)けど、その他の external system が JMS ならまあXAにするよね。ああでも Web Service ならそうもいかないしじゃあよく考えたらそこの robustness って意外と重要じゃなくて、障害があれば適切にリカバリできる管理者手続きがあればいいかってことで、一周回って本題に納得した。

  • FAQ
    • How can we continue a process instance after a session is restored from the database?

要するに、何もしなくていい。でも次のクラッシュの話と密接につながる

    • After a system crash, do we have to reload all the StatefulKnowledgeSessions instances from the database?

十分な回答ではない。。。が、ユースケースをリストアップするとっかかりにはなる。ただし漏れなくね！いずれにせよ、ksessionアーキテクチャが問題になる

    • Why is the session not removed from the SessionInfo table after all the process instances that it contains are completed?

jBPMのテーブル管理についての説明が少しある

11. Architectural and Integration Tips

たぶんここが一番大事で、もっとページ割くべきではなかったかと思うなあ、うん。

  • One session per knowledge context level

あー、これあまり考えてなかったユースケースだ。ひとつのアプリケーションだけど複数のコンテキスト(モデル、プロセス定義などが異なる)があって、それぞれ別に ksession を用意した方がいいってこと。

  • One session per process instance

やはりこれが一番分かりやすいパターン。

サンプルでは自前で BusinessEntity というエンティティを永続化している。クラッシュ時などのための管理者処理を考慮すると、この情報が永続化されているのは必要。現状ではこういう部分をアプリ側で作り込む必要があるのがイケてない。

  • One session per process category

うーん、One session per knowledge context level の角度を変えた見方のような気がする。いずれにせよ、プロセス定義など、適度な粒度でksessionを分けるってことだと思います。

  • Multiple sessions' coordination

WorkItemHandler から別のksessionを呼び出す。さらにその ksession が WorkItem をcompleteするパターン。ちょっと特殊かなあ。