jBPM5:jBPM3からの移行手順

渡邊です。こんにちは。

jBPM5の研究をしています。
備忘録を兼ねて、jBPM3系からjBPM5系への移行手順について概要を記します。

お題となりますのは、EJB3+jBPM3という構成のアプリケーションです。
このアプリケーションに組み込まれたjBPM3をjBPM5に移行する手順の概要を記します。
続きを読む

jBPM5:GenericHTWorkItemHandlerではまったこと

渡邊です。こんにちは。

jBPM5の研究をしています。
備忘録を兼ねて、GenericHTWorkItemHandlerではまったことを記します。

問題となったのは、Drools 5.5.0.Final + jBPM 5.4.0.Finalです。
JBoss World 2012 Keynoteのソースコードを参考にし、より実践的なアプリケーションを作成していました。
一通りの動作確認を終えたところで、サーバ再起動後に限り、サーバ再起動前に開始したプロセスの任意タスクを完了できないという不具合がみつかりました。
続きを読む

jBPM5:BPMN2 Processの単体テスト

渡邊です。こんにちは。

jBPM5の研究をしています。
備忘録を兼ねて、BPMN2 Processの単体テストについてまとめます。

Guvnor、TaskService、DBなどを使わずに、オフラインでBPMN2 Processの分岐網羅テストをしました。また、異なる経路を辿る複数のプロセスを並列に走らせ、整合性をテストしました(おまけ程度)。
続きを読む

jBPM5:Human task前後でアクションスクリプトを実行する

渡邊です。こんにちは。

jBPM5の研究をしています。
備忘録を兼ねて、ユーザガイドにも載っている初歩的なことですが、プロセスが任意のHuman taskに入る時、または出た時にアクションスクリプトを実行する方法を記します。

続きを読む

jBPM5: プロセスに紐づいたエンティティを取得する

渡邊です。こんにちは。

jBPM5の勉強をしています。jBPM3.2からの変わりのように苦戦しています。
結論からいうと、これからお話する簡単なシナリオはjBPM5で実現できたのですが、あまりスマートではないので、もっとよい方法があると考えています。
ご存知の方がいらっしゃいましたら、フィードバックをいただけると幸いです。

稟議書を管理する業務システムに適用するとして、こんなシナリオを考えました。
Aさんが稟議書を申請し、Bさんがその稟議書を承認する

続きを読む

【解決】Relay――アップロードができない件

【Relayとは】

ファイル管理機能を提供するWebアプリケーションです。
管理対象のファイルはサーバ側で管理されます。ブラウザを使い、複数の利用者でそれらのファイルを共有できます。認証機能があり、各利用者の権限設定も可能です。
続きを読む

Niji 第1話――怨み節

<error desu.>

画面にはそれだけが表示されていた。

この日だけで128回みたエラーメッセージだった。

byte型の変数ではカウントしきれない数だな。

私はキーボードを遠投したくなる衝動を必死で抑えた。

 

当時、常駐先で、あるWebサイトの裏方システムを開発していた。

典型的なデスマーチ・プロジェクトだった。

 

「ふざけやがって。またフレームワークのデバッグをしなければならない」

向かいのデスクにいた男が膝で机を蹴り上げながら言った。

私と同じエラーメッセージを拝んでいるのだろう。

「何が原因かわからない。全く無意味なエラーメッセージですね。
『error desu』でググって(Google検索して)も、何の情報もない」

「そりゃそうだ。このプロジェクトでしか使われていないフレームワークだから。
――単純な機能を開発するだけなら悪くないフレームワークだが、
そういう機能がシステム全体にどのくらいある?
ほとんどの時間をフレームワークのソースコード解析に費やしている。
本来の開発が全く進まねぇ」

 

<error desu.>は、フレームワークが出力したエラーメッセージだった。

フレームワークはシステムにとって枠組みとなるプログラムである。

そのできがよいほど、開発者の負担は減り、開発コストが抑えられる。

 

例えば、ショッピングサイト、オークションサイト、映画館の予約サイトには、
Web上で動くシステムに共通の処理・制御がある。

リクエストからユーザの入力値を抽出し、それを然るべきプログラムに処理させ、
適切な画面に遷移させるといったことだ。

フレームワークは、こういった共通の処理・制御を担当してくれる。

従って、フレームワークの導入により、共通部の開発を省き、
開発対象のシステムに固有の仕様(画面デザイン、決済までの手順、決済処理自体等)に
集中して開発できる。

 

当初の計画では、このプロジェクトの為に開発されたフレームワークが、
従来の開発の8割を吸収してくるはずだった。

しかし、実際に開発が始まってみると、こういう具合だった。

確かに、システム全体の2割の機能については、
従来の開発の8割をフレームワークが吸収してくれた。

残りの8割の機能については、従来の開発以上に余計なコストが発生した。

納期は当初の前提のまま動かなかった――動かせなかった。

 

「フレームワークの構造上、入力から出力まで全てを実装しないと動作確認できない。
やっと動作確認できた段階になって、<error desu.>しか出力されない」

どこにどんなバグ(不具合)があっても、フレームワークはこのメッセージしか出さなかった。

 

一つの機能は、画面表示・デザインを制御するプログラム、画面遷移を制御するプログラム、
業務ロジックが記述されたプログラム等によって構成される。

それぞれのプログラムを単体で動作確認できる場合と、
全てを連携させないと動作確認できない場合では、
不具合が発生した時にどちらの方が早く原因を特定できるだろうか。

当然、前者の方が早く特定できる。その方が不具合の改修も楽だ。

東京ドーム1,000個分の島に10頭の羊がいたとして、
東京ドーム1個分の土地ごとに仕切りがある場合と、ない場合では、
前者の方がより早く全ての羊を捕獲できるという話に近い。

 

そのフレームワークは他案件への導入実績がなく、十分なテストがされていなかった為、
多くの不具合を抱えていた。

原因が、自分の担当したプログラムにあるのか、フレームワークにあるのかを切り分ける為に、
膨大な時間を割く必要があった。

「たかが一項目を表示する為に、13時間はまっている。○○さんがいればなぁ」

○○さんとは、ただ一人でフレームワークの開発を担当していた他社の技術者のことだ。

 

その彼が会社を辞めて3ヶ月が経過していた。

だが、誰も彼のことを怨んでいなかった。怨みの対象は納期だけだった。

納期まであと72時間――1泊3日。

<END>

 

      ※      ※      ※

 

前置きが長くて申し訳ありません。半分はフィクションです。

この経験を生かして開発した自社フレームワーク『Niji』について、これから書いていきます。

よろしくお願い致します。

p.s. 上の話は続きません。あしからず。