# NEAL ラNEAL（Nexthink Experience Automation Language）は、ワークフロー構造と動作を定義するためのスクリプト言語です。 デザイナー画面の外での高度なデバッグや修正を可能にしますが、標準的なワークフローの作成や管理には使用を避けるべきです。 ワークフロービジュアルデザイナーは、すべてのアクションを自動的にNEALに変換し、完全な同期を保証します。 しかし、NEAL でワークフローを直接編集すると、複雑さや潜在的な不整合を招く可能性があります。 したがって、Nexthinkはビジュアルデザイナーが不十分な場合に限り、例外的なケースでのみNEALを使用することを推奨しています。 ## 構造 NEALはXMLを主な構文として使用し、ワークフロー内のステップを一貫して読みやすいタグで定義できます。 各NEAL定義のワークフローには、以下の最小構造が必要です。 1. ID 2. 開始 3. Thinklet 4. パス 5. 終了 ### NEALの例 これは、プリント スプーラーを再起動する 1 つのリモート アクション Thinklet を含むシンプルなNEALワークフローです。 

    私のワークフローの説明
<startEvent id="StartWorkflowID" name="Start workflow" /><thinklet type="act" id="RestartPrintSpooler" name="Restart Print Spooler" description="This will restart the print spooler service on the target device" timeout="900">    <remoteActionId>#service_controller</remoteActionId>    <parameter name="ServiceCommand" value="Restart"/>    <parameter name="ServiceName" value="Spooler"/></thinklet><endEvent id="EndStateID" name="End State"/><path id="step1" name="Step 1" sourceRef="StartWorkflowID" targetRef="RestartPrintSpooler" /><path id="step2" name="Step 2" sourceRef="RestartPrintSpooler" targetRef="EndStateID" />
`` タグはNEALスクリプトを開始、カプセル化、終了しますが、タグの順序は関係ありません。 ただし、ワークフローがタグを処理する順序は、``タグの属性（例えば`id="step1"`および`id="step2"`など）で定義されます。 ### ID すべてのワークフローには、Nexthinkがワークフローを参照できるようにするための基本的な詳細が必要です。他のNexthinkユーザーがそれを識別できるようにします。 * `id`：Nexthinkがワークフローを識別し参照するためのユニークな識別子です。 * `name`: ワークフロー管理ページのバージョン タブに表示されるワークフローの名前。 * `description`: 他のNexthinkユーザーにこのワークフローバージョンを説明するのに役立つワークフローの詳しい説明です。 このバージョンが作成された理由と、以前のバージョンに対してどのように改善されたかを説明することが良い実践です。 

	私の長いワークフローの説明は、これが何であるか、どのような役割を持つかを仲間が理解するのを助けます
## Thinklet Thinkletはワークフロー内の主要アクション コンポーネントであり、そのタイプに応じてさまざまな設定オプションがあります。 すべてのシンクレットは種類に関係なく、設定する必要のある以下のパラメータがあります。 * `type`: この構成が対象とするThinkletのタイプ。 * `id`: Nexthinkがワークフロー内でThinkletを識別するために使用する識別子。 * `name`: Thinklet のフレンドリーネーム。 システムはこの名称を使用してThinkletを視覚的に表示し、ワークフローの実行中にその現在のステータスを表します。 * `description`: このThinkletが意図する動作のより詳細な説明。 システムはこれを考慮してThinkletを視覚的に表示します。 * `timeout`: スィンクレットによって実行されるアクションからの応答を待つ時間（秒単位）を定義します。 ### リモートアクション リモートアクションThinkletは、エンドポイントデバイスでリモートアクションの実行を要求します。 以下の設定パラメーターを持っています。 * `remoteActionId`: thinkletで使用するリモートアクションのNQL ID。 * `parameter`：リモートアクションに送信されるパラメータを説明するタグ。 複数のパラメータを定義できます。 * `name`：リモートアクションから参照されるパラメータの名前。 * `value`：リモートアクションパラメータに挿入される値。 ここに入力された静的な値に対してこの構文が使用されます。 * `source`：グローバルまたは出力変数を参照するためにソースを使用します。 {% hint style="info" %} 各パラメータには、**value**または**source**のいずれかを使用しなければなりません。同じ行で一緒には使用できません。 {% endhint %} 以下はリモート アクション Thinklet の例です。 

    #service_controller
    f0b002cf-3723-43ae-a2a2-84baf4881952
### キャンペーン キャンペーン Thinklet は、エンドポイントデバイスのユーザーにキャンペーンを送信することを要求します。 次の構成パラメータがあります。 `CampaignId`: シンクレットが使用するキャンペーンのNQL IDです。 ```xml #reboot_request ``` ### サービス/API サービス/API Thinkletは、外部の公開APIにREST呼び出しを行います。 追加情報を取得したり、アクションの実行を要求するために使用します。 ```xml conn_cr-5 POST api/now/table/incident $.result.sys_id { "assignment_group": "Application Development", "business_service": "Zoom", "caller_id": "Terry Courtney", "description": "Hello Nexthink Flow", "impact": "5", "short_description": "Incident created by Nexthink Flow for {{nx.user.name}}", "urgency": 4, "cmdb_ci": "{{nx.device.name}}" } ``` * `credentialsId`：接続に使用するコネクター資格情報のID。 認証ページのURLから取得します。 * `httpMethod`：外部システムに連絡するために使用する方法。サポートされている方法には次のものがあります。 * GET * POST * PATCH * PUT * DELETE * `outputVariables`：呼び出しから取得する必要のある期待される値のID、名前、およびパスを定義します。 システムは最大5つの出力をサポートしています。 * `resourcePath`：呼び出しを行うときに接続するエンドポイント。 * `payloadTemplate`：外部システムに送信されるJSONペイロード。 {% hint style="info" %} NEALでのペイロード用には、引用符の代わりにHTMLエンティティの`"`を使用する必要があります。 {% endhint %} ### ワークフローパラメーター ワークフローパラメーターは、ワークフロー設計の一部として設定された値、Nexthinkユーザーからの入力要求、またはNexthink APIへの要求から取得された値です。 これらの値はワークフロー実行の寿命中は変わらず、作成しているワークフロー実行の最初から参照できます。 {% hint style="info" %} [ワークフローパラメータ](/platform/ja/user-guide/workflows/creating-workflows/parameters-and-dynamic-values.md#reference-to-workflow-parameter)のXMLタグは、歴史的な言語実装によりNEALで``として参照されます。 {% endhint %} ワークフローで必要とされる各ワークフローパラメーターに対して、``タグを使用して設定します。 各グローバル変数に対し、以下の属性を定義します： * `name`：Nexthinkがワークフローパラメーターを参照するために使用するユニークな識別子。 ワークフローの他の領域からの値を参照する際に名前を使用します。 ワークフローを実行する際にも表示されます。 * `type`：ワークフローパラメーターが使用するデータタイプ。 現在サポートされているデータタイプは\_string\_のみです。 後のバージョンではさらに多くのデータタイプのサポートが追加される可能性があります。 * `customValue`：自動化が手動でトリガーされた際にNexthinkユーザーが値を設定できるかどうかを定義します。 各タグ内にワークフローパラメーターを定義できます。 1つのみ定義すると、システムはこの値のみを使用します。 これらの値は``タグ内に配置する必要があります。 以下にワークフローパラメーターを宣言する方法の例を示します。 

    Spooler

月曜日
火曜日
水曜日
木曜日
金曜日
Thinkletは次の構文を使用してワークフローパラメーターを参照できます。 `source="global.valueName"` 以下は、前の例で示された`DayoftheWeek`のワークフローパラメーターがリモートアクションthinkletで参照されている例です。 

  #get_date
### Thinklet 出力 次の構文を使用して、Thinklet の出力値を参照します: `source="thinkletId.result.outputs.outputName"` たとえば、`ServiceName`という出力値を返すリモート アクションThinkletを、さらにリモート アクションの入力として使用したい場合は、次のようにしてサービスを開始するThinkletを参照します。 

    #start_service
### データベースの値 `device` および `user` オブジェクトの静的フィールドにアクセスするための構文は次のとおりです： * デバイス `source="nx.device.field_name"` * ユーザー `source="nx.user.field_name"` `device`または`user`のようなデータベースオブジェクトへの参照は常に`nx`で始まります。 以下は条件内でデバイス属性を使用した例です： ```xml ``` ## フロー制御 ### 開始ブロック すべてのワークフローには開始点が必要です。 通常、タグはそのままにしておくことができます。 これは主に、パスウェイの最初のthinkletをリンクするために使用されます。 開始タグは1つだけである必要があります。
### 終了ブロック ワークフローには開始点が必要なように、終了も必要です。 ワークフローのすべてのパスウェイは最終的に終了ブロックに到達する必要があります。 少なくとも1つのパスが終了ブロックに到達しない場合、それは無効と見なされ、システムは実行しません。 スタートブロックとは対照的に、ワークフローがエンドステートとみなされるポイントが複数存在することがあります。 エンドブロックは、ワークフローの結果を定義することができる場所でもあります。 システムがワークフローロジックを実行しエンドブロックに到達すると、結果とその詳細が保存され、NQLを使用してクエリすることができます。 エンドブロックには次の属性が必要です。 * `id`: システムがエンドブロックを識別し、参照するための一意の識別子。 * `name`: エンドブロックの説明的な名前。 * `description`: このエンドブロックが何を表すかを長く説明する、通常は期待される結果。 * `outcome`: エンドブロックに到達したときに何が起こるかを説明する必須の結果定義。 可能な値は次のとおりです。 * ACTION\_TAKEN * NO\_ACTION\_TAKEN * FAILED * OTHER * `outcomeDetails`: ワークフローがエンドブロックに到達したときに何が起こるかの説明。 このフィールドの文字制限は64文字です。 Nexthinkは、この説明をダッシュボードで情報が使用される可能性があることを考慮して簡潔に保つことを推奨しています。 
  
    ACTION_TAKEN
    ドライバーが削除されました
### パス パスは、ワークフローが各ステップがどのように次に繋がっているかを知るための方法です。 パスを設定するには、次の属性が必要です。 * `id`: システムがパスを識別し、参照するための一意の識別子。 * `name`: Nexthinkのユーザーインターフェースに表示されるパスの説明的な名前。 * `sourceRef`: このパスが始まるタグのID。 * `targetRef`: このパスが進むタグのID。 以下は、開始タグからリモートアクションthinkletに至るまでのパスの一例です：
### 条件 条件を使用して、ワークフローのどのパスが処理されるかを値に対して行われたチェックによって制御します。 これらの値は変数を通じて収集されます。 条件は排他的であり、システムは条件からの1つの経路しか使用しません。 条件は``タグで囲まれています。 各排他的条件タグでは次のものが必要です。 * `id`: システムが排他的条件を参照するための一意の識別子。 * `name`: Nexthinkのwebインターフェースに表示される説明的な名前。 * `description`: この条件が何のためにあるのか、他のNexthinkユーザーが判断するのに役立つ詳細な説明。 各排他的条件タグ内では、条件自体が次のように定義され、以下のものを必要とします。 * `id`: システムが条件を参照するための一意の識別子。 この属性の一意性は、含まれている排他的条件だけでなく、ワークフロー全体に適用されることに注意してください。 * `name`: Nexthinkのwebインターフェースに表示される条件の説明的な名前。 これは、条件によってテストされる値の複雑さを隠すために使用できます。 * `input`: この条件がテストされる対象であるグローバル又は出力変数。 * `operator`: 変数の値に対して実行されるテストのタイプ。 可能な演算子は次のとおりです。 * Is `"eq"` * Is not `"neq"` * Less than `"lt"` * Greater than `"gt"` * Less than or equal to `"lte"` * Greater than or equal to `"get"` * Contains `"contains"` * Does not contain `"notcontains"` * Is empty `"isempty"` * Is not empty `"isnotempty"` * `value`: 条件が真である場合の変数の期待値。 * `targetRef`: この条件が真である場合にジャンプするワークフロー内のステップのID。 以下の例は、インストールされたソフトウェアアプリケーションの存在を確認するリモートアクションの結果を示しています。 アプリケーションがインストールされている場合、ワークフローは終了します。 アプリケーションが存在しない場合、ワークフローはアプリケーションをインストールするためにリモートアクションthinkletを実行します。 
    
        #check_product_presence

\<exclusiveCondition id="ProductInstalled" name="Is Product Installed?" description="This condition checks the output of the remote action looking for a specific product install to see if it was found or not" >    \<condition id = "ProductInstalled\_Yes" name="Yes" input="CheckProduct.result.outputs.InstallState" operator="eq" value="true" targetRef="endState" />    \<condition id = "ProductInstalled\_No" name="No" input="CheckProduct.result.outputs.InstallState" operator="eq" value="false" targetRef="InstallApplication" />\</exclusiveCondition>
 
\#general\_application\_install

\<endEvent id="endState" name="End"/>\<path id="step2" name="Step 2" sourceRef="CheckProduct" targetRef="ProductInstalled" />
### 待機 待機フローコントロールを使用すると、一定時間経過するまで、または外部システムからのAPI呼び出しを待つことができます。 これは、システムが制御できない外部の何かを待つ必要がある場合に役立ちます。 待機は2種類あり、`type`パラメータを使用して次の値を設定できます。 * delay * api #### タイムデ――レー タイムデ――レーのパラメータは以下の通りです。 * `id`: システムが待機フローコントロールを参照するための一意の識別子。 * `name`: Nexthinkのwebインターフェースに表示される説明的な名前。 * `description`: これは、他のNexthinkユーザーがこの待機フローコントロールが何のためにあるのかを判断するのに役立つ詳細な説明です。 * `value`: この段階に到達したときに一時停止する時間の単位数。 * `unit`: デ――レーの時間単位は以下の通りです。 * minutes * hours ```xml ``` #### APIリスナー APIリスナーは以下のパラメーターを持ちます： * `id`: システムが待機フローコントロールを参照するための一意の識別子。 * `name`: Nexthinkのwebインターフェースに表示される説明的な名前。 * `description`: これは、他のNexthinkユーザーがこの待機フローコントロールが何のためにあるのかを判断するのに役立つ詳細な説明です。 * `timeout`: タイムアウトを分単位で設定します。 これは、要求されるAPI呼び出しを待つ時間を決定します。 タイムアウト制限に達すると、ワークフローは失敗状態に入り、処理を停止します。 出力は``要素内で定義され、最大5つの出力を定義できます。 各出力は``で囲まれています。 各出力の中には以下のパラメーターがあります： * `name`: Nexthink webインターフェースに表示されるパラメーターを説明する名前。 * `id`: 出力のunique identifier。 このIDは、このAPIリスナーのAPI呼び出しでパラメーターを特定するために使用されます。 ```xml ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.nexthink.com/platform/ja/user-guide/workflows/creating-workflows/neal.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.