In den folgenden Lektionen werden wir die verschiedenen Elemente einer Komponente besprechen. Hier finden Sie eine kurze Einführung in die allgemeine Struktur eines Workflows.
Eine Komponente ist eine Art von Workflow, der aus mehreren Bildschirmen/Schritten bestehen kann. Jeder Workflow, der mit verschiedenen Komponenten und UI-Schritten modelliert werden kann, kann auch in einer einzigen Komponente erstellt werden. Oft werden Komponenten bevorzugt, die wiederverwendbare Module sind, um eine bestimmte Funktion zu erfüllen, z. B. eine Komponente, mit der Sie nur ein Datum auswählen können. Auf diese Weise können Sie und auch Nicht-Entwickler Ihre Komponenten verwenden, um verschiedene business Prozesse zu modellieren.
Komponenten sind in XML geschrieben. Sie können das gewünschte Verhalten implementieren, indem Sie die Regeln niederschreiben, die aus ifA then B-Anweisungen bestehen.
Zum Beispiel für die folgende Anforderung: Wenn der Benutzer eine Maschine inspiziert und die Schaltfläche "Kamera" drückt, wird die interne Kamera des Geräts gestartet.
Die gleiche Regel könnte etwas näher an der Umsetzung ausgedrückt werden als:
Wenn wir uns im Schritt "inspect_machine" befinden und ein Ereignis mit dem Befehl "Camera" eintritt, führen wir die Aktion "start_camera" aus.
Struktureller Rahmen eines Bauteils
Der typische strukturelle Rahmen eines Bauteils sieht wie folgt aus:
<workflow [ATTRIBUTES]>
<context> [...] </context> // Data variables, optional
<rules> [...] </rules> // If [Expression] then [actions]; optional
<actions> [...] </actions> // optional
<steps>
<step [ATTRIBUTES]>
<states>
<onresume> [...] </onresume> // optional
<onevent> [...] </onevent> // optional
[...]
</states>
<mapping> [...] </mapping>
</step>
[...]
</steps>
</workflow>
Bevor wir mit einem Beispiel fortfahren, folgt ein Überblick über die XML-Tags:
<Inhalt> Definiert die Variablen (Daten), mit denen gearbeitet werden soll.
<Regeln> Besteht aus einem Ausdruck und einer weiteren Aktion. Sie definiert, unter welcher Bedingung eine Reihe von Aktionen ausgeführt wird.
<Aktionen> Vordefinierte Aktionen, die im Arbeitsablauf verwendet werden sollen (z. B.: Starten der Gerätekamera, Ändern des Werts eines Kontexts in x, ...).
<step> Bildschirm auf dem Gerät: Er enthält die Daten (Kontext) und die Logik (Regeln und Aktionen) des Bildschirms und ist mit einer Vorlage für die Benutzeroberfläche verbunden.
<States> Legt fest, wann eine Regel geprüft wird (z. B. wenn ein Ereignis eintritt, wenn ein Schritt betreten oder verlassen wird).
<mapping> Ordnet die Daten (Kontextvariablen) der Benutzeroberfläche zu (die in einer anderen Datei definiert ist, auf die wir später eingehen werden).
Beispiel für eine Komponente
Um die Struktur von Komponenten besser zu verstehen, werden wir ein Beispiel für eine sehr einfache Komponente verwenden.
Der Benutzer wählt zwischen den beiden Optionen "Apfel" und "Birne". Dieselbe Komponente wird für diese Schulung verwendet und im weiteren Verlauf verbessert.
Der untenstehende Screenshot zeigt den Bildschirm des Geräts.
Der Arbeitsablauf ist folgender:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<workflow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" wfd_version="1.0" reporting="false"
id="choice" name="choice" descriptor="Choice component" startstep="choose"
xsi:noNamespaceSchemaLocation="../../../configuration/workflow.xsd">
<steps>
<step id="choose" descriptor="the user selects between two options" uitemplate="ChoiceScreen">
<states>
<onevent>
<rule id="menu_button_selection">
<expression>#{event:command} == 'APPLE' || #{event:command} == 'PEAR'</expression>
<actions>
<finish_workflow id="finish_workflow">
<output>
<param name="selected_button" type="string">#{event:command}</param>
</output>
</finish_workflow>
</actions>
</rule>
</onevent>
</states>
</step>
</steps>
</workflow>
Komponente herunterladen
Erläuterung des Arbeitsablaufs
1. Der Workflow-Tag enthält ein Attribut startstep = "choose". Damit wird ausgewählt, welcher Schritt nach der Initialisierung der Komponente zuerst ausgeführt wird.
2. <step id="choose"... wird verwendet, um auf eine Auswahl zu verweisen, die mit uitemplate="ChoiceScreen" weiter angezeigt wird . ChoiceScreen ist eine Datei, die definiert, was auf dem Bildschirm angezeigt wird, während wir uns in diesem Schritt befinden.
Wie bereits erläutert, wird das Verhalten einer Komponente mithilfe von Regeln definiert. Eine Regel besteht aus einem Ausdruck (oder einer Bedingung) und der Aktion, die ausgeführt werden soll, wenn diese Bedingung wahr ist. Jede Regel ist einem der Zustände <onenter>, <onresume>, <onleave>, <onevent> oder <onpause> zugeordnet. Die Regeln werden nur geprüft, wenn sich die Komponente in diesem Zustand befindet (z. B. onenter, wenn die Komponente zum ersten Mal gestartet wird).
3. Die <rule id="menu_button_selection"> ist dem Zustand <onevent> zugeordnet. Immer wenn ein Ereignis eintritt, werden alle Regeln, die diesem Zustand zugeordnet sind, überprüft. Hier prüft <expression>#{event:command} == 'APPLE' || #{event:command} == 'PEAR'</expression>, ob das Ereignis einen bestimmten Befehl enthält. Ein solches Ereignis würde ausgelöst werden, wenn eine Schaltfläche mit dem Namen "APPLE" oder "PEAR" entweder per Sprachbefehl oder durch Drücken auf dem Bildschirm ausgelöst wird.
4. Wenn ein Regelausdruck zu "wahr" ausgewertet wird, wird der Satz von Aktionen im <actions>-Tag der Regel ausgeführt. In diesem Beispiel wird die Aktion finish_workflow verwendet. Diese verlässt die Komponente sofort, sobald der Benutzer eine der beiden Optionen gewählt hat, und übergibt die getroffene Wahl in einem <output>-Parameter, so dass wir auf der Grundlage dieser Wahl verschiedene Übergänge im Workflow-Diagramm erstellen können.
Zuweisung
Nehmen wir an, Sie möchten unsere Wahlkomponente so erweitern, dass sie eine Nachricht mit der Wahl des Benutzers zurück an den Frontline Connector sendet (der wiederum diese Information an ein Backend-System weitergeben könnte). Denken Sie über die folgenden Fragen nach:
- Welche Stufe(n) würde(n) Ihre Komponente haben?
- Werfen Sie einen Blick auf den Aktionskatalog: Welche Aktionen würden Sie wahrscheinlich brauchen?
Hilfe und Ressourcen
Aktionen sind die grundlegenden Bausteine, die wir verwenden können. Sie reichen von der Änderung dessen, was der Benutzer sieht (Farben, Text, Benachrichtigungen,...) bis zur Steuerung des Programmflusses (Übergang zum nächsten Schritt) durch Verwaltung von Daten und Kommunikation mit dem Frontline Connector oder externen Geräten.
Anmerkungen zur Lösung
Zunächst einmal könnten Sie argumentieren, dass die Kommunikation mit dem Frontline Connector eine separate Funktion ist und eine eigene Komponente haben sollte. Sie hätten absolut Recht: Die Trennung des Kommunikationsaspekts in eine eigene Komponente würde die Wiederverwendbarkeit beider Komponenten erhöhen. Andererseits möchten Sie manchmal den in der Frontline Creator Interface gezeigten Prozessablauf für Ihren Kunden vereinfachen, indem Sie mehrere Funktionalitäten in einer einzigen Komponente zusammenhalten. Nehmen wir zunächst an, dass wir beide Funktionalitäten in einer Komponente zusammenfassen.
Welche Stufen könnte Ihre Komponente haben?
Zuvor wurde Ihnen gesagt, dass Schritte im Grunde genommen mit Bildschirmen gleichzusetzen sind. Warum sollten Sie also mehr als einen Schritt haben, wenn die zusätzliche Funktionalität nur eine Backend-Kommunikation ist?
Die Antwort lautet: Wartbarkeit und Wiederverwendbarkeit. Wartbarkeit, weil man sich bei Änderungen am Kommunikationsaspekt nur diesen Schritt ansehen muss und nicht den anderen Code lesen muss. Wiederverwendbarkeit, weil man mit demselben Schritt auch andere Nachrichten senden könnte, wenn die Komponente noch komplexer wird.
Ebenso wäre es eine gute Idee, zwei getrennte Komponenten für diese beiden Funktionalitäten zu erstellen. Es ist eine gute Idee, zumindest getrennte Schritte zu erstellen, wenn Sie sie in einer Komponente kombinieren. Lassen Sie den Bildschirm einfach gleich aussehen oder fügen Sie eine Fortschrittsbestätigung durch den Connector hinzu. Wir schlagen daher vor, hier 2 Schritte zu haben, z. B. "choice" und "message_connector".
Welche Maßnahmen würden Sie wahrscheinlich benötigen?
Der Hauptzweck dieser Frage besteht darin, Sie mit dem Katalog "Aktionen" vertraut zu machen. Hier finden Sie Beispiele für Aktionen, die Sie bei der Umsetzung verwenden könnten:
- send_commit_message: Kommuniziert mit dem Frontline Connector
- step_transition: Wechsel vom Schritt "choice" zu "message_connector" (wenn Sie 2 Schritte haben)
- ui_progress_notification: Informiert den Benutzer, dass wir gerade mit dem Backend kommunizieren (falls wir auf eine Bestätigung warten)
- setvar: Wird verwendet, um eine Eingabe zu speichern, die später sowohl an den Konnektor als auch an einen Ausgabeparameter unserer Komponente zurückgegeben werden kann
Damit haben Sie nun die erste Lektion abgeschlossen. In der nächsten Lektion geht es um und um Ihre erste praktische Aufgabe.
