■ 仕様
前回とほぼ同じで、入力文字列が5文字以上なら文字列"LONG"、でなければ文字列"SHORT"を返すという仕様。これを Webサービス → BPELプロセス → ビジネスルールの構成で動かしてみる。アホらしい仕様だが、Getting Started なのでこんな感じ。
■ 環境
・Oracle SOA Suite 11g (11.1.1.2.0)
・Oracle JDeveloper 11g
■ コンポジット作成
- プロジェクト名:適当。ここではSimpleDecisionTable とした
- プロジェクト・テクノロジ:SOAを選択
- コンポジット・テンプレート:BPEL を使用するコンポジット
■ BPELプロセス作成
- 名前:適当。ここでは SimpleDecisionTableProcess とした
- テンプレート:同期BPELプロセス
- SOAPサービスとして公開:チェック
■ スキーマにファクトを追加
SimpleDecisionTableProcess.xsd が自動生成され、process と processResponse の定義が含まれているが、これを更に以下のように編集
- 列挙型 CategoryValueを追加
<simpleType name="CategoryValue">
<restriction base="string">
<enumeration value="SHORT"/>
<enumeration value="LONG"/>
</restriction>
</simpleType> - BusinessRuleに与えるファクトを追加
<element name="facts">
<complexType>
<sequence>
<element name="length" type="int"/>
</sequence>
</complexType>
</element> - 既存のprocessResponse/resultの型を CategoryValue に変更(名前空間のプレフィクスも適当は調整しておく。)
■ BusinessRule 作成
- composite.xml を開く
- コンポーネントのレーンにビジネスルールをドラッグ
- 適当に名前を指定。ここでは LenghtCategoryTable とした。
- 緑のプラスボタンで入力を追加
- プロジェクトのスキーマ・ファイルからfacts を選択
- 緑のプラスボタンで出力を追加
- プロジェクトのスキーマ・ファイルからprocessResponse を選択
- 作成したビジネスルールにBPELプロセスからワイアリング
■ BPEL の編集
- receiveInput と replyOutput の間に Assign を置いて、以下のようなコピー操作を追加
- From:string-length(bpws:getVariableData('inputVariable','payload','/client:process/client:input'))
- To:/変数/プロセス/変数/facts/client:facts/client:length
- 上で追加した Assign の下にBusinessRule を置く
- 名前は適当。ここでは デフォルトのままとした。
- ディクショナリに LenghtCategoryTable を指定
- 以下のように入力ファクトを追加
- From:変数/プロセス/変数/facts/client:facts
- To:変数/{凄い長い名前の変数}/client:facts
※To の「変数」は、ダブルクリックしないと展開されないので注意。展開すると凄い長い名前の変数が表示される
- 以下のように出力ファクトを追加
- From:変数/{凄い長い名前の変数}/processResponse
- To:変数/プロセス/変数/outputVariable/payload/processResponse
■ デシジョン表の作成
- composite.xmlからビジネスルールの編集を開始
- 緑のプラスボタンから[デシジョン表の作成]
■ デプロイ-テスト
- SimpleBusinessRule のコンテキストメニューからデプロイ
- SoapUI か emコンソール からリクエストを送る
- process/input に空文字列, "abcd", "こんちは"等を指定すると"SHORT"
- process/input に"abcde", "こんにちは"を送ると"LONG"が返ってくる
■ 雑感
今回やったようなのは極端に簡単な処理なので、標準BPEL コードでも出来ることではあるけど、BPEL から Business Rule として切り出すことで、一般的に以下のような効用が期待できる。
(1) BPEL プロセスの簡素化
BPEL の本来の目的からも、またスパゲティ化を回避する意味でも、他サービスをオーケストレイトしない制御ロジック(繰り返し/条件分岐)は BPEL に含めるべきではない。その変わりに XSLT か BusinessRule として切り出して BPEL をシンプルに保つべき。(設計上の都合に由来するなら XSLT、ビジネス要因に由来するものは BusinessRule。)
(2) ビジネスルールの外部化
コンポジットアプリをデプロイした後からでも、ビジネスの変更を契機として
ルールだけを独立に変更したい状況もある。またこの作業を、いちいち IT層 の人間に頼まずに、ビジネス層の人間が直接実施するニーズもあるはず。そうなると BPEL や XSLT では敷居が高いが、Business Ruleにしておけば、ウェブベースのルールエディタを使ってデプロイ後にも編集できる(11.1.1.2.0)。
0 件のコメント:
コメントを投稿