コラボレーションがビジネス・オブジェクト要求を宛先アプリケーションに送信する場合、コラボレーション・ランタイム環境で、ServiceCallException の例外タイプでコラボレーション例外をスローして失敗が示されます。
しかし、サービス呼び出しの失敗の原因はあいまいな場合があります。サービス呼び出しは、以下の理由により、失敗することがあります。
このセクションでは、コラボレーション・テンプレートでの次のサービス呼び出しのエラー条件の処理方法について説明します。
データの重複の可能性は、次のどの状態においても起こりえます。
トランスポート関連の例外によるデータの重複は、以下の両方の時点で回避する必要があります。
次のセクションでは、トランスポート関連の例外の処理方法について説明します。
コラボレーション実行時に発生するトランスポート障害によるデータの重複を回避するには、サービス呼び出しごとにトランスポート関連の例外とトランスポート関連ではない例外を区別するようにコラボレーション・テンプレートをコーディングします。トランスポート関連の例外を検査するには、ServiceCallException 例外タイプの ServiceCallTransportException サブタイプを使用します。
この例外サブタイプは、トランスポートでエラーがあり、要求がアプリケーションに到達できたかどうかを正確に確認できなかったことを示します。
このため、特に AppUnknown サブタイプについてチェックするコラボレーション・テンプレートは、ServiceCallTransportException についてもチェックする必要があります。AppUnknown サブタイプはトランスポート例外を処理しません。このため、コラボレーション・オブジェクトは、ServiceCallTransportException を除くすべてのサブタイプをチェックする場合、トランスポート例外をトラップしません。
例外分岐のすぐ後のノード (つまり、例外分岐が指すノード) でトランスポート関連例外を処理します。ServiceCallException 例外サブタイプを持つ例外をキャッチする例外処理ノードをコーディングして、宛先アプリケーションから要求ビジネス・オブジェクトを取得して、アプリケーションが正常に作成されたかまたはオブジェクトを変更したどうかを判別する、追加の検索サービス呼び出しを行います。オブジェクトが正常に作成または変更されていなかった 場合は、要求を再試行するようコラボレーションをコーディングします。
次のコード・フラグメントは、トランスポート関連例外についての例外処理を行います。ここでは、getSubType() メソッドを使用して currentException システム変数から例外サブタイプを取得します。
この例外サブタイプが ServiceCallTransportException の場合、例外処理コードで検索を実行して、サービス呼び出し要求の結果としてデータがアプリケーションで変更されたかどうかを判別する必要があります。
if (currentException.getType().equals(ServiceCallException)) { if (currentException.getSubType().equals( ServiceCallTransportException)) { //Perform a retrieve to determine whether data changed //in the application reflecting the ICS business object request } else raiseException(ServiceCallException, ...); }
コラボレーションのサービス呼び出し処理中に、InterChange Server のクラッシュが原因で発生するデータの重複を回避するには、以下のいずれかの手順を実行します。
InterChange Server がすべてのサービス呼び出しに対して差し戻しを指定するトランザクション・コラボレーションをリカバリーする場合、失敗した要求を再サブミットする前にコラボレーションをロールバックします。このロールバックにより、サーバー・クラッシュの原因によるデータの重複が問題ではなくなります。詳細については、"トランザクション機能の使用"を参照してください。
非トランザクション・コラボレーションのリカバリーでは、失敗した要求を再サブミットする前にコラボレーションはロールバックされません。したがって、データの重複が問題となります。非トランザクション・コラボレーションにおけるデータの重複を回避するには、コラボレーション・オブジェクトについて「Service Call In-Transit」永続性を構成します。「コラボレーション・プロパティー」ダイアログで、次のラベルのボックスにチェックマークを付けます。
Persist Service Call In Transit State
既存のコラボレーションとの後方互換性を維持する必要があること、およびトランザクション・コラボレーションで各サービス呼び出しの状態を永続的に保管することに利点がない ため、「Service Call In-Transit」永続性のデフォルト設定は、off になっています。つまり、コラボレーション・オブジェクトについて「Persist Service Call In Transit State」ボックスはチェックされていません。
永続的に構成されているコラボレーション・オブジェクトがサービス呼び出しを入力すると、ICS は、要求が完了するまでこの状態を維持します。コラボレーションによるサービス呼び出しの処理中にサーバーがクラッシュすると、この失敗したサービス呼び出しの状態が、次の状況で Flow Manager に表示されます。
Service Call In Transit
この場合、管理者は、トランスポート障害前にコラボレーション要求が正常に処理されたかどうかを手動で確認する必要があります。要求が成功しなかった 場合、管理者は再サブミットする必要があります。詳細については、「システム管理ガイド」を参照してください。
アプリケーションに送信されたサービス呼び出し要求を検証するには、コラボレーション・テンプレートで各サービス呼び出しを検査するようにコーディングします。要求が送信されたことを検証するには、ServiceCallException 例外タイプの AppRequestNotYetSent サブタイプを使用します。
並列コネクター・エージェントの場合、この例外サブタイプは、要求がエージェント・マスター内にキューイングされたが、アプリケーションにディスパッチされないため、要求を再送信できることを示します。
例外分岐のすぐ後のノード (つまり、例外分岐が指すノード) で未送信サービス呼び出し例外を処理します。要求を再サブミットするようにコラボレーション・テンプレートをコーディングします。次のコード・フラグメントは、未送信サービス呼び出し要求の例外処理を行います。ここでは、getSubType() メソッドを使用して currentException システム変数から例外サブタイプを取得します。
この例外サブタイプが AppRequestNotYetSent の場合、コードでサービス呼び出しを使用してアクション・ノードに戻ってイベントを再サブミットする必要があります。
if (currentException.getType().equals(ServiceCallException)) { if (currentException.getSubType().equals( AppRequestNotYetSent)) { // Resubmit the event by returning execution to the action node // with the service call. } else raiseException(ServiceCallException, ...); }