2020.10.4

Release-Datum: 15. Dezember 2020

Neuigkeiten

CyberArk® CCP-Integration

Viele gute Nachrichten im Vorfeld, denn wir haben unsere Funktionalität für den Anmeldeinformationsspeicher erweitert und verbessert, indem wir CyberArk CCP in Orchestrator integriert haben

Überblick

Der Central Credential Provider (CCP) ist die agentenlose AAM-Methode, die zur Integration des Orchestrators mit CyberArk verwendet wird. Er ermöglicht das Abrufen vertraulicher Informationen wie Roboteranmeldeinformationen und Anmeldeinformations-Assets aus CyberArk, ohne einen Agenten auf dem Server bereitzustellen, da Kennwörter, die in einem Tresor gespeichert sind, beim Central Credential Provider abgefragt werden, wo sie von autorisierten Remote-Anwendungen abgerufen werden können. Ein Client-Zertifikat ist erforderlich, um den sicheren Abruf der Anmeldeinformationen sicherzustellen.

Um eine erfolgreiche Integration mit CyberArk® CCP zu erreichen, empfehlen wir Ihnen, einen Blick auf die korrekte Einrichtung Ihrer Umgebung in CyberArk® PVWA zu werfen:

Nach dem Upgrade auf v2020.10.4 wird CyberArk CCP automatisch aktiviert, wenn Sie CyberArk in Ihrer Instance vor dem Upgrade aktiviert hatten. Wenn dies nicht Ihr Fall ist, fügen Sie UiPath.Orchestrator.SecureStore.CyberArkCCP.dll zum Plugins.SecureStores -Parameter in UiPath.Orchestrator.dll.config hinzu, um ihn zu aktivieren.

Verbesserungen

Job Count Strategien

In dieser Version geben wir Ihnen die volle Kontrolle über die Job-Count-Strategie für Aufträge, die über Trigger gestartet werden. Der Parameter Triggers.JobsCountStrategy ermöglicht es Ihnen, die Strategie auszuwählen, die Ihren Anforderungen am besten entspricht:

PerProcess ‑ Ein Trigger startet die erforderliche Anzahl von Aufträgen unter Berücksichtigung jeglicher ausstehender Aufträge für den angegebenen Prozess. Beispielsweise starten zwei Trigger, die für denselben Prozess definiert sind, 3 bzw. 5 Aufträge. Falls der erste Trigger 3 Aufträge zu einem bestimmten Zeitpunkt startet, wenn der zweite Trigger ausgelöst wird, werden 2 Aufträge gestartet, um die 5 erforderlichen Aufträge zu erreichen.
PerTrigger ‑ Ein Trigger startet die erforderliche Anzahl von Aufträgen unter Berücksichtigung vorhandener Aufträge, die zuvor von demselben Trigger gestartet wurden. Beispielsweise wird ein Trigger definiert, um 9 Aufträge zu einem bestimmten Zeitpunkt zu starten. Wenn 2 Aufträge bis zum erneuten Auslösen dieses Triggers erfolgreich abgeschlossen wurden, startet der Orchestrator weitere 2 Aufträge, um die erforderlichen 9 Aufträge zu erreichen.
NoLimit ‑ Der Trigger startet die erforderliche Anzahl von Aufträgen unabhängig von vorhandenen, ausstehenden Aufträgen. Beispielsweise wird ein Trigger definiert, um 5 Aufträge zu einem bestimmten Zeitpunkt zu starten. Beim zweiten Auslösen des Triggers werden weitere 5 Aufträge gestartet.

Lesen Sie mehr über den Parameter Triggers.JobsCountStrategy.

Persistenzaktivitäten ‑ Support

In dieser Version haben wir Unterstützung für Persistenzaktivitäten in Warteschlangenelement-basierten Workflows hinzugefügt. Zuvor gab Orchestrator Warteschlangenelemente auf, die länger als 24 Stunden in Arbeit waren, und störte so lang andauernde Workflows, die die 24-Stunden-Barriere überschritten haben. Diese Einschränkung wurde aufgehoben, so dass Sie menschliche Beiträge in Bezug auf Ihre Transaktionen erhalten können, ohne auf Zeit gedrängt zu werden.

Wichtig: Diese Funktion wurde nicht in 2020.10.4 geliefert, wie in den Versionshinweisen angegeben, aufgrund eines Missgeschicks von unserer Seite. Es ist unsere Priorität, es dem folgenden Orchestrator-Patch hinzuzufügen. Das 24-Stunden-Limit für laufende Warteschlangenelemente bleibt bestehen, bis unser Team es in die nächste Version einnimmt.

Einrichten

Es wird nun empfohlen, den passiven Modus für sekundäre Knoteninstallationen zu verwenden. Sie können den Parameter /passive angeben, um eine eingeschränkte Benutzeroberfläche mit einem Fortschrittsbalken und Fehler-Popups zu aktivieren. Obwohl bisher nur der stille Modus verfügbar war, sollten Sie /Q jetzt ausschließlich für unbeaufsichtigte Installationen verwenden.

Sonstige

Sie können jetzt steuern, ob Anmeldefehlercodes in der Benutzeroberfläche angezeigt werden oder nicht, indem Sie den Parameter HideErrorCodesInUi in der Identity Server- appsettings.Production.json -Datei verwenden.
Wenn das Element <system.webServer> in web.config gesperrte Abschnitte enthält, kann die Funktionsweise des Orchestrators beeinträchtigt werden. Deshalb haben wir im Plattform-Konfigurationstool eine zusätzliche Überprüfung hinzugefügt, bei der das gesamte <system.webServer>-Element auf gesperrte Abschnitte geprüft wird. Wenn solche Abschnitte vorhanden sind, müssen Sie sie manuell in IIS entsperren.
Um Verwirrung darüber zu vermeiden, was die Schaltfläche Immer ausgeführte Prozesse tut, haben wir sie in Prozess umbenannt und können nicht vom UiPath Assistant angehalten werden. Wenn Sie diese Funktionalität auf der Seite Prozesse-Einstellungen aktivieren, können Sie den entsprechenden Prozess nicht über den UiPath-Assistenten beenden.

Fehlerkorrekturen (Bug Fixes)

Alle Protokolle, die vor 2019.10 generiert wurden, wurden auf der Seite Protokolle angezeigt, ohne nach dem enthaltenden Ordner (früher Organisationseinheit) gefiltert zu werden. Wir haben die neue Einstellung UiPath.Orchestrator.dll.config (Logs.Elasticsearch.EnableFolderIdFilter) hinzugefügt und standardmäßig aktiviert, die verhindert, dass Protokolle, die nicht gefiltert werden können, auf der Seite Protokolle angezeigt werden. Sie können solche Protokolle weiterhin anzeigen unter Protokolle auf den Seiten Roboter (klassische Ordner) und Aufträge (Weitere Aktionen > Protokolle anzeigen).
Bei einem Fehler bei einem Upgrade und einem Rollback hat die Administratorrolle die Bearbeitungsberechtigungen für Aktionen und das Erstellen von Berechtigungen für die Aktionszuweisung verloren. Die Rolle behält nun beides, auch im Falle eines fehlgeschlagenen Upgrades.
Da appSettings von Web.Config nach UiPath.Orchestrator.dll.configverschoben wurde, würde das Configure-PlatformNode.ps1 -Skript dazu führen, dass Migrationen mit mehreren oder mehreren Knoten fehlschlagen. Das Skript löst keinen Fehler mehr aus.
Die Paketmigration hat den importierten, aber nicht verwendeten Storage Ordner nach einem fehlgeschlagenen Upgrade nicht bereinigt. Der übrig gebliebene Inhalt wird nun entfernt.
Das UiPathOrchestrator.msi -Installationsprogramm nicht vor dem Start des Upgrades nach verfügbarer Speicherplatz sucht, was zu einem Fehlschlag bei der Paketmigration führen könnte. Nun wird eine Warnung ausgegeben, bevor die Migration beginnt.
UiPathPlatformInstaller.exe SSL-Zertifikate nicht mit bestimmten Betreffformaten überprüft, was entweder zu einem Installationsfehler oder zu einer Upgradewarnung führte.
Die Verwendung der Windows-Authentifizierung während eines Upgrades verhinderte, dass das UiPathOrchestrator.msi -Installationsprogramm die Anmeldeinformationen validiert. Dies führte dazu, dass der Aktualisierungsprozess nicht erfolgreich war.
Der Argumenttyp wurde in Orchestrator nicht überprüft, sodass Benutzer nicht angepasste Parameterwerte für ihre Prozesse festlegen können. Die Validierung wird nun ordnungsgemäß durchgeführt, und es wird ein Fehler ausgelöst, wenn die Eingabe nicht mit dem zur Entwurfszeit festgelegten Argumenttyp übereinstimmt.
Beim Löschen eines klassischen Ordners wurden die zugeordneten Benutzer nicht entfernt. Benutzer werden nun beim Löschen eines klassischen Ordners gelöscht.
Upgrade von v2020.4 auf v2020.10 Orchestrator nicht zugewiesene Active Directory-Benutzer aus modernen Ordnern basierend auf dem Berechtigungsmodell Vererben von Mandanten. Dies geschah, obwohl dem Ordner die übergeordnete Active Directory-Gruppe zugewiesen wurde.
Beim Löschen von Asset-Anmeldeinformationen, die sich in Lese-/Schreibanmeldeinformationen befinden, wurden sie nur aus Orchestrator gelöscht. Von nun an entfernt das Löschen einer Asset-Anmeldeinformationen in Orchestrator auch das zugeordnete Anmeldeinformationsobjekt, auf das im Anmeldeinformationsspeicher verwiesen wird. Stellen Sie sicher, dass die zu löschenden Asset-Anmeldeinformationen nicht an anderen Stellen wie Automatisierungsprojekten verwendet werden.
Nach Ablauf des Zeitaufzeitzeitraums für Benutzersitzungen wurde kein Timeout ausgeführt, sodass Benutzer nicht wie erwartet von der Sitzung abgemeldet wurden.