Auslöser

Erfahren Sie, wie Sie mithilfe von Triggern Logik in Apps erstellen können, ohne Code schreiben zu müssen.

In diesem Artikel erfahren Sie:

• Trigger-Befehle, Logik und Ausführungsverhalten
• Bewährte Vorgehensweisen zum Erstellen und Organisieren von Triggern
• Häufige Anwendungsfälle

Mit Triggern können Sie Ihrer App Logik hinzufügen. Sie können Trigger nutzen, um mit Geräten zu interagieren, Benachrichtigungen zu versenden, Daten zu schreiben, mit Backend-Systemen zu kommunizieren und vieles mehr – und das alles, ohne auch nur eine einzige Zeile Code zu schreiben.

Zu den gängigen Anwendungsfällen für Trigger gehören:

• Navigieren innerhalb einer App: Verwenden Sie einen Übergang, um zu einem anderen Schritt zu gelangen.
• Eine App abschließen: Protokollieren Sie die Metadaten der App.
• Eine Connector-Funktion ausführen, um auf ein Backend-System zuzugreifen: Verwenden Sie Connectors, damit Tulip mit Systemen von Drittanbietern interagieren kann, und führen Sie eine Connector-Funktion über einen Trigger aus.
• Benachrichtigungen senden: Senden Sie E-Mails oder SMS-Benachrichtigungen von einer App an einen Administrator. Diese Nachrichten können Bilder, Statusinformationen zum Prozess oder andere relevante Informationen enthalten.
• Daten speichern: Speichern Sie Eingabedaten aus einer App in Variablen oder Tabellen.
• Ein Gerät verwenden: Für Bediener, die während eines Prozesses beide Hände benötigen, fügen Sie einen Trigger für ein Geräteereignis hinzu, z. B. ein Fußpedal, um zum nächsten Schritt zu gelangen.

Wie funktionieren Trigger?

Logik

Trigger verwenden eine „when, if, then, else “-Logikstruktur:

• wenn „Ereignis in Tulip registriert wird“
• dann „Maßnahme ergreifen“ oder „Übergang ausführen“.

Trigger können auch bedingte Logik enthalten:

• wenn „Ereignis in Tulip registriert“
• if „Bedingung ist erfüllt“
• dann „Maßnahme ergreifen“
• sonst „eine andere Aktion ausführen“

Erfahren Sie hier mehr über bedingte Trigger-Logik.

Trigger werden durch ein gebündelt und bestehen aus einer Aktion und Bedingungen.

Trigger können so einfach sein wie im folgenden Beispiel:

Wenn eine Schaltfläche gedrückt wird, dann zum nächsten Schritt wechseln.

Oder Trigger können komplexer sein, wie beispielsweise ein Barcode-Scan, der eine Backend-Datenbank abfragt, um Bestellinformationen als Variable zurückzugeben.

Wenn der Barcode-Scanner an der aktuellen Station Daten ausgibt, ruft ein (über eine Connector-Funktion) die Bestelldetails aus einer externen Datenbank ab und speichert den Wert in einer Variablen. Der Trigger wechselt anschließend zum nächsten Schritt.

Befehlstypen

In einem Trigger können Sie zwei Arten von Befehlen verwenden:

1. Aktion: Eine Änderung in der App, die nicht mit dem Wechsel zwischen Schritten zusammenhängt (z. B. eine Fehlermeldung anzeigen, eine E-Mail senden, einen Screenshot der App erstellen)
2. Übergang: Ein Navigationsereignis in der App selbst (z. B. zum nächsten Schritt wechseln, eine App abschließen, eine App abbrechen). Übergänge können das Auslösen (d. h. Starten) anderer Trigger ermöglichen. Sie können beispielsweise einen Trigger auf App-Ebene erstellen, der jedes Mal ausgelöst wird, wenn die App abgeschlossen wird.

Trigger-Warteschlange

s (z. B. das Klicken auf eine Schaltfläche) fügen Trigger zu einer sequenziellen, single-threaded hinzu, die im Tulip Player ausgeführt werden.

Die hat Auswirkungen auf:1. Funktionen: * Funktionen werden in die Trigger-Warteschlange aufgenommen2. Benutzerdefinierte Widgets: * Die Ausführung von Logik in einem benutzerdefinierten Widget kann sich auf die Trigger-Warteschlange auswirken

Ausführungsreihenfolge

Trigger werden nacheinander und in der Reihenfolge der „ Trigger Event “ (d. h. Schaltflächenklick, Timer, Auswahl einer Tabellenzeile) ausgeführt.

Trigger werden sequenziell ausgeführt, d. h., der erste Trigger in der Reihe muss abgeschlossen sein, bevor der zweite Trigger mit der Ausführung beginnt. Diese Reihenfolge der Triggerausführung wird als Trigger-Warteschlange bezeichnet.

Die Trigger-Warteschlange ist von anderen Aufgaben innerhalb einer App getrennt, wie z. B. Variableninteraktionen (z. B. Texteingaben, Kontrollkästchen), benutzerdefinierte Widgets und JavaScript in benutzerdefinierten Widgets.

Wie werden Eingabewerte in Triggern verwendet?

Eingabewerte (d. h. Variablen) werden per Referenz an Trigger übergeben.

Trigger beziehen sich auf den Eingabewert einer Variablen zum Zeitpunkt der Triggerausführung. Ändert sich der Eingabewert, bevor ein Trigger ausgeführt wird, bezieht sich der Trigger auf den aktuellsten Wert.

Variablen sind app-weit gültig, wodurch sie durch andere Logik in der App verändert werden können.

:

Wann werden Trigger abgebrochen?

Trigger in der Trigger-Warteschlange werden abgebrochen und daher nicht ausgeführt, wenn:

1. Ein Trigger nach einem Übergang in die Warteschlange gestellt wird: Wennein Übergang ausgeführt wird (z. B. „Weiter“, „App abschließen“, „Zum Schritt nach Name gehen“ usw.), werden alle in der Warteschlange verbleibenden Trigger abgebrochen.
2. Der Tulip Player wird zwangsweise geschlossen: Wennein Bediener den Player zwangsweise schließt (z. B. wenn eine App nicht mehr reagiert), werden alle verbleibenden Aktionen in einem laufenden Trigger sowie alle verbleibenden Trigger in der Warteschlange abgebrochen.

Fehlerbehandlung

Triggerfehler und die daraus resultierende Abbruch erfolgen in den folgenden Szenarien:

1. Fehler bei der Trigger-Aktion
2. Zeitüberschreitung des Triggers

Fehler bei einer Trigger-Aktion

Wenn eine Aktion in einem Trigger einen Fehler verursacht, werden die verbleibenden Aktionen in diesem Trigger übersprungen bzw. abgebrochen:

Nach einem Fehler werden standardmäßig alle verbleibenden Trigger in der Warteschlange und im Trigger-Ereignis für die folgenden Trigger auf App- und Schritt-Ebene nicht ausgeführt:* App gestartet* App abgeschlossen* App abgebrochen* Beim Betreten eines Schritts* Beim Verlassen eines Schritts

Bei allen anderen Triggertypen (z. B. „Wenn eine Schaltfläche gedrückt wird“) ist die Umschaltfunktion „Verbleibende Trigger bei Fehler stoppen“ standardmäßig deaktiviert.

Trigger-Timeout

Wenn ein Trigger ein Timeout erreicht (siehe Trigger-Timeouts), werden alle verbleibenden Trigger in der Warteschlange abgebrochen.

Technisches Verhalten

Trigger-Laufzeit

• Trigger werden nacheinander in einer einzigen Trigger-Laufzeit ausgeführt. Eine Trigger-Laufzeit ist der Zeitraum, in dem ein Trigger in Tulip aktiv ausgeführt wird.
• Trigger werden niemals parallel oder im Hintergrund anderer Trigger ausgeführt. Ein neuer Trigger kann erst dann mit der Ausführung beginnen, wenn der aktuell laufende Trigger beendet ist.
• Bediener können weiterhin mit der App interagieren (z. B. auf Schaltflächen klicken, mit Tabellen interagieren), während ein Trigger ausgeführt wird. Diese Schaltflächenklicks und andere Trigger-Ereignisse fügen der Trigger-Warteschlange neue Trigger hinzu.

Trigger-Timeouts – aktualisiert ab LTS15 / r332

Die Standard-Timeout-Dauer für Trigger beträgt 10 Minuten. Nach Ablauf dieser Zeit werden der Trigger und alle verbleibenden Aktionen abgebrochen, und alle anderen Trigger in der Warteschlange werden storniert.

Die Zeitüberschreitung von 10 Minuten gilt für das Trigger Event. Wenn beispielsweise ein Schaltflächenklick 5 Trigger auslöst, müssen alle 5 Trigger in der Trigger-Warteschlange und ihre jeweiligen Aktionen innerhalb der 10 Minuten ausgeführt werden.

Nach 30 Sekunden Trigger-Laufzeit zeigt die App dem Bediener die folgende Meldung an:

Nach 100 Sekunden Trigger-Laufzeit zeigt die App dem Bediener die folgende Meldung an:

Nach 10 Minuten wird der Trigger abgebrochen und die App zeigt die folgende Fehlermeldung an:

Optionale Timeout-Einstellungen

Bearbeiten Sie die Timeout-Einstellungen für eine Instanz mithilfe der folgenden Methoden:

1. Tulip kann eine Einstellung aktivieren oder deaktivieren, die es Bedienern ermöglicht, einen lang andauernden Trigger nach den ersten 100 Sekunden manuell abzubrechen. Wenden Sie sich an den Tulip-Support, um diese Funktion zu aktivieren.

2. Der Tulip-Support kann die Timeout-Dauer verkürzen oder verlängern. Beachten Sie, dass Tulip die Timeout-Dauer von 10 Minuten als Ausgangspunkt empfiehlt, um die Wahrscheinlichkeit zu erhöhen, dass Ihre Logik vollständig ausgeführt wird. Wenn die Ausführung eines Triggers durchweg länger als ein paar Minuten dauert, sollten Sie Folgendes in Betracht ziehen:

   • Vereinfachen Sie die Trigger-Logik, um die Benutzererfahrung zu verbessern und die Wahrscheinlichkeit eines Trigger-Fehlers zu verringern.
   • Starten Sie nach Möglichkeit eine Automatisierung im Hintergrund, um die Ausführung der Logik auszulagern und zu verhindern, dass der Bediener in seiner weiteren Arbeit blockiert wird.
   • Überprüfen und optimieren Sie alle Abhängigkeiten von Systemen von Drittanbietern in der Trigger-Logik (z. B. langsame Connector-Funktionen, nicht optimale API-Nutzung).

Aktionen für Tabelleneinträge

Tabelleneintrag erstellen

Bei der Erstellung eines neuen Tabellendatensatzes empfiehlt es sich, unmittelbar nach der Aktion „Tabellendatensatz / Datensatz erstellen“ die entsprechenden Datenbearbeitungsaktionen auszuführen, um die anderen Spalten des neu erstellten Tabellendatensatzes zu füllen.

Befinden sich zwischen der Aktion „Tabelleneintrag / Eintrag erstellen“ und den Aktionen zum Ausfüllen der anderen Spalten weitere Aktionen, wird die Erstellung dieses Tabelleneintrags im Widget „Eintragshistorie“ als separate Ereignisse angezeigt.

Tabellendatensatz erstellen – ab LTS15 / r332

Ab LTS15 werden aufeinanderfolgende Tabellenaktionen wie „Tabelleneintrag / Eintrag erstellen “ und „Datenbearbeitung / Speichern“ für denselben Eintrag gebündelt. Das bedeutet, dass die Aktionen „Erstellen“ und „Datenbearbeitung“ in einem Trigger in einer einzigen Transaktion ausgeführt werden.

Die Aktionen „Datensatz anlegen“ und „Datenbearbeitung / Speichern“ werden nicht in einer Transaktion gebündelt, wenn sich andere Aktionen zwischen ihnen befinden (z. B. Datenbearbeitungen an Variablen oder anderen Tabellendatensätzen, Konnektorfunktionen usw.).

In den folgenden Beispiel-Triggern werden die Aktion „Datensatz anlegen“ und die Aktionen „Datenmanipulation / Speichern“ gebündelt und entweder alle erfolgreich oder alle fehlgeschlagen. Wenn alle Aktionen fehlschlagen, werden sie gemeinsam mit ausfallsicheren Wiederholungsversuchen erneut ausgeführt.

Beispiel 1: Aufeinanderfolgende „Create“- und Datenmanipulationsaktionen für denselben Tabelleneintrag: Diesewürden in LTS15 entweder alle erfolgreich sein oder alle fehlschlagen, nicht jedoch in Versionen vor LTS12.

Beispiel 2: Aufeinanderfolgende Erstellungs- und Datenbearbeitungsaktionen für denselben Tabelleneintrag, gefolgt von einer Connector-Funktionsaktion: DieAktionen „Tabelleneintrag erstellen“ und „Datenbearbeitung“ selbst würden in LTS15 gebündelt. Die Connector-Funktionsaktion könnte fehlschlagen, unabhängig davon, ob die Tabellenaktionen erfolgreich waren.

Im folgenden Trigger finden die Aktionen „Datenbearbeitung“ und „Speichern“ für zwei verschiedene Tabellendatensätze statt, sodass die Aktionen nicht in einer einzigen Transaktion gebündelt werden.

Beispiel 3: „Tabelleneintrag / Anlegen“ und „Datenbearbeitung / Speichern“ für denselben Tabelleneintrag, getrennt durch eine weitere Aktion der Datenbearbeitung. DieseAktionen werden nicht in einer einzigen Transaktion gebündelt.

Im folgenden Trigger werden die Aktionen „Tabelleneintrag“ und „Datenmanipulation / Speichern“ nicht gebündelt, da Metadaten aus dem in der vorhergehenden Aktion angelegten Tabelleneintrag als Dateneingabe für die Aktion „Datenmanipulation / Speichern“ verwendet werden.

Beispiel 4: Anlegen und Aktualisieren von Lesedaten aus demselben DatensatzDiese Aktionen werden nicht in einer einzigen Transaktion gebündelt.

Bei Verwendung einer Aggregation in einer gebündelten Tabellenaktualisierungsaktion wird der Aggregationswert vor der Aktualisierung ermittelt. Der Aggregationswert spiegelt die gebündelte Aktualisierung des Tabellendatensatzes nicht wider.

Beispiel 5: Anlegen und Aktualisieren mit AggregationenDiese Aktionen werden gebündelt, und der Aggregationswert wird vor der Anlegeaktion ermittelt.

Aktualisierung eines Tabellendatensatzes

Aufeinanderfolgende Datenbearbeitungsaktionen für denselben Tabellendatensatz werden gebündelt und in einer einzigen Netzwerkanfrage ausgeführt, sodass sie alle gleichzeitig stattfinden

Trigger-Aktionen, die Tabellendatensätze betreffen, werden anhand ihres Aktionstyps und ihrer Reihenfolge gruppiert. Speicheraktionen mit demselben Speicherort werden in einer Netzwerkanfrage zusammengefasst. Dagegen werden Aktionen wie „Datensatz laden“ oder „Datensatz erstellen“ als einzelne Transaktionen behandelt.

Für eine optimale Leistung empfehlen wir, Aktualisierungen desselben Datensatzes nacheinander auszuführen – d. h., Aktualisierungen desselben Datensatzes nicht durch andere Tabellen- oder Datenaktionen zu unterbrechen.

Beispiel 1: Aufeinanderfolgende Aktualisierungen desselben Datensatzes DieseAktionen werden in einer Transaktion gebündelt:

Beispiel 2: Aktualisierungen desselben Datensatzes, getrennt durch andere Aktionen Diese Aktionen werden nicht gebündelt, da die Datensätze derselben Tabelle nicht aufeinanderfolgen:

Im folgenden Trigger finden Datenbearbeitungs- und Speichervorgänge für zwei verschiedene Tabellendatensätze statt, weshalb die Vorgänge nicht in einer einzigen Transaktion gebündelt werden.

Beispiel 3: Aktualisierungen an zwei verschiedenen DatensätzenDiese Aktionen werden nicht in einer einzigen Transaktion gebündelt.

Bei Verwendung einer Aggregation in einer gebündelten Tabellenaktualisierungsaktion wird der Aggregationswert vor der Aktualisierung ermittelt. Der Aggregationswert spiegelt die gebündelte Aktualisierung der Tabellendatensätze nicht wider.

Beispiel 4: Aktualisierungen mit AggregationenDiese Aktionen werden gebündelt, was bedeutet, dass der Aggregationswert vor der Aktualisierung berechnet wird.

Wiederholungsversuche bei Triggern (Tabellenaktionen) – neu ab LTS15 / r332

Trigger wiederholen nur Tabellenaktionen (z. B. das Schreiben von Tabellendaten, das Aktualisieren von Tabellendaten, Tabelleninteraktionen usw.).

Wenn innerhalb der 10-minütigen Laufzeit des Triggers eine einzelne Tabellenaktion fehlschlägt, wird sie bis zu 2 Minuten lang erneut versucht. Wenn die Aktion nach 2 Minuten nicht ausgeführt werden konnte, werden alle verbleibenden Aktionen und Trigger in der Trigger-Warteschlange abgebrochen.

Um einen netzwerkresilienten Trigger zu gewährleisten, stellen Sie sicher, dass die Aktionen eines Triggers ausschließlich Tabelleninteraktionen und Datenaktualisierungen umfassen. Hinweise zu resilienten Tabellenaktionen finden Sie unter „Tabellendatensatzaktionen “.

Wiederholungsversuche von Trigger-Aktionen führen nicht zu doppelten Ergebnissen, falls die Aktion versehentlich zweimal ausgeführt wird. Dadurch wird sichergestellt, dass eine Tabellenaktion nicht mehrere Kopien derselben Daten schreibt.

Beschränkungen und Zeitlimits

Arten von Triggern

Es gibt drei Arten von Triggern:

Auslöser auf App-Ebene

Sie können Auslöser auf App-Ebene auf folgende Ereignisse anwenden:

• App-Start
• App abgeschlossen
• App abgebrochen

Sie können auf Trigger auf App-Ebene über die Registerkarte „App“ zugreifen.

Erfahren Sie hier mehr über Trigger auf App-Ebene.

Trigger auf Schritt-Ebene

Sie können Trigger auf Schritt-Ebene auf folgende Ereignisse anwenden:

• In regelmäßigen Zeitabständen („zeitgesteuert“)
• Bei einer Eingabe von einer Maschine oder einem Gerät („Maschinen & Geräte“)
• Wenn der Schritt geöffnet wird
• Wenn der Schritt geschlossen wird

Sie können auf Trigger auf Schritt-Ebene über die Registerkarte „Schritt“ zugreifen.

Erfahren Sie hier mehr über die verfügbaren Trigger auf Schritt-Ebene

Widget-Auslöser

Widget-Trigger werden beim Drücken einer Schaltfläche aktiviert. In einem Schritt können mehrere Schaltflächen-Trigger vorhanden sein, die ausgelöst werden, wenn der jeweilige Bediener im Tulip Player auf die entsprechende Schaltfläche drückt.

Wählen Sie das gewünschte Widget aus und rufen Sie anschließend die Widget-Trigger über die Registerkarte „Widget“ auf.

Erfahren Sie hier mehr über Widget-Trigger.

Trigger erstellen

1. Klicken Sie im Side Pane im Abschnitt „Trigger“ auf „+ “. Der Trigger-Editor wird geöffnet.
2. Geben Sie Ihrem Trigger einen Namen, um zu kennzeichnen, welche Funktion er in der App erfüllt. Sie können auch eine Beschreibung hinzufügen, um weitere Details anzugeben.

Bewährte Vorgehensweisen

• Konfigurieren Sie Trigger so, dass sie auf Fehler reagieren können. Triggersollten so konfiguriert werden, dass sie im Falle eines Fehlers fortfahren oder anhalten. Ein Trigger kann aufgrund ungültiger Eingaben, eines Ausführungsfehlers oder einer fehlgeschlagenen Connector-Funktion bzw. eines fehlgeschlagenen Schreibversuchs in eine Tabelle einen Fehler auslösen.
• Wenn ein Trigger so konfiguriert ist, dass er fortfährt, wird der Trigger, bei dem ein Fehler aufgetreten ist, angehalten, der nächste Trigger wird jedoch fortgesetzt
• Wenn ein Trigger so konfiguriert ist, dass er anhält, werden die anderen Trigger im Trigger-Ereignis abgebrochen.

• Vermeiden Sie lang laufende Trigger in einem Schritt mit interaktiven Widgets. Widgetsändern ihren Zustand sofort nach einer Interaktion. Während der Bediener die Aktion sofort auf dem Widget sieht, kann die Logik aufgrund eines langsamen Netzwerks oder eines lang laufenden Konnektors mit einer leichten Verzögerung ausgeführt werden.
• Schulen Sie die Bediener darin, nach dem Klicken auf einen Übergang (z. B. „Nächster Schritt“) zu warten. Auf einem Schritt werden Trigger, die nach einem Übergang in der Warteschlange stehen, nicht ausgeführt. Wenn ein Bediener mit einem Widget interagiert, das einen Übergang enthält, verbleibt er auf dem Schritt, bis der Übergang ausgeführt wurde. Klickt der Bediener beispielsweise auf „Nächster Schritt“ und löst während des Wartens einen weiteren Trigger aus, wird der nach dem Übergang verbleibende Trigger nicht ausgeführt.
• Führen Sie lang laufende Konnektoren und Datenaktualisierungen in separaten Schritten durch. Interaktionen mit sensiblen Daten sollten nicht im selben Schritt wie lang laufende Konnektorlogik durchgeführt werden. Falls ein Bediener nach dem Klicken auf einen lang laufenden Trigger oder Übergang mit dem Schritt interagiert, besteht das Risiko, dass kritische Daten nicht gespeichert werden.
• Stellen Sie sicher, dass Variablen für jeden Schritt nur eine einzige Eingabe haben: Variablensollten nicht mit konkurrierender Eingabelogik geteilt werden (d. h. mehrere Schaltflächen in einer App, die dieselbe Variable aktualisieren), um Race-Conditions zu vermeiden. Ein Auslöser erfasst beispielsweise den aktuellen Wert einer Variablen. Ändert sich der Wert der Variablen, bevor ein Auslöser ihn erfasst, sind die Daten fehlerhaft.

Weiterführende Informationen

• Liste der Trigger-Aktionen und Übergänge
• Bedingte Triggerlogik
• Bewährte Verfahren für leistungsstarke Apps

{{snippet.Haben Sie gefunden, wonach Sie gesucht haben?}}