コラボレーションが処理できる例外には 2 つのカテゴリーがあります。
ビジネス・プロセス例外は、コラボレーション API メソッドを使用するコードから発生します。
例えば、シナリオでビジネス・オブジェクト属性の値を設定し、コネクターにサービス呼び出し要求を送信する場合などで、ビジネス・プロセス例外が発生することがあります。
特定のサービス呼び出し例外の処理方法の詳細については、特定のサービス呼び出し例外の処理を参照してください。
Java 例外は、ネイティブな Java メソッドを使用する開発者自身のコードが原因で発生します。このような例外が発生すると、例外タイプが JavaException で、その例外サブタイプに特定の Java 例外を含むコラボレーション例外を生成できます。
例外が発生すると、アクティビティー・ダイアグラム階層の所定レベルでの例外処理で、次のいずれかの方法で例外を処理できます。
アクティビティー・ダイアグラムで、例外分岐を使用して例外を明示的にキャッチしない 場合、コラボレーションの実行は (例外が発生したときになった) 例外状態のままです。例外が発生しても、コラボレーション・ランタイム環境はダイアグラム内の実行を停止しません。その代わりにアクティビティー・ダイアグラムのロジックに従って実行を継続し、終了成功ノードまたは終了障害ノードで終了します。
したがって、サブダイアグラムでの例外をキャッチし、さらに終了障害ノードにトラバースする場合は、コードでサブダイアグラム内の例外を確実にキャッチする必要があります (終了障害ノードの前)。
階層アクティビティー・ダイアグラムでは、例外分岐を使用してある実行レベルでの例外をキャッチしない場合、終了成功を使用して次に高いレベルのダイアグラムに制御を渡すことができます。この高位レベルのダイアグラムで、イベントをキャッチして、例外を処理するかまたは次に高いレベルに例外を発生することができます。
コラボレーション・テンプレートが、この実行経路内のどこにおいても例外をキャッチしなかった場合、その実行は例外状態のままになっています。この場合、コラボレーション・ランタイム環境は、例外状態の処理で説明するように、そのまま例外を処理します。コラボレーション・テンプレートは例外をキャッチしていないため、コラボレーション・ランタイム環境に未解決のフローを使用して独自のデフォルト例外メッセージ (Scenario failed.) を組み込む必要があります。
コラボレーション・テンプレートはアクティビティー・ダイアグラム内に、その分岐タイプが Exception に設定されている決定ノード内の分岐である、例外分岐 を使用した例外処理を組み込むことができます。決定ノードにより、アクション・シンボルがその可能性ある決定結果に接続されます。例外分岐により、例外が発生するアクション・シンボルが例外を処理するアクション・シンボルに経路付けされます。例外分岐には、例外分岐がキャッチする例外タイプを指定する例外条件が含まれます。表 44 に、例外条件を定義する際に選択できる、コラボレーション例外タイプをリストします。
例外が発生すると、コラボレーション・ランタイム環境により、currentException システム変数が設定されます。例外分岐に従うかどうかを判別するために、コラボレーション・ランタイム環境で例外分岐の条件での例外タイプと currentException システム変数内の例外タイプを比較して、例外分岐の例外条件を評価します。
コラボレーション・ランタイム環境でコラボレーションの実行は通常状態に変更され、例外分岐が指すアクション・シンボルに制御が渡されます。このアクション・シンボルには、例外条件で指定された例外タイプを処理する、例外処理コードを組み込むことができます。このコードで currentException システム変数にアクセスして例外情報を取得できます。
実行は、決定ノードのデフォルトの分岐 (存在する場合) に渡され、その後アクティビティー・ダイアグラムのロジック内の次のアクション・シンボルに渡されます。デフォルトの分岐で例外が処理されない場合、この状態はアクティビティー・ダイアグラムのこのレベルで例外が処理されない ことを意味します。また、コラボレーションの実行は例外状態のままであることも意味します。
指定された決定ノードは、最大 7 つの分岐を持つことができます。したがって、多くの例外タイプの例外処理を設定できます。各例外分岐にその例外条件での異なる例外タイプを指定して、その例外タイプについての例外処理ノードを指すことができます。あるいは、例外条件に AnyException 例外タイプを持つ単一の例外分岐で、すべて の例外タイプを処理できます。
コラボレーション・テンプレートで例外をキャッチして例外処理ノードに制御が渡されると、コラボレーション・テンプレートで、次の方法で例外を処理できます。
シナリオのロジックを続行するには、例外処理ノードで次のステップを実行します。
例外分岐が指すノード内に、例外を処理するコードを組み込むことができます。表 45 に、一部の使用できる処理ステップをリストします。
例外処理ノードが例外を生成しない 限り (raiseException() メソッドを使用して)、コラボレーションの実行は通常状態のままです。したがって、コラボレーション実行の完了時に、コラボレーション・ランタイム環境で未解決のフローは作成されません。コラボレーション・ランタイム環境によるこれらの終了ノードの処理方法の詳細については、通常状態の処理を参照してください。
表 45 に、例外処理ノードで実行できる使用可能な処理ステップの一部をリストします。これらのステップでは、コラボレーションの実行状態は変更しません。したがって、コラボレーションの実行は通常状態のままです。
例外処理ステップ | メソッド | 詳細 |
---|---|---|
メッセージをコラボレーションのログ宛先に記録 | logError()、logWarning()、logInfo() | メッセージのロギング |
例外についての情報の取得 | CollaborationException クラスのメソッド | 表 43 |
例えば、logError() メソッドはエラーをコラボレーションのログ宛先に記録します。
この宛先には、標準出力 (STDOUT) またはログ・ファイル (そのように構成されている場合) が可能です。また、このメソッドはエラー・メッセージを E メール受信側に送信します。コラボレーション・テンプレートはこのメソッドを使用してエラーを記録し、管理者がこれを調査できます。次のコード・フラグメントは、CollaborationException クラスの getMessage() と getMsgNumber() メソッドを使用して、currentException 変数から例外情報を抽出します。その後この情報を logError() 呼び出しを使用してエラーをフォーマット設定し、コラボレーションのログ宛先に送信します。
// extract exception information sMessage = currentException.getMessage(); imsgNumber = currentException.getMsgNumber(); // log message and send email (if configured) logError(imsgNumber, sMessage, ...);
詳細については、logError()、logInfo()、logWarning()の logError() メソッドの説明を参照してください。エラーをログ宛先に送信するだけでは、明確な例外メッセージを未解決のフローと関連付けるには通常は不十分であることに注意してください。例えば、例外が発生して、例外分岐でキャッチし、例外処理ノードは単にエラーをログに記録して失敗で終了すると仮定します。この場合、不成功のコラボレーションの未解決のフローには失敗したイベントが含まれますが、その例外メッセージはコラボレーション・ランタイム環境のデフォルトのメッセージ (Scenario failed.) のみです。
raiseException() メソッドは、次に高い実行レベルにコラボレーション例外を発生します。
コラボレーション・ランタイム環境で raiseException() 呼び出しが実行されると、コラボレーションの実行が例外状態に変更され、アクティビティー・ダイアグラムのロジックが続行されます。アクティビティー・ダイアグラム内の次に高いレベルに例外を発生するには、例外処理ノードで次のステップを実行します。
例外処理ノード内で、CollaborationException クラスのメソッドを使用して、currentException システム変数から例外情報を抽出できます。
コラボレーション・ランタイム環境で raiseException() 呼び出しが実行されると、コラボレーションの実行を例外状態に変更します。raiseException() 呼び出しにより、次に高い実行レベルに発生する例外が指定されます。
例外を発生したので、コラボレーション実行は例外状態です。各実行レベルで例外が発生される限り (raiseException() を使用)、コラボレーションの実行は例外状態のままです。したがって、コラボレーション実行の完了時に、コラボレーション・ランタイム環境で未解決のフローが作成されます。コラボレーション・ランタイム環境によるこれらの終了ノードの処理方法の詳細については、例外状態の処理を参照してください。
コラボレーション・テンプレートで raiseException() メソッドと logError() メソッドを使用して例外を処理する方法を理解するには、次の例を考慮します。コラボレーションのメインダイアグラムが subdiagramA を呼び出し、それが次に subdiagramB を呼び出すと仮定します。subdiagramB は、例外を発生させる可能性があるサービスを呼び出します。したがって、このサブダイアグラムにはサービス呼び出しを起動するアクション・ノードが含まれます。このアクション・ノードはサービス呼び出し例外を検査する例外分岐を持つ決定ノードに接続します。サービス呼び出し例外が発生すると、例外処理コードを持つアクション・ノードに例外分岐が接続します。
例外が発生すると、コラボレーション・ランタイム環境によりコラボレーションの実行が例外状態に変更され、subdiagramB でのサービス呼び出しと関連した例外分岐の例外条件が評価されます。例外分岐の条件が true と評価されると、例外分岐により例外がキャッチされ、例外分岐が指す例外処理ノードに制御が渡されます。例外分岐が例外をキャッチすると、コラボレーションの実行は通常状態に戻ります。
図 56 に、subdiagramB でのサービス呼び出し例外についての例外処理を実行するコード・フラグメントを示します。
図 56. subdiagramB でのサービス呼び出し例外の処理
// exception handling in subdiagramB sMessage = currentException.getMessage(); sType = currentException.getType(); // raise the exception to subdiagramA raiseException(sType, 2345, parameter1, parameter2, sMessage); }
この例外処理ノードのコードは、次のステップを実行します。
コードで currentException から例外メッセージと例外タイプを取得し、2 つのストリング変数 (それぞれ sMessage と sType) に保管します。
例外情報を収集したら、コードで raiseException() メソッドを呼び出して、subdiagramA に例外を発生します。この形式の raiseException() メソッドが、3 つのメッセージ・パラメーターを持つ例外タイプとエラー・メッセージ (2345) として、例外情報を受け取ります。これらのメッセージ・パラメーターには、currentException システム変数からコードで取得した例外メッセージが組み込まれています。その後 raiseException() 呼び出しにより、この例外情報を含む例外が作成されます。また、コラボレーションの実行を例外状態に変更します。
注:
raiseException() を実行後、コラボレーション・ランタイム環境で行うアクションは、実行経路を終了する終了ノードにより異なります。実行経路が終了成功ノードで終了すると、コラボレーション・ランタイム環境で次のステップが実行されます。
例外分岐を持つ決定ノードが subdiagramA に存在する場合、コラボレーション・ランタイム環境で各例外分岐の条件が評価されます。この例外条件が true に評価されると、subdiagramA は subdiagramB が発生した例外をキャッチします。コラボレーションの実行が通常状態に変更されて例外処理ノードに制御が渡され、このノードで次の raiseException() 呼び出しを使用して親ダイアグラム (メインダイアグラム) に例外を発生して例外を処理します。
// exception handling in subdiagramA: raise the exception to main diagram raiseException(currentException);
この形式の raiseException() メソッドは、引き数として受け取る例外オブジェクトを発生するだけです。渡された情報から例外は作成しません。この場合、subdiagramB (図 56) 内の例外処理コードで、該当する例外情報を使用して例外が作成済みなので、raiseException() で例外を作成する必要はありません。subdiagramA がその currentException 変数内に持つ例外は、subdiagramB が発生した例外と同じです。raiseException() が完了すると、subdiagramA のロジックに従ってコラボレーションの実行が続行します。subdiagramA の例外処理分岐が終了成功で終了すると、コラボレーション・ランタイム環境は subdiagramA を終了して、その親ダイアグラム (メインダイアグラム) に制御を渡します。したがって、raiseException() で生成される例外オブジェクト (subdiagramA の currentException 例外オブジェクト) は、メインダイアグラムに対して生成されます。
コラボレーションは、現在、メインダイアグラムの subdiagramA ノードで実行されています。subdiagramA の例外処理ノードで raiseException() を呼び出したので、コラボレーション実行は現在、例外状態です。したがって、コラボレーション・ランタイム環境で、発生した例外をキャッチする例外分岐がないかメインダイアグラムを検査します。これらの例外分岐は、subdiagramA の呼び出しを 1 つ以上の例外処理アクション・ノードに接続する決定ノード内にあります。例外分岐の条件が true と評価されると、メインダイアグラムにより subdiagramA が発生した例外がキャッチされます。コラボレーションの実行は通常状態に変化して、例外処理ノードに制御が渡され、このノードで該当する上位レベルの例外処理ステップを実行できます。
例として、メインダイアグラム内のこの例外処理ノードで次のステップを実行すると仮定します。
すべてのコラボレーション・オブジェクトで、logError() がログ宛先に送信するエラーの E メールの受信側を指定できます。コラボレーションが CollaborationFoundation に基づいている場合、SEND_EMAIL コラボレーション・プロパティーに用意されている追加機能を利用できます。コラボレーション・オブジェクトが E メール送信に構成され、さらに SEND_EMAIL が all またはメッセージ番号のリストに設定されている場合、何らかのエラー (SEND_EMAIL が all の場合) または指定されたエラー (SEND_EMAIL でメッセージ番号リストが指定された場合) が発生すると、コラボレーションにより指定された受信側に E メールが送信されます。
これらの条件が一致すると、例外処理ノードにより logError() が呼び出されてエラーがログに記録され、E メールが指定された受信側に送信されます。したがって、コードでまず例外情報を取得して、現行の例外からエラー・メッセージに組み込む必要があります。
コラボレーション・オブジェクトが E メール送信に構成されている場合、logError() メソッドでエラー・メッセージが指定された E メール受信側に自動的に送信されます。この分岐では logError() メソッドを使用して、コラボレーションのログ宛先 (標準出力またはログ・ファイル) に例外を送信します。
次のメインダイアグラムの例外処理ノードのコード・フラグメントは、これらのステップを実行します。
// exception handling in main diagram // determine if SEND_EMAIL is set to "all" or a message-number list; // if so, obtain exception information from the current exception sMessage = currentException.getMessage(); imsgNumber = currentException.getMsgNumber(); // log message and send email logError(imsgNumber, sMessage, ...); // raise the exception to collaboration runtime environment raiseException(currentException);
コラボレーション・ランタイム環境でこの raiseException() 呼び出しを実行すると、次のステップが実行されます。
管理者が未解決のフローを表示すると、Flow Manager ツールはこの未解決フローのメッセージ (subdiagramB で、最初にスローされたときに例外から取得) を表示します。