具体的に説明するために、様々なプロセスを使用してマルチチャネル・バンキングを実行するアプリケーションを使用していると仮定します。このシナリオでは、各プロセスの実行は、特定のプロセス・インスタンスごとのチャネルに基づいています。
この章の内容は次のとおりです。
2レイヤーのBPMを使用すると、レイヤー・アプローチを使用してビジネス・プロセスをモデル化できます。このモデルの第1レベルは、ビジネス・プロセスに関する抽象的な仕様です。第1レベルのプロセスのアクティビティは、第2レベルのプロセスまたはサービスに作業を委任します。図54-1 に、この動作を示します。
図54-1 では、ビジネス・プロセスのPhase Iアクティビティは、その作業を対応するレイヤーIIのプロセスのタスク1.1、タスク1.2またはタスク1.3のいずれかに委任できます。
2レイヤーのBPM機能を使用すると、重要な要素(つまり、phaseアクティビティ)を宣言的に作成できます。
Oracle Business Rulesのデザインタイムおよびランタイム機能を使用すると、ビジネス・プロセスを再デプロイせずに、さらにチャネルを動的に追加できます。実行時デザインタイムでは、実行時に複数のルール(複数の列)を動的ルーティング・デシジョン表に追加できます。実行中にビジネス・プロセス・インスタンスはそれらの新規ルールを考慮し、最終的にリクエストを別のチャネルにルーティングします。
また、Oracle Business Rulesの実行時デザインタイム機能を使用すると、phaseアクティビティから起動されるサービスのエンドポイント参照を別のサービスを指し示すように変更できます。
注意:
Oracle SOAコンポーザとOracle Business Rules SDKを通じて、Oracle Business Rulesの実行時デザインタイム機能を使用できます。
Oracle SOAコンポーザとOracle Business Rules SDKの使用の詳細は、次を参照してください。
Oracle Business Process Managementを使用したビジネス・ルールの設計
Oracle Business Rules Java APIリファレンス
2レイヤーのBPMでは、フェーズはBPELプロセスのレベル1アクティビティです。これは、既存の上位レベルのOracle Business Rulesおよびヒューマン・タスクBPELアクティビティを補完します。
Oracle BPELデザイナで、phaseアクティビティをプロセスに宣言的に追加するには、「コンポーネント」ウィンドウの「Oracle Extensions」セクションからこのアクティビティをプロセス・モデルにドラッグ・アンド・ドロップします。図54-2に詳細を示します。
注意:
参照WSDL(レイヤー2またはコールした参照)には、自動作成されるフェーズ参照と同じ抽象的なWSDLが必要です。
コンポジット・アプリケーションのphaseアクティビティは、必要な変数を作成した後に作成します。
phaseアクティビティを作成する手順は、次のとおりです。
composite.xml
ファイル)をクリックします。SOAコンポジット・エディタが表示されます。phaseアクティビティを作成すると、表54-1 に記載されているアーティファクトが作成されます。
表54-1 phaseアクティビティとともに作成されるアーティファクト
アーティファクト | 説明 |
---|---|
BPELスコープ |
phaseアクティビティをドロップしたBPELプロセス内の場所に、新しいBPELスコープが作成されてBPELプロセスに挿入されます。スコープには、phaseアクティビティの名前が指定されます。スコープ内にはいくつかの標準BPELアクティビティが作成されます。最も重要なアクティビティは、Oracle MediatorへのinvokeアクティビティとOracle Mediatorからのreceiveアクティビティです。 |
Oracle Mediatorコンポーネント |
BPELプロセス・サービス・コンポーネントのSOAコンポジット・アプリケーションとともに、新しいOracle Mediatorサービス・コンポーネントが作成されます。Oracle Mediatorサービス・コンポーネントは、BPELコンポーネントのphaseアクティビティに接続されます。このBPELコンポーネントは、プロセス・モデル内でphaseアクティビティがドロップされたレベル1のBPELプロセスを構成するコンポーネントです。Oracle Mediatorサービス・コンポーネントの入出力は、phaseアクティビティの入出力によって定義されます。 Oracle Mediatorプラン(Oracle Mediatorサービス・コンポーネントの処理命令)は非常に単純です。処理命令の作成はOracle Business Rulesサービス・コンポーネントに委任されます。 |
Oracle Business Rulesコンポーネント |
BPELプロセス・サービス・コンポーネントのSOAコンポジット・アプリケーション内に、新しいOracle Business Rulesサービス・コンポーネントが作成され、BPELプロセス・サービス・コンポーネントのphaseアクティビティに関連付けられているOracle Mediatorコンポーネントに接続されます。Oracle Business Rulesサービス・コンポーネントには、ルール・ディクショナリが含まれています。ルール・ディクショナリには、ファクト・タイプ、ルールセット、ルール、デシジョン表や同様のアーティファクトなど、Oracle Business Rulesエンジン・アーティファクトのメタデータが含まれています。ルール・ディクショナリは、Oracle Business Rulesサービス・コンポーネントの作成過程で、次のデータを使用して事前に初期化されます。
|
phaseアクティビティの入力は、実行時に動的ルーティング・デシジョン表を評価するために使用されます。評価は、phaseアクティビティの特定のデシジョン・コンポーネントによって実行されます。この評価の結果が、Oracle Mediatorに対する指示になります。Oracle Mediatorは、デシジョン・コンポーネントからの指示に基づいて、リクエストをサービスにルーティングします。
注意:
現在のリリースでは、非同期のphaseアクティビティがサポートされています。同期または一方向のphaseアクティビティはサポートされていません。
phaseアクティビティを作成する場合は、次の事項について理解している必要があります。
デシジョン・サービスで構成または作成する必要のあるルール。これは、ルールの評価に使用するペイロードのデータに基づきます。
デシジョン・サービスで作成した各ルールがtrueと評価されたときに起動する必要のある、対応するエンドポイントURLを認識している必要があります。Oracle Mediatorでは、このエンドポイントURLを使用してレイヤー2のサービスを起動します。
注意:
ペイロードに対するトランスフォーメーション、割当てまたは検証は実行できません。
動的ルーティング・デシジョン表は、Oracle Business Rulesによって評価されるデシジョン表です。phaseアクティビティの入力データに対して条件が評価されます。この評価の結果が、Oracle Mediatorに対するルーティング指示になります。
phaseアクティビティを作成すると、ウィザードによってOracle JDeveloperのOracle Business Rulesデザイナが起動され、動的ルーティング・デシジョン表を編集できるようになります。図54-3 に、Oracle Business Rulesデザイナ内のデシジョン表のサンプルを示します。
レベル2のプロセス・フェーズのモデリング中には情報を空にしておき、Oracle SOAコンポーザを使用してレベル1のプロセスをデプロイした後で完了できます。
動的ルーティング・デシジョン表を作成および編集すると、図54-4 に示すように、新規のレベル1のphaseアクティビティがOracle JDeveloperのBPELプロセスに表示されます。
動的ルーティング・デシジョン表を作成することで、着信ペイロードに適用される条件を動的に評価し、対応するルーティング・ルールをOracle Mediatorに提供するデシジョン・サービスが構成されます。その後、Oracle Mediatorは、これらのルールをレイヤー2のサービスの起動時に実行します。
動的ルーティング・デシジョン表を作成すると、具体的には、設計時に次の処理が行われます。
新しいデシジョン・コンポーネントがプロジェクトのコンポジットに作成されます。
新しいルール・ディクショナリがコンポジット・プロジェクトのディレクトリに作成されます。
ルール・ディクショナリに、フェーズ入力のデータ・モデルを反映するデータ・モデルが移入されます。つまり、フェーズ入力のXMLスキーマがルール・ディクショナリにインポートされます。