Einstellungen

Auf der Seite Einstellungen können Administratoren Orchestrator-Mandanteneinstellungen anpassen.

Registerkarte „Allgemein“

Feld	Beschreibung
Anwendungseinstellungen	Zeitzone – Die Zeitzone des Mandanten. Standardmäßig ist dieses Feld auf UTC festgelegt. Interaktionskonfiguration – Enthält die Option Eindeutige Bestätigung beim Löschen, mit der Sie bestimmen können, wie streng das Löschen von Orchestrator-Objekten behandelt werden soll. Wenn diese Option ausgewählt ist, wird ein Bestätigungsfenster angezeigt, in dem Sie aufgefordert werden, einen Text einzugeben, bevor Sie die Löschung durchführen. Anzeigeeinstellungen – Enthält die Option High Density-Ansicht, die standardmäßig ausgewählt ist. Wenn Sie die Auswahl aufheben, können Sie zu einer Anzeige von Tabellenelementen mit niedriger Dichte wechseln. Dies gilt für den gesamten Mandanten.
Persönliche Arbeitsbereiche	Erkundung persönlicher Arbeitsbereiche automatisch beenden nach – Ermöglicht Orchestrator-Administratoren, eine Regel durchzusetzen, die vorschreibt, dass die Erkundung persönlicher Arbeitsbereiche nach einer festgelegten Zeit automatisch beendet wird. Die verfügbaren Optionen sind 15 Minuten, 1 Stunde, 1 Tag und benutzerdefinierter Wert. Standardmäßig ist dieser Wert beim Migrieren oder Erstellen neuer Mandanten nicht festgelegt. Sie müssen ihn manuell konfigurieren, sobald der Migrations-/Erstellungsprozess abgeschlossen ist. Alle aktiven Sitzungen zum Erkunden persönlicher Arbeitsbereiche anhalten – Ermöglicht Orchestrator-Administratoren, alle derzeit aktiven Erkundungssitzungen des persönlichen Arbeitsbereichs zu beenden.Dies wird durch die Anzahl der aktiven Sitzungen angehängt, die in Klammern angezeigt werden, und kann aktiviert werden, indem Sie auf Beenden der Erkundungssitzung(en) klicken. Änderungen, die Sie an Erkundungseinstellungen vornehmen, gelten nicht rückwirkend für Sitzungen, die bereits erkundet wurden. Massenaktivierung von persönlichen Arbeitsbereichen für aktuelle Benutzer und Gruppen: – Erstellen Sie persönliche Arbeitsbereiche für alle Benutzer in einem Mandanten, die ein bestimmtes Attended-Lizenzprofil verwenden und wählen Sie gleichzeitig das UI-Profil aus, das für diese Benutzer verwendet werden soll. Hinweis: Diese Aktion kann nicht rückgängig gemacht werden. Sobald die Funktion „Persönliche Arbeitsbereiche“ aktiviert ist, kann sie nicht mehr deaktiviert werden.
Standardrollen	Erstellen Sie Standardrollen für Ordner. Mit diesen Rollen können Sie die Vorteile von Benutzergruppen nutzen. Klicken Sie neben jeder Rolle, die Sie erstellen möchten, auf Rolle erstellen.
Client-Binärdateien (Robot, Studio, Assistant) Einstellungen für die automatische Aktualisierung	Ignorieren Sie den Status für automatische Aktualisierungen für Robotermaschinen, die länger als ___ Tage offline waren – Schließen Sie inaktive Maschinen vom Aktualisierungsprozess aus und berücksichtigen Sie sie bei der Meldung des Aktualisierungsstatus nicht mehr.
Ordner	Konto-Maschinen-Zuordnungen aktivieren – Aktivieren Sie die Funktion Konto-Maschinen-Zuordnungen.

Abschnitt „Ausführungseinstellungen“

Feld/Standardwert	Beschreibung
Trigger – Strategie zum Zählen von Aufträgen (Triggers.JobsCountStrategy) Standardwert: Pro Prozess	Wählen Sie die Strategien zur Auftragszählung für Aufträge aus, die über Trigger gestartet werden. Beachten Sie, dass hierbei keine Argumente berücksichtigt werden, die möglicherweise bereitgestellt wurden. Die folgenden Optionen sind verfügbar: Pro Prozess ‑ 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. Pro Trigger ‑ 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 5 Aufträge zu einem bestimmten Zeitpunkt zu starten. Wenn 3 Aufträge bis zum erneuten Auslösen dieses Triggers erfolgreich abgeschlossen wurden, startet der Orchestrator weitere 2 Aufträge, um die erforderlichen 5 Aufträge zu erreichen.
Trigger – Warteschlangentrigger – Strategie zum Aktivieren ausstehender Aufträge (Features.QueueTriggers.PendingJobsStrategy) Standardwert: True	Wählen Sie die Berechnungsmethode für die Anzahl zusätzlicher Aufträge aus, die ausgelöst werden sollen, wenn neue Elemente zu einer Warteschlange hinzugefügt werden. Dazu wird die Anzahl der Aufträge in einem bestimmten Status von der maximalen Zielanzahl der zu erstellenden Aufträge abgezogen. Die folgenden Optionen sind verfügbar: True – Diese Option eignet sich am besten für Fälle, in denen der Orchestrator davon ausgehen soll, dass alle ausgeführten Aufträge Warteschlangenelemente bereits aus dem Status Neu verschoben haben. Die Zahl wird wie folgt berechnet: Maximale Anzahl zusätzlicher Aufträge, die basierend auf neu verfügbaren Warteschlangenelementen erstellt werden können = die maximale Anzahl der gleichzeitig zulässigen ausstehenden und laufenden Aufträge – die Anzahl der Aufträge im Status Ausstehend. False – Diese Option eignet sich am besten für Fälle, in denen der Orchestrator davon ausgehen soll, dass alle ausgeführten Aufträge Warteschlangenelemente noch aus dem Status Neu verschieben müssen. Die Zahl wird wie folgt berechnet: Maximale zusätzliche Aufträge, die basierend auf neu verfügbaren Warteschlangenelementen erstellt werden können = die maximale Anzahl der gleichzeitig zulässigen ausstehenden und laufenden Aufträge abzüglich der Anzahl der Aufträge in einem der folgenden Zustände: Pending,Resumed,Running,Stopping,Terminating.
Trigger – Bei dieser Anzahl von fehlgeschlagenen Auftragserstellungen deaktivieren (Triggers.DisableWhenFailedCount) Standardwert: 10	Konfigurieren Sie einen Trigger so, dass er nach einer bestimmten Anzahl fehlgeschlagener Starts und nach keiner erfolgreichen Ausführung in einer bestimmten Anzahl von Tagen automatisch deaktiviert wird. Diese Option funktioniert wie folgt in Verbindung mit Trigger – Übergangszeitraum, wenn diese Anzahl von Auftragserstellungen weiterhin fehlschlägt (Tage): Mit Trigger – Bei dieser Anzahl von fehlgeschlagenen Auftragserstellungen deaktivieren können Sie die Anzahl der fehlgeschlagenen Ausführungen anpassen, während Sie mit Trigger – Anzahl (Tage) nach der bei wiederholtem Fehlschlagen deaktiviert wird die Anzahl der Tage ändern können. Standardmäßig ist der Wert von Trigger – Bei dieser Anzahl von fehlgeschlagenen Auftragserstellungen deaktivieren 10 und Trigger – Übergangszeitraum, wenn diese Anzahl von Auftragserstellungen weiterhin fehlschlägt (Tage) 1, was bedeutet, dass der Trigger nach 10 erfolglosen Startversuchen deaktiviert wird, wenn am vergangenen Tag keine erfolgreichen Ausführungen stattgefunden haben. Diese Option kann in einem Bereich von 10 bis 100 festgelegt werden.
Trigger – Übergangszeitraum, wenn diese Anzahl von Auftragserstellungen weiterhin fehlschlägt (Tage) (Triggers.DisableWhenFailingSinceDays) Standardwert: 1	Konfigurieren Sie einen Trigger so, dass er nach einer bestimmten Anzahl fehlgeschlagener Starts und nach keiner erfolgreichen Ausführung in einer bestimmten Anzahl von Tagen automatisch deaktiviert wird. Diese Option funktioniert in Verbindung mit Trigger – Zählfunktion deaktivieren, wenn sie fehlschlägt, wie oben beschrieben. Sie kann in einem Bereich von 1 bis 30 festgelegt werden.
Trigger – Verbundene Trigger – Bei dieser Anzahl von fehlgeschlagenen Auftragsausführungen deaktivieren Standardwert: 5	Hinweis: Dies zielt nur auf verbundene Trigger ab (d. h. in Studio Web erstellte Trigger), die in persönlichen Arbeitsbereichen veröffentlicht wurden. Der Trigger wird nach der Anzahl fehlgeschlagener Ausführungen deaktiviert, die Sie für diese Einstellung wählen. Er kann in einem Bereich von 0 bis 100 festgelegt werden, wobei 0 bedeutet, dass der Trigger nie deaktiviert wird. Wenn Sie 0 auswählen, wird Trigger – Verbundene Trigger – Übergangszeitraum, wenn diese Anzahl von Auftragsausführungen weiterhin fehlschlägt (Tage) irrelevant und das entsprechende Feld wird deaktiviert. Diese Einstellung gilt nur für neu erstellte verbundene Trigger. Änderungen werden nicht rückwirkend auf vorhandene verbundene Trigger angewendet.
Trigger – Verbundene Trigger – Übergangszeitraum, wenn diese Anzahl von Auftragsausführungen weiterhin fehlschlägt (Tage) Standardwert: 0	Hinweis: Dies zielt nur auf verbundene Trigger ab (d. h. in Studio Web erstellte Trigger), die in persönlichen Arbeitsbereichen veröffentlicht wurden. Diese Einstellung legt die Anzahl der zu wartenden Tage fest, bevor der Trigger nach dem ersten Fehlschlag eines Auftrags deaktiviert wird. Sie kann in einem Bereich von 0 bis 30 festgelegt werden. Wenn Trigger – Verbundene Trigger – Bei dieser Anzahl von fehlgeschlagenen Auftragsausführungen deaktivieren auf 0 festgelegt ist, wird dieses Feld deaktiviert.
Trigger – API-Trigger – Maximale Grenze für ausstehende Aufträge Standardwert: 10	Legen Sie die maximale Anzahl der ausstehenden Aufträge fest, die von einem API-Trigger erstellt werden können. Der unterstützte Bereich ist 1–100.
Warteschlangen – In Bearbeitung befindliche Warteschlangenelemente nach dem Schwellenwert (Stunden) verwerfen (inProgressMaxNumberOfMinutes) Standardwert: 24	Legen Sie die maximale Zeit in Stunden fest, die Warteschlangenelemente den Status In Bearbeitung haben können. Nach dieser Zeit ändert sich der Status der Warteschlangenelemente in Abgebrochen. Der Standardwert ist 24 Stunden, was bedeutet, dass Warteschlangenelemente nicht als Abgebrochen markiert werden können, es sei denn, sie haben mindestens einen Tag lang den Status In Bearbeitung. Dies wird von einem Hintergrundauftrag verarbeitet, der einmal pro Stunde ausgeführt wird. Sie können also davon ausgehen, dass der Übergang bis zu einer Stunde nach dem gewählten Wert erfolgt.
Warteschlangen – Häufigkeit der Überprüfung auf nicht verarbeitete Warteschlangenelemente (Minuten) (Queue.ProcessActivationSchedule) Standardwert: 30	Der Zeitraum zwischen den Überprüfungen für nicht verarbeitete Warteschlangenelemente. Um das Prüfintervall anzupassen, können Sie zwischen 10, 15, 20, 30 oder 60 Minuten wählen. Für jeden Warteschlangentrigger, den Sie erstellen, wird ein Hintergrundzeittrigger generiert, der Warteschlangenelemente verarbeiten soll, die zum Zeitpunkt der Einreihung in die Warteschlange nicht verarbeitet werden konnten. Dieser Hintergrundzeittrigger wird verwendet, um die durch die Einstellung vorgegebene Häufigkeit zu berechnen. Vorhandene Warteschlangentrigger: Die Einstellung wird angewendet, wenn der Standardwert zum ersten Mal geändert wird, und kann nicht wiederhergestellt werden. Neue Warteschlangen-Trigger: Die Einstellung wird immer angewendet. Wichtig: Der verwendete Referenzzeitstempel basiert auf dem Zeitpunkt, zu dem der Warteschlangentrigger erstellt wurde. Wenn beispielsweise um 14:22:43 Uhr ein Warteschlangen-Trigger erstellt wird und diese Option auf 10 Minuten festgelegt ist, wird die folgende Wiederholung generiert: 14:32:43, 14:42:43, 14:52:43 und so weiter. Es kann bis zu 10 Minuten dauern, bis die Hintergrundaufgabe, die die durch diese Einstellung ausgelösten Änderungen ausführt, wirksam wird.
Aufträge – Zeitüberschreitung für Beenden (Stunden) (Jobs.TerminatingJobsTimeout) Standardwert: 24	Legen Sie die verstrichene Zeit in Stunden fest, bis Aufträge im Status Wird beendet als Fehlgeschlagen markiert werden können. Der Standardwert ist 24, was bedeutet, dass Aufträge nicht als Fehlgeschlagen markiert werden können, es sei denn, sie befinden sich mindestens einen Tag im Status Wird beendet. Dies wird von einem Hintergrundauftrag verarbeitet, der einmal pro Stunde ausgeführt wird. Sie können also davon ausgehen, dass der Übergang bis zu einer Stunde nach dem gewählten Wert erfolgt.

Abschnitt „API-Einstellungen“

Einstellung	Beschreibung
CORS-Zulassungsliste für API-Trigger	Ermöglicht Ihnen die Eingabe von Domänen, die für eingehenden Datenverkehr zulässig sind. Trennen Sie verschiedene Domänen durch ein Komma oder durch Drücken der Eingabetaste.
Authentifizierungsheader zum Synchronisieren von API-Trigger-Umleitungen erforderlich	Dies ist standardmäßig aktiviert und erzwingt die Verwendung eines Authentifizierungs-Headers, wenn der Aufrufmodus Sync (Long-Polling) für einen API-Trigger ausgewählt wird.
Strikte API	Wenn diese Option aktiviert ist, können bestimmte API-Felder nicht mehr filterbar und/oder nicht sortierbar sein, wodurch Leistungsprobleme vermieden werden. Eine Liste dieser Felder finden Sie auf der entsprechenden Seite. Diese Einstellung ist für neue Mandanten standardmäßig aktiviert, bestehende Mandanten müssen jedoch manuell angemeldet werden. Bei API-Integrationen sollte diese Option immer aktiviert bleiben.

Registerkarte „Bereitstellung“

Ermöglicht das Konfigurieren und Sichern von Feeds für Pakete und Bibliotheken. Sie können die Feeds für alle Mandanten von einer zentralen Stelle aus über Automation Ops verwalten. Weitere Informationen finden Sie unter Feeds-Verwaltung im Automation Ops-Handbuch.

Einstellungen hier wirken sich nur auf Mandantenfeeds aus; Ordnerfeeds und Feeds des persönlichen Arbeitsbereichs sind immer intern und im Kontext des jeweiligen Ordners oder des persönlichen Arbeitsbereichs verfügbar.

Pakete

Ermöglicht Ihnen die Einrichtung eines internen oder externen Feeds, in dem Automatisierungspakete gehalten werden können. Standardmäßig wird ein interner Feed verwendet. Die Feeds können entweder durch Definieren von einfachen Authentifizierungsanmeldeinformationen oder mithilfe eines API-Schlüssels gesichert werden.

Feld	Beschreibung
Intern	Verwenden Sie einen internen Feed. Der Feed kann entweder mit der Option Sichere Bereitstellung oder mit einem API-Schlüssel gesichert werden: Sichere Bereitstellung – Gewährleistet, dass Ihre Automatisierungspakete durch einen sicheren NuGet-Feed heruntergeladen werden API-Schlüssel – Der Schlüssel, mit dem Ihr Feed vor Schreiboperationen wie Löschen oder Hochladen gesichert wird. Das ist nur erforderlich, wenn Sie ein Paket mithilfe eines externen Clients direkt in den NuGet-Feed hochladen möchten.
Extern	Verwenden Sie einen externen Feed. Der Feed kann entweder durch Verwendung eines API-Schlüssels oder grundlegender Authentifizierungs-Anmeldeinformationen gesichert werden: Bereitstellungs-URL * – Die Adresse, unter der sich der NuGet-Feed befindet. API-Schlüssel – Der Schlüssel, mit dem Ihr Feed vor Schreiboperationen wie Löschen oder Hochladen gesichert wird. Authentifizierung – Ermöglicht es Ihnen, die Anmeldeinformationen für Ihren grundlegenden authentifizierten Feed anzugeben. Bitte berücksichtigen Sie, dass auch in diesem Fall der Benutzername sowie das Kennwort in Verbindung mit der Option API-Schlüssel verwendet werden sollten.

Wichtig: Wir unterstützen keine plattformübergreifenden Pakete, die in einen externen Feed hochgeladen werden. Ihre Metadaten können nur gelesen werden, wenn sie direkt in den Orchestrator hochgeladen werden.

Bibliotheken

Ermöglicht Ihnen die Konfiguration des Feeds, der für Bibliotheks- und Aktivitätspakete verwendet werden soll.

Feld	Beschreibung
Nur Hostfeed	Bibliotheken werden im Hostfeed gespeichert und stehen allen Mandanten zur Verfügung, die diesen verwenden. Die Seite Bibliotheken ist für eine Orchestrator-Instanz die gleiche. Das bedeutet, dass Bibliotheken nicht auf Mandantenebene isoliert sind: Jeder Mandant hat Zugriff auf die Aktivität der anderen Mandanten. Sie können vom Orchestrator keine Bibliotheken hochladen, wenn diese Option ausgewählt ist. Diese Option ermöglicht dem Roboter nur Zugriff auf den Mandantenfeed.
Nur Mandantenfeed	Bibliotheken sind auf Mandantenebene isoliert. Dies bedeutet, die Daten sind über die Mandanten hinweg getrennt. Sie können einen internen oder externen Feed festlegen, in dem die Bibliotheken verwaltet werden. Standardmäßig wird ein interner Feed verwendet. Diese Option ermöglicht dem Roboter nur Zugriff auf den Mandantenfeed.
Sowohl Host- als auch Mandantenfeeds	Bibliotheken sind auf Mandantenebene isoliert. Dies bedeutet, die Daten sind über die Mandanten hinweg getrennt. Sie können einen internen oder externen Feed festlegen, in dem die Bibliotheken verwaltet werden. Standardmäßig wird ein interner Feed verwendet. Diese Option ermöglicht den Roboterzugriff auf sowohl den Host- als auch auf den Mandantenfeed.
Intern	Wird angezeigt, wenn Nur Mandantenfeed oder Sowohl Host- als auch Mandantenfeeds ausgewählt ist. Verwenden Sie einen internen Feed für Ihre Bibliotheken. Der Feed kann entweder mit der Option Sichere Bereitstellung oder mit einem API-Schlüssel gesichert werden: Sichere Bereitstellung – Gewährleistet, dass Ihre Automatisierungspakete durch einen sicheren NuGet-Feed heruntergeladen werden API-Schlüssel – Der Schlüssel, mit dem Ihr Feed vor Schreiboperationen wie Löschen oder Hochladen gesichert wird.
Extern	Wird angezeigt, wenn Nur Mandantenfeed oder Sowohl Host- als auch Mandantenfeeds ausgewählt ist. Verwenden Sie einen externen Feed für Ihre Bibliotheken. Der Feed kann entweder mit einem API-Schlüssel oder einfachen Anmeldeinformationen für die Authentifizierung gesichert werden: Bereitstellungs-URL * – Die Adresse, unter der sich der NuGet-Feed befindet. API-Schlüssel – Der Schlüssel, mit dem Ihr Feed vor Schreiboperationen wie Löschen oder Hochladen gesichert wird. Authentifizierung – Ermöglicht es Ihnen, die Anmeldeinformationen (Benutzername und Kennwort) für Ihren grundlegenden authentifizierten Feed anzugeben. Bitte berücksichtigen Sie, dass auch in diesem Fall der Benutzername sowie das Kennwort in Verbindung mit der Option API-Schlüssel verwendet werden sollten.

Weitere Informationen finden Sie auf der Seite Bibliotheksfeeds .

Registerkarte „Robotersicherheit“

Sicherheit

Feld	Beschreibung
Gesamtstunden, die ein Roboter ohne Lizenzverifizierung offline laufen kann	Geben Sie die Anzahl der Stunden an, die ein Roboter offline arbeiten kann, ohne dass der Orchestrator seine Lizenz überprüfen muss. Standardmäßig ist sie auf 0 festgelegt. Der maximal akzeptierte Wert beträgt 168 Stunden.

Roboter-Authentifizierung

Feld	Beschreibung
Authentifizierung von Unattended-Robotern	Client-Anmeldeinformationen (empfohlen) – Diese Option ermöglicht nur Verbindungen mit ablaufenden Tokens. Es verwendet das OAuth 2.0-Framework als Basis für das Authentifizierungsprotokoll, d. h. Unattended-Roboter können sich mit einem Paar aus Client-ID und geheimem Client-Schlüssel, das über Maschinenvorlagenobjekte generiert wird, mit Orchestrator verbinden. Das Paar aus Client-ID und geheimem Client-Schlüssel generiert ein Token, das die Verbindung zwischen dem Roboter und dem Orchestrator autorisiert und dem Roboter Zugriff auf die Orchestrator-Ressourcen gewährt. Hybrid – Diese Option ermöglicht sowohl Verbindungen mit Token, die nicht ablaufen (Maschinenschlüssel), als auch Verbindungen mit Token, die ablaufen (Client-Anmeldeinformationen).
Authentifizierung von Attended-Robotern	Interaktive Anmelde-SSO (Empfohlen) – Diese Option erlaubt nur Roboterverbindungen mit ablaufenden Token. Benutzer können ihre Roboter nur authentifizieren, indem sie sich mit ihren Anmeldeinformationen im Assistant anmelden. Eine Benutzeranmeldung ist erforderlich, um Attended-Roboter auszuführen, HTTP-Anfragen an den Orchestrator zu stellen oder Prozesse im Assistant anzuzeigen. Bei Verwendung der interaktiven Anmeldung müssen keine Maschinenobjekte im Orchestrator erstellt werden. Hybrid – Diese Option ermöglicht sowohl Verbindungen mit Token, die nicht ablaufen (Maschinenschlüssel), als auch Verbindungen mit Token, die ablaufen (interaktive Anmeldung oder Client-Anmeldeinformationen). Benutzer haben die Möglichkeit, sich mit ihren Anmeldeinformationen anzumelden, um ihre Roboter zu authentifizieren, was ihnen wiederum ermöglicht, Studio und den Assistant mit dem Orchestrator zu verbinden. Dies ist jedoch nicht obligatorisch.

Skalierbarkeits-Registerkarte

Geben Sie an, ob der Roboter-Dienst die SignalR-Kanäle des Orchestrators abonnieren soll, und konfigurieren Sie die Transportprotokolle, die für Sie am besten geeignet sind.

SignalR (Roboter)

Feld	Beschreibung
Aktiviert	Dieser Umschalter legt fest, ob der Roboterdienst die SignalR-Kanäle vom Orchestrator abonniert hat oder nicht. Standardmäßig ist diese Einstellung aktiviert, und alle verfügbaren Kanäle sind ausgewählt: WebSocket Server-Sent Events (SSE) Lange Abrufe Wenn alle Transportkanäle aktiviert sind, wird automatisch der beste verfügbare Transport in der folgenden Prioritätsreihenfolge ausgewählt: WebSocket > Server-Sent Events > Lange Abrufe. Wenn das erste Protokoll aus irgendeinem Grund nicht verfügbar ist, wird das nächste in der Zeile (falls aktiviert) verwendet, um die Kommunikation zwischen Orchestrator und Robot zu erleichtern.
WebSocket	Wenn diese Option ausgewählt ist, kann das WebSocket-Transportprotokoll verwendet werden, um den Roboter mit den SignalR-Kanälen vom Orchestrator zu verbinden. Dies ist das höchste Protokoll, das in der Reihenfolge der Priorität aufgrund seiner Leistung und Unterstützung für die gleichzeitige Kommunikation in beide Richtungen verwendet wird – vom Roboterdienst zum Orchestrator und umgekehrt. Wenn die Funktion SignalR (Roboter) nicht aktiviert ist, wird WebSocket das einzige verfügbare Transportprotokoll.
Server-Sent Events (SSE)	Wenn diese Option ausgewählt ist, kann die SSE-Push-Technologie (Server-Sent Events) verwendet werden, um den Roboter mit den SignalR-Kanälen vom Orchestrator zu verbinden. Dies ist die erste Sicherung, falls WebSockets nicht verfügbar sein sollte. Diese Option kann nicht verwendet werden, wenn die Funktion SignalR (Roboter) nicht aktiviert ist.
Lange Abrufe	Wenn diese Option ausgewählt ist, kann das Transportprotokoll mit langen Abrufen verwendet werden, um den Roboter mit den SignalR-Kanälen vom Orchestrator zu verbinden. Dieses Protokoll wird verwendet, wenn die WebSockets- und SSE-Protokolle nicht verfügbar sind. Diese Option kann nicht verwendet werden, wenn die Funktion SignalR (Roboter) nicht aktiviert ist.

Registerkarte „Arbeitsfreie Tage“

Definieren Sie eine Liste von arbeitsfreien Tagen pro Mandant, an denen Sie die Ausführung von Triggern einschränken können. Dies bedeutet, dass Ihre langfristigen Zeitpläne an öffentlichen Feiertagen, Wochenenden oder anderen Tagen, an denen keine normalen Geschäftsaktivitäten stattfinden, so konfiguriert werden können, dass sie nicht auslösen. Nach den angegebenen arbeitsfreien Tagen löst der Zeitplan wieder normal aus.

Um diese Einschränkungen auf Ihre Trigger anzuwenden, müssen Sie beim Konfigurieren von Triggern den Kalender für arbeitsfreie Tage auswählen. Alle Änderungen, die Sie auf der Registerkarte Arbeitsfreie Tage vornehmen, wirken sich auf alle Trigger aus, die diesen Kalender verwenden.

Ausführliche Informationen zur Verwaltung von Nicht-Arbeitstagen finden Sie hier.

Cloudverbindungen

Auf dieser Registerkarte können Sie Integrationen mit Cloud-Dienstanbietern (CSPs) von Drittanbietern konfigurieren, die für Elastic Robot Orchestration verwendet werden.