手順 5: 組織を Automation Suite にマージする

移行ツールの入力

UiPath.OrganizationMigrationApp ツールを実行する際は、以下の詳細情報を指定する必要があります。

• スタンドアロン製品の組織 ID のリスト
• Automation Suite の組織 ID のリスト

詳しくは、「 移行ツールのパラメーター」をご覧ください。

注:

「手順 1: ID 組織のデータをスタンドアロンから Automation Suite に移動する」で特定した組織 ID と同じ組織 ID を使用してください。

(Linux 用)

注:

必ず、選択したシェル ツールの一般的なエスケープ手順に従ってください。たとえば、Bash では、特殊文字の前に \ を追加する必要があります。

組織を Automation Suite にマージするには、次のコマンドを実行します。

./UiPath.OrganizationMigrationApp merge -i '<identity database connection of Automation Suite>' -o '<restored orchestrator DB in Automation Suite connection string>' -s '<list of tenant IDs of the standalone product separated by comma, e.g. tenantID1,tenantID2>' -d '<list of organization IDs of Automation Suite separated by comma, e.g. orgID1,orgID2>'

注:

• 入力内のソース SQL 接続と宛先 SQL 接続の両方に対して TrustServerCertificate=True を必ず追加してください。
• マージする組織のペアが複数ある場合は、スタンドアロン製品の組織 ID のシーケンスと Automation Suite の組織 ID のシーケンスが一致することを確認してください。
• すべてのテナントに対して、1 つのスタンドアロン テナントを 1 つの Automation Suite 組織に移行する場合、すべての移行に対して コマンドを 1 回実行できます。ただし、複数のスタンドアロン テナントを 1 つの Automation Suite 組織に移行する場合は、テナント間でのユーザーの競合の解決が必要になる場合があるため、テナントごとに個別にコマンドを実行する必要があります。次のサンプルは、テナントごとにコマンドを個別に実行する方法を示しています。

./UiPath.OrganizationMigrationApp merge -i '<identity database connection of Automation Suite>' -o '<restored orchestrator DB in Automation Suite connection string>' -s 'tenant1' -d 'orgId1'
./UiPath.OrganizationMigrationApp merge -i '<identity database connection of Automation Suite>' -o '<restored orchestrator DB in Automation Suite connection string>' -s 'tenant2' -d 'orgId1'
./UiPath.OrganizationMigrationApp merge -i '<identity database connection of Automation Suite>' -o '<restored orchestrator DB in Automation Suite connection string>' -s 'tenant3' -d 'orgId1'

複数のスタンドアロン テナントを 1 つの Automation Suite 組織に移行する際のユーザーの競合に対処する方法については、「 ユーザーの競合を解決する」をご覧ください。

(Windows 用)

組織を Automation Suite にマージするには、次のコマンドを実行します。

./UiPath.OrganizationMigrationApp merge -i "<identity database connection of Automation Suite>" -o "<restored orchestrator DB in Automation Suite connection string>" -s "<list of tenant IDs of the standalone product separated by comma, e.g. tenantID1,tenantID2>" -d "<list of organization IDs of Automation Suite separated by comma, e.g. orgID1,orgID2>"

注:

• 入力内のソース SQL 接続文字列と宛先 SQL 接続文字列の両方に対して TrustServerCertificate=True を必ず追加してください。
• すべてのテナントに対して、1 つのスタンドアロン テナントを 1 つの Automation Suite 組織に移行する場合、すべての移行に対して コマンドを 1 回実行できます。ただし、複数のスタンドアロン テナントを 1 つの Automation Suite 組織に移行する場合は、テナント間でのユーザーの競合の解決が必要になる場合があるため、テナントごとに個別にコマンドを実行する必要があります。次のサンプルは、テナントごとにコマンドを個別に実行する方法を示しています。

./UiPath.OrganizationMigrationApp merge -i '<identity database connection of Automation Suite>' -o '<restored orchestrator DB in Automation Suite connection string>' -s 'tenant1' -d 'orgId1'
./UiPath.OrganizationMigrationApp merge -i '<identity database connection of Automation Suite>' -o '<restored orchestrator DB in Automation Suite connection string>' -s 'tenant2' -d 'orgId1'
./UiPath.OrganizationMigrationApp merge -i '<identity database connection of Automation Suite>' -o '<restored orchestrator DB in Automation Suite connection string>' -s 'tenant3' -d 'orgId1'

複数のスタンドアロン製品のテナントを 1 つの Automation Suite 組織に移行する際に、ユーザーの競合に対処する方法については、「 ユーザーの競合を解決する」をご覧ください。

結合に関する期待

ユーザー

注:

Automation Suite への移行後は、スタンドアロンの Orchestrator にアクセスできるのは、スタンドアロンの Orchestrator を起源とするユーザーのみです。

次の表に、複数の移行シナリオと、それらがユーザーに与える影響についての洞察を示します。

条件	結合元のユーザーはメール アドレスを持っているか	結合先のユーザーはメール アドレスを持っているか	結合元のユーザーのメール アドレスは結合先のユーザーと同じか	結合元のユーザー名は結合先のユーザー名と同じか	結果
1	✅	✅	❌	❌	結合元のユーザーは結合先の組織に移動され、結合先の組織のユーザーがスタンドアロンの Orchestrator にアクセスできます。
2	✅	✅	❌	✅	結合元のユーザーは結合先の組織に移動され、結合先の組織のユーザーがスタンドアロンの Orchestrator にアクセスできます。 結合後、2 人のユーザーが同じユーザー名を持ち、そのメール アドレスを使用してログインする必要があります。
3	✅	✅	✅	✅ または ❌	結合元のユーザーは結合先のユーザーにマージされ、結合先のユーザーがスタンドアロンの Orchestrator にアクセスできます。
4	❌	❌	N/A	❌	結合元のユーザーは結合先の組織に移動され、結合先の組織のユーザーがスタンドアロンの Orchestrator にアクセスできます。
5	❌	❌	N/A	✅	結合元のユーザーは結合先のユーザーにマージされ、結合先のユーザーがスタンドアロンの Orchestrator にアクセスできます。
6	✅	❌	N/A	❌	結合元のユーザーは結合先の組織に移動され、結合先の組織のユーザーがスタンドアロンの Orchestrator にアクセスできます。
7	✅	❌	N/A	✅	結合先のユーザーのメール アドレスを手動で設定するか、結合先のユーザーを削除する必要があります。 メール アドレスを設定すると、結合元のユーザーは結合先のユーザーにマージされ、結合先のユーザーがスタンドアロンの Orchestrator にアクセスできます。 結合先のユーザーを削除すると、結合元のユーザーは結合先の組織に移動され、結合先の組織のユーザーがスタンドアロンの Orchestrator にアクセスできます。
8	❌	✅	N/A	❌	結合元のユーザーは結合先の組織に移動され、結合先の組織のユーザーがスタンドアロンの Orchestrator にアクセスできます。
9	❌	✅	N/A	✅	結合先のユーザーのメール アドレスを空に設定するか、結合先のユーザーを削除する必要があります。 メール アドレスを空に設定すると、結合元のユーザーは結合先のユーザーにマージされ、結合先のユーザーがスタンドアロンの Orchestrator にアクセスできます。 結合先のユーザーを削除すると、結合元のユーザーは結合先の組織に移動され、結合先の組織のユーザーがスタンドアロンの Orchestrator にアクセスできます。

ロボット ユーザー

結合元のロボット ユーザー名と結合先のロボットユーザー名が同じ場合、結合元のロボット ユーザーにユーザー ID が追加されて、結合先の組織に移動されます。

結合元のロボット ユーザー名	結合先のロボット ユーザー名	移動後の結合元のロボットのユーザー名
sameRobot	sameRobot	sameRobot_47a26d4a-2180-4fdd-8e1e-2379300a1162

グループ

結合元と結合先のロボット グループ名が同じ場合、結合元のロボット ユーザーに文字列が追加されて、結合先の組織に移動されます。

結合元のグループ名	結合先のグループ名	移動後のソース グループのユーザー名
sameGroup	sameGroup	sameGroup_db39a5c6-f73c-4011-b40e-4ea620fe3d01

設定

結合元の設定と結合先の設定が同じ名前の場合、結合先の設定の値が使用されます。

組織結合後に Insights を有効化する

Insights を移行する場合は、結合の完了後に各組織にログインし、これまでスタンドアロン (MSI) 環境で Insights が有効化されていた各テナントに対して Insights を有効化します。

移行後に Automation Suite が使用する Insights データベースではすでに Insights が有効化されているため、この手順は必須です。この手順をスキップすると、Automation Suite がテナントに対して Insights が有効化されているように見えても、対応する Insights インスタンスがプラットフォームに登録されていないステートになることがあります。

注:

接続文字列を更新する前に、各テナントで Insights を有効化します。これにより、Insights が移行対象のデータベースに正しくリンクされ、構成の不整合が防止されます。

ユーザーの競合の解決

複数のスタンドアロン テナントを 1 つの Automation Suite 組織に移行すると、ユーザーの競合が発生する可能性があります。次の例は、このような競合に対するエラー メッセージを示しています。

[03:18:08 WRN] We found users in the target organization have the same email as those from the source organization. If you continue, we will keep the users in the target organization, but none of the application data for the source organization users will be moved.
The format is orgId -> list of emails.
[03:18:08 WRN] 3d8d01e6-3300-4988-87db-071bd8c8e786 -> [e-mail],[e-mail],[e-mail],[e-mail]
[03:18:08 WRN] We found users without emails in the target organization have the same username with the users without emails from the source organization.If you continue, we will keep the users in the target organization, but none of the application data for the source organization users will be moved.
The format is orgId -> list of usernames.
[03:18:08 WRN] 3d8d01e6-3300-4988-87db-071bd8c8e786 -> user1
[03:18:08 INF] Do you want to continue? Type (y/n)

ユーザーの競合は、次の 2 つの方法で解決できます。

• 「 n 」と入力して結合プロセスを終了し、Automation Suite 組織内で競合があるユーザーを削除してから、結合コマンドを再度実行します。 このオプションを選択すると、削除されたユーザー情報が失われます。

• 「 y 」と入力して、結合プロセスを続行します。 このオプションを選択すると、すべてのソース・ユーザー ID がターゲット・ユーザー ID に置き換えられます。 Automation Suite で実行されている製品 (Insights など) にユーザー ID への参照がある場合、スタンドアロン環境からマージされたユーザーのデータは失われます。 たとえば、2 人のユーザーを想定します。

  • スタンドアロン環境で tenant1 のユーザー名user1とメール アドレス [e-mail]を持つ 1 人のユーザー
  • スタンドアロン環境で tenant2 から、同じユーザー名とメール アドレスを使用する別の使用。

  最初に Automation Suite の組織に tenant1 マージした場合、競合は発生しません。 しかし、 tenant2 同じ Automation Suite 組織にマージすると、2 人のユーザーが同じメール アドレス [e-mail]を持っているため、競合が発生します。 yを入力して結合処理を続行すると、製品が tenant2からユーザーを参照しているユーザー データは失われます。

組織のマージに失敗した場合

組織のマージに失敗した場合は、ログを確認します。移行が失敗したのが Identity か Orchestrator かによって、以下の手順を実行します。

Identity の移行が失敗した

Identity の移行が失敗した場合は、エラーを修正して組織のマージ コマンドを再度実行できます。Identity の操作に対してトランザクションが設定されているため、すべての変更がロールバックされます。

Orchestrator の移行に失敗した

Orchestrator の移行に失敗した場合、Orchestrator データベースはロールバックされますが、Identity データベースはロールバックされません。このため、Identity データベースのバックアップを復元し、接続文字列を置換してから新しいデータベースを使用する必要があります。エラーを修正したら、組織のマージ コマンドを再度実行します。

Orchestrator の移行に失敗した場合は、次の手順を実行します。

1. Identity データベースのバックアップを復元します。

   1. データベース ディレクトリを右クリックして、[Import Data-tier Application] を選択します。

      

   2. バックアップ データベース ファイルを選択します。

      

   3. バックアップ データベース名を入力します。

      

   4. プロセスが完了するまで待ちます。

      

2. Identity の接続文字列を置換します。

   `"platform": {
       "sql_connection_str": "<dotnet connection string>",   (added line)
       "enabled": true, 
   },`
   

3. エラーを修正し、新しいプラットフォームの接続文字列を使用して、マージ コマンドを再び実行します。