TOP>製品/サービス>カテゴリから探す>ビジネスルール管理(BRMS)>Progress Corticon>【BRMS Tech コラム】

Progress Corticon

【BRMS Tech コラム】

No.6 Corticonの呼び出し方と処理速度について
(大量データ処理EDC編) 【後編】

No.6 Corticonの呼び出し方と処理速度について (大量データ処理EDC編)

これまで、2回にわたりCorticonの呼び出し方と処理速度について、Webサービスによる方法とインプロセスによる方法について、解説してきました。前回は、Progress Corticonが大量データの判定処理にも利用できることを説明しましたが、さらに大量のデータを容易に用いる方法としてCorticonのEDC(Enterprise Data Connector)オプションについて解説します。EDCはデシジョンテーブルに必要なデータの所在がDBである場合に有効なオプションです。

EDCを利用したルールの作成と実行

前回のインプロセスでのテストと同じルールでEDCを利用した場合の検証を行います。
ここではインプロセスの検証用に作成していた語彙(ecore), ルールシート(ers)に、EDC用の設定を追加して処理速度を検証します。

EDCでは、「m_post」の12万件のデータをクライアントアプリケーションからの入力としてルールに与える必要がありません。ルール内から直接DBを参照し、DB内のテーブル「m_post」のデータをルール内のエンティティ「m_post」に取り込む設定を行うことができます。詳細な設定方法などは製品マニュアルの「Corticon EDC: Using Enterprise Data Connector」を参照してください。ここでは簡単に設定を行った箇所だけ紹介します。

語彙(ecore)の設定画面で、DB接続設定を行います。

(▼DB接続設定画面)
シソーラス(階層語彙、データ構造体、Corticonにおける語彙)設計時にDBへの接続設定を行います。

case1

検証環境

次にメニューの「語彙」-「DBアクセス」-「DBメタデータのインポート」を実行し、テーブルとエンティティのマッピング設定を行います。今回の例では、エンティティ「m_post」の「データストア永続化」を「はい」にして、エンティティIDを「row_id」にします。

(▼テーブル「m_post」とエンティティ「m_post」のマッピング設定)
エンティティと属性に対してテーブルとカラムをマップします。

case2

(▼デシジョンテーブル(ルールシート)の設定)
最後にルールシートのスコープで、「m_post」を右クリックし、「データベース拡張」にチェックを入れます。

このように設定の修正を行ったソーシラス(語彙)とデシジョンテーブル(ルールシート)をもとに、Corticon Serverにデプロイします。Corticon Studioの「プロジェクト」-「デシジョンサービスのパッケージとデプロイ」機能で、「Corticonサーバにデプロイ」を行う場合は、EDC機能を有効にするために、つぎのように設定します。

(▼Corticon Studio「Corticonサーバにデプロイ」画面)

case4

EDCの設定を行ったルールをCorticon Serverにデプロイしたら、つぎのような手順でCorticon Studioでテスト実行します。
リクエストの入力はインプロセスプログラムで作成したPersonデータと同じPersonデータになります。m_postデータはルール内で取得されるため入力する必要はありません。レスポンス結果はインプロセスプログラムでの実行結果と同じになります。

(▼Corticon Studioで表示したリクエストとレスポンス)

case5

この結果が返ってくるまでのServerでの処理時間は平均「3.5秒」程度でした。
インプロセスより少し速い結果(インプロセスは平均5.0秒)ですが、劇的に速くなるわけではありません。これは、インプロセスのプログラムがDBにアクセスしてデータを取得したのとほぼ等しい動きであることがわかります。さらに処理を最適化するために、同じルールシートのスコープのフィルタ設定を変更します。フィルタ部分を右クリックし、「データベースフィルタ」をチェックします。

今回の検証で使用した環境はつぎのとおりです。

  • CPU: 2.20 GHz * 2コア
  • OS: Windows 7 Professional 64bit
  • Corticon Server: 5.5.2.7
  • Microsoft SQL Server 2012 Express

case6

この機能は、DBに対するクエリ(SQL文)にフィルタで設定した条件を足す機能で、今回の例では、以下のWHERE句が追加されて実行されます。つまり、設定変更前は住所データを全件取得した後、デシジョンテーブルを適用するタイミングで対象データの絞り込みを行っていたところを、設定変更後はあらかじめデシジョンテーブルに必要なデータをDBにリクエストする動きに変わります。

SELECT * FROM m_post WHERE m_post.post_no = ‘1020073’ or m_post.post_no = ‘11111111’;

変更したルールを再度Corticon Serverにデプロイし実行します。
処理時間の平均は約「0.07秒」になりました。
ルールの実行結果の出力は通常のフィルタとかわりませんが、データの絞込処理がDBサイドで実行されるため、処理速度は劇的に向上します。これは、前回のインプロセスでの検証時に説明したアプリケーションとルールの分離にも当てはまります。インプロセスのプログラム中で検索条件を設定すればおそらく同等の結果となるでしょう。しかし、クライアントアプリケーション側に業務ルールが実装されることになりますが、Corticonのデータベースフィルタを用いることでその課題もクリアします。

結果の考察

case7

今回の検証で使用したような量のデータを一度のWebサービス(SOAP や REST)で処理することはCorticonに限らず現実的ではないことがわかります。そこでCorticonでのそのような要求にも対応できる手法を検証しました。インプロセスの場合は、数秒という単位で処理し許容できるバッチ処理等に適用することができますし、デシジョンテーブルに必要なデータがDBにある場合には、ルールシートにDBフィルタを設定することでさらに処理速度の向上が見込まれる可能性はあります。
もちろん、処理時間はデータ量に応じて増えますし、ルールの複雑さによっては、この検証には現れないポイントの最適化を検討する必要が出てくるかもしれません。しかし、EDCに最適化したルールであれば、処理速度の面から見ると劇的に向上するため、そのような修正を行うメリットがあると言えます。


著者紹介

谷列樹さん

情報基盤事業部 製品統括部プログレス推進部

以前は、Linux系のプログラマ兼SEとして、受託請負開発などに従事していた。
また、IT系雑誌や書籍の記事執筆などにも携わった経験をもつ。
現在は、BRMS Progress Corticonの技術サポート、研修などを行う。

「BRMS Tech コラム」記事一覧





お求めの情報は見つかりましたでしょうか。

資料請求/お問い合わせはこちら(専門の担当者が確認し、ご対応します。)

お客様の状況に合わせて詳しい情報をお届けできます。お気軽にご相談ください。

ページの先頭へ戻る