ここまでのレッスンをすべて終えると、ほとんどのコンポーネントを実装できるようになります。ただし、まだ説明していないワークフロー要素であるハンドラーがあります。

ハンドラーは 、(アクションと比較して) より複雑な論理モジュールをカプセル化します。ワークフローの実行中にバックグラウンドで実行され、特定のイベントをリッスンして処理し、独自のイベントを発行します。1 つのステップには、各タイプのハンドラーが 1 つしか存在できません。ハンドラーには ID がありません。

ハンドラーの数は少ないです。このレッスンでは、非常に頻繁に使用される 1 つのハンドラー ( value_extractor_handler.

バーコードの読み取り

は value_extractor_handler 入力を検証し、入力から関連情報を抽出します。主にバーコードスキャンに使用され、場合によっては音声コマンドに使用されます。どのタイプの入力が有効かを制御し、入力のどの部分を変数に格納するかを定義する正規表現 (regex) を指定する必要があります。

次の例は、ハンドラー定義がどのようになるかを示しています。

<ステップ...>
    <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})|(終了))">
            <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です>

正規表現に慣れている方なら、ここで新しいことは何もありません。を使用して () 作成した各グループは、ステップ変数にキャプチャされます。「or」を表すために作成する必要があるグループは、 を使用して ?:無視できます。正規表現を分解してみましょう。

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

現在のステップでスキャンできるさまざまなコードタイプを定義しておきます。特定のタイプのコードがスキャンされるたびに、他のタイプの変数は未定義になります。たとえば、「PLUS 10 TIMES 5」をスキャンすると、グループ1〜3の変数にはコンテンツが含まれますが、残りは未定義になります。したがって、ルールでは、変数が存在するかどうかを確認する必要があります。ハンドラーの ドキュメント で、どのイベントが発行されるかを確認できます。以下に、処理のルール例をいくつか示します。

<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}" is not valid!</message>
            </ui_notification>
        </actions></rule><
/onevent>
    

📌割り当て

外部バーコードスキャナーを利用できる場合は、時間をかけて試してみvalue_extractor_handlerる価値があります。

  • ユーザーがバーコードをスキャンして選択できるようにします。
  • 予想されるバーコード値の各オプションに新しいコンフィギュレーション入力フィールドを追加します (たとえば、作業者は製品コード 123456 を含むリンゴの箱のバーコードをスキャンできます)。
  • いくつかのテストスキャンを実行します。

 ワークフローのダウンロード(事前割り当て)

解決

 ダウンロードワークフロー(課題後)