2014年10月31日金曜日

BPMを使っていかに旅行業界を盛り上げるか

原文: How To Excite the Travel Industry With a BPM Story by Eric D. Schabell

旅行代理店による予約プロセス
ビジネスプロセスの話をするにあたり、もっとも興味深い事例の1つに旅行業界があります。

インターネットを検索していただくと、たくさんのソリューションや広告、そして旅行業界用BPMソリューションを組み込んだ製品を見つけることができます。

あなたが航空会社と話している時、手荷物のチェックインをしている時、旅行代理店のスタッフと予約について話している時、いずれも共通の複雑なビジネスプロセスを共有しています。その複雑なビジネスプロセスは、ルールやイベント、リソースプランニング、やプロセス処理といった概念を取り組む必要が多々あります。

合計金額を算出するサブプロセス(ルールを使用)
JBoss BPM Suiteには、それら必要なものがすべて用意されており、workbench 1つを使うだけで、ソリューションを現実のものにします。

今回の記事では、新しく用意された JBoss BPM Suite用デモプロジェクトをご案内します。このデモプロジェクトは、旅行代理店の予約システムを題材にしています

このプロジェクトは、UK在住の同僚である Niraj Patel Shepherd Chengeta と一緒に作成しました。私は数日間、彼らのオフィスで一緒に過す機会があり、このプロジェクトに関するいくつかの詳細について、彼らとブレインストームすることができました。隠蔽化(カプセル化)されてはいますが、プロジェクトからこの共同作業の成果を見つけることができます。

彼らは素晴らしい作業をされました!

旅行代理店のデモでは、まず顧客の予約情報を要求し、提供されしだい ホテルやフライト情報をリクエストする為、様々なバックエンドサービスが使われます。最終的にルールエンジンにより検査やレビューが行われた結果が、概要として提示されます。

プロジェクトには以下の内容が含まれます:
  • forms modelerにより作成されたカスタム task form
  • sub-processの使用例
  • 2つの異なる service task
    • ホテルの利用状況確認サービス
    • フライトの利用状況確認サービス
  • ルールエンジンとの連携
    • DRLルール
    • decision table
    • ガイド付きルール(guided rule)
  • 複数のテストシナリオ

承認用に用意された予約情報
このデモは、作業を開始する為に必要なものはインストーラーを通して提供されます。旅行代理店プロジェクトを完成させる為の解説は、オンライン上で完全にカバーされています。製品の評価目的の方へは、完成された旅行代理店プロジェクトを提供しています。後ほど、プロジェクトの開発や実行に関する動画を提供する予定です。

クイックスタート

  1. ダウンロードし解凍
  2. インストールディレクトリに製品を配置
  3. 'init.sh'か 'init.bat'を実行
  4. /target/jboss-eap-6.1/bin ディレクトリにある 'standalone.sh'か 'standalone.bat'を実行し、JBoss BPMSサーバーを起動
  5. http://localhost:8080/business-central にログイン
    - admin権限や他権限を持つユーザーでログイン (u::erics / p:bpmsuite1!)

最初に表示される旅行申請入力フォームにある旅行者数を調整することで、プロセスのシナリオ(パス)を制御できます。6を選んだシナリオはこれからご紹介します。その他 2を選んだ場合のシナリオ(パス)も用意されます。ぜひ自由にお試しください。

エディンバラ旅行をブッキング(シナリオの 1つ)

1. プロジェクトを ビルドしデプロイ
2. フォームに下記情報を入力し、プロセスを開始:
Name(名前): [あなたの名前]

Email Adress(Emailアドレス): [emailアドレス]

Number of Travellers(旅行者数): 6

From Destination(移動元): ロンドン

To Destination(移動先): エディンバラ

Preferred Date of Departure(希望出発日): 2014-06-06

Preferred Data of Arrival(希望到着日): 2014-06-10

Other Details / Notes(その他 詳細/ノート): [テキストを記述]

3. webサービスを2つ実行後、ブッキングの価格をレビューする前に sub-processが 費用を算出し、価格のレビューが必要かどうかを判断します。レビューが不要であった場合、'Employee Booking(従業員によるブッキング)'という Taskに処理が進みます。

4. task用のフォームに情報を入力します。ブッキング用の提出されたデータや、サービスにより生成されたデータ、ルールエンジンにより算出された情報を確認できます。価格を見直す為に差し戻すことや、taskを承認し、プロセスを進めることができます。

5. 他のシナリオ(パス)を実行する為には、プロセス開始時に表示されるフォームの '旅行者数:'に 2と入力してください。

このプロジェクトをお楽しみいただければと願っています。また、プロジェクトの改善案などフィードバックを歓迎します。


原文: How To Excite the Travel Industry With a BPM Story by Eric D. Schabell

2014年10月24日金曜日

ルールの開発/デザイン/トレーサビリティに関する3つのシンプルなガイドライン

原文: 3 Simple Guidelines to Rule Development, Design and Traceability by Eric D. Schabell


(この記事は、ノースアメリカ在住の Red Hat シニアコンサルタント John Hurlocker との共同執筆です)

今回の tips and tricksでは、ルールプロジェクトに参加した際に経験するであろうデザインサイクルについて、いくつかバックグラウンドやガイドラインを紹介します。

この記事では、ルールやイベントを取り扱ったプロジェクトが発展していく方法が記載された唯一の基準(standard)でもすべて網羅した記事でもありません。

この記事では、現実世界で組織がかかえるプロジェクトを多数経験してきたうえで基礎といえる内容をご案内します。JBoss BRMSを利用し独自のルールやイベントを活用していこうとされているあなたにとって、自信を与えるよう意図して執筆しました。

ルール開発関連でおこなわれる要件定義について考察します。その他、プロジェクトのトレーサビリティを要求された場合に選択できるオプションや、これから経験されるであろうデザインの選択肢について触れます。

1.要件

ルール作成者はプロジェクト要件を担当するチームメンバーと協力してプロジェクト要件を解析し、実装する必要のあるルール数を見積ります。チームメンバーと協力することで、質問がでた時に即座に回答を得ることができます。

ルール作成の為に要件を解析する際、以下の質問がでてくるでしょう:
  • 要件をレビューする際、WHENやTHENが明解ではない状況(condition)はありますか?
  • データを検証する為のルールは含まれていますか?
  • 複数の要件を1つのルールにまとめることはできますか?
開発の前段階でプロジェクト要件を検討及び検証することで、開発サイクルですべき作業のスコープを絞り込むことができます。

これらの質問は、以前の tips and tricksで取り上げられた内容です。

2.デザイン

デザインフェーズでは、企業のルール管理者は組織と一緒に働き、下記質問からいくつか問い合わせる必要がでてきます:
  • 組織は、セントラル ルール リポジトリをホストする必要がありますか? ホストすることは有益ではないですか?
  • ルールの所有者は誰ですか?ルールを更新したり新バージョンをリリースする責務を持っていますか?
  • グループ間で再利用可能な共通ルールはありますか?

セントラル JBoss BRMS リポジトリ
ルールをオーサリング、管理、ビルドする為に JBoss BRMSサーバーをセントラル リポジトリとして組織で活用することは有効です。

組織内に複数リポジトリを配備するよりもメンテナンス性にすぐれており、ルールの再利用を促進します

複数グループ間で特定のルールが共有される場合、必ずどちらかのグループがオーナーシップを持ち、ルールの更新や新バージョンのリリースに対する責務を負うべきです

ルール作成者は、アプリケーションチームと一緒に働き、ルールのフォーマットやオーサリングツールを決定する必要があります。下記質問について話し合われるべきです:
  • BRMS Dashboard と JBoss Developer Studio(JBDS)のどちらでルールは開発されるべきですか?
  • ルール作成者がより快適でいられる要素は何ですか?
  • 将来、誰がルールをメンテナンスしますか?
    • Java開発者ですか?、ビジネスアナリストですか?
  • どのフォーマットが要件に適していますか?
    • e.g. webベースのデータテーブルですか? business guided ruleですか? DSLですか?
  • どのようなタイプのテストが必要ですか?
    • JUnit と BRMSテストシナリオですか?
これらのトピックは以前の記事で紹介されてきました。より深い議論についてはそちらをご参照ください。

3.トレーサビリティ

要件のトレーサビリティ用途に使えるメタデータオプション
ルールやイベントが実装されたら、実装する根拠となった要件をトレースすることができるリンクをルールやイベントに添付することが重要です。

JBoss BRMSであれば、ルール作成者はルールのメタデータに要件へのトレーサビリティが可能となる情報をセットすることができます。例えば:

  • descriptionセクションに、関連要件を設定することができます
  • 関連要件は、外部リンクとしてルールのメタデータに設定することができます
  • リポジトリからメタデータ情報を取得することで、レポートを作成することが可能です
今後の記事では、ルールの実装と要件定義を結びつける為、どのようにメタデータ フィールドを使うべきかより深く考察します。また、それら情報を取得し要件定義に関するドキュメントを生成する方法についてご紹介する予定です。

原文: 3 Simple Guidelines to Rule Development, Design and Traceability by Eric D. Schabell

2014年10月10日金曜日

Red Hat JBoss BRMS ルールやイベントを用いたデザインアーキテクチャーの考察(PartⅢ)

原文: Examining Red Hat JBoss BRMS design time architecture for rules and events (part III) by Eric D. Schabell

(この記事は、ノースアメリカ在住の Red Hat シニアコンサルタント John Hurlocker との共同執筆です)

この記事は、Red Hat JBoss Business Rules Management System(BRMS) のデプロイメントアーキテクチャーに関するスタートガイドシリーズの第3回目となります。

過去2回の記事を通じ、エンタープライズ環境でルールやイベントプロジェクトをデプロイする為のデプロイメントアーキテクチャーを紹介しました。

今回は、ルール管理者がすべき管理業務について話を進めます。エンタープライズの運用では、ビジネスロジックの変更を効率良く適切に実施する必要があり、ルール管理者が如何にこの業務を実施すべきかに焦点をあてます。

ルール管理業務

ルールが作成される前、ルール管理者は JBoss BRMS ダッシュボードツールの設定に関与します。

ルールをビルドする管理業務
まず、ルール管理者は製品のセットアップに付随する問題に巻き込まれるかもしれません。しかし、ここでは管理者が本来担当すべき業務領域に注目していきます。管理者は、プロジェクトで使用されるルールフォーマットを決定し、オーサリングツールを選択する業務を担当します。

プロジェクトがスタートし、ルール作成者が選択したツールを使い始め、アプリケーション開発チームと協力し始めた後、ルール管理者には実際に使用するビジネスロジックを検証する業務が控えています。
テスト シナリオ

ビルド

ビジネスロジックがルールプロジェクトの対象となった際には、ルール管理者はアプリケーションに配布されるルールパッケージをビルドする責務があります。

この作業は、ビジネスロジックやルールプロジェクトに含まれるすべてのテストを実行するところから始まります。ルール開発ツールが提供するテストや開発者テストが含まれます。

考察の対象となる企業では、一般的に継続的インテグレーションツールが使える環境があるはずです。このツールを使ったテスト方法に関する話は他の人に委ねるとして、JBoss BRMSのダッシュボード内にあるルール管理者用のツールを使い、ルールパッケージをテストする機能に焦点を当てます。

失敗を表示するレポート

  • テスト シナリオ
    • ルール管理者は JBoss BRMS ワークベンチを利用し、ルールとナレッジベースを検証する為にテストシナリオを作成することが可能です。テストシナリオはアプリケーションの実装に依存しません
  • JUnit テスト
    • 簡単な補足ですが、アプリケーションコードを持つ任意のルールをテストする場合、ユニットテストツールのフォームを使うべきです
テストに合格した後、デプロイされたルール
    • JBoss BRMS ワークベンチに用意したテストをパスしたというだけでは、アプリケーション内での使用用途について問題がないとは言えません
  • エラーがある場合、ルール開発者に通知します
  • エラーがない場合、ルール管理者はルールパッケージをビルドすることができます。JBoss BRMSは、一般的な JARファイルである Mavenアーティファクトを生成します。

次回は
このシリーズの次回投稿では、ルール管理者が企業内にルールパッケージを配備し、アプリケーションによる利用をサポートする為の業務について説明します。

Part Ⅰに戻る(現在、未翻訳)
Part Ⅱに戻る(現在、未翻訳)

原文: Examining Red Hat JBoss BRMS design time architecture for rules and events (part III) by Eric D. Schabell

2014年10月1日水曜日

ミュンヘン開催のOktoberfestで見つけた JBoss BPMSに関する2つのサプライズ

原文: 2 Surprising JBoss BPM Discoveries at Munich Oktoberfest by Eric D. Schabell

JBoss BPM はどこに?
ミュンヘンにある Red Hatオフィスへ先週行った際、Octoberfestと呼ばれる地元の文化イベントがあり、うれしいサブライズとなりました。

このイベントをご存知ですか?

素晴らしかったです。皆 民俗衣装を身に着けて巨大なテントの下に集まり、楽しく飲んで歌っていました。

Who am I to judge? (私が言うのもなんですが)

ミュンヘンでJBoss BPMを取り扱うにあたって、いくつか私の興味をひきつけることがありました。皆さんと共有すべき経験だったのです。

数千人規模の祭が開催されている中でも、JBossや BPMについて考えさせられることがあるんです。見逃せないドイツビールや魅力的な食べ物がある巨大なテントからも、JBoss BPMSは人々を遠ざけるのです。

1. JBoss BPM エバンジェリストによるブレインストーミング

1日中 JBoss!
人々を祭りから遠ざけた最初のイベントは、オフィスで開催したブレインストーミング セッションです。(正直に言うと、数人を遠ざけた程度です)

良き同僚である Markus Eiseleとパーティー会場のテントから離れ、JBoss、BPMS、rules、インテグレーションについてしばらく話し合いました。今後数ヶ月で、これらトピックを集めた何かをご紹介できるかもしれません。

彼は、ヨーロッパを中心にインテグレーションについてさらに活発に活動するでしょう。ぜひご注目ください。私達はプロジェクトだけでなく、ルールやBPMの構成を含んだインテグレーションに取り組みます。

2. JBoss BPMワークショップ

人々をミュンヘンから遠ざけた2つ目のサプライズは、JBoss BRMと JBoss BPMS Suiteハンズオンの開催を約束していたのです!

オンラインワークショップを使い、終日 BPMプロジェクトの開発を行いました。ミュンヘンのパートナーグループも参加し、祭りがあるにも関わらずワークショップを実施していました。




ワークショップでは何人かの参加者が OpenShift bpmPaaSに興味を持たれ、クラウドに直接プロジェクトを作成していました。

参加者全員は祭りの最後に参加することができ、帰宅する前に少しだけ音楽を楽しむことができました。

JBoss BPMの技術により、テントから観衆を引き寄せる恒例行事を作る良い機会なのかもしれませんね。

原文: 2 Surprising JBoss BPM Discoveries at Munich Oktoberfest by Eric D. Schabell