知識ベース

サポート概要に戻る

コンポーネントは XML で記述されており、そのルール (if A then B ステートメント) を書き留めることで、目的の動作を実装できます。

たとえば、要件は、マシンの検査中にユーザーが「カメラ」ボタンを押すと、デバイスの内部カメラが起動することです。

同じルールは、実装に少し近いものを次のように表現できます。

「inspect_machine」に step いて、「カメラ」でcommand  発生した  event場合は、「start_camera」を実行します。 action 

コンポーネントの構造フレーム

コンポーネントの一般的な構造フレームは次のとおりです。

<workflow [ATTRIBUTES]>
    <context> [...] </context> // データ変数、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>

例を挙げる前に、XML タグの概要を以下に示します。

  • <context>: 操作する変数 (データ) を定義します
  • <rules>: 一連のアクションが実行される条件を定義します。1 つの式ともう 1 つのアクションで構成されます
  • <actions>:ワークフローで使用する事前定義されたアクション(例:デバイスカメラの起動)。
  • <ステップ>: 画面のデータ (コンテキスト) とロジック (ルールとアクション) を含み、ユーザー インターフェイス テンプレートにリンクされているデバイス上の画面
  • <states>: ルールがチェックされるタイミングを決定します (例: イベントが発生したとき、ステップの開始時または終了時)
  • <mapping>: データ (コンテキスト変数) をユーザー インターフェイス (別のファイルで定義) にマップします。

コンポーネントの例

コンポーネントの構造をよりよく理解するために、 Image Choice コンポーネントの例を使用します。

ユーザーは「Apple」と「Pear」の2つのオプションから選択します。このトレーニングにも同じコンポーネントが使用され、今後改善されます。

コンポーネントのダウンロード

以下の UI は、このコンポーネントが Frontline Workplace スマート グラス アプリケーションでの実行中にどのように表示されるかを示しています。

ワークフローは次のとおりです。

<?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="ユーザーが 2 つのオプションから選択" 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. ワークフロータグに属性 startstep="choose" が含まれている。これは、コンポーネントの初期化後に最初に実行する手順を選択するために使用されます。

2. <step id="choose"... は、を使用してさらに表示される uitemplate="ChoiceScreen"選択肢を参照するために使用されます。ChoiceScreenは、このステップ中に画面に表示される内容を定義するファイルです。

説明したように、コンポーネントの動作はルールを使用して定義されます。ルールは、式 (または条件) と、その条件が True の場合に実行するアクションで構成されます。各ルールは、<onenter><onresume><onleave> <onevent> <onpause>ルールは、コンポーネントがその状態にある場合にのみチェックされます (たとえば、onenter - コンポーネントが最初に起動されたとき)。

3. が<rule id="menu_button_selection">状態に割り当てられます<onevent>。イベントが発生するたびに、この状態に与えられたすべてのルールがチェックされます。ここでは、<expression>#{event:command} == 'APPLE' || #{event:command} == 'PEAR'</expression>イベントに特定のコマンドが含まれているかどうかをチェックします。このようなイベントは、"APPLE" または "PEAR" という名前のボタンが音声コマンドまたは画面上で押すことによってトリガーされたときにアクティブになります。

4. ルール式が true と評価された場合、ルールの<actions>タグ内の一連のアクションが実行されます。この例では、アクションがfinish_workflow使用されています。これにより、ユーザーが 2 つのオプションのいずれかを選択すると、すぐにコンポーネントが終了し、どちらの選択がパラメーターで行われた<output>かが渡され、その選択に基づいてワークフロー図にさまざまな遷移を作成できます。

📌割り当て

choice コンポーネントを拡張して、 ユーザーの選択を含むメッセージを Frontline Connector に送り返すとします (Frontline Connector は、この情報をバックエンド システムに伝達できます)。次の質問について考えてみましょう。

  • コンポーネントにはどのステップがありますか?
  • 「」を見てください。 どのアクションが必要でしょうか?

ヘルプとリソース

アクション は、私たちが使用できる基本的な構成要素です。これらは、ユーザーに表示される内容 (色、テキスト、通知,...) の変更から、データの管理と Frontline コネクタまたは外部デバイスとの通信によるプログラムの流れの制御 (次の手順への移行) まで多岐にわたります。

ソリューションノート

まず第一に、Frontline Connector との通信は別の機能であり、独自のコンポーネントを持つ必要があると主張するかもしれません。おっしゃる通り、通信の側面を独自のコンポーネントに分離することで、両方のコンポーネントの再利用性が高まります。一方、複数の機能を 1 つのコンポーネントにまとめることで、顧客の Frontline Creator インターフェイスに表示されるプロセス フローを簡略化したい場合があります。ここでは、両方の機能を 1 つのコンポーネントに組み合わせると仮定します。

コンポーネントにはどのようなステップがありますか?

以前は、ステップは画面と同等であると説明されていました。では、追加機能がバックエンド通信だけなのに、なぜ複数のステップが必要なのでしょうか。

その答えは、保守性と再利用性です。保守性:通信の側面に変更を加える場合、そのステップを見るだけでよく、他のコードを読む必要がないためです。再利用性:コンポーネントがさらに複雑になった場合に、同じ手順を使用して異なるメッセージを送信することもできます。

同様に、これら 2 つの機能の 2 つのコンポーネントを別々に作成することをお勧めします。ステップを 1 つのコンポーネントに結合する場合は、少なくとも個別のステップを作成することをお勧めします。画面を同じにするか、コネクタから進行状況通知の確認を追加するだけです。そのため、ここでは「選択」と「message_connector」の2つのステップを用意することをお勧めします。

おそらく必要なアクションはどれですか?

この質問の主な目的は、「アクション」カタログに慣れてもらうことです。実装プロセスで使用できるアクションの例を次に示します。

  • send_commit_message: Frontline コネクタと通信します
  • ui_progress_notification:現在バックエンドと通信していることをユーザーに通知します(確認を待つ場合)
  • setvar: 後でコンポーネントのコネクタと出力パラメータの両方に返すことができる入力を保存するために使用されます

これで、最初のレッスンは終了です。次のレッスンはスコープについてで、最初の実践的な課題を網羅します。