Oracle® Fusion Middleware Oracle Business Process Composerによるビジネス・プロセスの開発 12c (12.2.1.1) E77375-01 |
|
![]() 前へ |
![]() 次へ |
この付録では、Oracle Business Process Management (Oracle BPM)でサポートされているBusiness Process Model and Notation 2.0 (BPMN 2.0)フロー・オブジェクトについて詳しく説明します。Oracle BPMにおけるBPMN 2.0標準の実装について説明します。正式な仕様を含むBPMNの詳細は、http://www.bpmn.org
を参照してください。
この付録で説明するBPMN 2.0フロー・オブジェクトは、ビジネス・プロセスで実行する必要があるタスクのタイプ別に構成されています。
この付録の内容は次のとおりです。
開始イベントは、プロセスの開始点を定義するBPMNフロー・オブジェクトです。一方、終了イベントはプロセスの終了点を定義します。
この項では、プロセスの開始と終了を定義するBPMN 2.0フロー・オブジェクトについて説明します。
開始イベントは、プロセスの開始点を定義するBPMNフロー・オブジェクトです。開始イベントには様々なタイプがあり、それによってプロセス・インスタンスの作成方法が定義されます。
一方、終了イベントはプロセスの終了点を定義します。終了イベントには様々なタイプがあり、それによってプロセス・インスタンス完了時の処理が定義されます。
注意:
Oracle BPMでは、すべてのBPMNプロセスに少なくとも1つの開始イベントと1つの終了イベントが必要です。
開始イベントではプロセスの始まりを定義するため、受信シーケンス・フローは含まれません。同じく、終了イベントには送信シーケンス・フローを含めることができません。
ただし、None開始イベントとNone終了イベント以外の開始イベントと終了イベントには、他のビジネス・プロセスおよびサービスとの間の入出力を含めることができます。
新しいプロセスを作成すると、Oracle Business Process Composerではメッセージ開始イベントとメッセージ終了イベントがデフォルトで作成されます。これらのデフォルトは、作成するビジネス・プロセスのタイプに応じて変更できます。表A-1は、各プロセス・タイプのデフォルトの開始イベントと終了イベントを示しています。
表A-1 各プロセス・タイプの開始イベントおよび終了イベント
プロセス・タイプ | デフォルトの開始イベント・タイプおよび終了イベント・タイプ |
---|---|
非同期サービス |
メッセージ開始イベントおよび終了イベント |
同期サービス |
メッセージ開始イベントおよび終了イベント |
手動プロセス |
None開始イベントおよび終了イベント |
Oracle BPMでサポートされている様々なタイプのプロセスの詳細は、ビジネス・プロセスの概要を参照してください。
サブプロセスには、デフォルトでNone開始イベントおよびNone終了イベントが含まれています。これらは必須の開始イベントおよび終了イベントであり、変更できません。
イベント・サブプロセスには、デフォルトでメッセージ開始イベントおよびNone終了イベントが含まれています。ただし、処理するイベントのタイプに応じて、開始イベントを変更できます。
1つのBPMNプロセスに、複数の開始点を定義できます。複数の開始点を定義すると、使用される開始イベントに応じて、プロセス・インスタンスの複数の作成方法を指定できます。
図A-1は、メッセージ開始イベントとタイマー開始イベントの両方を含むプロセスの例を示しています。
このプロセスは、別のプロセスまたはサービスからのコール時にメッセージ・イベントを使用して起動できます。また、プロセス・インスタンスを自動的に作成する必要がある場合は、タイマー開始イベントを起動して一定の時間間隔に基づいて開始することもできます。
複数の開始イベントを使用すると、2つの異なるプロセスを作成することなく、1つのプロセスが複数の方法で開始されるようにできます。
終了イベントは、プロセス・パスの終わりを示します。プロセスに1つしか終了イベントがないときに、トークンがその終了イベントに到達すると、終了イベント到達時にプロセスが停止します。
注意:
メッセージ終了イベントを使用できるのは、メッセージ開始イベントによって開始したプロセスを終了する場合のみです。さらに、複数のメッセージ終了イベントを1つのメッセージ開始イベントに関連付けた場合、各メッセージ終了イベントには同じ数とタイプの出力引数を設定する必要があります。
複数の終了イベントを使用している場合は、1プロセス内で様々なトークンが様々なパスを経由する可能性があります。通常は、すべてのパラレル・パスが終了イベントに達して初めてプロセスが完了します。
ただし、次のような特別な場合には、すべてのプロセス・パスが完了する前にプロセス・インスタンスが停止することがあります。
エラー終了イベント: エラー終了イベントに達すると、すべてのプロセス・アクティビティが停止します。
エラー・スロー・イベントと同様に、エラー終了イベントでは、プロセスのフローが停止されます。詳細は、エラー終了イベントの概要を参照してください。
強制終了イベント: 強制終了イベントが発生すると、プロセス上のすべての作業が即時に停止します。
エラー処理や、その他の実行中プロセスのクリーン・アップは行われません。詳細は、強制終了イベントの概要を参照してください。
Oracle BPMでは、プロセス・インスタンスをトリガーするために次の方法がサポートされています。
メッセージ開始イベント、シグナル開始イベントまたはタイマー開始イベントを使用する方法。
詳細は、次の各項を参照してください。
None開始イベントを使用し、その後で受信タスクを使用。
プロセス・インスタンスを作成するために受信タスクを構成する必要があります。詳細は、受信タスクの概要を参照してください。
None開始イベントを使用し、その後でイニシエータ・パターンで定義したユーザー・タスクを使用。
詳細は、ユーザー・タスクの概要を参照してください。
新しいプロセス・インスタンスを作成するように構成されたイベント・ベース・ゲートウェイを使用する方法。
詳細は、ガイド付きビジネス・プロセスを使用したプロジェクトのマイルストンの作成を参照してください。
None開始イベントは、インスタンス・トリガーが明確に定義されていないときに使用します。プロセスの必要な開始イベントが不明か未定義であるか、または後でプロセス開発者によって定義および実装される場合、None開始イベントをプレースホルダとして使用できます。
図A-2は、None開始イベントのデフォルトの表記を示しています。
None開始イベントでは、プロセス・インスタンスが別のフロー・オブジェクトで作成される場合に、プロセスの始まりを指定することもできます。通常、None開始イベントは新しいプロセス・インスタンスの作成をトリガーしません。
ただし、次のタスクとともに使用する場合、None開始イベントは新しいプロセス・インスタンスをトリガーします。
受信タスク: 受信タスクでは、「インスタンスの作成」プロパティがtrueに設定されている必要があります。
ユーザー・タスク: イニシエータ・パターンを使用して実装されたユーザー・タスク。
他の開始イベントと同様に、None開始イベントも受信シーケンス・フローを含むことはできません。含むことができるのは、デフォルトの送信シーケンス・フローのみです。
注意:
Noneイベントは、サブプロセスの開始を定義するときに常に使用されます。
図A-3は、営業見積サンプル・プロジェクト内のNone開始イベントの例を示しています。この例では、None開始イベントによってプロセスの開始が定義されています。また、プロセスにはイニシエータ・パターンを使用して実装されたユーザー・タスクが含まれているため、None開始イベントによってプロセス・インスタンスがトリガーされます。
メッセージ開始イベントは、メッセージを受信するとプロセス・インスタンスをトリガーします。このメッセージは、別のBPMNまたはBPELプロセス、あるいはサービスから送信されます。
メッセージとは、プロセス間で情報を交換するために使用されるタイプのデータです。データ・オブジェクトが、プロジェクト内で使用されるデータを定義するために使用されるのと同様に、メッセージは、プロセス間またはプロセスとサービスとの間で使用されるデータを定義するために使用されます。
図A-5は、メッセージ開始イベントのデフォルトの表記を示しています。
他の開始イベントと同様に、メッセージ開始イベントには受信シーケンス・フローを含めることができません。メッセージ開始イベントには、デフォルトの送信シーケンス・フローが必要です。
他のプロセスやアプリケーションがプロセスを起動できるように、BPMNプロセスをサービスとして公開できます。プロセスをサービスとして公開するには、プロセスをメッセージ開始イベントで開始する必要があります。また、プロセスへの入力引数(メッセージ開始イベントに渡されるデータ・オブジェクト)を定義する必要があります。詳細は、プロセスの入力と出力の定義を参照してください。
図A-5は、営業見積プロセスの修正バージョンを示しています。ここでは、プロセスは、プロセス・インスタンスを開始するメッセージ開始イベントから開始されています。
メッセージ開始イベントを使用すると、プロセスに対して入力引数および出力引数を指定できます。これらの引数では、他のプロセスやサービスがプロセスを呼び出すときに送信する必要があるメッセージが定義されます。プロセスの入力引数と出力引数を構成する方法については、プロセスの入力と出力の定義を参照してください。
シグナル開始イベントは、別のプロセスまたはサービスからの通信に基づくという点でメッセージ開始イベントに似ています。ただし、メッセージ開始イベントは、特定のプロセスに送信されたメッセージに応答します。対照的に、シグナル開始イベントは複数のプロセスにブロードキャストされたシグナルに対するレスポンスです。
シグナルは、BPMNプロセスからシグナル・スロー・イベントを使用してブロードキャストできます。シグナル・スロー・イベントとシグナル開始イベントを組み合せて使用すると、複数のプロセスを同時に起動できます。
シグナル開始イベントとシグナル・スロー・イベントは、プロセス開発者によってプロセスに追加されます。シグナル・スロー・イベントの実装の詳細は、Oracle Business Process Management Studioによるビジネス・プロセスの開発のシグナル・イベントを使用したプロセス間通信の概要に関する項を参照してください。
図A-6は、シグナル開始イベントのデフォルトの表記を示しています。
タイマー開始イベントは、特定の時間条件に基づいてプロセス・インスタンスの作成をトリガーします。タイマー開始イベントは、次の内容に基づいてプロセス・インスタンスをトリガーするように構成できます。
特定の日付および時刻。
たとえば、12月31日の午後11時59分にプロセスをトリガーできます。
繰返し間隔。
たとえば、10時間ごと、5分ごと、32秒ごとにプロセスをトリガーできます。
図A-7は、タイマー開始イベントのデフォルトの表記を示しています。
エラー開始イベントは、インライン・ハンドラの開始イベントとして使用されます。インライン・ハンドラを使用して、プロセス内で発生するエラーに対応する個別のプロセス・フローを定義できます。
図A-8は、None終了イベントのデフォルトの表記を示しています。
注意:
エラー開始イベントを使用できるのは、インライン・ハンドラ内のみです。通常のプロセス・フロー内では使用できません。
複数のインライン・ハンドラを指定して、エラーの状況に対応できます。ただし、同じ例外を使用するインライン・ハンドラを複数定義することはできません。
None終了イベントは、プロセス・パスの終わりを示すために使用します。トークンは、None終了イベントに到達すると消費されます。プロセス・インスタンス内に他のトークンがない場合は、インスタンスが完了します。
None終了イベントは、プロセス完了後にアクションを実行する必要がない場合に使用します。また、このイベントは、後で実装時にプロセス開発者が変更するためのプレースホルダとして、プロセス・アナリストが使用することもできます。
図A-9は、None終了イベントのデフォルトの表記を示しています。
None終了イベントは、サブプロセスおよびイベント・サブプロセスの終わりを示すときに常に使用されます。
図A-10は、営業見積サンプル内のNone終了イベントの例を示しています。この例では、営業見積サービス・タスクを使用して、営業見積に関する情報をデータベースに保存しています。
トークンがプロセスの終わりに到達した場合は、他の作業を実行できないため、None終了イベントが使用されています。プロセス・トークンがすべてNone終了イベントに到達すると、プロセス・インスタンスが完了します。
エラー終了イベントは、エラー状態が原因でプロセスを終了する場合に使用します。
通常、エラー終了イベントは、エラー境界イベントとともに使用します。エラー境界イベントは、特定のエラーに基づいてプロセス・フローを変更するために使用します。通常、エラー境界イベントを使用したフローは、エラー終了イベントを使用して終了します。エラー中間イベントの使用方法の詳細は、エラー・キャッチ・イベントの概要を参照してください。
図A-11は、エラー終了イベントのデフォルトの表記を示しています。
エラー終了イベントの実装の詳細は、Oracle Business Process Management Studioによるビジネス・プロセスの開発を参照してください。
メッセージ終了イベントは、プロセス完了時に他のプロセスやサービスにメッセージを送信するために使用します。メッセージ終了イベントは、常にメッセージ開始イベントまたはメッセージ・キャッチ・イベントとともに使用します。
注意:
複数の終了イベントを持つプロセスを作成する場合は、メッセージ終了イベントに到達するすべてのトークンがメッセージ開始イベントによって作成されることを確認する必要があります。たとえば、タイマー開始イベントによって開始されたプロセス・インスタンスを終了するためにメッセージ終了イベントを使用することはできません。
図A-12は、メッセージ終了イベントのデフォルトの表記を示しています。
メッセージ終了イベントを使用してプロセスの出力引数を構成する方法については、プロセスの入力と出力の定義を参照してください。
多くのビジネス・アプリケーションでは、組織内のプロセス参加者からの相互作用が必要です。相互作用は、フォームに情報を入力するなどの単純な操作の場合や、複数のワークフローおよび複数のユーザーが関与する場合があります。
この項では、プロセス参加者がビジネス・プロセスと相互作用する方法をモデリングするために使用されるBPMN 2.0フロー・オブジェクトについて説明します。内容は次のとおりです。
多くのエンドツーエンドのビジネス・プロセスでは、プロセスとの手動による相互作用が必要です。承認、例外管理、ビジネス・プロセスを進めるために必要なアクティビティの実行などにユーザーの相互作用が必要となります。
Oracle Human Workflowでは、次の機能によってユーザーの参加が包括的にサポートされます。
適切なユーザーまたはグループに対するタスクの割当ておよびルーティングを含む、プロセスとの手動による相互作用
タスクが適切なタイミングで実行されることを保証するために必要な期限、エスカレーション、通知およびその他の機能。
プロセス参加者が各自のタスクを実行するときの生産性を向上するために必要な組織、フィルタ、優先順位付けおよびその他の機能。
スーパーバイザおよびビジネス所有者がタスクのパフォーマンスを管理するために必要なレポート、再割当て、ロード・バランシングおよびその他の機能。
詳細は、Oracle SOA SuiteによるSOAアプリケーションの開発のヒューマン・ワークフローのスタート・ガイドを参照してください。
ヒューマン・タスクは、Oracle Human Workflowのコンポーネントの1つです。ヒューマン・タスクを使用すると、エンドツーエンドのプロセス・フロー内のシステムおよびサービスとの接続を使用して、手動による相互作用をインタリーブできます。ヒューマン・タスクの役割は、ビジネス・プロセスに参加しているユーザーおよびグループのすべての相互作用を処理することです。これを行うために、組織内で該当するユーザーのタスクを作成して追跡しています。ユーザーは通常、ワークリスト・アプリケーション、電子メール、ポータル、カスタム・アプリケーションなどの各種クライアントを通じてタスクにアクセスします。
ヒューマン・タスクにより、開発者はプロセス参加者が、Oracle BPM SuiteおよびOracle Service-Oriented Architecture (SOA) Suiteを使用して作成されたプロセス・ベースのアプリケーションと相互作用する方法を定義できます。
プロセス開発者はヒューマン・タスクを使用して次の要素を作成することで、エンド・ユーザー相互作用のインタフェースとワークフローを定義できます。
ロールと割当て
期限とエスカレーション
プレゼンテーション
ヒューマン・タスクは、同じUIを使用する他のプロセス内で使用できる再使用可能なサービスです。ヒューマン・タスクは、Oracle BPM Studioを使用して作成されます。
ユーザー・タスクは、プロセス内で、プロセス参加者が作業を実行する必要がある部分を表します。ユーザー・タスクは、フォームへの入力などの単純な相互作用である場合もあれば、複数のプロセス参加者からの入力を必要とする複雑なワークフローの一部である場合もあります。
図A-13は、ユーザー・タスクのデフォルトの表記を示しています。
Oracle BPM Suiteでは、プロセス参加者はプロセス・ワークスペースを使用してビジネス・アプリケーションと相互作用を行います。プロセス参加者に対して表示される画面やパネルなどの具体的なユーザー・インタフェース要素は、ヒューマン・タスクを使用して作成します。
プロセスの設計時には、多くの場合、プロセス・アナリストがユーザー・タスクをプロセス図に追加します。その後、プロセス開発者が必要なヒューマン・タスクを作成し、プロセスベースのビジネス・アプリケーション作成の構成要素として実装します。
トークンがユーザー・タスクに到達すると、対応するヒューマン・タスクが実行されます。トークンは、ヒューマン・タスクが完了するまで待機してから、次のフロー・オブジェクトに移動します。
ビジネス・カタログの要素をユーザー・タスクに割り当てる手順については、ビジネス・カタログのコンポーネントをフロー・オブジェクトに割り当てる方法を参照してください。
ユーザー・タスクの実装の詳細は、Oracle Business Process Management Studioによるビジネス・プロセスの開発のヒューマン・タスクの使用に関する項を参照してください。
他のフロー・オブジェクトと同様、ユーザー・タスクには受信および送信データ・アソシエーションを含めることができます。
また、ユーザー・タスクには、受信シーケンス・フローおよびデフォルトの送信シーケンス・フローを含めることもできます。
営業見積サンプルでは、見積入力タスク(図A-14を参照)は見積情報を入力する作業を表します。
ユーザーが営業見積に関する情報を入力すると、プロセス・フローは送信シーケンス・フローに従ってプロセス内の次のフロー・オブジェクトに移動します。
Oracle BPM Studioを使用して、対話型アクティビティをコンポーネント・パレットからプロセスに直接追加できます。対話型アクティビティは、Oracle Human Workflowのタスク・ルーティング機能および承認機能に基づくショートカットです。詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』の 「ヒューマン・ワークフローのスタート・ガイド」を参照してください。
表A-2は、Oracle Business Process Composerのコンポーネント・パレットで利用できる対話型アクティビティを示しています。
表A-2 対話型アクティビティ
パターン | 説明 |
---|---|
複合 |
ヒューマン・タスク内に定義されている複雑なルーティング・フローを使用します。 |
管理 |
スイムレーンに割り当てられたグループまたはロールに属するプロセス参加者の管理チェーン・パターンに割当て先を設定する管理チェーン・パターンを使用します。 |
FYI |
割当てはスイムレーンに定義された参加者、ロールまたはグループに基づきます。FYIアクティビティはユーザー対話型アクティビティに類似していますが、完了を待機せずに処理を続行する点が異なります。 |
グループ |
グループ投票パターンを使用します。タスクの割当て先はレーンに関連付けられたロールまたはグループに自動的に設定されます。この対話型アクティビティはロールまたはグループに関連付けられたスイムレーンにのみ追加できます。 |
イニシエータ |
イニシエータ・パターンは、プロセス・インスタンスを作成するために使用します。 |
手動タスクは、Oracle BPMのスコープ外のプロセス参加者が実行するタスクを表します。手動タスクはプロセス内のプレースホルダとして使用され、実行時にBPMNサービス・エンジンによって管理されない作業を示します。また、手動タスクはプロセス・ワークスペース・アプリケーションには表示されません。
注意:
手動タスクはOracle BPMによって管理されません。Oracle BPMランタイムでは、手動タスクの開始および完了は追跡されません。
図A-15は、手動タスクのデフォルトの表記を示しています。
手動タスクでは、デフォルト受信シーケンス・フローとデフォルト送信シーケンス・フローをそれぞれ1つのみ使用できます。
多くのBPMN 2.0フロー・オブジェクトと異なり、手動タスクではデータ・オブジェクトを操作できません。以前のフロー要素に関連付けられたデータ・オブジェクトはそのままの状態で次のフロー要素に渡されます。
営業見積サンプルのコンテキストでは、図A-16に示すように正式な契約書を印刷して署名するための手動タスクを追加できます。
この例では、正式な契約書への署名をビジネス・プロセスの一部として明示的に示す必要がありますが、署名はBPMNサービス・エンジンによって管理されないため、手動タスクが使用されています。
更新タスクは、1つ以上のヒューマン・タスクに対して操作を実行する場合に使用します。たとえば、更新タスクを使用して、別のユーザーへのタスクの再割当てなどのアクションを実行できます。
図A-17は、更新タスクのデフォルトの表記を示しています。
更新タスクの使用方法の詳細は、Oracle Business Process Management Studioによるビジネス・プロセスの開発を参照してください。
Oracle BPMでは、プロセス指向アプリケーション内のビジネス・プロセス間の相互作用を定義できます。以降の項では、プロセス間の通信のモデリングに使用されるBPMNフロー・オブジェクトについて説明します。
この項では、Oracle Business Process Composerを使用してプロセス・モデルを作成する場合のこれらのフロー・オブジェクトの使用方法について説明します。プロセス・ベースのアプリケーションにおけるこれらのフロー・オブジェクトの実装方法の詳細は、Oracle Business Process Management Studioによるビジネス・プロセスの開発を参照してください。
サービス・タスクを使用すると、他のプロセスおよびサービスと通信できます。プロセス・アナリストは、プロセスで外部サービスまたは外部プロセスを呼び出す必要がある場合、サービス・タスクを追加できます。
その後、プロセス開発者は必要なサービスを実装できます。サービス・タスクを使用して、次を呼び出すことができます。
他のBPMNプロセス
BPELプロセス
SOAサービス・アダプタ
サービスとして公開されているメディエータ
ビジネス・カタログの要素をサービス・タスクに割り当てる手順の詳細は、「ビジネス・カタログ・コンポーネントをフロー・オブジェクトに割り当てる方法」を参照してください。
サービス・タスクの動作は、送信タスクと受信タスクのペアの動作、およびメッセージ・スロー・イベントとメッセージ・キャッチ・イベントのペアの動作と似ています。主な違いは、サービス・タスクがプロセスおよびサービスを同期的に起動するために使用される点です。サービス・タスクがプロセスやサービスを起動すると、レスポンスが返されるまで、トークンはサービス・タスクで待機します。レスポンスを受信した後、トークンはプロセス内の次のシーケンス・フローに移動します。
サービスおよびBPMNプロセスを使用したサービス・タスクの実装方法の詳細は、Oracle Business Process Management Studioによるビジネス・プロセスの開発のサービス・タスクを使用した、サービスおよびBPMNプロセスの同期操作の起動に関する項を参照してください。
図A-18は、サービス・タスクのデフォルトの表記を示しています。
通知タスクはサービス・タスクに類似しています。通知タスクは、事前定義されたサービスを使用して、様々なタイプの通知を実行します。さらに、式を使用して、通知タスクで生成された通知を受信するユーザーまたはグループを決定できます。
通知タスクの実装の詳細は、Oracle Business Process Management Studioによるビジネス・プロセスの開発を参照してください。
次のようなタイプの通知があります:
IM: インスタント・メッセージをユーザーまたはグループに送信します。
図A-20は、IM通知タスクのデフォルトの表記を示しています。
電子メール: 電子メールをユーザーまたはグループに送信します。
電子メールには添付ファイルを含めることもできます。図A-21は、電子メール通知タスクのデフォルトの表記を示しています。
SMS: SMSメッセージをユーザーに送信します。
図A-22は、SMS通知タスクのデフォルトの表記を示しています。
音声: ボイスメールをユーザーに送信します。
図A-23は、ボイスメール通知タスクのデフォルトの表記を示しています。
ユーザー: 使用可能な通知タイプに基づいて、通知をユーザーに送信します。
たとえば、ユーザーがボイスメールと電子メールの両方を構成している場合、通知タスクでは両方とも送信します。図A-24は、ユーザー通知タスクのデフォルトの表記を示しています。
コール・アクティビティを使用すると、再使用可能なプロセスを現在のプロセス内からコールできます。被コール側プロセスは、コール側プロセスの子プロセスになります。再使用可能なプロセスをコールしている場合、親プロセスのコール・アクティビティは、子プロセスが完了するまで待機してから処理を続行します。
図A-25は、コール・アクティビティのデフォルトの表記を示しています。
詳細は、再使用可能なプロセス(再使用可能なサブプロセス)の概要を参照してください。
親プロセスのデータ・オブジェクトは、再使用可能なプロセスに対して自動的に使用可能になりません。データ・オブジェクトは、コール・アクティビティの引数マッピングを使用して、子プロセスとの間で受け渡す必要があります。
送信タスクでは、現在のプロセス外部のシステムまたはプロセスにメッセージが送信されます。このメッセージが送信されると、タスクは完了し、プロセスの実行はプロセス・フロー内の次のタスクに移動します。
多くの場合、送信タスクは受信タスクと組み合せて使用され、プロセスまたはサービスを起動してレスポンスを受信します。送信タスクおよび受信タスクは非同期的にプロセスおよびサービスを起動するために使用します。プロセスおよびサービスを同期的に起動する場合は、サービス・タスクを使用します。
注意:
送信タスクおよび受信タスクでは、メッセージ・スロー・イベントおよびメッセージ・キャッチ・イベントと同様の機能が実行されます。ただし、メッセージ開始イベントによって開始されるプロセスは、送信タスクを使用して起動できません。
図A-26は、送信タスクのデフォルトの表記を示しています。
プロセスまたはサービスを起動するための送信タスクの実装の詳細は、Oracle Business Process Management Studioによるビジネス・プロセスの開発の送信タスクおよび受信タスクを使用した、BPMNプロセスでの同期操作の定義に関する項を参照してください。
プロセス間で通信するための送信タスクおよび受信タスクの使用方法の詳細は、「送信タスクおよび受信タスクを使用した、プロセス間の通信」を参照してください。
送信タスクとは対照的に、受信タスクでは、現在のプロセス外部のシステムまたはプロセスからのメッセージを待機します。このメッセージを受信すると、タスクは完了し、プロセスの実行はプロセス・フロー内の次のタスクに移動します。
図A-27は、受信タスクのデフォルトの表記を示しています。
プロセスまたはサービスを起動するための送信タスクの実装の詳細は、Oracle Business Process Management Studioによるビジネス・プロセスの開発の送信タスクおよび受信タスクを使用した、BPMNプロセスでの同期操作の定義に関する項を参照してください。
プロセス間で通信するための送信タスクおよび受信タスクの使用方法の詳細は、「送信タスクおよび受信タスクを使用した、プロセス間の通信」を参照してください。
メッセージ・スロー・イベントを使用すると、他のプロセスまたはサービスにメッセージを送信できます。
図A-28は、メッセージ・スロー・イベントのデフォルトの表記を示しています。
次のタイプのプロセスおよびサービスを起動するには、メッセージ・スロー・イベントを使用します。
他のBPMNプロセス
BPELプロセス
SOAサービス・アダプタ
サービスとして公開されているメディエータ
プロセス・アナリストは、プロセスにメッセージ・スロー・イベントを追加して、プロセスから他のプロセスやサービスを呼び出す必要がある位置を定義できます。ただし、他のプロセスとの接続の実装は、通常はプロセス開発者が担当します。また、メッセージ・スロー・イベントによって起動されるサービスの作成および実装も、通常はプロセス開発者が担当します。
メッセージ・スロー・イベントの実装方法の詳細は、Oracle Business Process Management Studioによるビジネス・プロセスの開発のメッセージ・イベントを使用した、他のBPMNプロセスおよびサービスとの通信に関する項を参照してください。
多くの場合、メッセージ・スロー・イベントは、他のプロセスのメッセージ開始イベントを呼び出すことによって他のBPMNプロセスを起動するために使用します。詳細は、メッセージ開始イベントの概要を参照してください。
また、多くの場合、メッセージ・スロー・イベントは、起動したプロセスまたはサービスからレスポンスを受信するメッセージ・キャッチ・イベントとともに使用します。ただし、メッセージ・スロー・イベントは常に非同期的に使用されます。メッセージ・スロー・イベントから他のプロセスまたはサービスにメッセージが送信された後、トークンは即時にプロセスの次のフロー・オブジェクトに移動します。
プロセスで同期的にレスポンスを受信する場合は、サービス・タスクを使用してプロセスまたはサービスを起動します。詳細は、サービス・タスクの概要を参照してください。
注意:
送信タスクおよび受信タスクでは、メッセージ・スロー・イベントおよびメッセージ・キャッチ・イベントと同様の機能が実行されます。ただし、メッセージ受信タスクによって開始されるプロセスをメッセージ・スロー・イベントを使用して起動することはできません。
メッセージ・キャッチ中間イベントでは、別のプロセスまたはサービスからのメッセージを受信できます。
図A-29は、メッセージ・キャッチ・イベントのデフォルトの表記を示しています。
多くの場合、メッセージ・キャッチ・イベントは、他のBPMNプロセスと通信するためのメッセージ・スロー・イベントとともに使用されます。メッセージ・スロー・イベントとメッセージ・キャッチ・イベントを組み合せて使用する方法の詳細は、メッセージのスロー・イベントおよびキャッチ・イベントを使用した、プロセス間の通信を参照してください。
メッセージ・スロー・イベントの実装方法の詳細は、Oracle Business Process Management Studioによるビジネス・プロセスの開発のメッセージ・イベントを使用した、他のBPMNプロセスおよびサービスとの通信に関する項を参照してください。
この項では、ビジネス・ルール・タスクを使用してビジネス・プロセス内にOracle Business Rulesを取り込む方法について説明します。
Oracle Business Process Composerを使用したOracle Business Rulesの操作の詳細は、「Oracle Business Rulesの使用」を参照してください。
ビジネス・ルール・タスクでは、プロセス内にOracle Business Rulesを取り込むことができます。
図A-30は、ビジネス・ルール・タスクのデフォルトの表記を示しています。
ビジネス・プロセス内にOracle Business Rulesを取り込むユースケースは、主に2つあります。
構造ルールの使用
構造ルールを使用すると、ビジネス・プロセス内で使用される計算を実行できます。たとえば、信用度を計算するためにビジネス・ルールを使用できます。
運用ルールの使用
運用ルールは、プロセスのフローを変更するために使用します。運用ルールの典型的な使用方法として、ルール・カタログ内のルール条件のチェックの実行があります。その後、出力データ・アソシエーションの一部として、式を使用してデータ・オブジェクトに値を割り当てます。
このシナリオでは、ビジネス・ルール・タスクの直後にゲートウェイが配置されます。このゲートウェイは、データ・オブジェクトの値に従ってプロセス・パスを分岐するために使用されます。
運用ルールの使用方法の詳細は、「コンテキスト内のビジネス・ルール・タスク」を参照してください。
ビジネス・カタログの要素をビジネス・ルール・タスクに割り当てる手順の詳細は、「ビジネス・カタログ・コンポーネントをフロー・オブジェクトに割り当てる方法」を参照してください。
シーケンス・フローでは、プロセス内で作業が実行される順序(シーケンス)が定義されます。シーケンス・フローによって、プロセス内のフロー・オブジェクトが接続され、プロセス内でプロセス・トークンが移動するパスが特定されます。
この項では、シーケンス・フローを使用してビジネス・プロセスの動作を定義する方法を説明します。
受信シーケンス・フローは、フロー・オブジェクト内に移動するシーケンス・フローです。送信シーケンス・フローは、フロー・オブジェクトから外部に移動するプロセス・パスを特定するシーケンス・フローです。
多くのフロー・オブジェクトには、受信シーケンス・フローと送信シーケンス・フローの両方が含まれています。ただし、開始イベントと終了イベントは例外です。開始イベントには送信シーケンス・フローのみを含めることができます。終了イベントには受信シーケンス・フローのみ含めることができます。また、イベント・サブプロセスには、受信シーケンス・フローも送信シーケンス・フローも含まれません。
無条件シーケンス・フローは2つのフロー・オブジェクト間の典型的なパスです。デフォルトのシーケンス・フローは図A-32のように矢印線として表示されます。
ほとんどのフロー・オブジェクトでは、デフォルト送信シーケンス・フローを1つのみ使用できます。プロセスのパラレル・パスを表す複数の無条件シーケンス・フローを使用できるのは、パラレル・ゲートウェイのみです。
排他ゲートウェイ、包含ゲートウェイおよびConditional Gatewayには、無条件送信シーケンス・フローを使用できません。これらのゲートウェイでは、条件シーケンス・フローおよびデフォルト・シーケンス・フローを使用して、プロセスのフローを決定します。
条件シーケンス・フローは、特定の条件に基づいてプロセスのフローを制御するために使用します。無条件シーケンス・フローと同様に、条件シーケンス・フローは、矢印線として表示されます。
図A-33は、2つの送信条件シーケンス・フローと1つのデフォルト・シーケンス・フローを示しています。
送信条件シーケンス・フローを使用できないフロー・オブジェクトもあります。送信条件シーケンス・フローを使用できるのは、次のタイプのゲートウェイのみです。
排他ゲートウェイ
包含ゲートウェイ(スプリット)
条件シーケンス・フロー内で使用される条件は、式を使用して定義されます。式エディタを使用した式の定義の詳細は、「式を使用したデータのコントロール」を参照してください。
条件シーケンス・フローと同様に、デフォルト・シーケンス・フローは排他ゲートウェイ、包含ゲートウェイおよびConditional Gatewayへの送信シーケンス・フローとして使用されます。デフォルト・シーケンス・フローは、いずれの条件もtrueと評価されない場合に、プロセスがこれらのゲートウェイから脱出するパスを表します。
デフォルト・シーケンス・フローは、図A-33のように一方の端にチック・マークが付いた矢印として表示されます。
ゲートウェイはプロセスのフローを定義するフロー要素です。ゲートウェイはトークンがプロセスを辿るパスを指定します。ゲートウェイはパスの分割とマージによってプロセス内の制御ポイントを定義します。
この項では、ゲートウェイを使用してプロセスのフローおよび動作を制御する方法を説明します。
ゲートウェイはパスのスプリットとマージによってプロセス内の制御ポイントを定義します。プロセスのデフォルト・パスに対する例外または逸脱となるパスには、可能なかぎりゲートウェイを使用します。
次のゲートウェイには分割とマージのペアが必要です。
パラレル・ゲートウェイ
包含ゲートウェイ
複合ゲートウェイ
これらのゲートウェイのいずれかをBPMNプロセスに追加すると、Oracle BPM Studioは分割とマージのフロー・オブジェクトを自動的に作成します。
ゲートウェイのマージ部分は常に必要となりますが、必ずしも分割されたすべてのパスをマージ部分に戻す必要はありません。
ゲートウェイで分割されたプロセス・パスのうち、ゲートウェイでマージされないものがあってもかまいませんが、通常はお薦めしません。ゲートウェイのマージ動作の詳細は、後述の各ゲートウェイ・タイプの項を参照してください。
注意:
プロセスからマージ・ゲートウェイを削除すると、対応する分割ゲートウェイも削除されます。
Exclusive Gatewayでは、プロセスを複数のパスに分割できます。ただし、複数の送信シーケンス・フローが存在する場合でも、プロセスが経由するパスは、これらのパスのうちの1つのみです。排他ゲートウェイでは、条件送信シーケンス・フローを使用でき、少なくとも1つのデフォルト送信シーケンス・フローが必要です。
プロセスが条件シーケンス・フローを経由するかどうかを決定するために使用される式を定義できます。詳細は、「式を使用したデータのコントロール」を参照してください。
プロセスに排他ゲートウェイに対する複数の送信シーケンス・フローがある場合は、それらが評価される順序を定義できます。評価の順序は、排他ゲートウェイのプロパティで構成します。
複数の条件シーケンス・フローがtrueと評価される排他ゲートウェイがある場合、この順序に従って判断された最初の条件シーケンス・フローにプロセスが移動します。
排他ゲートウェイは、他のゲートウェイとは異なり、分割後、対応するマージをプロセス内に明示的に定義する必要はありません。
図A-34は、排他ゲートウェイのデフォルトの表記を示しています。
図A-35は、営業見積サンプル内で使用されている排他ゲートウェイの例を示しています。ここでは、排他ゲートウェイは、ビジネス実行のレビューが必要であるかどうかを評価するために使用されます。
この評価は、送信条件シーケンス・フローに定義された式によって決定されます。評価がtrueである場合、プロセス・フローは「はい」のパスを進みます。評価がfalseである場合、プロセス・フローは、デフォルト送信シーケンス・フローのパスを進みます。
トークンが排他ゲートウェイに到達すると、送信条件シーケンス・フローの1つがtrueに評価されるまで、送信条件シーケンス・フローが評価されます。排他ゲートウェイのプロパティを構成することによって、送信条件シーケンス・フローが評価される順序を定義できます。この構成に基づいて、最初の条件シーケンス・フローの評価がtrueである場合、トークンはこの送信シーケンス・フローに従って次のフロー・オブジェクトに移動します。複数の送信条件シーケンス・フローがある場合は、それらの評価順序を決定できます。trueと評価される送信条件シーケンス・フローが存在しない場合、トークンはデフォルト送信シーケンス・フローに従って移動します。したがって、排他ゲートウェイには、デフォルト送信シーケンス・フローを定義する必要があります。
排他ゲートウェイでは受信シーケンス・フローもマージできます。ただし、プロセス・フロー内の他のパスから受信する可能性がある他のトークンと同期されません。
注意:
他のトークンが排他ゲートウェイのマージに到達した場合、そのトークンもそのまま次のフロー・オブジェクトに渡されます。トークンを同期する場合や、受信シーケンス・フローで評価を実行する場合は、別のタイプのゲートウェイを使用する必要があります。
Inclusive Gatewayでは、プロセスを複数のパスに分割できます。ただし、排他ゲートウェイとは異なり、送信条件シーケンス・フローの評価結果に応じて、トークンは1つ以上のパスに移動する場合があります。
包含ゲートウェイの分割には、少なくとも1つのデフォルト・シーケンス・フローを定義する必要があります。包含ゲートウェイのスプリットには、複数の送信条件シーケンス・フローを指定できます。トークンは、trueと評価されたシーケンス・フローのみに沿って進みます。いずれのシーケンス・フローもtrueと評価されていない場合、トークンはデフォルト・シーケンス・フローに沿って進みます。
図A-36は、包含ゲートウェイのスプリットのデフォルトの表記を示しています。
図A-37は、包含ゲートウェイのマージのデフォルトの表記を示しています。
包含ゲートウェイでは、排他ゲートウェイと同様にプロセスがスプリットされますが、トークンが複数の送信シーケンス・フローを進むことができる点が異なります。トークンが包含ゲートウェイに到達すると、包含ゲートウェイの条件シーケンス・フローの式が評価されます。
次に、trueと評価された各条件シーケンス・フローに対してトークンが生成されます。trueと評価された条件シーケンス・フローがない場合のみ、デフォルトのシーケンス・フローに対してトークンが生成されます。
これらのトークンは、包含ゲートウェイのマージで結合されます。トークンがマージ・ゲートウェイに到達すると、分割によって生成されたすべてのトークンがマージに到達するまで待機します。すべてのトークンが包含ゲートウェイのマージに到達すると、マージが完了して、トークンはゲートウェイに続く次のシーケンス・フローに移動します。
Parallel Gatewayでは、プロセスを複数のパスに分割すると、プロセス・フローがすべてのパス上を同時に移動できます。パラレル・ゲートウェイは、プロセスで複数のタスクをパラレルに実行する必要がある場合に便利です。
図A-38は、パラレル・ゲートウェイのスプリットのデフォルトの表記を示しています。
図A-39は、パラレル・ゲートウェイのマージのデフォルトの表記を示しています。
営業見積のサンプルでは、プロセスの承認ステージでパラレル・ゲートウェイを使用しています。図A-40に、パラレル・ゲートウェイを使用して2つのプロセス・パスを同時に実行する方法を示します。
この例では、2つの異なるプロセス・パスが同時に実行されます。
トークンがパラレル・ゲートウェイに到達すると、パラレル・ゲートウェイでは各送信シーケンス・フローのトークンが作成されます。パラレル・ゲートウェイの分割では、送信シーケンス・フローは評価されません。
パラレル・ゲートウェイを使用して、パラレル・ゲートウェイによって分割されたプロセス・パスをマージすることもできます。パラレル・ゲートウェイのマージでは、各受信シーケンス・フローからのトークンの到着が待機されます。すべてのトークンが到着すると、1つのトークンのみが送信シーケンス・フローに渡されます。
注意:
パラレル・ゲートウェイのマージの各受信シーケンス・フローにトークンが到着するようにプロセスを設計してください。このように設計しないと、到着しないトークンをマージで待機し続け、プロセスがフリーズする可能性があります。
複合ゲートウェイでは、包含ゲートウェイと同様にプロセスが分割されます。ただし、複合ゲートウェイのマージにすべてのトークンが到着しない場合でもインスタンスを続行できるアクティブ化条件を定義できます。
たとえば、2つ以上のトークンが到着した後に続行する、複合ゲートウェイを構成できます。包含ゲートウェイの条件のうち2つのみがtrueと評価されると、プロセス・インスタンスは次のアクティビティに進みます。ただし、包含ゲートウェイではすべての条件シーケンス・フローが即時に評価されるため、これらのプロセス・パスのすべてのフロー・オブジェクトもすべて実行されます。
図A-41は、複合ゲートウェイのスプリットのデフォルトの表記を示しています。
図A-42は、複合ゲートウェイのマージのデフォルトの表記を示しています。
イベント・ベース・ゲートウェイを使用すると、イベントが発生する可能性に基づいてプロセス・フローを分岐できます。これは、コンテキストに応じて、様々なイベント・タイプの1つになります。
イベント・ベース・ゲートウェイでは、様々なタイプのイベントがプロセス内の特定の位置で発生する可能性を予想できます。これは排他ゲートウェイに類似していますが、式に基づいてパスを選択するのではなく、イベント・ベース・ゲートウェイではプロセス内でのイベントの発生に基づいてパスを選択します。
たとえば、注文処理プロセスでは、現在使用可能な在庫がない場合にプロセス内のある位置に移動できます。プロセスは、在庫が使用可能になるまで待機する必要がありますが、無限に待機することはできません。イベント・ベース・ゲートウェイを使用すると、プロセスは、(メッセージ・キャッチ・イベントを使用して)新しい在庫の到着を知らせるメッセージを待機したり、(タイマー・イベントを使用して)一定時間の経過後にメッセージを受信しない場合に処理を続行することができます。
図A-43は、イベント・ベース・ゲートウェイのデフォルトの表記を示しています。
イベント・ベース・ゲートウェイは、プロセス・フローに関する決定がデータ固有の条件ではなく、イベントに基づいている点が他のゲートウェイと異なります。
イベント・ベース・ゲートウェイは、次の要素から構成されます。
イベントベース・ゲートウェイ
2つ以上のターゲット・イベント
これらのイベントには、次のタイプがあります。
メッセージ・キャッチ・イベント
メッセージ・キャッチ・イベントを使用してプロセスを開始する場合は、メッセージ・スロー・イベントを使用してプロセスを起動する必要があります。
タイマー・キャッチ・イベント
一般に、イベント・ベース・ゲートウェイに付随して単一のタイマー・イベントのみが使用されます。
受信タスク
イベント・ベース・ゲートウェイに付随して受信タスクを使用し、プロセス・インスタンスを開始できます。ただし、プロセスは、コール側プロセス内の送信タスクから起動する必要があります。
注意:
同じイベント・ベース・ゲートウェイ内にメッセージ・イベントと受信タスクを混在させることはできません。
ターゲット要素には、イベント・ベース・ゲートウェイからの受信シーケンス・フローのみを含めることができます。プロセスの他の部分からのシーケンス・フローを含めることはできません。イベント・ベース・ゲートウェイでは、プロセスにおいて発生する可能性のあるイベントを複数設定できますが、プロセス・インスタンス内でトリガーされるのは1つのイベントのみです。イベント・ベース・ゲートウェイで最初のイベントがトリガーされると、そのイベントに続くパスが使用されます。
プロセスにイベント・ベース・ゲートウェイを追加すると、デフォルトでタイマー・キャッチ・イベントおよびメッセージ・キャッチ・イベントも作成されます。
注意:
イベント・ベース・ゲートウェイを削除すると、すべての送信シーケンス・フローも削除されます。関連付けられたイベントは削除されません。
プロセスの最初でイベント・ベース・ゲートウェイを使用して新しいプロセス・インスタンスを作成することもできます。これはプロセス内に複数の開始イベントを保持するのと同じです。
イベント・ベース・ゲートウェイを使用可能にして新しいプロセス・インスタンスを作成するには、次のことを確認する必要があります。
イベント・ベース・ゲートウェイのInitiateプロパティが有効であること。
イベント・ベース・ゲートウェイへの受信シーケンス・フローがないこと。
イベント・ベース・ゲートウェイは、新しいプロセス・インスタンスの作成に使用できますが、別のプロセスからのデータ入力は受け入れません。プロセス・インスタンスに渡す必要があるデータは、ターゲット・イベントを使用して構成する必要があります。
開始イベントおよび停止イベントとは異なり、中間イベントはプロセス・フローの最中に発生します。
この項では、中間イベント、および中間イベントを使用してプロセスのフローおよび動作を制御する方法について説明します。
中間イベントには次の2つのタイプがあります。
標準フロー・イベント
標準フロー・イベントは、プロセスの一般的なフローで発生します。
境界イベント
境界イベントは、プロセスの中断をトリガーします。境界イベントはフロー・オブジェクトに関連付けられており、これらのオブジェクトの通常の動作を中断するように構成できます。
境界イベントは、プロセスが経由するフロー・オブジェクトのパスを特定するために使用されるという点で、シーケンス・フローと同様に動作します。
境界イベントは、連続しないタイプおよび連続するタイプの2つのタイプに分類されます。
タイマー捕捉イベントを使用すると、時間条件を使用してプロセスのフローを制御できます。次に、タイマー・キャッチ・イベントの使用例を示します。
アクティビティ実行の前に遅延を作成する
アクティビティの期限を構成する
プロセスの期限を構成する
一定時間経過後に追加のアクティビティをトリガーする
図A-44は、タイマー・キャッチ・イベントのデフォルトの表記を示しています。
タイマー・イベントは、アクティビティの境界イベントとして使用できます。タイマー・イベントは、連続しない境界イベントまたは連続する境界イベントとして定義できます。
連続しないタイマー・イベントが発生した場合、トークンはメイン・プロセス・フローを離れて、タイマー・イベントによって定義されたフローを進みます。連続しないタイマー・イベントによって定義されたフローは、メイン・プロセス・フローに直接戻ることができます。
連続するイベントが発生した場合は、トークンのコピーが作成され、タイマー・イベントによって定義されたフローに渡されます。連続するイベントによって定義されたフローからメイン・プロセス・フローに戻ることはできません。
エラー・キャッチ・イベントは、プロセス・フロー内で発生したエラーを処理するために使用される中間イベントです。
注意:
インライン・ハンドラを使用して、プロセス内で発生するエラー状態に対応することもできます。
エラー・キャッチ・イベントは、常に境界イベントとして使用され、次のタスクやサブプロセスに添付できます。
サービス・タスク
コール・アクティビティ
ユーザー・タスク
送信タスク
受信タスク
スクリプト・タスク
ルール・タスク
サブプロセス
エラー・キャッチ・イベントは常に割込みを実行します。つまり、このイベントによって、プロセスの通常のフローが中断されます。
図A-45は、サービス・タスクに境界イベントとしてアタッチされたエラー・キャッチ・イベントのデフォルトの表記を示しています。
サービスまたはプロセスでエラーが発生すると、エラー・キャッチ・イベントがトリガーされます。これにより、プロセス・フローはエラー・キャッチ・イベントの送信シーケンス・フローのパスに進みます。
このフローを使用して、エラーの処理方法を定義できます。エラーは、次の2通りの方法のいずれかで処理されます。
プロセス・フローが、メイン・プロセス・フローに戻ります。
実行する必要があるすべての作業は、メイン・フローに戻る前にエラー・プロセス・フロー内で処理されます。
注意:
連続する境界イベントの場合、境界フローはメイン・フローに戻ることはできません。
プロセス・フローは終了イベントに移動します。
プロセスは即時に停止されます。プロセスの制御は、そのプロセスを開始したサービスまたはプロセスに戻ります。
サブプロセスを使用して、ビジネス・プロセスを整理できます。サブプロセスによって、プロセスの機能領域をグループ化してプロセスをさらにわかりやすくできます。
Oracle BPMでは、次のタイプのサブプロセスがサポートされています。
再使用可能なプロセス
埋込み(インラインとも呼ばれる)サブプロセス
イベント・サブプロセス(インライン・ハンドラとも呼ばれる)
Oracle BPMでは、再使用可能なプロセスというプロセス・タイプをサポートしています。BPMN用語では、再使用可能なサブプロセスと呼ばれることもあります。再使用可能なプロセスを使用すると、別のBPMNプロセスからコールできるプロセスを作成できます。
再使用可能なプロセスを使用すると、別のBPMNプロセスからコールできるプロセスを作成できます。たとえば、すべてのプロセスにクレジット・カード払いが必要な場合は、再使用可能なクレジット・カード払いのサブプロセスを作成できます。
再使用可能なプロセスには、次の特性があります。
単一のNone開始イベントで開始する必要があります。
複数の終了イベントを含めることができます。
コールできるのは、別のBPMNプロセスのみです。
埋込みサブプロセスを使用すると、BPMNフロー・オブジェクトをグループ化して、プロセスをさらにわかりやすくできます。Oracle BPMでは、サブプロセスは埋込みのサブプロセスとなります。サブプロセスは、親サブプロセスの一部として包含されます。埋込みサブプロセスは、Noneイベントの開始で始まり、None終了イベントで終わる必要があります。
埋込みサブプロセスは拡張または縮小できます。図A-46は、プロセス内の縮小されたサブプロセスの表示を示しています。
図A-47は、プロセス内の拡張された埋込みサブプロセスの表示を示しています。埋込みサブプロセスを拡張すると、サブプロセス内のフロー・オブジェクトを編集できます。また、埋込みサブプロセス・ウィンドウの端をクリックしてドラッグすると、ウィンドウのサイズを変更できます。
他のタイプのプロセスと同様に、埋込みサブプロセスは開始イベントと終了イベントを持つことができ、別のプロセス・フローを含めることができます。埋込みサブプロセスは、None開始イベントで始まり、None終了イベントで終わる必要があります。埋込みサブプロセスにスイムレーンを含めることはできません。
また、埋込みサブプロセスはアクティビティと同様に動作します。受信シーケンス・フローおよび送信シーケンス・フローを使用できます。また、埋込みサブプロセス内で使用されるデータ・オブジェクトを定義するデータ・アソシエーションが含まれています。
埋込みサブプロセスには、タイマー境界イベント、メッセージ境界イベントおよびエラー境界イベントを含めることもできます。
必要に応じて、プロセスにはネストした埋込みサブプロセスを含めることができます。ただし、ネストした埋込みサブプロセスは、プロセスをわかりやすくするために必要な場合にのみ使用してください。
埋込みサブプロセス内のフロー・オブジェクトには、サブプロセス外部のフロー・オブジェクトに接続するシーケンス・フローを含めることができません。
他のフロー・オブジェクトと同様に、埋込みサブプロセスには、受信シーケンス・フローおよび送信シーケンス・フローがあります。
図A-48は、埋込みサブプロセスの例を示しています。この例では、埋込みサブプロセスは、営業見積の処理に使用されるサービス・タスクをグループ化するために使用されています。
イベント・サブプロセスはサブプロセスの1タイプで、通常のプロセス・フローの外部で発生しうる条件をモデル化できます。イベント・サブプロセスは、イベント・ハンドラとも呼ばれます。
イベント・サブプロセスは、次の開始イベントがあります。
エラー開始
タイマー開始
メッセージ開始
インライン・ハンドラをプロセスに追加すると、デフォルトでは、メッセージ開始イベントで作成されます。開始イベントのタイプは、必要に応じて変更できます。
注意:
一連のインライン・ハンドラには、1つの開始イベントのみを使用できます。ただし、プロセス内では複数のインライン・ハンドラを使用できます。
この項では、スクリプト・タスクを使用してプロセス内のデータ・オブジェクトの値を変更する方法について説明します。
データ・オブジェクトの一般情報は、「データ・オブジェクトおよびデータ・アソシエーションの使用」を参照してください。
スクリプト・タスクは、プロセス内のデータ・オブジェクトの値を変更するために使用します。スクリプト・タスクは、値の変更をビジネス・プロセス内で明示的に表示する場合、または別のフロー・オブジェクトの外部でデータ・オブジェクトの値を変更する場合に使用します。多くの場合、スクリプト・タスクは、プロセス開始時にデータ・オブジェクトの初期値を設定するために使用します。
図A-49は、スクリプト・タスクのデフォルトの表記を示しています。
スクリプト・タスクは、プロセスおよびプロセスベースのアプリケーション内におけるデータ・オブジェクトの動作の定義を担当する、プロセス開発者がプロセスに追加します。
図A-50は、営業見積サンプルの開始時に使用される2つのスクリプト・タスクの例を示しています。営業見積サンプルでは、プロセス・インスタンスの作成時にデータ・オブジェクトに対して初期値を設定し、いくつかのビジネス・インジケータに値を設定するスクリプト・タスクが使用されています。
プロジェクト・データ・オブジェクトは、プロジェクト内に定義するデータ・オブジェクトです。プロジェクト内のすべてのプロセスは、定義されているデータ・オブジェクトにアクセスしますが、実際の値はオブジェクトを使用するプロセスに応じて変化します。また、プロジェクトがビジネス・インジケータを使用するように構成されている場合には、ビジネス・インジケータとしてマークされたデータ・オブジェクトの値が、エンジンによってプロセス分析データベースに保存されます。
図A-51は、ビジネス・インジケータの初期値を設定するために使用されるデータ・アソシエーションを示しています。
図A-51 ビジネス・インジケータの設定スクリプト・タスクによって使用されるデータ・アソシエーション
データ・アソシエーションを受け入れる他のフロー・オブジェクトと同様に、式を使用してデータ・オブジェクトの値を変更できます。図A-52は、割引プロジェクト変数の値を変更する場合の式の使用方法を示しています。
注意:
BPM Studioを使用した変換を使用してスクリプト・タスクを実装した場合、それらのスクリプト・タスクは、Oracle Business Process ComposerでBPMプロジェクトを開く際には表示されません。