test

Sun Identity Manager の概要

障害のシナリオについて

この節では 8 つの障害のシナリオを示し、セッション持続性が有効な配備とセッション持続性が無効な配備を比較します。

シナリオ 1: ワークフローなし

シナリオの説明

エンドユーザーまたは管理者は、ワークフローの一部でないフォームを編集しています。ユーザーがセッションを確立していたインスタンスが停止します。

セッション持続性が無効な場合

ユーザー体験: 非透過的なフェイルオーバー。フォームを送信すると、ユーザーはログインページに戻されます。

回復手順: ユーザーは自分のユーザー名とパスワードを再入力します。Identity Manager はフォームを処理して、ログイン直後のページに結果を表示します。

セッション持続性が有効な場合

ユーザー体験: ユーザーのフォームは送信され、結果が返されます。ユーザーはログオフせず、再ログインの必要はありません。

回復手順: ユーザーのアクションは必要ありません。

その他のシナリオの例

シナリオ 2: ワークフローの実行中

シナリオの説明

エンドユーザーまたは管理者が、ワークフローをトリガーするフォームを送信しています。ワークフローを実行しているインスタンスと、ユーザーのセッションが存在するインスタンスは、一部の定期タスクで別にできる場合を除いて、通常は同じになります。このインスタンスが、ワークフローの実行中に停止します。

セッション持続性が無効な場合

ユーザー体験: 非透過的なフェイルオーバー。フォームの送信により、ユーザーはログインページに戻されます。実行中のワークフロータスクのインスタンスはリポジトリにあるべきですが、実行のノードが停止しているため、ワークフローの状態は「終了」になります。

回復手順: ワークフローをもう一度送信する必要があります。再送信を行うには、ノードで障害が発生する前にワークフローのトリガーに使用したフォームに戻り、同じ情報を入力する必要があります。

同じ要求データを送信することで、動作する場合もありますが、動作しない場合もあります。ワークフローの実行中に複数のリソースに対してプロビジョニングが実行され、これらのリソースの一部が障害発生前にプロビジョニングされている場合、ユーザーからのワークフローの再送信では、「すでにプロビジョニングされた」リソースを考慮する必要があります。終了したワークフローは、TaskInstance オブジェクトで resultLimit が期限切れになるまで、リポジトリで待機しています。

セッション持続性が有効な場合

ユーザー体験: 非透過的なフェイルオーバー。ユーザーのセッションは維持され、新しいインスタンスで再確立されるため、ユーザーのログアウトは発生しません。ただし、ワークフローが終了するため、フォームの送信はエラーになる可能性があります。このフェイルオーバーは、回復アクションが必要であるため非透過的です。

回復手順: セッション持続性が無効な場合と同じです。ユーザーは、前回のワークフローをトリガーした要求を、同じパラメータまたは修正したパラメータを使用して再送信する必要があります。

その他のシナリオの例

シナリオ 3: ワークフローが一時休止中またはスリープ中

シナリオの説明

このシナリオは、ワークフローが開始されているが、承認者による手動アクションを待機中である場合です。

セッション持続性が無効な場合

ユーザー体験: 承認者がまだログインしていない場合、承認者に関しては透過的なフェイルオーバー。ノードで障害発生したあと、承認者がログインすると、現在ダウンしているノードからトリガーされた要求であっても、承認要求は承認者の受信箱に表示されます。

回復手順: ユーザーのアクションは必要ありません。

セッション持続性が有効な場合

ユーザー体験: セッション持続性が無効な場合と同じです。

回復手順: セッション持続性が無効な場合と同じです。

その他のシナリオの例

シナリオ 4: 作業項目の編集中

シナリオの説明

このシナリオは、ユーザーが作業項目を編集中で、ユーザーがセッションを確立していたノードが作業項目を送信する前に停止する場合です。

セッション持続性が無効な場合

ユーザー体験: 非透過的なフェイルオーバー。作業項目の編集フォームを送信すると、ユーザーはログオフし、ログインページに戻されます。

回復手順: ログイン資格を再送信すると、ユーザーの作業項目が「完了」にマークされ、ワークフローはそこから再開されます。ワークフローは、ユーザーの手動アクションが「完了」にマークされた場所から、新しい実行モードによって取得されます。

セッション持続性が有効な場合

ユーザー体験: 作業項目の編集フォームを送信すると、ユーザーには送信の結果が表示されます。たとえば、カスタムワークフローの次のフォームや成功のメッセージが表示されます。

回復手順: ユーザーのアクションは必要がありません。

その他のシナリオの例

シナリオ 5: スケジュールタスクの実行中

シナリオの説明

このシナリオは、調整の実行中やレポートの実行中に、ノードで障害が発生した場合です。

セッション持続性が無効な場合

ユーザー体験: スケジュールタスクが途中で終了します。

回復手順: 実行中に終了したスケジュールタスクは、再起動する必要があります。タスクは最初から実行されます (障害が発生した場所から再開されるのではありません)。新しいタスクを作成および開始する場合と同様です。

セッション持続性が有効な場合

ユーザー体験: セッション持続性が無効な場合と同じです。

回復手順: セッション持続性が無効な場合と同じです。

その他のシナリオの例

シナリオ 6: スケジュールタスクが一時休止中

シナリオの説明

このシナリオは、ユーザーのカスタムワークフローに、後日、特定のノードで実行するスケジュールタスクが含まれている場合です。予定日になる前に、タスクがスケジュールされたノードで障害が発生します。

セッション持続性が無効な場合

ユーザー体験: このタスクを予定時刻に実行することを保証するために必要な回復アクションに関して、フェイルオーバーは透過的です。

回復手順: スケジュールタスクは、予定時刻になったときに有効なノードに引き継がれます。

セッション持続性が有効な場合

ユーザー体験: セッション持続性が無効な場合と同じです。

回復手順: セッション持続性が無効な場合と同じです。

その他のシナリオの例

シナリオ 7: Web サービスのワークフロー要求が Identity Manager でまだ受信されていない

シナリオの説明

このシナリオは、Identity Manager の GUI を使用せずにプロビジョニングを開始する場合です。SPML やその他のカスタム Web サービスインタフェースを使用して Identity Manager を内部的に呼び出すアプリケーションによって、ユーザーインタフェースが提供されています。この場合、UI を使用するユーザーに関連するユーザーセッションは、呼び出し元のアプリケーションを通して管理されます。Identity Manager では、要求はすべて「soapadmin」として開始されます。

このようなユースケースで、Identity Manager エンドポイントを経由して要求をまだ受信していないときに、対象のノードで障害が発生する場合を考えます。

セッション持続性が無効な場合

ユーザー体験: 透過的なフェイルオーバー。SOAP 管理者の資格は、ネットワーク経由で、または Identity Manager の Waveset.properties 設定で各 SOAP 要求に渡されます。この SOAP 要求を受信するノードが、停止前に要求を受信していなければ、セッション持続性の状態にかかわらずフェイルオーバーは透過的です。

回復手順: 必要なアクションはありません。SOAP 要求は、それを実行する有効なノードに送信されます。

セッション持続性が有効な場合

ユーザー体験: セッション持続性が無効な場合と同じです。

回復手順: セッション持続性が無効な場合と同じです。

シナリオ 8: Web サービスワークフロー要求が Identity Manager で実行中

シナリオの説明

このシナリオはシナリオ 7 に似ています。唯一の違いは、ノードで障害が発生したときに、ワークフローが実行中である (ノードが SOAP 要求をすでに受信している) ことです。

セッション持続性が無効な場合

ユーザー体験: このシナリオは、シナリオ 2 (ワークフローの実行中) と同様です。ワークフローは「終了」とマークされ、ユーザーには SOAP 要求の結果としてエラーが表示されます。

回復手順: ユーザーは他社アプリケーションのユーザーインタフェースを使用して、ワークフローのどこで障害が発生したかに応じて、同じパラメータまたは修正したパラメータを指定してフォームを再送信する必要があります。

セッション持続性が有効な場合

ユーザー体験: セッション持続性が無効な場合と同じです。

回復手順: セッション持続性が無効な場合と同じです。