Les composants sont écrits en XML et vous pouvez implémenter le comportement souhaité en écrivant ses règles, qui sont des instructions if A puis B .
Par exemple, lors de l’inspection d’une machine, si l’utilisateur appuie sur le bouton « Caméra », la caméra interne de l’appareil démarre.
La même règle pourrait être exprimée un peu plus près de la mise en œuvre comme suit :
Si nous sommes dans le step
« inspect_machine » et qu’unevent
se produit avec la command
« Caméra », alors exécutez action
« start_camera ».
L’ossature structurelle typique d’un composant est la suivante :
<workflow [ATTRIBUTS]> <context> [...] </context> // Variables de données, <règles facultatives > [...] </rules> // Si [Expression] alors [actions] ; optional <actions> [...] </actions> // optional <steps> <step [ATTRIBUTS]> <states> <onresume> [...] </onresume> // optional <onevent> [...] </onevent> // facultatif [...] </states> <mapping> [...] </mapping> </step> [...] </steps> </workflow>
Avant d’aller plus loin avec un exemple, vous trouverez ci-dessous un aperçu des balises XML :
Pour mieux comprendre la structure des composants, nous allons utiliser un exemple de composant Image Choice .
L’utilisateur choisit entre les deux options « Apple » et « Pear ». Le même volet sera utilisé pour cette formation et sera amélioré au fur et à mesure que nous avancerons.
L’interface utilisateur ci-dessous montre comment ce composant s’affiche lors de l’exécution sur l’application Frontline Workplace Smart Glass.
Le flux de travail est le suivant :
< ?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="Composant de choix » startstep="choose" xsi :noNamespaceSchemaLocation= ».. /.. /.. /configuration/workflow.xsd"> <steps> <step id="choose » descriptor="l’utilisateur choisit entre deux 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>
1. La balise de workflow contient un attribut startstep="choose ». Ceci est utilisé pour sélectionner l’étape qui sera effectuée en premier après l’initialisation du composant.
2. <step id="choose"...
est utilisé pour faire référence à un choix qui sera affiché ultérieurement à l’aide de uitemplate="ChoiceScreen"
. ChoiceScreen est un fichier qui définit ce qui est affiché à l’écran pendant que nous sommes dans cette étape.
Comme expliqué, le comportement d’un composant est défini à l’aide de règles. Une règle se compose d’une expression (ou d’une condition) et de l’action à effectuer lorsque cette condition est True. Chaque règle est affectée à l’un des états <onenter>
, <onresume>
, <onleave>
<onevent>
ou <onpause>
. Les règles ne seront vérifiées que lorsque le composant est dans cet état (par exemple, onenter - lorsque le composant est démarré pour la première fois).
3. Le <rule id="menu_button_selection">
est attribué à l’État<onevent>
. Chaque fois qu’un événement se produit, toutes les règles données à cet état seront vérifiées. Ici, <expression>#{event:command} == 'APPLE' || #{event:command} == 'PEAR'</expression>
vérifie si l’événement contient une commande spécifique. Un tel événement serait activé lorsqu’un bouton portant le nom « APPLE » ou « PEAR » est déclenché soit par commande vocale, soit en appuyant dessus sur l’écran.
4. Si une expression de règle a la valeur true, l’ensemble des actions de la balise de <actions>
la règle est exécuté. Dans cet exemple, l’action finish_workflow
est utilisée. Cela quitte immédiatement le composant une fois que l’utilisateur a choisi l’une des deux options, et transmet quel choix a été fait dans un <output>
paramètre afin que nous puissions créer différentes transitions dans le diagramme de flux de travail en fonction de ce choix.
Supposons que vous souhaitiez étendre notre composant de choix pour renvoyer un message contenant le choix de l’utilisateur au connecteur de première ligne (qui pourrait à son tour communiquer cette information à un système principal). Posez-vous les questions suivantes :
Les actions sont les éléments de base que nous pouvons utiliser. Ils vont de la modification de ce que l’utilisateur voit (couleurs, texte, notifications,...) au contrôle du flux du programme (transition vers l’étape suivante) en gérant les données et en communiquant avec le connecteur de première ligne ou des périphériques externes.
Tout d’abord, vous pourriez faire valoir que la communication avec le connecteur de première ligne est une fonctionnalité distincte et doit avoir son propre composant. Vous avez tout à fait raison : séparer l’aspect communication en ses propres composantes rendrait les deux composants plus réutilisables. D’autre part, vous souhaitez parfois simplifier le flux de processus affiché dans l’interface Frontline Creator pour votre client en regroupant plusieurs fonctionnalités dans un seul composant. Pour l’instant, supposons que nous combinions les deux fonctionnalités en un seul composant.
Auparavant, on vous disait que les étapes étaient équivalentes à des écrans. Alors, pourquoi auriez-vous plus d’une étape si la fonctionnalité supplémentaire n’est qu’une communication backend ?
La réponse est la maintenabilité et la réutilisabilité. Maintenabilité, car lorsque vous apportez des modifications à l’aspect communication, vous n’aurez qu’à regarder cette étape et ne lire aucun autre code. Réutilisation, car vous pouvez également envoyer des messages différents en utilisant la même étape si le composant devient encore plus complexe.
De la même manière, il serait judicieux de faire deux composants distincts de ces deux fonctionnalités. C’est une bonne idée de créer au moins des étapes distinctes si vous les combinez en un seul composant. Il suffit de faire en sorte que l’écran ait la même apparence ou d’ajouter un accusé de réception de notification de progression à partir du connecteur. En tant que tel, nous suggérons d’avoir 2 étapes ici, par exemple, « choix » et « message_connector ».
L’objectif principal de cette question est de vous familiariser avec le catalogue 'Actions'. Voici des exemples d’actions que vous pouvez utiliser dans le processus d’implémentation :
Avec cela, vous avez maintenant terminé la première leçon. La prochaine leçon portera sur les champs d’application et englobera votre premier devoir pratique.