April 2022

18. April 2022

Unterstützung für Verbindungen mit mehreren Konten

Hinweis: Diese Funktion ist nur in persönlichen Arbeitsbereichen verfügbar.

Um Automatisierungsprojekte für Verbindungen mit mehreren Konten zu unterstützen, haben wir eine neue Funktion implementiert, mit der Inhaber von persönlichen Arbeitsbereichen diese Konten anzeigen und eines für das Starten des Auftrags angeben können. Sie können das Konto auf der Registerkarte Paketanforderungen ändern, wenn Sie einen Prozess erstellen oder einen vorhandenen bearbeiten. Für jede Verbindung mit mehreren Konten ist eine Dropdownliste verfügbar, mit der Sie die gesamte Liste der verfügbaren Konten sehen und das aktive Konto nach Bedarf ändern können.

Um Ihre Verbindungen zu verwalten oder neue hinzuzufügen, können Sie zum Integration Service springen, indem Sie auf die Schaltfläche klicken.

Weitere Informationen zu Verbindungen finden Sie im Integration Service-Leitfaden.

Von cookie- zu tokenbasierter Authentifizierung

Wir sind von der cookiebasierten Authentifizierung zur tokenbasierten Authentifizierung migriert. Nach dieser Änderung werden Benutzeranmeldeversuche nicht mehr im Orchestrator gespeichert. Infolgedessen sind der /odata/UserLoginAttempts({key})-Endpunkt und der entsprechende Abschnitt Anmeldeversuche auf der Seite Mein Profil im Orchestrator jetzt veraltet und zeigen nur Anmeldeversuche vor dieser Änderung (d. h. Anmeldeversuche mit Cookies). Von nun an können Anmeldeversuche mit Zugriffstokens ausschließlich über Prüfungsprotokolle in Automation Cloud aufgerufen werden. Wenden Sie sich an Ihren Administrator, um Zugriff auf diese Daten anzufordern.

Die tokenbasierte Authentifizierung ändert die Art und Weise, in welcher der Orchestrator die letzte Anmeldezeit eines Benutzers berechnet. Von nun an wird die letzte Anmeldezeit einmal pro Stunde für einen Benutzer berechnet, der den Orchestrator aktiv verwendet.

Angenommen, ein Benutzer verwendet den Orchestrator zwischen 14:10 und 15:00 Uhr. Wenn er um 14:10 Uhr authentifiziert wurde, bedeutet dies, dass 14:10 als seine letzte Anmeldezeit bis zur nächsten stündlichen Prüfung angezeigt wird. Bei der Verwendung vom Orchestrator bis 16:00 Uhr wird 15:10 Uhr als letzte Anmeldezeit des Benutzers angezeigt.

Hier sind die Orte in der Orchestrator-Benutzeroberfläche, bei denen Sie die Änderungen bei der Berechnung der letzten Anmeldezeit für Ihre Benutzer sehen können:

• Seite Rollen zuweisen (Mandant > Zugriff verwalten)

• Seite Persönliche Arbeitsbereiche (Mandant > Ordner > Persönliche Arbeitsbereiche)

  Hinweis: Als Ausnahme von unserer typischen Release-Frequenz ist diese Funktion für Enterprise-Benutzer nicht eine Woche nach dem Community-Release-Datum verfügbar. Stattdessen wird sie Enterprise-Benutzern in der Woche des 2. Mai bereitgestellt.

Autorisieren von API-Aufrufen in Swagger

Sie können jetzt API-Aufrufe in der Swagger-Benutzeroberfläche mit OAuth2 autorisieren.

Hier erfahren Sie, wie Sie ein Zugriffstoken erhalten, Anforderungen senden oder den Zugriff widerrufen.

Weitere Verbesserungen

Elastic Robot Orchestration

• Wenn Sie einem Ordner jetzt einen Elastic Robot Pool hinzufügen, wird der Pool nun auch allen Unterordnern hinzugefügt. So können auch alle Aufträge aus Unterordnern mit Elastic Robot Orchestration ausgeführt werden.
• Wir haben die Einschränkung für einen einzigen Pool pro Ordner beseitigt. Skalieren Sie los!

CyberArk CCP

• Der Orchestrator unterstützt jetzt .cer-Zertifikate als Server-Root-CA-Zertifikate.
• Zertifikatkonfigurationsfehler enthalten jetzt mehr Details zur Ursache des Problems.

5. April 2022

Cloud Robot – Serverless (Vorschau)

Diese Funktion ist nur für Community-Benutzer verfügbar.

Haben Sie sich jemals gefragt, wie Ihr Leben aussehen würde, wenn Sie sich keine Gedanken über die Infrastruktur machen müssten, auf der Ihre Automatisierungen ausgeführt werden?

In den letzten Monaten haben wir es zu unserer obersten Priorität gemacht, dies umzusetzen, und heute präsentieren wir Ihnen UiPath Automation CloudTM Robots – Serverless oder kurz Cloud Robots – Serverless.

Mit Serverless Cloud Robots ist es einfach, die Automatisierung im Hintergrund auszuführen, ohne sich um die notwendige Infrastruktur kümmern zu müssen. Sie bieten Ihnen völlige Freiheit bei der Bereitstellung, Verwaltung, Wartung und Skalierung der zugrunde liegenden Infrastruktur. UiPath übernimmt die gesamte Arbeit im Hintergrund, sodass Sie sich nicht mit Containern, virtuellen Maschinen oder physischen Servern herumschlagen müssen.

Details zu Automation Cloud Robots – Serverless und Anweisungen zu deren Einrichtung finden Sie hier.

4. April 2022

Änderungen an Rollen, API-Edition

API: Neuer Endpunkt für die Zuweisung von Rollen

Ein neuer Endpunkt ist jetzt in der Orchestrator-API verfügbar, um Rollen zuzuweisen oder die zugewiesenen Rollen für ein vorhandenes Konto zu überschreiben:

Posten /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles

Dieser Endpunkt wurde im Vergleich zu unseren vorhandenen Benutzerendpunkten verbessert, da er Rollen basierend auf der Rollen-ID und nicht auf dem Rollennamen zuweist, was ihn zuverlässiger macht.

Sie finden den neuen Endpunkt im Swagger der Orchestrator-API, verfügbar unter <OrchestratorURL>/swagger.

API-Leitfaden: Zuweisen von Rollen

API: Grundlegende Änderungen

Durch die anderen neuen Verbesserungen an Rollen (Details hier und hier), die zur Umbenennung einiger Rollen führten, müssen alle API-Aufrufe, die auf eine umbenannte Rolle verweisen, mit dem neuen Rollennamen aktualisiert werden.

Dies wirkt sich aus auf:

• API-Aufrufe im Zusammenhang mit einer benutzerdefinierten Version einer Standardrolle, die jetzt in „Role name – Benutzerdefiniert“ umbenannt wird
  Wichtig: Diese Aufrufe funktionieren weiterhin, ohne Änderungen vorzunehmen, aber das Ergebnis ist nicht wie erwartet. Denn der Aufruf weist nun die Standardrolle anstelle der benutzerdefinierten Version der Rolle zu.

• API-Aufrufe im Zusammenhang mit der alten Tenant Administrator-Rolle, die jetzt Orchestrator Administrator heißt.

  Diese Aufrufe sind mit einem Fehler fehlgeschlagen, da keine Rolle mit dem angegebenen Namen gefunden werden konnte.

Betroffene Endpunkte

Die folgenden Anforderungen können eine Rolle basierend auf dem Rollennamen zuweisen:

• POST /odata/Users
• PUT /odata/Users({key})
• PATCH /odata/Users({key})
• POST /odata/Users({key})/UiPath.Server.Configuration.OData.ToggleRole

Behebung

Um dieses Problem zu beheben, können Sie den neuen Endpunkt verwenden, um Rollen basierend auf der Rollen-ID anstelle des Rollennamens zuzuweisen.

Es gibt zwei Möglichkeiten, Ihre Integrationen zu aktualisieren, die von dieser Änderung betroffen waren, damit sie wie erwartet funktionieren:

A. Fügen Sie einen zweiten API-Aufruf hinzu (empfohlen)

Sie können Ihre vorhandenen API-Anforderungen unverändert lassen, aber folgen Sie jedem Aufruf, der Rollen zuweist, mit einem Aufruf des neuen Endpunkts, um die zugewiesenen Rollen mit korrigierten zu überschreiben.

Beispiel: Wenn Sie eine POST-Anforderung an /odata/Users haben, um ein Tenant Administrator-Konto zu erstellen – also wenn die Anforderung im Rahmen der Kontoerstellung versucht, die Tenant Administrator-Rolle zuzuweisen, die in Orchestrator Administrator umbenannt wurde – dann sollten Sie danach eine neue POST-Anforderung an /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles stellen, welche die Rollen-ID für die Orchestrator Administrator-Rolle übergibt, damit sie korrekt zugewiesen wird.

Für diese Behebungsmethode müssen Sie in Ihrer Integration betroffene Anforderungen identifizieren und dann für jede identifizierte Anforderung Folgendes ausführen:

1. Notieren Sie sich die Benutzer-ID und die Rollennamen, die von der betroffenen Anforderung zugewiesen werden sollen.
2. Stellen Sie eine GET-Anforderung an /odata/Roles, um die aktuelle Liste der Rollen abzurufen.
3. Notieren Sie sich die IDs für die Rollennamen, die Sie sich zuvor notiert haben.

4. (Optional, aber empfohlen) Aktualisieren Sie in Ihrer Integration die betroffene Anforderung, um die Rollennameneigenschaft zu entfernen.

   Mit dieser Änderung weist die Anforderung keine Rollen mehr zu und die Anforderung im nächsten Schritt übernimmt ab jetzt die Zuweisung von Rollen.

   Sie müssen die Rolleneigenschaft nicht von dieser Anforderung entfernen, da die Anforderung im nächsten Schritt alle zugewiesenen Rollen überschreibt.

5. Fügen Sie unmittelbar nach der betroffenen Anforderung eine POST-Anforderung zu /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles hinzu, einschließlich der Rollen-IDs im Textkörper der Anforderung.
   Der {key}-Wert muss die Benutzer-ID der betroffenen Anforderung sein.

Dadurch wird sichergestellt, dass alle Rollen, welche die betroffene Anforderung, die Sie identifiziert haben, zugewiesen hätte, sofort mit den richtigen Rollen überschrieben werden.

B. Aktualisieren Sie die Rollennamen

Eine einfachere, aber weniger effiziente Behebungsmethode ist die Aktualisierung der betroffenen Anforderungen mit den neuen Rollennamen.

Hinweis: Auch wenn diese Methode einfacher ist, empfehlen wir, stattdessen die vorherige Methode zu verwenden, da sie Ihre Integration vor späteren Änderungen der Rollennamen schützt.

Für diese Behebungsmethode müssen Sie in Ihrer Integration betroffene Anforderungen identifizieren und dann für jede identifizierte Anforderung Folgendes ausführen:

1. Stellen Sie eine GET-Anforderung an /odata/Roles, um die aktuelle Liste der Rollen abzurufen.
2. Notieren Sie sich den aktuellen Namen für die Rollennamen, welche die betroffenen Anforderungen zuweisen.
3. Aktualisieren Sie in Ihrer Integration die Rollennameneigenschaftswerte in der betroffenen Anforderung mit den aktualisierten Rollennamen.

API: Hinweis zu veralteter Eigenschaft

Aufgrund der letzten Änderungen und da wir die Möglichkeit behalten möchten, Rollen in Zukunft ohne Auswirkungen auf Sie zu aktualisieren, wird die Verwendung der Rollenname-Eigenschaft in der Orchestrator-API bald veraltet sein.

Wir werden diese Eigenschaft ab heute noch mindestens 6 Monate lang unterstützen.

Wir empfehlen aber, mit der Verwendung des neuen Endpunkts für die Zuweisung von Rollen zu beginnen, um grundlegende Veränderungen zu vermeiden, wenn die Eigenschaft veraltet ist.

Verbesserungen

Wir haben die maximale Anzahl der für Rollennamen zulässigen Zeichen von 32 auf 64 Zeichen erhöht.

Erratum 02. November 2022: Die Nutzlast des jobs.created -Webhooks für den Testfall zeigt jetzt die spezifische Roboter-ID und die Maschine an, die für die Auftragsausführung verwendet wird.

Fehlerkorrekturen (Bug Fixes)

Wir haben die Berechtigungen zum Anzeigen für Roboter als Voraussetzung zum Starten oder Erstellen von Aufträgen in modernen Ordnern hinzugefügt. Dadurch ist die Schaltfläche zum Starten des Auftrags inaktiv, bis Sie die erforderlichen Berechtigungen zuweisen, die im Schaltflächen-Tooltip angezeigt werden. Wenn Sie zuvor Aufträge in modernen Ordnern gestartet oder erstellt haben, wurde die Fehlermeldung You are not authorized! (#0) angezeigt.