BRMS6.2 2016版

Red Hat JBoss BRMS 6.2

レッドハット株式会社サービス事業統括本部

これまでの実績について

Copyright © 2016 Red Hat K.K.2

2015年度 BRMS市場シェア


レッドハット35.1%

A社11.9%

「システム連携/統合ミドルウェア市場 2015 国内BRMS市場動向」ベンダー別売上⾦額推移およびシェア(2015年度予測）株式会社アイ・ティー・アール 2015年12⽉発⾏より

3年連続シェア No.1市場規模はおよそ20億円

国内実績


企業システムプロセスルール三菱総研DCS 事務処理委託処理 ◯ ◯加賀東芝エレクトロニクス製造プロセス進捗管理 ◯ ◯北陸コカ・コーラ営業システム ◯ ◯ソフトバンクモバイル契約受付システム ◯通信業プロビジョニングシステム ◯ ◯⽇産⾃動⾞受発注システム ◯ ◯⽇産⾃動⾞⽣産管理システム ◯⼤⼿⾦融業契約受付システム ◯ ◯⼤⼿⾦融業不正利⽤検知システム ◯⼤⼿製造業会計システム ◯⼤⼿製造業製造管理システム ◯⼤⼿製造業製造プロセス管理システム ◯都市銀⾏契約管理システム ◯ ◯⼤⼿⾦融業顧客管理システム ◯地⽅⾃治体審査システム ◯通信業課⾦システム ◯ ◯流通業受発注システム ◯セキュリティ災害情報配信システム ◯

国内実績


企業システムデータグリッドプロセスルール通信業 CADシステム ◯通信業契約管理システム ◯⾦融業リアルタイムマーケティング ◯インテリジェンス統計情報からの営業⽀援システム ◯サービス業業務⽀援システム ◯⾦融業海外⽀店業務⽀援システム ◯ ◯運輸業料⾦計算システム ◯製造業物流計画システム ◯ (Planner)

通信業リアルタイム・ビッグデータ ◯ ◯製造業製造可否システム ◯製造業検査機器利⽤計画システム ◯ (Planner)

エネルギー料⾦計算システム ◯⾦融業事務処理システム ◯ ◯

旅⾏業旅⾏造成システム ◯

⾦融業ローン⾦利計算システム ◯

サービス業先進的通販サイトシステム ◯ ◯

製造業製造機器監視・制御システム ◯ ◯

他多数

l  チェックl  オブジェクトマッチングがもっとも得意とするところl  固定値との⽐較だけではなく、2つのオブジェクトの⽐較等l  ルール間の依存性が無いように記述することで独⽴性を担保

l  計算l  計算式のパラメータをわかりやすく記述できるl  ⼀般的な四則演算のほか技術演算、論理演算を実⾏可能

l  集計l  多数のオブジェクトの集計l  バッチ処理などでよく⾏われる

l  イベント処理l  時間内にデータが⼊っていきた・⼊ってこなかった、その関連性をトリ

ガーにしてアクションを起こすl  推論

l  AならばB、BならばC という2つのルールを再評価を⾏い、ルールを連続発⽕させることで導き出す

l  製造業、⾦融業、計画系ソリューションなどで良く⾏われる

ルールエンジンで⾏う要素


ルールの主な適⽤内容


業務内容チェック計算集計イベント処理推論契約管理・受付 ◯ ◯ 組合せのチェック

製造管理 ◯ ◯ 順序の組み⽴て

リアルタイム・レコメンデーション ◯ ◯ 関連商品の導出

ローン審査 ◯ ◯ ◯

タスクのアサイン ◯ 承認パスの導出

料⾦計算 ◯ ◯ ◯

物流計画 ◯ ◯ ◯ 最⼩稼働時間の探索

制御・監視 (IoT) ◯ ◯ ◯ 前後イベント間の関係性

⽣産管理 ◯ ◯ 次の製造対象候補の絞込

原価管理 ◯ ◯ ◯製造可否判定 ◯ ◯マスターデータチェック ◯ 親⼦関係の導出請求審査 ◯ ◯ 事象の確定と再評価⼈・物のリソース計画 ◯ 最短パスの探索

l  その意思決定の理由はご存じですか？l  仕様書から設計書に落とされソースコードになった時点で、「な

ぜ」は消えます。l  設計が悪かった場合、仕様書の改変はされずにソースコードだけが

改変されます。l  その改変は「動けばいい」だけの世界になり、スパゲッティが形成

さてていきます。

l  どのように変更できますか？l  DBのテーブルにマスターとして⼊れているケースが殆どですが、

例外条件はマスターに記載しきれません。その場合はアプリケーション側にもロジックが記述され、⼆重管理となります。

l  ⻑く使っていればいるほど、引き継がれた担当者は過去の経緯がわからず、ロジックの整理ができなくなります。その無⽤なロジックをも考慮した新しい例外を作らねばならず、メンテナンス⼯数は莫⼤になります。

何故アプリケーションロジックはスパゲッティになるのか？


l  戦略的意思決定l  頻度は少ないものの、⻑期間に渡り⾮常に複雑である。ビジネスに⼤きな影

響を与える。l  どうやって会社を成⻑させるか、どうやってマーケットに会社を売るか等。

l  技術的意思決定l  頻度は多少有り、短期間で適度にビジネスに影響がある。l  競合や法律等の市場の変化に対応。

l  運⽤的意思決定l  ⾼頻度、即時対応、通常は単純な変更で即時にビジネスへの影響はない。l  お客様のリスクを評価、製品の税⾦の計算、リクエストの優先順位付け等。

様々な意思決定


ITを活⽤する場合、全てプログラミング対象

全てのプログラムがビジネスの変化に迅速に追従する必要がある

BRMS 製品について


Red Hat JBoss Middleware のラインナップ

Dev

elop

men

t Too

ls

Automation

Integration

Foundation

Man

agem

ent T

ools

l  JBoss BRMSl  JBoss BPM Suite

l  JBoss A-MQl  JBoss Fusel  JBoss Fuse Service Worksl  JBoss Data Virtualization

l  JBoss EAPl  JBoss Data Gridl  JBoss Mobile

JBoss DeveloperStudio

JBoss OperationsNetwork

Red Hat JBoss Middleware


BPM Suite と BRMS


Red Hat JBoss BPM Suite

Red Hat JBoss BRMS

BPM DBSchema

Process Engine Rule EngineKie API

GIT

MavenBAMDashboard

Complex Event Process

Business Resource Planner

Business Central

ExecutionServer

•  Business Central•  Maven Repository•  GTI Repository •  Kie APIはBPM / BRMSで共⽤

BRMS : Business Rule Management System


ビジネスルールとは

ビジネスルールを管理するという意味

ビジネスを実⾏するために必要な規則・規約のこと例）もし「プラチナカスタマー」ならば、「10%引き」する。

もし「製品仕様に追加」ならば、「製造⼯程を追加」する。もし「申込み⽇が2016年3⽉1⽇から2016年3⽉31⽇まで」ならば、

「カレーパン販促キャンペーン」を適⽤する。

ルールの変更を、いつ、誰が、どのような理由で⾏ったかを記録に残すルールの変更⼿順を、ガバナンスを効かせて不⽤意な変更をさせない問題が起きた場合、いつでもすぐに元の状態に戻せる

ルール作成の管理と、実⾏時のルールの管理が必要

ルール表記 : DRL

l  DRL : Drools Rule Languagel  ルールエンジンが解釈できる表記l  MVEL または Java 構⽂でルールを記述

l  DRL 基本構造

rule “<ルール名>” when <LHS> then <RHS>end

rule"プラチナカスタマは1割引”when$customer:Customer(status==Customer.PLATINUM,$id:id)$order:Order(id==$id,$amount:amount)thenlog.debug($customer.getName()+"様はプラチナカスタマ");order.setTotalAmount($amount*0.9);end

JBoss Developer Studio等で記載した時のイメージ

14 Copyright © 2016 Red Hat K.K.

ルール表記 : Decision Table

15

l  似たルールの繰り返しをスプレッドシート形式で表現l  業務ユーザが⼀番良く使う表記⽅法をそのまま利⽤l  xls形式、csv形式の書類を直接読み込み可能

Copyright © 2016 Red Hat K.K.

ルールエンジンの歴史


MycinDendral

1972

エキスパートシステム

発明者：Edward Albert Feigenbaum

PrologRETE

1974

OPS5

CLIPSJess

DroolsSoar ILOGJRules

1984

1983

19952001

1987

JBoss EnterpriseBRMS 5

2009

現在

1996

Red HatJBossBRMS 6

ビジネスルールの２つの顔


可視化

⼈⼯知能

RETE アルゴリズム

意思決定表ルールフロー⽇本語でのルール表記

BRMSを使ったアーキテクチャ

各役割を明確にしましょう


業務要件仕様書 ~⼈事システム例〜


勤怠管理においては下記の要素がある。・会社としての出退勤規則法令を順守した勤務時間の算出・営業所単位でのカレンダー

扱うサービスに依存するカレンダー。

・出退勤規則 1回の勤務を8時間とする。休息時間は1時間とし、勤務時間に含めない。 8時間以上の勤務は残業とする。夜10時以降の勤務は連続2⽇以上続けない。社員は所定の画⾯で出退勤を記録するものとする。出退勤の記録は上⻑が確認の上承認する。上⻑に承認された出退勤の記録は⼈事部にて勤務の妥当性を確認し、労働管理上問題のある場合は関係部署へメールにて連絡を⾏う。休暇は勤続年数に応じて別表2の通り、年度初⽇に付与される。ただし、有効期間は2年間とし、有効期間を過ぎた有給休暇取得の権利は消滅するものとする。

プロセス

ルールデータ

画⾯

勘定科⽬マスター

取引科⽬マスター

既存のアプリケーションの作り


取引先マスター

画⾯

契約管理マスターを参照しながら契約情報を

作成

取引先マスターを参照しながらチェック、計算、

情報作成

稟議番号

契約管理レコード

取引先レコード

稟議番号

契約レコード

取引先番号


アプリケーションワークフロー

部⾨管理マスター

部署確認

上申部署情報

契約管理マスター

取引先番号

取引科⽬情報

取引科⽬

勘定科⽬情報

… …

•  DBの”マスター”を都度参照して物事を決定していくスタイル。

•  条件によって参照する・しないマスターがあり、その制御が複雑怪奇。

•  マスターに記載できない例外条件をロジックとして実装。

•  その結果保守開発などのメンテナンスにコストが掛かり、品質が低下する。

•  結果、⾼コスト体制のアプリケーションとなっている。

取引先マスターを参照しながらチェック、計算、

情報作成

例外条件がスパゲッティの元

画⾯

画⾯

アプリケーションの中のルールエンジンの位置付け




ルールエンジン


データ取得


データ取得

ルール実⾏



稟議番号



取引停⽌確認

銀⾏営業⽇確認

科⽬確認

上申部署確認

勘定科⽬確認

稟議番号


取引先番号


アプリケーションワークフロー

ディシジョン・サービス

データ・サービス画⾯

画⾯

アプリケーションの中のルールエンジンの位置付け


ルールエンジン


データ取得


データ取得

ルール実⾏





稟議番号



取引停⽌確認

銀⾏営業⽇確認

科⽬確認

上申部署確認

勘定科⽬確認

稟議番号


取引先番号


税抜き処理


データ書込契約管理マスター


お客様でのアプリケーションアーキテクチャ


ルール

給与テーブル

研修履歴テーブル

ステータス管理

BPMプロセススタート

部署名確認

対象者確認

移動理由確認

役職適正確認

研修適正確認

費⽤確認

社員テーブル

ステータス管理

BPM承認待ち

ステータス管理BPM

タスクリスト

⼈事決裁テーブル

承認画⾯

社員番号等をキーにしてデータを取得

全ての情報を⼀括受け渡し

結果を返却

プロセススタート

データ取得

ルール判断

結果書込

プロセス次へ

⼈事決裁テーブル

BPM承認済みステータス

管理

リスト取得

データ取得

プロセス次へ

DBへのアクセスはデータを取得・格納だけに使⽤し、データの判定、なかった時のハンドリングなどはDB側では⾏わないようにする。

データの確認事項などは全てルールエンジン側で⾏い、判定結果を出⼒する。

事案のデータは⼈事決裁テーブルに格納しておき、承認時などに参照する。

⼊⼒画⾯

部署名リスト

⼊⼒完了

承認完了

参考：BPMとは


DB格納

他システム連携(MQ)

DB検索

計算・判断(BRMS)

申請者承認者購買部⾨

縦の連携は“サービスオーケストレーション”

Click!! Click!! Click!!

プロセス管理(BPM)

ビジネスプロセス

次の⼈へ次の⼈へ

サービス

メール通知(Message)

24

横の連携は“ビジネス・プロセス”（誰がいつ責任をもってタスクを実⾏したかを記録し、次の⼈へバトンを渡す仕組み）

組合せチェック(BRMS)

アーキテクチャ策定の⽅法


現⾏仕様 Red Hatベストプラクティス

現⾏の仕様をRed Hatのベストプラクティスに当てはめ、最適なアーキテクチャを策定します。

策定アーキテクチャ

Java / .NET Java VM

システム連携


Service

API

RuleEngine

Decision Service

画⾯アプリ

アプリ DB

EJB / POJOアプリケーション BRMS

Git Repository

File

Management

HTTPHTTP/SOAP/REST

Web Service

稼働形態としては、Online , Batch 共に利⽤可能です

J2EEの環境さえあれば、OSやApplication Serverを問わず、どこでも稼働可能

JBoss EAPWebSphereWebLogic

ApplicationServer drldrl

xls

l  JDKl  Oracle JDK / Open JDK 1.6, 1.7, 1.8 / Zing 1.7l  IBM JDK 1.6, 1.7, 1.8 / Fujitsu JDK 1.6, 1.7

l  Application Server l  JBoss EAP 6.4, JBoss EWS 2.0.1l  Oracle WebLogic 12cl  IBM WebShpere 8.5.5l  Tomcat 6.0.37 / 7.0.40l  JBoss Fuse 6.1 （Runtimeのみ）

l  開発環境l  JBoss Developer Studio 8.1

サポート環境


サポート情報は弊社カスタマーポータルhttps://access.redhat.com/articles/705183 を御覧ください。

開発⼿法

イテレーション開発をおすすめしています


初期開発の⽅法イテレーション開発


第1回プロトタイプ

レッドハットのBRMS開発のベストプラクティスでご提供します。

第2回プロトタイプ

評価

第2回ゴール策定

全体設計⽅針策定

本開発

第1回ゴール策定

①  システム全体のアーキテクチャ、プロセス化、ルール化の範囲の策定を⾏います。また、製品トレーニングもこの期間に⾏います。

②  要件に従い、1回⽬のプロトタイプのゴールを策定します。これは単体で稼働可能な簡単なアプリケーションとルールの動作を確認する事を⽬的とします。

③  1回⽬のプロトタイプを作成します。④  1回⽬のプロトタイプの評価を⾏います。⑤  評価に基づき、2回⽬のプロトタイプのゴールを策定します。システム連携部分も含めた、

簡単なアプリケーションとルールの動作を確認する事を⽬的とします。⑥  2回⽬のプロトタイプを作成します。⑦  2回⽬のプロトタイプの評価と、本開発に向けた課題の整理を⾏います。

① ② ③ ④ ⑤ ⑥ ⑦

1.5ヶ⽉ 1ヶ⽉

設計フェーズ⼀般的なプロジェクト開発

期間は⽬安

評価

要件定義フェーズ

29

応⽤：ルールを探すためにルールエンジンを使う


BRMSでの答えオリジナルとの⽐較

基本ルール

基本ルール例外ルール1

⼀致率 45%

⼀致率 67%

基本ルール例外ルール1

⼀致率 100%例外ルール1例外ルール9

「ルールを作成→実⾏→評価→調査」を⾼速に何度も⾏う

オリジナルの答え⼊⼒データ

ルールの成熟度の進捗図


⽅針決め1ルール作成1

実⾏1

検証1調査⽅針決め2

ルール作成2

実⾏2

検証2

ルール作成3

調査⽅針決め3

実⾏3

検証3調査⽅針決め4

ルール作成4

実⾏4成熟度

時間

l  BRMSの「繰返し開発に強い」という特徴を活かした開発⼿法のことl  コンバージョンツールではありません。l  今までのロジックを100%保証できる⽅法でもありません。

l  完全な設計書の無いところから、実装⽅針決め、ロジックを作成、実⾏、評価を⾼速で⾏う開発⽅法です。従来のV字開発では時間がかかり過ぎる開発を⾼速に⾏います。

l  「諦め」「潔さ」も必要です。l  業務内容によっては不向きなものもあります。

COBOL to BRMS ソリューションとは


l  アーキテクチャl  “Decision Service” として利⽤することにより、アプリケーション

全体のアーキテクチャがスッキリして、⾒通しが良くなるl  →品質の向上、属⼈性の排除、役割分担の明確化

l  開発⼿法l  繰り返し開発に強いため、要件の詳細が確定していない場合でも設

計・開発が可能である。l  →イテレーション開発、⾒通しがつけやすい、⼿戻りがない開発

l  過去のデータ（⼊⼒値・結果）がある場合、それを元にしたロジックの発⾒も可能。

l  「よく変わるところをルール化する」l  確かに⼀番効果的ではあるl  ただし、現場の認識では今までで変わったところは少ない

l  → ルールをDBに「データとして」登録していたために、ロジック⾃体の変更がなかったl  → 業務側が改変要求を諦めていた

l  この基準でルールの適⽤範囲を決めるのは間違い

なぜルールエンジンを⼊れるのか？


Technology

BRMS6.2 2016版