Auslöser

Trigger bieten einen einheitlichen Mechanismus zum Abonnieren von Ereignissen von den Connector-Plattformen. Er bietet Ihnen die Flexibilität, Automatisierungen in Orchestrator automatisch zu starten.

Trigger im Orchestrator

Wichtig:

Ab dem späten April 2025 können Sie neue Integration Service-Trigger nur in Orchestrator erstellen. Im Orchestrator erstellte Trigger werden nicht auf der Registerkarte Trigger des Integration Service aufgeführt. Vorhandene Trigger des Integration Service werden weiterhin ausgeführt und bleiben auf der Registerkarte Trigger des Integration Service bis zum 31. Juli 2025 sichtbar (dieses Datum unterliegt möglichen Verlängerungen). Nach diesem Datum werden vorhandene Integration Service-Trigger zu Orchestrator migriert und die Registerkarte Trigger im Integration Service wird entfernt. Diese Änderung soll zuerst für Community-Benutzer und dann für Enterprise-Benutzer verfügbar werden, je nach Organisation und Mandantenregionen. Folgen Sie den Integration Service-Versionshinweisen, um zu erfahren, wann die Änderung zum ersten Mal angekündigt wird.

Vorteile von Triggern im Orchestrator

Das Verschieben von Integration Service-Triggern in den Orchestrator ist eine große Veränderung, bringt aber viele Vorteile mit sich. Hier sind die Hauptgründe für dieses Update:

1. Konto-Maschinen-Zuordnung: Der Orchestrator ermöglicht die Steuerung über vom Integration Service ausgelöste Prozesse auf Maschinenebene.
2. Bot-spezifische Prozessausführungssteuerung: Mit dem Orchestrator können Sie angeben, welcher Roboter einen Prozess in einem Ordner ausführen soll, in dem mehrere Bots zugewiesen sind. Dies bietet eine genaue Kontrolle darüber, welcher Bot einen ausgelösten Prozess ausführt, macht Problemumgehungen wie Einzel-Bot-Ordner überflüssig und erhöht die Skalierbarkeit, indem mehrere Bots zugelassen werden, ohne die Ausführungskontrolle zu verlieren.
3. Eingabeargumente und dynamische Prozesszuweisung: Der Orchestrator ermöglicht dynamische Eingabeargumente und ermöglicht es Ihnen, die maximale Anzahl aktiver Prozessinstanzen zu definieren. Dies reduziert die Prozessduplizierung, indem dynamische Argumente zugelassen werden, optimiert die Ressourcennutzung, indem aktive Prozesse begrenzt werden, und verbessert die Effizienz von Prozessen, die Anforderungen sequenziell verwalten.
4. Verbesserte Verwaltung von Prozessen mit langer Ausführungszeit: Im Orchestrator erstellte Trigger unterstützen die Optionen „Anhalten nach“ und „Beenden nach“ und ermöglichen so das automatische Beenden von Prozessen nach einer bestimmten Dauer oder Bedingung. Dies verhindert eine Überbelegung von Ressourcen, indem Prozesse mit langer Ausführungszeit beendet werden, und gewährleistet eine rechtzeitige Ausführung, indem nicht reagierende Workflows gestoppt werden.
5. Bearbeitungsfunktionen: Der Orchestrator ermöglicht es Ihnen, vorhandene Trigger zu bearbeiten.
6. Einheitliche Trigger-Funktion: Erstellen und verwalten Sie alle Arten von Triggern von einem zentralen Ort aus.
7. Ansicht eines einzelnen Triggers: Das Verschieben der Triggererstellung in den Orchestrator stellt sicher, dass alle Integration Service-basierten Trigger eine einzige Ansicht behalten. Sie können jetzt auf zwei Arten einen Integration Service-basierten Trigger erstellen: Im Integration Service, indem Sie einen Trigger für einen bestimmten Connector erstellen, und in Studio, indem Sie eine Triggeraktivität verwenden, um eine Automatisierung zu starten. Die für die beiden Trigger angezeigten Konfigurationsinformationen können sich leicht unterscheiden, obwohl sie das gleiche Ereignis erfassen.

Überblick

Es gibt zwei Arten von Ereignistriggern, die auf Integration Service-Verbindungen basieren:

• Verbunden – Erstellt mit Triggeraktivitäten in Studio, verwendet in einem Prozess.
• Getrennt – Erstellt im Orchestrator oder Integration Service, wird verwendet, um eine Automatisierung zu starten.

Hinweis:

Trigger hängen von Verbindungen ab. Durch das Löschen einer Verbindung werden auch alle zugehörigen Trigger gelöscht.

Voraussetzungen

Bevor Sie Trigger konfigurieren können, stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:

• Integration Service ist aktiviert und für Ihren Mandanten bereitgestellt.
• Sie haben bereits einen Unattended- oder Non-production-Roboter in Ihrer Orchestrator-Instanz eingerichtet.
• Sie verwenden moderne Ordner (Prozesse innerhalb klassischer Ordner sind beim Definieren von Triggern nicht sichtbar).
• Benutzer, die mit Triggern arbeiten, verfügen über die erforderlichen Berechtigungen in Orchestrator. Zum Erstellen eines Triggers muss ein Benutzer über die Berechtigung Trigger – Erstellen im Zielordner verfügen. Weitere Informationen zu Berechtigungen finden Sie unter Konfigurieren des Zugriffs für Konten im Orchestrator-Benutzerhandbuch.

So funktionieren Trigger

Abrufbasierte Trigger wie Datensatz erstellt oder Incident erstellt sind für mehrere UiPath-Connectors verfügbar. Dieser Triggertyp erkennt neue Datensätze mithilfe eines Abrufmechanismus für die öffentlichen APIs der Zielanwendung.

Die Trigger funktionieren wie folgt:

1. Abrufintervall – Integration Service fragt das Zielsystem in einem festgelegten Intervall ab (standardmäßig alle fünf Minuten). Das Abrufintervall wird auf Verbindungsebene festgelegt, daher wirkt sich eine Änderung des Abrufintervalls auf alle Trigger aus, die dieser Verbindung zugeordnet sind.

2. API-basierte Erkennung : Während jedes Abrufzyklus fragt der Integration Service das relevante Objekt/die relevante Tabelle mithilfe der standardmäßigen REST-APIs des Anbieters ab.

3. Inkrementelle Datensatzidentifizierung – Neue Datensätze werden mithilfe von API-Abfrageparametern identifiziert, meistens basierend auf:

   • Zeitstempel für die Datensatzerstellung (z. B. sys_created_on)
   • In einigen Szenarien müssen Zeitstempel geändert werden

   Integration Service speichert den neuesten Erstellungszeitstempel (oder entsprechenden Marker) aus dem letzten erfolgreichen Abrufzyklus. Bei der nächsten Abfrage wird die Abfrage ab diesem gespeicherten Wert fortgesetzt, um Kontinuität zu gewährleisten und doppelte Verarbeitung zu verhindern.

   Eine Abfrage zum Abfragen neuer Vorfälle in ServiceNow könnte beispielsweise folgendermaßen aussehen: GET https://{instance}.service-now.com/api/now/v1/table/incident?sysparm_query=sys_created_on>={last_max_created_date}

   Hinweis:

   Zusätzliche Parameter wie Paginierung, Grenzen, Offsets oder Felderweiterung können aufgenommen werden, um das Filtern und die Datengestaltung zu unterstützen. Diese ändern nicht die Kernabruflogik.

Erstellen von Triggern

Sie erstellen getrennte Ereignistrigger direkt in Orchestrator. Weitere Informationen dazu finden Sie im Abschnitt Ereignistrigger im Benutzerhandbuch des Orchestrator.

Der Orchestrator bietet die direkte Verwaltung dieser Trigger. Im Integration Service besteht Ihre einzige Option für die Triggeränderung im Anpassen des Abrufintervalls, das auf Verbindungsebene festgelegt wird.

Aktualisieren des Abrufintervalls

Connectors unterstützen Ereignisse durch einen Abrufmechanismus.

Wenn Sie einen Ereignistrigger für eine Verbindung einrichten, wird das Abrufintervall standardmäßig auf fünf Minuten festgelegt.

Das Abrufintervall wird auf Verbindungsebene festgelegt. Das bedeutet, dass Sie nur ein Abrufintervall pro Verbindung haben können, obwohl Sie mehrere Trigger pro Verbindung erstellen. Das Ändern des Abrufintervalls wirkt sich auf alle Trigger aus, die einer Verbindung zugeordnet sind.

Das Abrufen wird für die Verbindung im ausgewählten Intervall ausgeführt. Sobald Daten abgerufen wurden, werden alle aktiven Trigger für diese Verbindung auf das Dataset angewendet. Wenn eine Abfrage ausgeführt wird, während Sie das Intervall ändern, wartet der Dienst auf den Abschluss der vorhandenen Abfrage und startet dann eine andere.

So aktualisieren Sie das Abrufintervall:

1. Wählen Sie Orchestrator im Produktstartprogramm aus.
2. Wählen Sie einen Ordner aus und navigieren Sie dann zur Registerkarte Verbindungen .
3. Wählen Sie auf der rechten Seite einer Verbindung Weitere Aktionen > Anzeigen/Bearbeiten aus , um die Seite zum Bearbeiten der Verbindung zu öffnen.
4. Wählen Sie unter Auf Ereignisse prüfen alle: das Zeitintervall in Minuten oder Stunden aus. Das Abrufintervall muss mehr als eine Minute und höchstens 24 Stunden oder 1440 Minuten betragen.
5. Wählen Sie Aktualisieren.

Anzeigen des Verlaufs der Trigger-Ausführung

Wichtig:

Die Verlaufstabelle der Versuche ist ausschließlich für Trigger verfügbar, die im Integration Service erstellt und auf der Registerkarte Trigger aufgeführt sind. Der Verlauf von Versuchen ist für Trigger, die im Orchestrator erstellt wurden, nicht verfügbar.

So zeigen Sie den Verlauf der Trigger-Ausführung an:

1. Wählen Sie in Integration Service die Registerkarte Trigger aus.
2. Wählen Sie für jeden aufgeführten Trigger die Option Trigger mit anzeigen Menü „Weitere Aktionen“:

Die Verlaufstabelle der Versuche zeigt:

• Die Ereigniszeit – Wenn das Ereignis erfasst wurde
• Die Anzahl der Versuche
• Der Triggerstatus – ob der Prozess erfolgreich gestartet wurde oder nicht.

Hinweis:

Der Status Erfolgreich zeigt nur an, dass der Auftrag erfolgreich gestartet wurde. Es spiegelt nicht wider, ob der Auftrag erfolgreich bis zum Ende ausgeführt wurde oder nicht. Falls ein Auftrag nicht gestartet werden kann, wird sein Status als Fehlgeschlagen angezeigt. Zeigen Sie mit dem Mauszeiger auf den Status Fehlgeschlagen , um die Fehlermeldung anzuzeigen.

Um zu überprüfen, ob ein Auftrag erfolgreich ausgeführt wurde, wählen Sie die Taste Auftragsprotokolle anzeigen . Diese Aktion leitet Sie zum Orchestrator um, wo Sie alle erforderlichen Informationen zur Auftragsausführung sehen können.

Verwalten von Triggern

Die folgenden Aktionen sind für Trigger verfügbar, die im Integration Service erstellt wurden.

Direkt im Orchestrator erstellte Trigger können im Orchestrator verwaltet werden.

Umbenennen eines Triggers

Führen Sie die folgenden Schritte aus, um einen Trigger umzubenennen:

1. Access the Triggers tab.
2. Zeigen Sie mit dem Mauszeiger auf den Namen des Triggers, den Sie ändern möchten. Die Schaltfläche Bearbeiten wird angezeigt. Alternativ können Sie Ihren Trigger aus der Liste auswählen, um auf die detaillierte Ansicht zuzugreifen. Die Schaltfläche Bearbeiten befindet sich rechts neben Ihrem Triggernamen.
3. Wählen Sie die Schaltfläche Bearbeiten aus und Sie können einen neuen Namen für Ihren Trigger wählen

Löschen eines Triggers

Wechseln Sie im Fenster Integration Service zur Registerkarte Trigger . Wählen Sie die Schaltfläche Weitere Aktionen aus, die Ihrem Trigger entspricht, und wählen Sie Löschen.

Aktivieren oder Deaktivieren eines Triggers

Um einen Trigger zu aktivieren oder zu deaktivieren, müssen Sie ihn zuerst auswählen, um seine Details anzuzeigen. Wählen Sie dann den Schalter aus, der sich auf der oberen linken Seite des Fensters befindet.

Ereignisargumente

Getrennte Trigger ermöglichen es Ihnen, Daten in Bezug auf den Connector und das Ereignis abzurufen, das einen Prozess auslöst.

Wenn Sie den tatsächlichen Connector, das Ereignis, den Datensatztyp oder den Datensatz wissen möchten, der den Prozess in Ihrem Workflow ausgelöst hat, definieren Sie die folgenden Eingabeargumente des Typs String in Ihrem Prozess. Integration Service füllt sie automatisch auf, wenn er den Auftrag startet:

• UiPathEventConnector – Bestimmt, welcher Connector die Automatisierung gestartet hat.
• UiPathEvent – Bestimmt den Typ des aufgetretenen Ereignisses.
• UiPathEventObjectType – Definiert den spezifischen Datensatztyp, der sich aus dem Ereignis ergibt.
• UiPathEventObjectId – Gibt den eindeutigen Bezeichner für das Objekt an, das am Ereignis beteiligt ist.

Hinweis:

Das gilt nur für getrennte Trigger. Für verbundene Trigger sollte beim Entwerfen Ihres Prozesses das gesamte Objekt bereits verfügbar sein.

Sie können diesen Argumenten keinen Wert zuweisen. Sie werden zum Zeitpunkt der Triggerausführung automatisch aufgefüllt und Sie können sie im Argumentbereich in Studio nicht anzeigen oder bearbeiten. Weitere Informationen zur Funktionsweise und Verwaltung von Argumenten finden Sie in der Studio-Dokumentation: Verwalten von Argumenten.

Um einen Datensatz abzurufen, der einen Trigger bei einer Auftragsausführung hat, verwenden Sie das Eingabeargument UiPathEventObjectId , um den Datensatz aus dem Quellsystem abzurufen.

Hier ist ein Beispiel dafür, wie Integration Service die Eingabeargumentwerte an Orchestrator-Protokolle übergibt:

Triggerspezifische Ausgaben

Verbundene Trigger haben objektspezifische Ausgaben. Beispielsweise gibt der Microsoft OneDrive & SharePoint E-Mail erhalten Trigger ein Objekt vom Typ Office365Message mit Eigenschaften wie AttachmentsNamesList, FromAddress, InternetMessageId, SentDateTime usw. aus. Weitere Informationen finden Sie unter Microsoft OneDrive & SharePoint-Ereignisse.

Verwenden Sie den Ausdrucks-Editor in Studio, um alle verfügbaren Eigenschaften für ein beliebiges Trigger-Ausgabeobjekt anzuzeigen.

Einschränkungen

Trigger-Einschränkungen werden im Abschnitt zur Fehlerbehebung dieses Handbuchs dokumentiert. Siehe Trigger-Einschränkungen.

Häufig gestellte Fragen

Wenn eine Verbindung unterbrochen wird, was geschieht mit den Triggern, die dieser Verbindung zugeordnet sind?

Wenn eine Verbindung getrennt wird, werden die zugehörigen Trigger vorübergehend nicht mehr ausgeführt. Sobald die Verbindung erfolgreich wiederhergestellt wurde, setzen die Trigger die Ausführung automatisch fort. Stellen Sie als zusätzlichen Schritt sicher, dass sich der Trigger nicht in einem deaktivierten Zustand befindet .

Wie kann ich bei getrennten Triggern die Triggerausgabe mit meinem Prozess verknüpfen?

Weitere Informationen zum Abrufen von Daten in Bezug auf den Connector und das Ereignis, das einen Prozess auslöst, finden Sie im Abschnitt Ereignisargumente .

Mit dem Argument UiPathEventObjectId können Sie einen Get Record- oder HTTP-Aktivitätsaufruf in Ihrem Prozess hinzufügen, um die entsprechenden Datensatzdaten abzurufen.

Hinweis:

Das gilt nur für getrennte Trigger. Für verbundene Trigger sollte beim Entwerfen Ihres Prozesses das gesamte Objekt bereits verfügbar sein.

Wie kann ich das Abrufintervall für meinen Trigger ändern?

Sie können das Abrufintervall direkt über die Triggerkonfiguration ändern. Ausführliche Schritte finden Sie in diesem Handbuch: Aktualisieren des Abrufintervalls.

Kann ich filtern, welche Datensätze meine Automatisierung auslösen?

Ja. Sie können Datenfilter hinzufügen (für Connectors, die dies unterstützen), um zu steuern, welche Aufzeichnungen letztlich Ihren Prozess auslösen.

Hinweis:

Filter werden angewendet, nachdem die Datensätze von Integration Service abgerufen wurden.

Zum Beispiel:

• Erstellen Sie einen Filter in Studio Web:

  

• Erstellen Sie einen Filter im Orchestrator:

  

Warum wird mein Trigger nicht sofort ausgelöst?

Die Ausführungszeit von Triggern kann je nach Triggertyp, Datenvolumen und Roboterverfügbarkeit variieren.

Für abrufbasierte Trigger:

• Der Trigger ruft neue oder aktualisierte Datensätze basierend auf dem im Integration Service konfigurierten Abrufintervall ab.

• Abhängig vom abgerufenen Datenvolumen wendet der Integration Service alle definierten Filter oder Triggerbedingungen an, bevor qualifizierende Ereignisse an den Orchestrator übergeben werden.

• Diese Verarbeitung kann zu geringfügiger Latenz führen, insbesondere bei der Verarbeitung großer Datasets oder komplexer Filter.

• Nachdem die Ereignisse an den Orchestrator übergeben wurden, startet die Automatisierung nur, wenn in diesem Moment ein Unattended-Roboter verfügbar ist .

• Wenn das Abrufintervall zu lang ist, kann eine große Datenmenge auf einmal abgerufen werden, was möglicherweise Ihren Prozess verlangsamt. In solchen Fällen sollten Sie das Intervall verkürzen , um die Leistung zu verbessern.

  Hinweis:

  Wenn Ihr Trigger verzögert erscheint, überprüfen Sie Ihr Abrufintervall, überprüfen Sie die Filter auf Effizienz und stellen Sie sicher, dass ein Unattended-Roboter zur Ausführung des Auftrags verfügbar ist.

Für Webhook-basierte Trigger (z. B. HTTP-Webhook):

• Webhook-Trigger sind so konzipiert, dass sie fast sofort ausgelöst werden, da Ereignisse direkt von der externen Anwendung an den Integration Service gesendet werden.
• Da Webhooks in der Regel einen Datensatz pro Transaktion verarbeiten, ist die Latenz minimal.
• Wenn jedoch Triggerfilter oder Verarbeitungslogik angewendet werden, bevor das Ereignis an den Orchestrator übergeben wird, kann dennoch eine kleine Verzögerung auftreten.

Wie kann ich einen Trigger beheben, der nicht ausgelöst wird?

• Überprüfen Sie, ob die zugehörige Verbindung aktiv ist.
• Überprüfen Sie, ob der Trigger aktiviert ist.
• Überprüfen Sie, ob Ihre Verbindung einen bestimmten Scope oder eine bestimmte Rolle für den Zugriff auf den abgefragten Ziel-API-Endpunkt erfordert.
• Bestätigen Sie, dass der Filter mit den erwarteten Daten übereinstimmt.
• Bestätigen Sie bei Webhook-Triggern, dass die Webhook-Registrierung für die externe Anwendung gültig ist.

Wann nimmt ein Trigger zum ersten Mal Datensätze auf?

Die erste Ausführung eines Triggers beginnt mit dem Zeitpunkt, zu dem der Trigger erstellt wird.

Datensätze, die vor der Erstellung des Triggers erstellt wurden, werden nicht aufgenommen und alle Datensätze, die nach dem Zeitstempel der Triggererstellung erstellt/aktualisiert wurden, sind für die Verarbeitung gemäß den Filtern des Triggers berechtigt.

Wann nimmt der Trigger im Debugmodus zum ersten Mal Datensätze auf?

Im Debugmodus berücksichtigt der Trigger Startereignis (der Trigger, der einen Prozess initiiert) Ereignisse aus der letzten Stunde relativ zum Zeitpunkt der Konfiguration.