Februar 2022

28. Februar 2022

Neuer Anmeldeinformationsspeicher jetzt verfügbar

You can now choose from a wider selection of plugins to store your Orchestrator credentials. BeyondTrust, a new credential store, is now integrated with Orchestrator. For configuration instructions, see Beyond Trust integration.

25. Februar 2022

OAuth 2.0-basiertes Framework für die Roboterauthentifizierung

In this release, we ship a new robot authentication mechanism that uses the OAuth 2.0 framework as the basis for its authentication protocol, meaning unattended robots can connect to Orchestrator using a client ID - client secret pair generated via machine template objects. The client ID - client secret pair generates a token that authorizes the connection and provides the robot with access to Orchestrator resources.

Client-Anmeldeinformationen ermöglichen dem UiPath Roboter den Zugriff auf Ressourcen, indem er seine eigenen Anmeldeinformationen verwendet, anstatt sich als ein Benutzer auszugeben. Wenn der Roboter Ressourcen vom Orchestrator anfordert, erzwingt der Orchestrator, dass der Roboter selbst über die Autorisierung zum Ausführen einer Aktion verfügt, da an der Authentifizierung kein Benutzer beteiligt ist.

Wichtig:

Client credentials require the UiPath Robot 2022.2 or higher. As an exception to our typical release cadence, client credentials do not become available to Enterprise users one week after the Community release date. Instead, the feature will be shipped to Enterprise users alongside the 2022.4 enterprise release of the UiPath Robot.

Mehr zur Roboterauthentifizierung.

Instructions for administrators on how to manage client credentials (create new credentials, revoke access).

Intstructions for RPA developers and attended users on how to connect their robots to Orchestrator.

24. Februar 2022

Verbesserungen bei den Rollen

We provide several default roles in Orchestrator to make access assignment for the main use cases easy and to serve as a functioning base for any new customer that is just starting with the environment. After getting familiar with the ecosystem and understanding your particular use cases for automation, you could edit these roles, or create new ones to suit your needs.

Aber die Grundlagen bleiben immer relevant. Daher möchten wir sicherstellen, dass diese Rollen für Sie so verfügbar bleiben, wie sie vorgesehen waren – als Standard.

Aus diesem Grund haben wir mehrere Verbesserungen an Rollen und Berechtigungen vorgenommen, insbesondere in Bezug auf die Standardrollen für moderne Ordner.

Standardrollen sind standardmäßig verfügbar

Sie müssen Ihrem Mandanten nicht mehr die Standardrollen aus den Orchestrator-Einstellungen hinzufügen. Jetzt sind sie standardmäßig verfügbar für alle neuen Mandanten oder Mandanten, die sie noch nicht manuell hinzugefügt haben.

Die Optionen zum Hinzufügen dieser Rollen von der Seite Einstellungen (Registerkarte Allgemein) auf Mandantenebene wurden entfernt.

Standardrollen sind jetzt schreibgeschützt

Sie können die Standardrollen nicht mehr bearbeiten. Sie können ihre enthaltenen Berechtigungen anzeigen, aber Sie können die Berechtigungen nicht mehr ändern.

Wenn Sie eine benutzerdefinierte Version benötigen, müssen Sie eine neue Rolle mit den erforderlichen Berechtigungen erstellen.

Benutzerdefinierte Versionen von Standardrollen werden in „Benutzerdefiniert“ umbenannt

Wenn Sie Standardrollen durch Ändern der Berechtigungen angepasst haben – keine Sorge, sie sind sicher. Wir haben alle Ihre benutzerdefinierten Rollen in Rollenname – Benutzerdefiniert umbenannt, damit Sie wissen, welche die standardmäßigen und welche Ihre benutzerdefinierten sind.

Wenn Sie beispielsweise die Berechtigungen der Standardrolle Automation User angepasst haben, haben Sie jetzt die folgenden Rollen:

Rolle	Ursprung	Kann bearbeiten?	Kann zuweisen?	Berechtigungen
Automation User	System	N	Y	Standard
Automation User – Benutzerdefiniert	Benutzerdefiniert	Y	Y	Benutzerdefiniert

Hinweis:

Auch wenn Ihre benutzerdefinierten Rollen jetzt einen neuen Namen haben, ist allen Konten oder Gruppen, denen die betroffenen Rollen zugewiesen waren, jetzt die umbenannte Version zugewiesen. Sie müssen also keine Maßnahmen nach dieser Änderung ergreifen. Alles funktioniert wie gewohnt.

Rollen duplizieren und anpassen

Wir haben eine neue Option für Rollen hinzugefügt, mit der Sie eine Ihrer vorhandenen Rollen kopieren und anpassen können. Diese Option ist sowohl für Standardrollen als auch für benutzerdefinierte Rollen verfügbar, aber nicht für gemischte Rollen.

Da Standardrollen jetzt schreibgeschützt sind, ist das die neue Möglichkeit, um sie anzupassen, wenn Sie eine Standardrolle möchten, aber ein paar Anpassungen gewünscht sind.

To use this option, go to Tenant > Manage Access > Roles, click (more options) at the right of a row, and select Duplicate & customize.

Rollenexport und -import

Sie können jetzt jede Ihrer vorhandenen Rollen im CSV-Format exportieren und in diesem Format wieder beim Orchestrator importieren. Dadurch können Sie Ihren sorgfältig angelegten Satz von Rollen organisations- und mandantenübergreifend wiederverwenden.

Exportieren einer Rolle und Importieren einer Rolle

22. Februar 2022

Neuer Anmeldeinformationsspeicher

You can now choose from a wider selection of plugins to store your Orchestrator credentials. HashiCorp Vault, a new credential store, is now integrated with Orchestrator. For configuration instructions, see HashiCorp Vault.

Inhalt von Warteschlangenelementen über API löschen

• Prevent queue items data tracing by deleting the value of the SpecificContent key via API. Use the PUT /odata/QueueItem({Id}) endpoint with the type of payload described in our documentation.

7. Februar 2022

Neuer(er) Warteschlangen-Trigger-Mechanismus zum Starten von Aufträgen über Warteschlangen-Trigger

Nach einigem Hin und Her im Bereich der Warteschlangen-Trigger verbessern wir das Starten von Aufträgen durch Warteschlangen-Trigger mit der bisher besten und hoffentlich finalen Implementierung.

Problembeschreibung: Immer wenn Ihre Warteschlangen weniger neue Elemente als Elemente in Bearbeitung enthielten, wurden keine Aufträge gestartet, obwohl Roboter inaktiv waren. Das geschah, weil die Anzahl der ausgeführten Aufträge (aktiv verarbeiteten Warteschlangenelemente) die Anzahl der Zielaufträge (erforderlichen Aufträge zur Verarbeitung der neuen Elemente) überschritten hat.

Ursprüngliche Lösung: Der Orchestrator berücksichtigte bei der Berechnung der Anzahl der Zielaufträge sowohl neue als auch in Bearbeitung befindliche Warteschlangenelemente, anstatt nur neue Elemente. Klang gut. Funktionierte nicht.

Brandneue Lösung: Der Orchestrator berücksichtigt bei der Berechnung der Anzahl der Zielaufträge die neuen Elemente, überprüft aber die Anzahl der ausstehenden Aufträge, wenn er entscheidet, ob ein neuer Auftrag gestartet werden soll oder nicht.

• Angenommen, Sie haben 2 neue Elemente in einer Warteschlange und es sind 2 ausstehende Aufträge vorhanden => dann werden keine neuen Aufträge gestartet.
• Angenommen, Sie haben 2 neue Elemente und es ist 1 ausstehender Auftrag vorhanden => dann wird 1 neuer Auftrag gestartet.

Dadurch wird sichergestellt, dass der Orchestrator genügend Aufträge startet, um alle neuen Elemente zu verarbeiten, ohne überlastet zu werden.

Neuer Berechtigungssatz

Dieser Release enthält einen neuen Satz von Ordnerberechtigungen für Verbindungen. Die Berechtigungen haben vorerst keinen tatsächlichen Nutzen, sie sind Teil einer zukünftigen Funktion.

Verbesserungen

• Um Ihnen dabei zu helfen, Fehlkonfigurationen auf Auftrags- oder Trigger-Ebene zu identifizieren, können Sie ab sofort beim Starten eines Auftrags oder Konfigurieren eines Triggers deutlich sehen, ob bestimmte Runtimes im enthaltenden Ordner konfiguriert wurden oder nicht.

Auf Auftragsebene stehen nur Runtimes zur Auswahl, die Maschinen im Ordner zugewiesen wurden. Der Versuch, nicht zugewiesene Runtimes auszuwählen, schlägt fehl und es wird dann ein Tooltip mit einer Erklärung des Verhaltens angezeigt.

Auf Trigger-Ebene können zwar auch Runtimes ausgewählt werden, die keinen Maschinen im Ordner zugewiesen sind, aber Sie können sie einfach anhand eines Warnsymbols erkennen.

• Zuvor konnten Sie keine Test-Runtimes für Remote-Debugging vom Studio oder bei der dynamischen Zuordnung im Orchestrator verwenden. Beide Vorgänge erlaubten nur die Verwendung von Non-Production- oder Unattended-Runtimes. Mit diesem Release ist beides mit Test-Runtimes möglich.

  

• Bei Automation Cloud™-Robotern bedeutet das Starten eines Auftrags mit Konto-/Maschinenzuweisung bei Wiederaufnahme des Auftrags beibehalten jetzt, dass der Auftrag auf einer Maschine aus dem gleichen Pool fortgesetzt wird – also auf einer Maschine des gleichen Typs, nicht unbedingt auf genau derselben Maschine.

  

• Sie können jetzt die Transaktionen einer Warteschlange nach dem Roboter filtern, der die Transaktionen verarbeitet hat. Im Dropdownmenü des Roboter-Filters werden die Roboter angezeigt, die im entsprechenden modernen Ordner vorhanden sind. Um die verfügbaren Roboter anzuzeigen, benötigen Sie Berechtigungen zum Anzeigen für Benutzer.

  

Fehlerkorrekturen (Bug Fixes)

• Occasionally, test set and test schedule executions failed with the following error: System.Data.Entity.Core.EntityException: The underlying provider failed on Open.System.PlatformNotSupportedException: This platform does not support distributed transactions. Test sets and test schedules are now executed with no errors.
• Zuvor bewirkte das Löschen eines Orchestrator-Ordners, der einen Azure-Speicher-Bucket enthielt, dass alle Daten endgültig aus Azure gelöscht wurden. Jetzt führt der Orchestrator beim Löschen eines Ordners einen vorläufigen Löschvorgang durch, sodass die Daten für Orchestrator-Benutzer nicht mehr verfügbar sind, aber in Azure verfügbar bleiben.