カスタム例外
回復できないエラーが発生すると、ビジネス プロセス管理ソリューションは、例外ハンドラとカスタム例外を組み合わせて使用します。
呼び出されたオーケストレーションで Terminate 図形を使用するのではなく、ルート オーケストレーションによって処理される例外をスローするパターンを使用できます。 これにより、最も強力なコンテキストのオーケストレーションで例外処理を判断できます。 下位のオーケストレーションがカスタム例外をスローすると、ルート オーケストレーションの詳細な情報と通信できます。
ビジネス プロセス管理ソリューションは、この方式に従います。 ソリューションには、ルートオーケストレーション (呼び出されないオーケストレーション) が 4 つあります。 OrderBroker、 OrderManager、 CableOrder1、 CableOrder2 です。 ルート オーケストレーションの 3 つがカスタム例外を受信して処理します。 OrderManager、 CableOrder1、 および CableOrder2。
一部のルート オーケストレーションでは Terminate 図形が使用され、オーケストレーションの通常のエンドポイントの直前に Terminate 図形が表示されることに注意してください。 オーケストレーションでは、エラーが発生した場合でも Terminate 図形が使用されるため、オーケストレーションは完了としてではなく、エラー メッセージとともに終了として記録されます。 これにより、このソリューションは、エラーの記録に加えて、失敗したインスタンスを簡単に追跡できます。
終了図形の詳細については、「 終了 図形 を構成する方法」を参照してください。 ThrowException 図形の詳細については、「例外のスロー図形を構成する方法」を参照してください。
次の 3 つのカスタム例外は、同じ方式に従います。 異なる種類を使用すると、コードは、各種の例外を区別できます。
例外 | スローされる (オーケストレーション) |
---|---|
ActivateException | 変更 |
CableOrderException | Activate、 CableOrder1 |
InterruptException | CableOrder1、 CheckInterrupt、 ErrorHandlerOrch |
すべてのカスタム例外は、 Utilities アセンブリで定義されます。 カスタム例外は、すべて .NET クラスです。 すべてのカスタム例外クラスは.NET ApplicationException クラスから継承され、そのクラスは System.Exception クラスから継承されます。 例外が退避されている (シリアル化されてデータベースに格納されている) 可能性があるので、シリアル化解除コンストラクタが例外に実装されている必要があります。 シリアル化解除コンストラクタは、2 つの引数 (SerializationInfo オブジェクトと StreamingContext オブジェクト) を使用するコンストラクタです。 例外の退避中に、シリアル化解除コンストラクタが使用されます。 ApplicationException クラスは既に逆シリアル化コンストラクターを実装しているため、カスタム例外のコンストラクターは単に基本 (ApplicationException) 逆シリアル化コンストラクターを呼び出します。 たとえば、 InterruptException には次のコンストラクターが含まれます。
// "info" is the object holding the serialized object data.
// "context" is the contextual information about the source
// or destination.
public InterruptException(SerializationInfo info,
StreamingContext context) : base(info, context) { }
カスタムのシリアル化の詳細については、『.NET Framework 開発者ガイド』の「カスタムのシリアル化 (Custom Serialization)」を参照してください。
特殊な例外としての機能に加えて、一部の場所のカスタム例外は、ソート フラグとしての役割も果たします。 Change オーケストレーションには、Cancel 操作をロールバックする必要がある場所が 2 つあります。
注意
Visual Studio で [オーケストレーションの変更 ] を開いた状態で、このセクションをお読みください。
オーケストレーションの上部で、 Cancel オーケストレーションの呼び出しが失敗した場合、 CancelCompensation ブロックが実行され、 Cancel トランザクションがロールバックされます。 すべてがうまくいった場合、オーケストレーションは アクティブ化 オーケストレーションを呼び出します。
アクティブ化操作が失敗した場合は、Cancel トランザクションもロールバックする必要があります。 ただし、 Activate の呼び出しの例外ハンドラーは 、Cancel トランザクションについて何も認識しません。 これに対処するには、オーケストレーション全体の例外ハンドラを使用します。 このハンドラーには Cancel スコープが含まれているため、 Cancel トランザクションについて認識されます。 ハンドラーは 、Activate スコープ ( ActivateException) からスローされた例外をキャッチし、 Cancel トランザクションをロールバックしてから、 Change オーケストレーションを呼び出したオーケストレーションが追加の処理を実行できるように、もう一度例外をスローします。
この設計では、アクティブ化が失敗した場合にのみ Cancel が補正されることに注意してください。 Cancel が失敗し、例外がスローされた場合、Cancel は発生せず、補正しないでください。
補正ブロックと補正図形の詳細については、「補正図形を構成する方法」を参照してください。