Base de connaissances

Retour à la vue d’ensemble de l’assistance

Dans cette leçon, nous allons parler des champs d’application et des références. Ceux-ci vous aideront à rendre les règles et les actions réutilisables, ainsi qu’à accéder aux données et à les gérer dans l’ensemble de votre composant.

Il existe deux étendues dans lesquelles vous pouvez déclarer des règles, des actions et stocker des données :

  • pas: Chaque étape d’un composant a sa propre portée. Les règles, actions et données définies ici ne sont pas disponibles ailleurs.
  • Flux de travail : Toutes les étapes d’un composant ont accès aux règles, actions et données ajoutées à l’étendue du workflow.

En outre, trois étendues sont disponibles pour stocker les données :

  • racine: Tous les composants d’un workflow ont accès à l’étendue racine. Cela peut être utilisé pour transmettre des données entre les composants.
  • user_session : Tant que l’utilisateur ne se déconnecte pas, les données stockées dans l’étendue user_session seront accessibles même après la fin de l’exécution du workflow (par exemple, à partir d’un autre workflow ou lors de l’exécution du même workflow plusieurs fois).
  • global: Tant que l’application Frontline Workplace n’est pas fermée, les données stockées dans l’étendue globale sont accessibles, même si un utilisateur se déconnecte et qu’un autre utilisateur se connecte.

Exemple de composant

<workflow [ATTRIBUTS]>
    <context> [...] </context>                              \
    <actions> [...] </actions>                              -\
    <rules>                                                 --\ 
        <rule id="menu_button_selection">                   ---\
            <expression>[..] </expression>                   ----\
            <actions>                                       -----|--> Portée
                du workflow[...]                                       ----/
            </actions>                                      ---/
        </rule>                                             --/
    </rules>                                                -/
                               
    <steps> 
        <step id="stepA » [ATTRIBUTS]>
            <context> [...] </context>                      ----\
            <rules> [...] </rules>                          -----|--> Step scope
            <actions> [...] </actions>                      ----/
            <states>
                <onevent> 
                    <rule ref="menu_button_selection"/>     -------> Référencement d’une règle à partir de l’étendue

                    du workflow<rule id="show_notification">           --\
                        <expression>[..] </expression>       ---\
                        <actions>                           ----\
                            [...]                           -----|--> Définition directe (peut toujours faire référence à une action prédéfinie)
                        </actions>                          ----/
                    </rule>                                 ---/
                </onevent> 
            </states>
        </step><

        step id="stepB » [ATTRIBUTES]>
            <states>
                <onevent> 
                    <rule ref="menu_button_selection"/>     -------> Référencement d’une règle à partir de l’étendue
                du workflow </onevent> 
            </states>
        </step>
    </steps>
</workflow>

Dans cet exemple :

  • Une règle avec id="menu_button_selection" est définie dans l’étendue du workflow, puis référencée à la fois dans l’étape id="stepA" et l’étapeid="stepB"  à l’aide de l’attribut. ref 

Remarque : La réutilisation des règles et des actions permet de rendre le comportement de votre composant cohérent, d’améliorer la maintenabilité et de réduire la quantité de code.

  • Les identifiants à l’intérieur d’une étendue doivent être uniques. Vous pouvez utiliser des ID identiques dans d’autres étendues, mais à moins que vous n’ayez une très bonne raison, nous vous recommandons de ne pas le faire, afin d’éviter toute confusion. Si vous utilisez des ID identiques, l’ordre de priorité est ascendant : si une règle avec id="menu_button_selection" est directement définie dans la portée de l’étape, elle sera exécutée à la place des règles prédéfinies avec le même ID dans la portée du workflow.
  • Vous pouvez également avoir des règles/actions qui ne sont nécessaires que dans l’une de vos étapes, mais qui sont nécessaires dans plusieurs états/règles de cette étape particulière. Dans ce cas, vous pouvez définir la règle/l’action dans la portée de l’étape et la référencer de la même manière.
  • Enfin, vous pouvez également définir des règles et des actions directement là où elles sont nécessaires. Une telle règle/action ne sera disponible nulle part ailleurs. Si vous savez que votre règle/action ne sera pas réutilisée, une définition directe peut rendre le composant plus lisible puisque vous n’avez pas besoin de vous déplacer pour voir l’implémentation.

Remarque : Les ID doivent être uniques au sein d’une étendue. Si vous copiez et collez une règle ou une action existante en tant que modèle lors de la création d’une nouvelle règle, une erreur typique est d’oublier de modifier l’attribut ID. Prenez l’habitude de changer d’abord l’identifiant.

📌Mission

Refactoriser notre composant de choix :

  • Placez l’action finish_workflow dans la portée globale et référencez-la dans la règle
  • Placez la menu_button_selection règle dans la portée globale et référencez-la dans l’étape
  • Assurez-vous que le composant fonctionne toujours comme prévu

Télécharger le composant (pré-affectation)

Aide et ressources

Voici quelques conseils pour faciliter le développement de workflows et de composants :

Mode de prévisualisation

Ce mode vous permet de tester immédiatement vos modifications sans avoir à publier le workflow. Pour plus d’informations, consultez la section Aperçu du flux de travail.

Journaux du serveur et du client

Vous pouvez accéder aux journaux FCC et de l’appareil en vous connectant avec l’utilisateur sysadmin ou en accédant directement à votre dossier UBIMAX_HOME\logs. Les journaux de l’appareil sont envoyés régulièrement au serveur, mais vous pouvez demander un téléchargement immédiat en tant qu’administrateur système.

Solution Notes

Si vous n’aviez pas encore tout mis en place pour le développement, cela aurait dû être la tâche principale de cette première mission pratique.

Il peut être intéressant de noter que dans la définition de la règle, vous faites désormais référence à une action prédéfinie définie dans la même étendue. L’ordre des balises et <rules> n’a pas d’importance <actions>pour que cela fonctionne. Voici à quoi devrait ressembler votre composant :

< ?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">
   
    <actions>
        <finish_workflow id="finish_workflow"> 
            <output>
                <param name="selected_button » type="string">#{event :command}</param>
            </output>
        </finish_workflow>
    </actions>
   

    <rules>
        <rule id="menu_button_selection">
            <expression>#{event : commande} == 'POMME' || #{event :command} == 'PEAR'</expression>
            <actions>
                <action ref="finish_workflow"/>
            </actions>
        </rule>  
    </rules><

 

    steps>
        <step id="choose » descriptor="l’utilisateur choisit entre deux options » uitemplate="ChoiceScreen">
            <states>
                <onevent>
                    <rule ref="menu_button_selection"/>
                </onevent>
            </states>
        </step>
    </steps>

</workflow>

Télécharger le composant (post-affectation)

Avec cela, vous avez terminé la deuxième leçon. La prochaine leçon portera sur les variables de données.