Lesen und beachten Sie die Automation Anywhere-Dokumentation

Automation Anywhere Automation 360

Inhalt schließen

Inhalte

Inhalt öffnen

Wie 10.x-Daten in Automation 360 kopiert werden

  • Aktualisiert: 7/22/2021
    • Automation 360 v.x
    • Migrieren
    • RPA Workspace

Wie 10.x-Daten in Automation 360 kopiert werden

Nutzer, Rollen, Lizenzen, Anmeldedaten, Bots und Zeitpläne von 10.xwerden als Teil des Kopiervorgangs in Automation 360 kopiert.

Das System kopiert 10.x-Daten in der folgenden Reihenfolge:
  1. Rollen
  2. Nutzer
  3. Anmeldedaten
  4. Bots
  5. Zeitpläne

Wenn beim Kopiervorgang ein Element in der Sequenz aus irgendeinem Grund übersprungen wird, werden auch alle zugehörigen Elemente übersprungen und nicht migriert. Wenn beispielsweise die Rolle „Bot_Manager“ nicht migriert wird und der Nutzer Jane_Smith nur zu dieser Rolle gehört, werden das Nutzerkonto und alle mit dieser Rolle verknüpften Anmeldedaten, Bots oder Zeitpläne ebenfalls nicht migriert.

10.x Elemente Wie 10.x-Elemente in Automation 360 kopiert werden
Nutzer

Wenn Sie 10.x-Nutzer das erste Mal kopieren und das System in Automation 360 auf einen Nutzer mit demselben Namen stößt, benennt der Migrationsprozess den 10.x-Nutzernamen um, indem ein Suffix wie _1, _2 usw. hinzugefügt wird, und kopiert dann den umbenannten Nutzer nach Automation 360. So wird beispielsweise ein doppelter Nutzername Jane_Smith in Automation 360 in Jane_Smith_1 umbenannt. Nachfolgende Datenkopiervorgänge überspringen die zuvor migrierten Nutzerdaten.

Bei Active Directory-Nutzern migriert das System keine doppelten Nutzer. Wenn in Automation 360 bereits ein Domänennutzer mit demselben Namen vorhanden ist, überspringt der Migrationsprozess diesen Nutzer und seine Abhängigkeiten.

Rollen

Wenn Sie 10.x-Rollen zum ersten Mal kopieren, werden duplizierte Systemrollen und nutzerdefinierte Rollen im Migrationsprozess unterschiedlich behandelt. Der Migrationsprozess ordnet 10.x-Systemrollen Automation 360-Systemrollen zu. Beispielsweise werden die 10.x-Rolle „Admin“ und die Rolle „Basic“ der Rolle „AAE_Admin“ bzw. der Rolle „AAE_Basic“ zugeordnet.

Wenn in 10.x und Automation 360 eine nutzerdefinierte Rolle mit demselben Namen vorhanden ist, benennt der Migrationsprozess sie um, indem ein Suffix wie _1, _2 usw. hinzugefügt wird, und kopiert dann die umbenannte Rolle nach Automation 360. Eine doppelte Rolle „Sales_Operations“ wird beispielsweise in Automation 360 in „Sales_Operations_1“ umbenannt.

Bei nachfolgenden Datenkopiervorgängen werden zuvor migrierte Rollen übersprungen.

Lizenzen

Durch den Migrationsprozess werden Nutzern zugewiesene Lizenzen automatisch migriert, sie werden jedoch nicht im Migrationsbericht angezeigt. Wenn der Automation 360-Control Room weniger Bot Creator- oder Bot Runner-Lizenzen als 10.x-Control Room hat und alle Automation 360-Lizenzen aufgebraucht wurden, werden den neu migrierten Nutzern keine Lizenzen zugewiesen. Das System migriert diese Nutzer und die zugehörigen Daten, ohne neue Lizenzen zuzuweisen.

Anmeldedaten

Bei Systemanmeldedaten, die einem migrierten Nutzer zugeordnet sind, migriert das System nur die Systemanmeldedaten „E-Mail-Einstellungen“ und „Einstellungen für Auto-Anmeldung“.

Für vom Control Room-Administrator erstellte Anmeldedaten erstellt das System den Locker AAE_10x_Credentials im Automation 360-Credential Vault und fügt die Anmeldedaten von 10.x als Standardanmeldedaten hinzu. Das System weist den Nutzer, der die 10.x-Daten migriert, als Eigentümer des Lockers AAE_10x_Credentials und alle nutzerdefinierten Rollen als Verbraucher des Lockers zu. Wenn in Automation 360 bereits ein Locker mit dem Namen AAE_10x_Credentials vorhanden ist, fügt das System die migrierten Anmeldedaten in diesem Locker hinzu.
Anmerkung:
  • Die Migration von Anmeldedaten mit mehr als 50 Attributen wird nicht unterstützt.
  • Nutzern, denen in 10.x nur die Rolle AAE_Basic zugewiesen ist, muss eine nutzerdefinierte Rolle in Automation 360 zugewiesen werden, damit sie Verbraucher des AAE_10x_Credential-Lockers sein können.
Für MetaBots, die Bildschirme als Assets enthalten und in diesen Bildschirmen Variablen vom Typ „Passwort“ verwenden, werden in Automation 360 entsprechende Variablen für den Anmeldedatentyp erstellt. Wenn es sich bei der Passwortvariablen in MetaBot um eine Eingabevariable handelt und ein Wert an diese Variable vom übergeordneten Bot in 10.x übergeben wird, führen Sie die folgenden Schritte aus, bevor Sie die migrierten Bots ausführen:
  1. Erstellen Sie die Anmeldedaten mit der Option Standard als Eingabe.
  2. Erstellen Sie einen Locker und verwenden Sie die Anmeldedaten, die Sie im vorherigen Schritt in diesem Locker erstellt haben.
  3. Verwenden Sie im migrierten übergeordneten Bot die von Ihnen erstellten Anmeldedaten, um diese Anmeldedaten an die untergeordneten Bots zu übergeben.
Wenn Sie eine Array-Variable innerhalb einer Schleife verwendet haben, um mehrere Werte an die im MetaBot verwendete Passwortvariable zu übergeben, verwendet der migrierte Bot die von Ihnen erstellten Anmeldedaten, um einen einzelnen Wert zu übergeben.
Bots Wenn in 10.x und Automation 360 ein Bot mit demselben Namen vorhanden ist, überspringt der Kopiervorgang die Bot-Migration und den zugehörigen Zeitplan. Befehle, die Anmeldedatenvariablen in 10.x-Bots verwenden, verwenden nach der Migration den Locker AAE_10x_Credentials.
Wenn Ihr 10.x-Control Room zur Verwendung der SVN-Versionskontrolle konfiguriert ist, kopiert der Vorgang „Daten kopieren“ auch die jeweils neueste Version jedes Bots einschließlich der Abhängigkeiten vom 10.x-Repository in das Automation 360-Repository. Verwenden Sie den Bot-Migrationsassistenten, um die 10.x-Bots zu Automation 360 zu migrieren. Der Versionsverlauf des Bots und seine Abhängigkeiten werden jedoch nicht kopiert und migriert.
Anmerkung: Die Migration der Produktionsversion von 10.x-Bots wird derzeit nicht unterstützt. Als Problemumgehung können Sie die aktuelle Produktionsversion der Bots als neueste Version festlegen und anschließend die Bots migrieren.
Zeitpläne

Wenn in beiden Umgebungen doppelte Zeitpläne vorhanden sind, wird der doppelte Zeitplan migriert und führt in Automation 360 zu zwei Zeitplänen mit demselben Namen.

Die Migration von Zeitplänen schlägt fehl, wenn der zugehörige Nutzer nicht in Automation 360 vorhanden ist.

Feedback senden