Après toutes les leçons précédentes, vous devriez maintenant être en mesure d’implémenter la plupart des composants. Cependant, il existe toujours un élément de flux de travail que nous n’avons pas abordé : les gestionnaires.

Les gestionnaires encapsulent des modules logiques plus complexes (par rapport aux actions). Ils s’exécutent en arrière-plan pendant l’exécution du workflow et écoutent certains événements qu’ils traitent ensuite, émettant leurs propres événements. Il ne peut y avoir qu’un seul gestionnaire de chaque type dans une étape. Les gestionnaires n’ont pas d’identifiants.

Il n’y a qu’un petit nombre de gestionnaires. Dans cette leçon, nous allons aborder un gestionnaire qui est utilisé assez souvent - le value_extractor_handler.

Lecture des codes-barres

Le value_extractor_handler valide l’entrée et extrait les informations pertinentes de l’entrée. Il est principalement utilisé pour la lecture de codes-barres et parfois pour les commandes vocales. Vous devrez fournir une expression régulière (regex) qui régule le type d’entrée valide et définit également les parties de l’entrée que vous souhaitez stocker dans les variables.

L’exemple suivant montre à quoi pourrait ressembler la définition de votre gestionnaire.

Exemple

<étape ... >
    <handlers>
        <value_extractor_handler pattern="( ?:( ?:ADD|PLUS\s)( ?:((\d{1,2})\sTIMES\s(\d{1,2}))|( \d{1,3})))|(\d{8,12})|(S([1-7])R([1-4]))|(B#[A-F0-9]{12})|(QUITTER) « >
            <grp>
                <param name="grp_1 » type="string">add_mutiplication</param>
                <param name="grp_2 » type="string">add_factor_1</param>
                <param name="grp_3 » type="string">add_factor_2</param>
                <param name="grp_4 » type="string">add</param>
                < param name="grp_5 » type="string">serialno</param>
                <param name="grp_6 » type="string">location</param>
                <param name="grp_7 » type="string">shelve</param>
                <param name="grp_8 » type="string">rack</param>
                <param name="grp_9 » type="string"> code</param>
                <param name="grp_10 » type="string">exit</param>
            </grp>
        </value_extractor_handler>
    </handlers>
</step>

Si vous êtes familier avec les expressions régulières, il n’y a rien de nouveau ici. Chaque groupe que vous créez à l’aide () de celui-ci est capturé dans une variable d’étape. Vous pouvez ignorer les groupes que vous devez créer pour exprimer « ou » à l’aide de ?:. Décomposons l’expression régulière :

( ?:( ?:AJOUTER|PLUS\s)( ?:(           grp_1 : par exemple #{add_multiplication} == « 10 fois 5"
        (\d{1,2})\sTIMES\s      grp_2 : par exemple #{add_factor_1} == « 10"
        (\d{1,2}))|             grp_3 : par exemple #{add_factor_2} == « 5"
    (\d{1,3})))|                grp_4 : par exemple #{add} == « 255"
(\d{8,12})|                     grp_5 : par exemple #{serialno} == « 123456789"
(S                              grp_6 : par exemple #{location} == « S5R2"
    ([1-7])R                    grp_7 : par exemple #{shelve} == « 5"
    ([1-4]))|                   grp_8 : par exemple #{rack} == « 2"
(B#[A-F0-9]{12})|               grp_9 : par exemple #{code} == « B#ABCDEF123456
(EXIT))                         grp10 : #{exit} == « EXIT »

Vous avez défini différents types de code qui peuvent être analysés à l’étape actuelle. Chaque fois qu’un type particulier de code est analysé, les variables des autres types ne sont pas définies. Par exemple, si vous scannez « PLUS 10 FOIS 5 », les variables des groupes 1 à 3 auront du contenu mais le reste ne sera pas défini. Par conséquent, vos règles doivent vérifier si la variable existe. Vous pouvez consulter la documentation du gestionnaire pour voir quels événements sont émis. Vous pouvez voir quelques exemples de règles pour le traitement ci-dessous :

<onevent>
    <rule id="location_scanned">
        <expression>< ![ CDATA[ #{event(value_extractor) :command} == 'VALID_EXTRACTION' && exists(#{shelve}) && exists(#{rack}) ]]></expression>
        <actions>
            <setvar id="set_loction">
                <context_of>workflow</context_of>
                <context_update>
                    <param name="shelve » type="long">#{shelve}</param>
                    <param name="rack » type="long">#{rack}</param>
                </context_update>
            </setvar>
        </actions>
    </rule>

    <rule id="invalid_input">
        <expression>< ![ CDATA[ #{event(value_extractor) :command} == 'INVALID_EXTRACTION' ]]></expression>    
        <actions>
            <ui_notification id="invalid_codeer » type="ERROR » duration="SHORT » show_immediately="true">
               <message>"#{event :payload.code} » n’est pas valide !</message>
            </ui_notification>
        </actions>
    </rule>
</onevent>

📌Mission

Si vous disposez d’un lecteur de codes-barres externe, cela vaut la peine de l’essayervalue_extractor_handler.

  • Permettez à l’utilisateur de scanner les codes-barres pour faire son choix.
  • Ajoutez un nouveau champ de saisie de configuration à chaque option pour la valeur attendue du code-barres (par exemple, le travailleur pourrait scanner un code-barres sur une boîte de pommes contenant le code produit 123456).
  • Effectuez des analyses de test.

 Workflow de téléchargement (pré-affectation)

Solution

 Workflow de téléchargement (post-affectation)