| Oracle® Fusion Middleware Oracle Business Process Managementによるビジネス・ルールの設計 12c (12.1.3) E57557-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Process Managementによるビジネス・ルールの設計 12c (12.1.3) E57557-04 |
|
|
前 |
次 |
この章では、Oracle Business Rulesをサポートするデシジョン・コンポーネントについて説明します。また、デシジョン・コンポーネントの使用方法について、ルールおよびルールセットを、複数のビジネス・プロセスから起動できる再利用可能なサービスとして公開するメカニズムとして説明します。
デシジョン・コンポーネントは、コンポジット内で使用でき、かつBPELコンポーネントに接続できるSCAコンポーネントです。それ以外に、デシジョン・コンポーネントはヒューマン・ワークフローでのメディエータおよび拡張ルーティング・ルールの動的ルーティング機能に使用されます。
この章の内容は次のとおりです。
デシジョン・コンポーネントは、基礎となるデシジョン関数にルール・セッションをラップするWebサービスです。
デシジョン・コンポーネントは、次の要素で構成されています。
Rules Engineを使用して評価されるルールまたはデシジョン表。これらはルール・デザイナを使用して定義し、ビジネス・ルール・ディクショナリに格納します。
特定のルールの評価に必要なファクトを記述したメタデータ。ルールまたはデシジョン表を含むルールセットは、入力および出力であるファクトとともにサービスとして公開されます。これらのファクトは、XSD定義を介して公開される必要があります。
たとえば、信用格付ルールセットにはファクトとして顧客IDおよび過去のローン履歴が必要ですが、年金支払ルールセットにはファクトとして従業員の勤続年数、給与および年齢の値が必要です。
詳細は、「デシジョン・コンポーネント・メタデータの使用」を参照してください。
Webサービスは、基礎となるルール・エンジンに入力、出力およびコールをラップします。
このサービスにより、ビジネス・プロセスはファクトをプロセスの一部としてアサートしたり、取り消すことができます。すべてのファクトをビジネス・プロセスから1単位としてアサートできる場合があります。また、ビジネス・プロセスでファクトを増分アサートし、最終的にルール・エンジンによる推論を参照する場合もあります。したがって、サービスではステートレスな相互作用とステートフルな相互作用の両方をサポートする必要があります。
このような多様なビジネス・ルール・サービス・コンポーネントを作成できます。
詳細は、Oracle SOAスイートによるSOAアプリケーションの開発を参照してください。
Oracle JDeveloperとルール・デザイナを使用すると、これらのツールにより必須のメタデータおよびWSDL操作すべてが自動的に生成されます。
デシジョン・コンポーネントは、次の方法でSOAコンポジット・アプリケーションに統合できます。
SOAコンポジット・エディタで、デシジョン・コンポーネントをスタンドアロン・コンポーネントとして作成します。このシナリオでは、デシジョン・サービスはコンポジット・レベルで公開されるため、任意のWebサービス・クライアントから起動できます。
詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle Business Rulesのスタート・ガイドを参照してください。
SOAコンポジット・エディタでデシジョン・コンポーネントを作成し、BPELプロセスに関連付けます。このシナリオでは、デシジョン・サービスはコンポジット・レベルで公開されません。ただし、BPEL、Oracle Mediator、Oracle Human Workflowなど、コンポジット内の他の任意のコンポーネントに接続できます。
詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のOracle Business Rulesのスタート・ガイドを参照してください。
ヒューマン・タスク・コンポーネントのヒューマン・タスク・エディタで、デシジョン・コンポーネントを作成します。
この統合には、次のメリットがあります。
動的な処理: 適切なルーティング、プロセス内のポリシーの検証および制約チェックの提供
非定型ヒューマン・タスクとの統合: ポリシーベースのタスクの割当て、各種エスカレーション・ポリシーおよびタスクのロード・バランシングを提供
デシジョン・コンポーネントは、次のファイルで定義されています。
デシジョン・サービス・メタデータ(.decs)ファイル
SCAコンポーネント・タイプ(.componentType)ファイル
composite.xml内のデシジョン・コンポーネント・エントリ
通常、これらのファイルの生成およびメンテナンスにはOracle JDeveloperを使用します。
デシジョン・サービス・メタデータ(.decs)ファイル
コンポジット内のすべてのデシジョン・コンポーネントには、1つのビジネス・ルール・メタデータ・ファイルが含まれています。ビジネス・ルール・メタデータ・ファイルにより、コンポーネントのビジネス・ルール・ディクショナリの場所およびデシジョン・コンポーネントによって公開されるデシジョン・サービスに関する情報が提供されます。
1つのデシジョン・コンポーネントは、1つ以上のデシジョン・サービスを公開します。たとえば、CreditRatingデシジョン・コンポーネントは、2つのサービス、CheckEligibilityおよびCalculateCreditRatingを公開します。Oracle Fusion Middleware 11gリリース1 (11.1.1)以降では、デシジョン・サービス・メタデータにはWebサービスとして公開されるデシジョン関数名が含まれます。Oracle SOA Suiteの以前のリリースから移行されたプロジェクトに対し、デシジョン・サービス・メタデータは、10.1.3.xで使用された相互作用のパターンによっては、より多くの情報を保持していることが一般的です。
ビジネス・ルール・メタデータ・ファイル(business_rule_name.decs)では、ビジネス・ルールとデザインタイムおよびバックエンドOracle Rules Engineとの相互作用に関与するコンポーネント間の規定が定義されます。
このファイルは、SOAコンポジット・アプリケーションの場合、Oracle JDeveloperの「アプリケーション・ナビゲータ」の「SOAコンテンツ」領域にあります。表11-1に、デシジョン・サービスの.decsファイルの最上位レベル要素を示します。
表11-1 デシジョン・メタデータ・ファイル(.decs)の最上位レベル要素
| 要素 | 説明 |
|---|---|
|
<ruleEngineProvider name="OracleRulesSDK" provider="Oracle_11.0.0.0.0">
<repository type="SCA-Archive">
<path>AutoLoanComposite/oracle/rules/AutoLoanRules.rules</path>
</repository>
</ruleEngineProvider>
デシジョン・コンポーネントの場合、リポジトリ・タイプは
|
|
デシジョン・サービスは、ビジネス・ルールのWebサービス(SOA)イネーブラです。Webサービスという意味ではサービスであるため、サービス指向アーキテクチャ(SOA)にビジネス・ルールをもたらします。12c (12.2.1)では、デシジョン・サービスはサービスのメタデータおよびWSDL規定で構成されます。
通常、デシジョン・サービスには、次の要素が含まれています。
操作(パターン)とは別に、操作のパラメータ型(ファクト・タイプ)が指定されています(後で実行時に検証されます)。したがって、各デシジョン・サービスでは強い型指定を持つ規定が公開されます。 |
SCAコンポーネント・タイプ(.componentType)ファイル
SCAのbusiness_rule_name.componentTypeファイルは、各デシジョン・コンポーネントとともに組み込まれています。このファイルには、ビジネス・ルール・サービス・コンポーネントにより公開されるサービスがリストされます。次の例では、2つのサービスCreditRatingServiceおよびLoanAdvisorServiceが公開されています。
<?xml version="1.0" encoding="UTF-8" ?> <!-- Generated by Oracle SOA Modeler version 1.0 at [5/24/07 9:27 AM]. --> <componentType xmlns="http://xmlns.oracle.com/sca/1.0"> <service name="CreditRatingService"> <interface.wsdl interface="http://xmlns.oracle.com/creditrating/Rating#wsdl.interface(IDecisionSer vice)"/> </service> <service name="LoanAdvisorService"> <interface.wsdl interface="http://xmlns.oracle.com/loanoffer/Advisor#wsdl.interface(IDecisionServi ce)"/> </service> </componentType>
composite.xml内のデシジョン・コンポーネント・エントリ
デシジョン・コンポーネントに対してcomposite.xml内にエントリが作成されます。次に例を示します。
<component name="OracleRules1">
<implementation.decision src="OracleRules1.decs"/>
</component>
ビジネス・ルール・サービス・エンジンでは、サービス・エンジンに対するリクエストを処理するためにこの実装タイプからの情報が使用されます。SCAの視点からは、デシジョン・コンポーネントは新しい実装タイプです。
デシジョン・サービスを使用すると、Oracle Business Rulesデシジョン関数をサービスとして公開できます。デシジョン関数は、Java EEアプリケーションまたは別のコンポーネントからルールをコールするために使用する関数です。
次のコード例に、サービスとして公開されるOracle Business Rulesデシジョン関数のメタデータを定義する、business_rule_name.decsファイルのdecisionServices要素を示します。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <decisionServices xmlns="http://xmlns.oracle.com/bpel/rules" name="PurchaseItems"> <ruleEngineProvider name="OracleRulesSDK" provider="Oracle_11.0.0.0.0"> <repository type="SCA-Archive"> <path>PurchasingSampleProject/oracle/rules/com/example/PurchaseItems.rules</path> </repository> </ruleEngineProvider> <decisionService targetNamespace="http://xmlns.oracle.com/PurchaseItems/PurchaseItems_DecisionService_ValidatePurchasesDF" ruleEngineProviderReference="OracleRulesSDK" name="PurchaseItems_DecisionService_ValidatePurchasesDF"> <catalog>PurchaseItems</catalog> <pattern name="CallFunctionStateless"> <arguments> <call>com.example.PurchaseItems.ValidatePurchasesDF</call> </arguments> </pattern> <pattern name="CallFunctionStateful"> <arguments> <call>com.example.PurchaseItems.ValidatePurchasesDF</call> </arguments> </pattern> </decisionService> </decisionServices>
この場合、デシジョン関数ValidatePurchasesDF自体は、PurchaseItems.rulesファイルで全体が指定されています。
詳細は、デシジョン関数の使用を参照してください。
ステートフルなデシジョン・サービスを提供するには、デシジョン関数を作成し、そのデシジョン関数をステートレスでないように指定します。そのためには、デシジョン関数の「ステートレス」チェック・ボックスの選択を解除します。
デシジョン・コンポーネントとのステートフルな相互作用については、次の詳細に注意してください(図11-2も参照)。
キャッシュからのルール・セッションおよびプールからのルール・セッションは相互排他です。
ルール・セッション・プールは、単純でステートレスな相互作用専用です。
ルール・セッション・キャッシュでは、デシジョン・サービス・リクエスト間でルール・セッションの状態が維持されます。
ビジネス・ルール・サービス・エンジンで実行されるデシジョン・コンポーネントでは、ステートフルな操作とステートレスな操作のいずれかがサポートされます。「ビジネス・ルールの作成」ダイアログの「セッションのリセット」(ステートレス)チェック・ボックスを使用して、これら2つの操作モードを切り替えることができます。
「セッションのリセット」チェック・ボックスを選択すると、ステートレスな操作が指定されます。
「セッションのリセット」(ステートレス)チェック・ボックスの選択が解除されている場合、基礎となるOracle Business Rulesオブジェクトは、(操作の終了時にルール・セッション・プールに戻されないように)別の場所にあるビジネス・ルール・サービス・エンジンのメモリー内に保持されます。このオプションが必要な場合にのみステートフルな操作を使用してください(ステートフルな操作を使用すると実行時にエラーが発生する場合があり、そのエラーによってサービス・エンジンのメモリーが大量に使用される場合があります)。
「セッションのリセット」(ステートレス)チェック・ボックスの選択が解除されている場合、デシジョン・コンポーネントがその後使用されると、キャッシュされたRuleSessionオブジェクトはcallFunctionStatefulの起動以降のすべての状態情報とともに再利用され、callFunctionStateless操作の終了後、解放されてルール・セッション・プールに戻されます。
デシジョン・サービスは、サービスの記述のみで構成されます。その他のすべてのアーティファクトは、デシジョン・コンポーネント内で共有されます。
図11-1にこれを示します。
ランタイムの中心部分は、ツリー構造で編成されたデシジョン・サービス・キャッシュです。各デシジョン・コンポーネントは、そのキャッシュのサブツリーを(コンポジット識別名(DN)、コンポーネントおよびサービス名に応じて)所有します。この点では、デシジョン・コンポーネントのデシジョン・サービスは次のデータを共有していることになります。
デシジョン・コンポーネントのメタデータ
ファクト・タイプのメタデータ。
関数のメタデータ。
ルールセットのメタデータ。
ルール・セッション・プール
デシジョン・コンポーネントごとにルール・セッション・プールが1つ作成されます。
プール内のルール・セッションは、データ・モデルのOracle RLおよび実行済のルールセットのOracle RLを使用して事前に初期化されます。
必要に応じて新規のルール・セッションが作成されます。
ルール・セッションは再利用でき、その回数は構成可能です。
ルール・セッション・プールの初期サイズは構成可能です。
ステートフルなルール・セッション・キャッシュ
ステートフルなルール・セッションの場合は、特別なキャッシュがメンテナンスされます。
詳細は、「デシジョン・コンポーネントとのステートフルな相互作用の使用」を参照してください。
デプロイメント・アーティファクト
デシジョン・コンポーネントのデプロイメントにより、最終的にJAXBファクト・タイプのクラスを生成できます。これらのクラスはコンポジット間で共有できます。
図11-2に、デシジョン・サービス・リクエスト中の、ステートレスなルール・セッションおよびステートフルなルール・セッションとルール・セッション・プールの相互作用、およびステートフルなルール・セッションとステートフルなルール・セッション・キャッシュの相互作用を示します。
図11-2 デシジョン・サービス・リクエストに対するステートレスおよびステートフルなルール・セッションの使用方法
