Share via

Workflow Manager 1.0 での障害復旧とスコープ復元

  • [アーティクル]

 

このトピックでは、Workflow Manager 1.0 の障害復旧のオプションと手順の概要を示します。 データベース サーバーおよびアプリケーション サーバーの障害に対応する手順と、破損または削除されたスコープを復元する手順について説明します。

  • 災害復旧

  • スコープの復元

災害復旧

Workflow Manager 1.0 を使用すると、障害のシナリオに対応する準備を行うことができます。 このトピックでいう障害とは、重大な損失、破損、困難な状況などを発生させるイベントのことです。 サーバー製品の場合、障害とはサーバーの可用性が著しく損なわれるようなイベントのことであり、サーバーに対して設定された元のクラスター (またはその一部) のさまざまな程度の損失を伴う場合があります。

障害復旧と高可用性

一般的に、障害復旧と高可用性は結び付いています。 高可用性は、通常の状況においてサービスが高度に利用可能であるようにする問題であり、システムに十分な冗長性を持たせたり、単一の障害点を排除したりすることが含まれます。 これに対して、障害復旧は自然災害など外部的な状況が原因でプライマリ サービスが停止した場合に、同じレベルのサービスを継続して提供する必要がある問題です。

障害復旧モデルの概要

障害に備えて準備し、それに対応するプロセスは、以下に示すようなさまざまな段階に分類することができます。 次の図は、このような各段階に加えて、ユーザーが持つべき責任と、ワークフロー マネージャー によって提供される機能を示しています。

Workflow Manager 1.0 Manageability Diagram

Workflow Manager でのさまざまな種類の障害シナリオ

ワークフロー マネージャー の場合、備えておく必要があるいくつかの障害シナリオが想定されます。

  1. ワークフロー マネージャー で使用されている 1 つ以上のデータベースの損失が発生する障害。

    1. この原因として、ハードウェア障害またはデータ センター全体の障害イベントが考えられます。

  2. ワークフロー マネージャー バイナリが展開されているアプリケーション サーバーの損失が発生する障害。

  3. アプリケーション サーバーとデータベースの両方が失われる、クラスター全体の損失が発生する障害。

ワークフロー マネージャー にはユーザーのワークフロー、アクティビティ、およびインスタンスに関連する情報が格納されているため、ワークフロー マネージャー の障害復旧の鍵となるのは、バックアップ コピーを使用して ワークフロー マネージャー インストールのデータを復元する機能です。 したがって、これらのほとんどのシナリオでは、バックアップからデータを復元し、ワークフロー マネージャー のさまざまなサブシステム全体でデータの一貫性を実現することが、障害復旧の主な内容となります。

障害復旧の準備

障害復旧では、緊急事態の発生に備えて準備することがすべてです。ワークフロー マネージャー を使用して、障害が発生した場合でも、すべてのアクティビティ、ワークフロー、およびインスタンスに関連するデータを維持する必要があります。

ワークフロー マネージャー は、そのすべてのデータを SQL Server データベースに格納します。 そのため、障害復旧の重要な前提条件として、定期的なバックアップおよびデータの冗長性ソリューションを設定して、データ センターを襲う障害が実際に発生した場合に、ワークフロー マネージャー インストールの復元に使用できるデータベースの最新のコピーが存在するようにする必要があります。

ワークフロー マネージャー インストールでは次のデータベースが使用されます。

データベース名

説明

WFManagementDB

ワークフロー マネージャー ファーム管理データベース

SbManagementDB

Service Bus ファーム管理データベース

WFResourceManagementDB

ワークフロー マネージャー リソース管理ストア

WFInstanceManagementDB

ワークフロー マネージャー インスタンス管理ストア

SbGatewayDatabase

Service Bus ゲートウェイ データベース

SBMessageContainer01 - n

Service Bus メッセージ コンテナー データベース

ワークフロー マネージャー インストールにあるワークフロー データの重要度に応じて、さまざまな障害復旧準備オプションから選択できます。ワークフロー マネージャー のすべてのデータは上記の SQL Server データベースに格納されているので、SQL Server ベースのあらゆる高可用性とバックアップの手法が、ワークフロー マネージャー にも適用されます。

SQL Server での高可用性と障害復旧の実装の詳細については、「高可用性ソリューションの選択」および「Microsoft SQL Server の障害復旧オプションの説明」を参照してください。

注意

これらのデータベースをバックアップするために選択するオプションにかかわらず、バックアップの間隔が長くなりすぎないようにします。 たとえば、個別のデータベースのバックアップの間隔が何時間も何日も離れている場合、ワークフロー マネージャー を正しく復元するのは困難です。

次の図は、ワークフロー マネージャー インストールのさまざまなコンポーネントを示しています。

Workflow Manager 1.0 Server Farm Administrator Vie

サーバー ファーム管理者の観点からは、障害が発生した場合に破損する可能性のある ワークフロー マネージャー の部分が 2 つあります。それらは、関連する 1 つ以上のデータベース、または 1 つ以上のアプリケーション サーバー ノードです。 さまざまな組み合わせのアプリケーション サーバーとデータベース サーバーが停止している可能性がありますが、概略的にはデータ層とアプリケーション層が障害点です。

  • データ層

  • コンピューティング層 (ワークフロー/メッセージング層)

データ層

Workflow Manager 1.0 は、データを次の SQL Server データベースに格納します。

データベース名

説明

WFManagementDB

ワークフロー マネージャー ファーム管理データベース

SbManagementDB

Service Bus ファーム管理データベース

WFResourceManagementDB

ワークフロー マネージャー リソース管理ストア

WFInstanceManagementDB

ワークフロー マネージャー インスタンス管理ストア

SbGatewayDatabase

Service Bus ゲートウェイ データベース

SBMessageContainer01 - n

Service Bus メッセージ コンテナー データベース

データ層に関しては、障害復旧に関連して次の 3 つの重要なタスクがあります。

  1. 準備 - データベースに対して正しいバックアップ/レプリケーションの手法を使用していて、データベースに関連する障害が発生した場合にデータが失われないことを確認します。

    障害の状況から回復するためには、障害に備えて準備しておく必要があります。 具体的にいうと、データベースの損失に関連する障害からの回復に関しては、データのコピーを別の場所に格納するための方法が必要です。 これらのデータベースは標準の SQL データベースなので、次のような実証された SQL 技法を使用することをお勧めします。

    1. SQL ミラーリング

    2. SQL レプリケーション

    3. 単純なバックアップおよびバックアップとログ配布の組み合わせ

    ビジネスの特性、およびバックアップとプライマリ データベースの間で必要なデータの忠実性レベルに応じて、これらの任意の技法を選択することができます。

    基本的に、ワークフロー マネージャー ファームの管理者には、ニーズに応じた適切なバックアップの手法を使用して、これらのデータベースのバックアップを作成することが求められます。ワークフロー マネージャー は、これらのバックアップ データベースの作成を支援する機能を備えていません。

  2. バックアップ データベースの復元

    データ レプリケーションの手法に応じて、バックアップ データベースを復元するための適切な復元ツール/メカニズムを使用する必要があります。 SQL データベースを復元するために使用できる、業界標準の SQL ツールと技法があります。

  3. ワークフロー マネージャー ファームの復元

    この手順は、ワークフロー マネージャー ファームが一貫性のある状態に復元され、正しく機能するようにするプロセスです。ワークフロー マネージャー には、この手順を実行するために必要な PowerShell スクリプトとガイダンスが用意されています。

コンピューティング層 (ワークフロー/メッセージング層)

障害復旧シナリオに備えて、第 2 の格納場所にセカンダリ ファームを作成することができます。 セカンダリ ファームは、障害発生の前または後に作成できます。 次の 3 つのモデルを考慮します。

  1. コールド スタンバイ

    このモデルでは、障害が発生した後にファームを再作成できます。 この場合、新しいコンピューティング ノードをプロビジョニングし、それらのノードに新規に ワークフロー マネージャー をインストールするため、ファームの回復までに時間がかかります。

  2. ウォーム スタンバイ

    障害が発生する前にセカンダリ ファームが作成され、それをテスト済みであるようにする場合、通常はこのモデルを選択します。 このモデルでは、障害が発生する前に新しいファームでコンピューティング ノードをプロビジョニングします。 データベースのペアリング関係を確立したら、この新しいファームでセカンダリ データベースを指定します。

    この新しいファームを設定したら、基本的にコンピューティング ノードをオフにし、アイドル状態で実行されないようにします。 障害復旧の一部として、Workflow Manager で提供されるデータベース一貫性スクリプトを実行する必要があります。

    注意

    このモデルでは、最初の設定後にプライマリで Service Bus コンテナー データベースが作成されないことが前提となっています。 プライマリで新しい Service Bus コンテナー データベースが作成される場合、回復中に追加の手順を実行する必要があります。

  3. ホット スタンバイ

    これはコンピューティング ノードをオンにできるウォーム スタンバイを強化したものです。 これにより、障害から回復するための時間が高速になります。

    警告

    ホット スタンバイは ワークフロー マネージャー ではサポートされていません。

障害復旧プロセス

ここでは、前に説明したさまざまな障害シナリオで使用される実際の障害復旧プロセスについて説明します。 推奨されるプロセスを大まかにいうと、(標準的な任意の SQL Server 技法を使用して作成した) バックアップから必要なデータベースを復元し、ワークフロー マネージャー で提供される復元コマンドレットを使用してファームを復元します。

注意

次の手順は、前のファーム管理データベースを破棄し、再作成するプロセスを示しています。

復元コマンドを実行するプロセス

  1. ServiceBus ファーム証明書と Service Bus 暗号化証明書の両方を秘密キーと一緒にエクスポートします。 両方を新しいサーバーの Local Computer\Personal フォルダーにインポートします。 また、ルート証明書を新しいサーバーの Local Computer\Trusted Root Authority フォルダーにインポートします。 ファーム証明書と暗号化証明書は Get-SBFarm の出力で識別できます。

    System_CAPS_noteメモ

    インポートは、古い WFM/SB サーバーの古い ServiceBus 暗号化証明書が以下のいずれかの場合にのみ正常に行われます。

    • 古いファームの構成時に構成ツールによって自動生成された。

    • または、古い環境で ServiceBus にカスタム証明書を使用していた場合、証明書の [サブジェクトの別名] フィールドが、*.mydomainname.com などの値を指定して作成された (ドメインのワイルドカード証明書である必要があるため)。

    古い ServiceBus 証明書のインポートが実行されなかった場合、次の手順の Restore-WFFarm コマンドレットは、次のようなエラーと共に失敗します。

    Token provider returned message: '<Error><Code>400</Code><Detail>The namespace 'WorkflowDefaultNamespace' does not have a valid issuer that can be used to issue tokens. Add a valid issuer with a valid signature to the namespace.

  2. 新しいコンピューターで、管理者特権の PowerShell (管理者として実行) ウィンドウを開きます。

  3. 次のパラメーターを渡して Restore-SBFarm コマンドレットを呼び出します。 このコマンドレットは新しい Service Bus ファーム管理データベースを作成します。 作成後、古い Service Bus ファーム管理データベースを削除できます。

    Restore-SBFarm -FarmCertificateThumbprint <String> -GatewayDBConnectionString <String> -SBFarmDBConnectionString <String> [-AdminApiCredentials <PSCredential> ] [-AdminGroup <String> ] [-AmqpPort <Int32> ] [-AmqpsPort <Int32> ] [-EncryptionCertificateThumbprint <String> ] [-FarmDns <String> ] [-Force] [-HttpsPort <Int32> ] [-InternalPortRangeStart <Int32> ] [-MessageBrokerPort <Int32> ] [-RPHttpsPort <Int32> ] [-RunAsAccount <String> ] [-TcpPort <Int32> ] [-TenantApiCredentials <PSCredential> ] [-Confirm] [-WhatIf] [ <CommonParameters>]

    注意

    古い ServiceBus 構成でカスタム ワイルドカード証明書を使用していて、FarmCertificate と EncryptionCertificate に 2 つの異なる証明書を使用していた場合、それぞれの新しいノードに、それらの両方をインポートし、それに応じて上記のコマンドレットで FarmCertificateThumbprint と EncryptionCertificateThumbprint パラメーターを指定する必要があります。

    次のスニペットは、Restore-SBFarm を呼び出す例を示しています。

    Restore-SBFarm -RunAsAccount 'farm\test' -FarmCertificateThumbprint 41FED42EC87EA556FB64A41572111B96D13FBFC2 -GatewayDBConnectionString 'Data Source=DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False' -AdminGroup 'BUILTIN\Administrators' -EncryptionCertificateThumbprint 41FED42EC87EA556FB64A41572111B96D13FBFC2

  4. いずれかのファーム ノードで、次のパラメーターを使用して Restore-SBGateway コマンドレットを呼び出します。

    Parameter

    説明

    SBFarmDBConnectionString

    前の手順で作成された Service Bus ファーム データベースの接続文字列。

    GatewayDBConnectionString

    復元されたゲートウェイ データベースの接続文字列。

    次のスニペットは、Restore-SBGateway を呼び出す例を示しています。

    Restore-SBGateway -GatewayDBConnectionString 'Data Source= DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'

  5. 各コンテナー データベースで、次のパラメーターを使用して Restore-SBMessageContainer コマンドレットを呼び出します。 このコマンドレットは、いずれかのファーム コンピューターで実行します。

    Parameter

    説明

    SBFarmDBConnectionString

    前の手順で作成された Service Bus ファーム データベースの接続文字列。

    ContainerDBConnectionString

    コンテナー データベースの接続文字列。

    ID

    復元されたメッセージ コンテナーの ID。

    ゲートウェイ データベースの [dbo].[ContainersTable] テーブルから復元されたメッセージ コンテナーの ID を取得します。このテーブルには、すべてのメッセージ コンテナーの ID、接続文字列、データベース サーバー名、およびデータベース名が格納されています。 データベース名が元のコンテナー データベース名に一致するコンテナーの ID を選択します。

    Restore-SBMessageContainer コマンドレットを呼び出す例を次のスニペットに示します。

    Restore-SBMessageContainer -ContainerDBConnectionString "Data Source=localhost;Initial Catalog=SBMessageContainer01;Integrated Security=SSPI;Asynchronous Processing=True" -SBFarmDBConnectionString "Data Source=localhost;Initial Catalog= SBManagementDB;Integrated Security=SSPI;Asynchronous Processing=True" –id 1

  6. Add-SBHost コマンドレットを呼び出し、次のパラメーターを渡します。

    Parameter

    説明

    SBFarmDBConnectionString

    前の手順で作成された Service Bus ファーム データベースの接続文字列。

    CertificateAutoGenerationKey

    SB 証明書の自動生成に使用されるキー。

    RunAsPassword

    Service Bus プロセスが実行されるアカウントのパスワードを含む SecureString。

    EnableFirewallRules

    Service Bus のデータがファイアウォールを通過できるようにするために、ホストのファイアウォール規則を更新する必要がある場合は true、 それ以外の場合は false。

    次の例は、コマンドレットを呼び出す方法を示しています。

    $myPassword=convertto-securestring 'ereee' -asplaintext -force Add-SBHost -EnableFirewallRules $TRUE -RunAsPassword $myPassword -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'

  7. Restore-WFFarm コマンドレットを呼び出し、ResourceManagement およびインスタンス データベース接続文字列を使用します。

    次の例は、コマンドレットを呼び出す方法を示しています。

    $mykey=convertto-securestring 'etwegff' -asplaintext -force Restore-WFFarm  -RunAsAccount 'farm\test' -InstanceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFInstanceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -ResourceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFResourceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False' -InstanceStateSyncTime 'Sunday, May 11, 2014 12:30:00 PM' -ConsistencyVerifierLogPath 'c:\log.txt' -CertificateAutoGenerationKey $myKey

    注意

    InstanceStateSyncTime は、前の例で指定したとおりの形式に従う必要があります。 ConsistencyVerifierLogPath は、このコマンドレットが復元プロセスに関連するログを書き込むフォルダーへのパスです。

  8. Add-WFHost コマンドレットを呼び出します。

    次の例は、コマンドレットを呼び出す方法を示しています。

    Add-WFHost -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -RunAsPassword $myPassword -EnableFirewallRules $TRUE -CertificateAutoGenerationKey $myKey

シナリオ 1 - 障害がクラスター全体に影響する

このシナリオでは、クラスター全体が障害のために影響を受けます。 この障害シナリオから回復するには、最新のデータベース バックアップを使用してクラスター全体を再構築する必要があります。

  1. Workflow Manager 1.0 を新しいコンピューターにインストールします。

    注意

    インストーラーを使用して Workflow Manager 1.0 をインストールしますが、ファームの構成は開始しないでください。

  2. SQL Server の復元機能を使用して、バックアップしたプライマリ データベースを復元します。 この手順は、選択したバックアップ ソリューションによって変わります。

    復元するのは、次のデータベースのみです。

    • WFResourceManagementDB

    • WFInstanceManagementDB

    • SbGatewayDatabase

    • SBMessageContainer*

    System_CAPS_important重要

    WFManagementDB データベースおよび SbManagementDb データベースを復元しないでください。これらのデータベースは、復元操作の一部として再作成されます。

  3. 「復元コマンドを実行するプロセス」で説明されている手順に従います。

シナリオ 2 - 障害が SQL Server データベースのみに影響する

この場合、ワークフロー マネージャー によって使用される 1 つ以上のデータベースが失われるか、アクセスできなくなります。 この原因として、ハードウェアの障害または SQL Server のみに対して発生した他の障害が考えられます。

注意

このシナリオの手順に従って、1 つのデータ センターから別のデータ センターに移行することもできます。その場合、データベースの最新のバックアップを新しいデータ センターに転送し、このセクションで説明されているプロセスを使用します。

  1. いずれかの既存のアプリケーション サーバー ノードから Workflow Manager 1.0 をアンインストールします。

  2. 前の手順のサーバーに Workflow Manager 1.0 を再インストールします。

    注意

    インストーラーを使用して ワークフロー マネージャー をインストールしますが、ファームの構成は開始しないでください。

  3. SQL Server の復元機能を使用して、バックアップしたプライマリ データベースを復元します。 この手順は、選択したバックアップ ソリューションによって変わります。 障害の性質に応じて、既存の SQL Server または別の SQL Server に対して復元します。

  4. 「復元コマンドを実行するプロセス」で説明されている手順に従います。

これらの手順を完了すると、既存のデータベースを使用する 1 つのノードがあるファームが復元されます。 このファームは、元のデータベースのバックアップ コピーを使用して復元され、完全に機能できるよう一貫性のある状態になりました。

プライマリ ファームの一部であるノードごとに、次の手順を実行します。

  1. Workflow Manager 1.0 をアンインストールします。

  2. Workflow Manager 1.0 を再インストールします。

  3. 「復元コマンドを実行するプロセス」の説明に従って、Add-SBHost および Add-WFHost コマンドレットを実行します。

シナリオ 3 - 障害がアプリケーション サーバーのみに影響する

場合によっては、局部的な障害が原因でアプリケーション サーバーのみがクラッシュまたは失われたが、データベース サーバーは影響を受けていないことがあります。 これがデータ センターで発生することはまれですが、このような障害を回復するのは簡単です。 データベースが失われていないので、プライマリ ロケーションで手順を進め、既存のファームに新しいノードを追加します。 なんらかの理由で第 2 の格納場所に移動する場合でも、データベースを第 2 の格納場所にコピーし、回復手順を実行するときに新しいデータベースを参照することができます。

アプリケーション サーバーの障害シナリオから回復するには、次の手順を実行します。

  1. Workflow Manager 1.0 を新しいコンピューターにインストールします。

  2. 次のデータベースを削除します。

    • WFManagementDB

    • SbManagementDB

  3. 「復元コマンドを実行するプロセス」で説明されている手順に従います。

    注意

    データベースを移動した場合は、これらの手順を実行するときに新しいデータベースを参照します。それ以外の場合は、元のデータベースを参照します。

これらの手順が完了すると、既存の (または移動した) データベースを使用する 1 つのノードがあるファームが復元されます。 必要に応じて、ワークフロー マネージャー ファームにさらにノードを追加するのと同じ方法で、ファームにノードを追加できます。

スコープの復元

誤って特定のスコープを削除したり、特定のスコープのコンテンツが破損したりする状況が考えられます。 スコープのコンテンツが正常なときの、ワークフロー マネージャー データベースのバックアップを作成している場合、 このスコープのみのコンテンツを、持っているバックアップ コピーから復元します。

スコープを復元すると、次のコンテンツが復元されます。

  • スコープと子スコープ、およびその構成

  • 復元するスコープ階層内のアクティビティ

  • スコープ階層内のワークフロー、およびその構成

  • スコープ階層内のワークフローのインスタンス

    • インスタンスは最後の永続化ポイントから実行を継続します。

  • これらのインスタンスに対応する追跡レコード

  • このスコープ階層内のワークフローに対する配信不能メッセージ

注意

スコープを削除すると、そのすべてのコンテンツ (インスタンスおよび追跡レコードを含む) は、数分以内にクリーンアップされます (このプロセスは非同期です)。

次の表に、スコープの復元操作で使用される主要な用語の説明を示します。

用語

説明

バックアップ データベース

ワークフロー マネージャー によって使用されるすべてのデータベースのバックアップを作成し、復元する予定のスコープはこのバックアップ コピーで利用できることを前提とします。 つまり、このデータベースはこのスコープのコンテンツをコピーするためのソース データベースとして機能します。

ライブ データベース

この用語は、ワークフロー マネージャー ファームの現在のアクティブなデータベースを指します。 つまり、これはスコープ復元プロセスのターゲット データベースです。

復元するスコープ

バックアップ データベースから復元するスコープ階層内で任意のスコープを指定できます。

ワークフロー マネージャー には、このシナリオを可能にする機能が用意されています。 スコープの復元を達成するために従う必要がある手順を次に示します。

  • スコープ復元プロセス

  • スコープ復元の考慮事項

スコープ復元プロセス

復元するスコープは、ライブ データベースに存在していない必要があります。 したがって、ライブ データベースにこのスコープの破損したコピーが含まれているために、バックアップからスコープを復元する場合は、破損したスコープをライブ データベースから削除する必要があります。

  1. SQL データベースの復元:最初の手順では、「データベースのバックアップの復元 (SQL Server Management Studio)」で示されているように、バックアップを使用して SQL データベースを復元します。

    System_CAPS_important重要

    バックアップ データベースは別のサーバーに復元する必要があります。 ライブ データベースを上書きしないでください。

  2. 次のパラメーターを渡して Restore-WFScope PowerShell コマンドを実行します。

    • 復元するスコープのパス

    • バックアップ リソース DB の接続文字列

    • バックアップ インスタンス DB の接続文字列

    • バックアップが作成された時間。これはおおよその近似値でかまいません。 バックアップが作成された時間がさまざまである場合は、それらのタイムスタンプのうち最も古いものを、この手順の入力値として指定します。

    • ゲートウェイ DB の接続文字列

    • 1 つ以上のコンテナー データベースの接続文字列。 通常は、1 つのコンテナー データベースのみがあります。 サーバーに複数のコンテナー データベースがある場合は、このコマンドレットにそれらすべての接続文字列を指定します。

    この時点で、スコープとコンテンツはライブ データベースに復元され、新しく復元されたバックアップ データベースを削除できます。

スコープ復元の考慮事項

スコープ復元で、バックアップされたデータベースおよび復元されたデータベースからスコープが復元されるときは、復元プロセス全体に関して次の点を考慮してください。

  • スコープを復元できるのは、現在のライブ データベースの以前のバックアップ コピーからのみです。 つまり、特定のスコープを 1 つの ワークフロー マネージャー ファームから別のファームに移動しようとすることはできません。

  • スコープ復元では、スコープとそのすべての子に属しているコンテンツのみが復元されます。 現在のスコープの子階層以外のコンテンツは復元されません。

  • アクティビティまたはワークフローがこのスコープ階層以外の別のアクティビティを参照している場合 (参照されているアクティビティが、復元されるスコープの上位の親スコープにあるなど)、参照されているアクティビティはこの操作では復元されません。 つまり、このようなワークフローは無効となり、このようなワークフローのインスタンスを作成しようとすると、エラーになります。