66.2. ランタイムマネージャー
					RuntimeManager クラスは、プロセスエンジン API でレイヤーを提供し、その使用方法を単純化し、強化します。このクラスは、KIE ベースおよび KIE セッションと、プロセス内のすべてのタスクにハンドラーを提供するタスクサービスをカプセル化および管理します。ランタイムマネージャーの KIE セッションとタスクサービスが相互に機能するように設定されているため、このような設定を指定する必要はありません。たとえば、ヒューマンタスクハンドラーを登録し、必要なサービスに接続されていることを確認する必要はありません。
				
ランタイムマネージャーは、事前定義されたストラテジーに従って KIE セッションを管理します。以下のストラテジーを利用できます。
- 
							シングルトン: ランタイムマネージャーは単一の KieSessionを維持し、要求されたすべてのプロセスに使用します。
- 
							リクエストごと: ランタイムマネージャーはリクエストごとに新しい KieSessionを作成します。
- 
							プロセスインスタンスごと: ランタイムマネージャーはプロセスインスタンスと KieSessionの間のマッピングを維持し、指定のプロセスインスタンスを使用するたびに常に同じKieSessionを提供します。
					ストラテジーに関係なく、RuntimeManager クラスはプロセスエンジンコンポーネントの初期化と設定で同じ機能を保証します。
				
- 
							KieSessionインスタンスは同じファクトリーで読み込まれます (メモリーまたは JPA ベース)。
- 
							ワークアイテムハンドラーは、すべての KieSessionインスタンスに登録されます (データベースから読み込むか、新規に作成されているかのいずれか)。
- 
							イベントリスナー (Process、Agenda、WorkingMemory) は、データベースからセッションが読み込まれるか、新たに作成されるかに関係なく、すべての KIE セッションに登録されます。
- タスクサービスは、以下の必須コンポーネントで設定されます。 - JTA トランザクションマネージャー
- 
									KieSessionインスタンスに使用されるものと同じエンティティーマネージャーファクトリー
- 
									環境で設定できる UserGroupCallbackインスタンス
 
					ランタイムマネージャーは、プロセスエンジンを正常に破棄することもできます。これは、必要がなくなった場合に RuntimeEngine インスタンスを破棄する専用のメソッドを提供し、取得した可能性のあるリソースを解放します。
				
					以下のコードは、RuntimeManager インターフェイスの定義を示しています。
				
RuntimeManager インターフェイスの定義
					RuntimeManager クラスは、基礎となるプロセスエンジンコンポーネントへのアクセスを取得するメソッドが含まれる RuntimeEngine クラスも提供します。
				
RuntimeEngine インターフェイスの定義
						RuntimeManager クラスの識別子は、ランタイムの実行中に deploymentId として使用されます。たとえば、識別子は、Task が永続化される Task の deploymentId として永続化されています。Task の deploymentID は、Task が完了してプロセスインスタンスを再開する際に、これを RuntimeManager に関連付けます。
					
						同じ deploymentId も履歴ログテーブルの externalId として永続化されます。
					
						RuntimeManager インスタンスの作成時に識別子を指定しない場合は、ストラテジーに応じてデフォルト値が適用されます (例: PerProcessInstanceRuntimeManager の default-per-pinstance)。つまり、アプリケーションはライフサイクル全体で RuntimeManager クラスと同じデプロイメントを使用することを意味します。
					
						アプリケーションで複数のランタイムマネージャーを維持する場合は、すべての RuntimeManager インスタンスに一意の ID を指定する必要があります。
					
たとえば、デプロイメントサービスは複数のランタイムマネージャーを維持し、KJAR ファイルの GAV 値を識別子として使用します。Business Central と KIE Server でも、デプロイメントサービスに依存するため、同じロジックが使用されます。
						ハンドラーまたはリスナー内からプロセスエンジンまたはタスクサービスと対話する必要がある場合は、RuntimeManager インターフェイスを使用して、指定のプロセスインスタンスの RuntimeEngine インスタンスを取得し、RuntimeEngine インスタンスを使用して KieSession インスタンスまたは TaskService インスタンスを取得します。このアプローチにより、選択したストラテジーに従って管理されるエンジンの正常な状態が維持されます。
					
66.2.1. ランタイムマネージャーストラテジー
						RuntimeManager クラスは、KIE セッションを管理するための以下のストラテジーをサポートします。
					
- シングルトンストラテジー
- このストラテジーは、単一の - RuntimeEngineインスタンスを維持するようにランタイムマネージャーに指示します (これにより、単一の- KieSessionインスタンスおよび- TaskServiceインスタンス)。ランタイムエンジンへのアクセスは同期されるためスレッドセーフになりますが、同期によりパフォーマンスの低下が発生します。- このストラテジーは、簡単なユースケースに使用します。 - このストラテジーには以下の特徴があります。 - ランタイムエンジンのインスタンスおよびタスクサービスが 1 つのインスタンスを持つメモリーフットプリントは小さくなります。
- 設計と使用はシンプルでコンパクトです。
- アクセスが同期されているため、プロセスエンジンの低から中程度の負荷に適しています。
- 
											このストラテジーでは、単一の KieSessionインスタンスが原因で、(ファクトなど) すべての状態オブジェクトがすべてのプロセスインスタンスに直接表示され、その逆も同様です。
- 
											ストラテジーはコンテキストではありません。シングルトン RuntimeManagerからRuntimeEngineのインスタンスを取得する場合は、Contextインスタンスを考慮する必要はありません。通常は、EmptyContext.get()をコンテキストとして使用できますが、null 引数も受け入れ可能です。
- このストラテジーでは、ランタイムマネージャーは - KieSessionの ID を追跡するため、- RuntimeManagerの再起動後も同じセッションが使用されたままになります。ID はファイルシステムの一時的な場所にシリアライズファイルとして保存され、環境によっては以下のディレクトリーのいずれかになります。- 
													jbpm.data.dirシステムプロパティーの値
- 
													jboss.server.data.dirシステムプロパティーの値
- 
													java.io.tmpdirシステムプロパティーの値
 
- 
													
 警告- Singleton ストラテジーと EJB Timer スケジューラーの組み合わせにより、負荷がかかった状態で Hibernate の問題が発生する可能性があります。この組み合わせは、実稼働アプリケーションで使用しないでください。EJB Timer スケジューラーは、KIE Server のデフォルトスケジューラーです。 
- リクエスト別のストラテジー
- このストラテジーは、ランタイムマネージャーに対し、リクエストごとに - RuntimeEngineの新しいインスタンスを提供するように指示します。1 つのトランザクション内でのプロセスエンジンを 1 つ以上呼び出すことは、1 つのリクエストとみなされます。- 状態が正確になるように、単一のトランザクション内で - RuntimeEngineの同じインスタンスを使用する必要があります。それ以外の場合は、1 つの呼び出しで完了した操作が次の呼び出しで表示されません。- プロセスの状態は要求内でのみ保持されるため、このストラテジーはステートレスです。要求が完了すると、 - RuntimeEngineインスタンスは永続的に破棄されます。永続性を使用する場合は、KIE セッションに関連する情報は永続データベースから削除されます。- このストラテジーには以下の特徴があります。 - すべてのリクエストに対して完全に分離されたプロセスエンジンとタスクサービス操作を提供します。
- ファクトは要求期間中のみ保存されるため、完全にステートレスになります。
- これは、高負荷のステートレスプロセスに適しています。この場合、リクエスト間でファクトやタイマーを保持する必要はありません。
- このストラテジーでは、KIE セッションは要求のライフサイクル中にのみ利用でき、要求の最後に破棄されます。
- 
											ストラテジーはコンテキストではありません。リクエストごとの RuntimeManagerからRuntimeEngineのインスタンスを取得する場合は、Contextインスタンスを考慮する必要はありません。通常は、EmptyContext.get()をコンテキストとして使用できますが、null 引数も受け入れ可能です。
 
- プロセスインスタンスごとのストラテジー
- このストラテジーは、KIE セッションとプロセスインスタンス間の厳密な関係を維持するように - RuntimeManagerに指示します。各- KieSessionは、それが属する- ProcessInstanceがアクティブである限り利用できます。- このストラテジーは、ルール評価やプロセスインスタンス間の分離など、プロセスエンジンの高度な機能を使用する最も柔軟なアプローチを提供します。これにより、パフォーマンスを最大化し、同期によって生じる潜在的なボトルネックを減らします。同時に、要求ストラテジーとは異なり、KIE セッションの数は、要求の合計数ではなく、実際のプロセスインスタンス数に減らされます。 - このストラテジーには以下の特徴があります。 - すべてのプロセスインスタンスに分離を提供します。
- 
											これは、KieSessionとProcessInstanceの間の厳密な関係を維持し、指定のProcessInstanceに常に同じKieSessionを提供するようにします。
- 
											これは、KieSessionのライフサイクルをProcessInstanceにマージし、プロセスインスタンスの完了時または中止時に両方破棄されます。
- これにより、プロセスインスタンスの範囲内でファクトやタイマーなどのデータのメンテナーンスが可能になります。プロセスインスタンスのみがデータにアクセスできます。
- 
											プロセスインスタンスの KieSessionを検索して読み込む必要があるため、オーバーヘッドが発生します。
- 
											KieSessionの使用状況をすべて検証し、他のプロセスインスタンスには使用できません。別のプロセスインスタンスが同じKieSessionを使用する場合は、例外が発生します。
- ストラテジーはコンテキストであり、以下のコンテキストインスタンスを許可します。 - 
													EmptyContextまたは null: プロセスインスタンス ID が利用できないため、プロセスインスタンスを開始するときに使用
- 
													ProcessInstanceIdContext: プロセスインスタンスの作成後に使用します。
- 
													CorrelationKeyContext:ProcessInstanceIdContextの代わりに、プロセスインスタンス ID の代わりにカスタム (business) キーを使用します。
 
- 
													
 
66.2.2. ランタイムマネージャーの典型的な使用シナリオ
ランタイムマネージャーの典型的な使用シナリオは、以下の段階で設定されます。
- アプリケーションの起動時に、以下の段階を完了します。 - 
										RuntimeManagerインスタンスをビルドし、アプリケーションの有効期間全体を維持します。これはスレッドセーフで、同時にアクセスできます。
 
- 
										
- 要求時に、以下のステージを完了します。 - 
										RuntimeManagerクラスに設定したストラテジーによって決定される適切なコンテキストインスタンスを使用して、RuntimeManagerからRuntimeEngineを取得します。
- 
										RuntimeEngineからKieSessionオブジェクトおよびTaskServiceオブジェクトを取得します。
- 
										startProcess、completeTaskなどの操作には、KieSessionオブジェクトおよびTaskServiceオブジェクトを使用します。
- 
										処理が完了したら、RuntimeManager.disposeRuntimeEngineメソッドを使用してRuntimeEngineを破棄します。
 
- 
										
- アプリケーションのシャットダウン時に、以下の段階を完了します。 - 
										RuntimeManagerインスタンスを閉じます。
 
- 
										
							アクティブな JTA トランザクションで RuntimeManager から RuntimeEngine を取得した場合は、トランザクションの完了時に、(完了ステータスが commit または rollback に関わらず) RuntimeManager が自動的に RuntimeEngine を破棄するため、最後に RuntimeEngine を破棄する必要はありません。
						
						以下の例は、RuntimeManager インスタンスをビルドし、そこから (KieSession クラスおよび TaskService クラスをカプセル化する) RuntimeEngine インスタンスを取得する方法を示しています 。
					
RuntimeManager インスタンスをビルドして、RuntimeEngine および KieSession を取得します。
						この例では、RuntimeManager クラスおよび RuntimeEngine クラスを使用する最も簡単な、または最小限の方法を提供します。これには、以下の特徴があります。
					
- 
								KieSessionインスタンスは、newDefaultInMemoryBuilderビルダーを使用してメモリーに作成されます。
- アセットとして追加される 1 つのプロセスが実行に利用できます。
- 
								TaskServiceクラスはLocalHTWorkItemHandlerインターフェイスを介して設定されてKieSessionインスタンスに割り当てられ、プロセス内でユーザータスク機能をサポートします。
66.2.3. ランタイム環境設定オブジェクト
						RuntimeManager クラスは、ハンドラーの作成、破棄、登録など、内部プロセスエンジンの複雑さをカプセル化します。
					
						また、プロセスエンジンの設定を詳細に制御することもできます。この設定を設定するには、RuntimeEnvironment オブジェクトを作成してから、RuntimeManager オブジェクトを作成する必要があります。
					
						次の定義は、RuntimeEnvironment インターフェイスで利用可能なメソッドを示しています。
					
RuntimeEnvironment インターフェイスのメソッド
66.2.4. ランタイム環境ビルダー
						必要なデータが含まれる RuntimeEnvironment のインスタンスを作成するには、RuntimeEnvironmentBuilder クラスを使用します。このクラスは Fluent API を提供し、事前定義された設定で RuntimeEnvironment インスタンスを設定します。
					
						次の定義は、RuntimeEnvironmentBuilder インターフェイスのメソッドを示しています。
					
RuntimeEnvironmentBuilder インターフェイスのメソッド
						RuntimeEnvironmentBuilderFactory クラスを使用して RuntimeEnvironmentBuilder のインスタンスを取得します。設定のない空のインスタンスとともに、ランタイムマネージャーの設定オプションがいくつか事前設定されたビルダーを取得できます。
					
						次の定義は、RuntimeEnvironmentBuilderFactory インターフェイスのメソッドを示しています。
					
RuntimeEnvironmentBuilderFactory インターフェイスのメソッド
						ランタイムマネージャーは、KIE セッションと通信するように設定された RuntimeEngine オブジェクトの統合コンポーネントとして TaskService オブジェクトへのアクセスも提供します。デフォルトビルダーのいずれかを使用する場合は、タスクサービスの以下の設定が表示されます。
					
- 
								永続ユニット名は org.jbpm.persistence.jpa(プロセスエンジンとタスクサービスの両方) に設定されます。
- ヒューマンタスクハンドラーは KIE セッションに登録されます。
- JPA ベースの履歴ログイベントリスナーは KIE セッションに登録されます。
- 
								ルールタスク評価をトリガーするイベントリスナー (fireAllRules) が KIE セッションに登録されます。
66.2.5. ランタイムエンジンのハンドラーおよびリスナーの登録
ランタイムマネージャー API を使用する場合、ランタイムエンジンオブジェクトはプロセスエンジンを表します。
						独自のハンドラーまたはリスナーを使用してランタイムエンジンを拡張するには、RegisterableItemsFactory インターフェイスを実装し、RuntimeEnvironmentBuilder.registerableItemsFactory() メソッドを使用してランタイム環境に追加します。次に、ランタイムマネージャーは、ハンドラーまたはリスナーを、作成するすべてのランタイムエンジンに自動的に追加します。
					
						以下の定義は、RegisterableItemsFactory インターフェイスのメソッドを示しています。
					
RegisterableItemsFactory インターフェイスのメソッド
						プロセスエンジンは、RegisterableItemsFactory のデフォルト実装を提供します。これらの実装を拡張して、カスタムハンドラーおよびリスナーを定義できます。
					
利用可能な実装は役に立ちます。
- 
								org.jbpm.runtime.manager.impl.SimpleRegisterableItemsFactory: 最も単純な実装。事前定義されたコンテンツがなく、リフレクションを使用して指定のクラス名に基づいてハンドラーおよびリスナーのインスタンスを生成します。
- 
								org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory: Simple 実装の拡張。この拡張により、デフォルトのランタイム環境ビルダーと同じデフォルトが導入され、引き続き Simple 実装と同じ機能を提供します。
- 
								org.jbpm.runtime.manager.impl.cdi.InjectableRegisterableItemsFactory: CDI 環境向けに調整され、プロデューサーを使用してハンドラーとリスナーを検索する CDI スタイルのアプローチを提供するデフォルト実装の拡張。
66.2.5.1. ファイルを使用したワークアイテムハンドラーの登録
							CustomWorkItem.conf ファイルでファイルを定義し、クラスパスにファイルを配置して、ステートレスまたは KieSession の状態に依存する簡単なワークアイテムハンドラーを登録することができます。
						
手順
- 
									クラスパスのルートの META-INFサブディレクトリーにdrools.session.confという名前のファイルを作成します。Web アプリケーションの場合、ディレクトリーはWEB-INF/classes/META-INFになります。
- 以下の行を - drools.session.confファイルに追加します。- drools.workItemHandlers = CustomWorkItemHandlers.conf - drools.workItemHandlers = CustomWorkItemHandlers.conf- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
									同じディレクトリーに CustomWorkItemHandlers.confという名前のファイルを作成します。
- CustomWorkItemHandlers.confファイルで、以下の例のように MVEL スタイルを使用してカスタムのワークアイテムハンドラーを定義します。- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
結果
リストしたワークアイテムハンドラーは、アプリケーションがランタイムマネージャー API を使用しているかどうかに関係なく、アプリケーションによって作成されたすべての KIE セッションに登録されます。
66.2.5.2. CDI 環境におけるハンドラーおよびリスナーの登録
アプリケーションがランタイムマネージャー API を使用して、CDI 環境で実行される場合、クラスは専用のプロデューサーインターフェイスを実装し、カスタムワークアイテムハンドラーおよびイベントリスナーをすべてのランタイムエンジンに提供できます。
							ワークアイテムハンドラーを作成するには、WorkItemHandlerProducer インターフェイスを実装する必要があります。
						
WorkItemHandlerProducer インターフェイスの定義
							イベントリスナーを作成するには、EventListenerProducer インターフェイスを実装する必要があります。イベントリスナープロデューサーに適切な修飾子にアノテーションを付け、提供されるリスナーのタイプを示します。以下のアノテーションのいずれかを使用します。
						
- 
									ProcessEventListenerの@Process
- 
									AgendaEventListenerの@Agenda
- 
									WorkingMemoryEventListenerの場合は@WorkingMemory
EventListenerProducer インターフェイスの定義
							META-INF サブディレクトリーに beans.xml を追加し、これらのインターフェイスの実装を Bean アーカイブとしてパッケージ化します。アプリケーションクラスパスに Bean アーカイブを配置します (例: Web アプリケーションの WEB-INF/lib)。CDI ベースのランタイムマネージャーはパッケージを検出し、データストアから作成または読み込みを行うすべての KieSession でワークアイテムハンドラーおよびイベントリスナーを登録します。
						
プロセスエンジンは、ステートフルで高度な操作を有効にするために、特定のパラメーターをプロデューサーに提供します。たとえば、ハンドラーまたはリスナーはパラメーターを使用して、エラーが発生した場合にプロセスエンジンまたはプロセスインスタンスに通知できます。プロセスエンジンは、以下のコンポーネントをパラメーターとして提供します。
- 
									KieSession
- 
									TaskService
- 
									RuntimeManager
							さらに、RuntimeManager クラスインスタンスの識別子はパラメーターとして提供されます。フィルターを識別子に適用して、この RuntimeManager インスタンスがハンドラーとリスナーを受け取るかどうかを決定することができます。