WXPにおけるワークフローの自動化

Prev Next

はじめに

HP Workforce Experience Platform(WXP)のワークフロー機能は、大規模なITリメディエーション向けに設計されたローコードワークフローオーケストレーション機能です。これにより、IT管理者は数千のエンドポイントに自動化されたワークフローを展開し、視覚的なドラッグ&ドロップインターフェースで、チームが受動的なチケット処理からプロアクティブな対応へと移行するのを支援します。

依存関係と前提条件

スクリプトおよびウェブフックのテスト要件

スクリプトはワークフローで使用する前にテストすることができます。スクリプトの出力は以下の用途に使われます:

  • 分岐論理

  • Webhookペイロード/クエリパラメータ

Webhookはワークフローで使用する前にテストが必要です。現在、webhookはJSON入力とプレーンテキストまたはJSON出力をサポートしています。

プラットフォームおよびバージョン要件

ワークフローを作成する前に、以下の要件が満たされていることを確認してください:

対応OS

Windowsサポートはアラート(イベントトリガー)、スクリプト、ドライバー更新ノードのみです

ウェブフックはデバイスOSに依存しません

グループ(スケジュールトリガー)はLinux、Mac、Windows OSをサポートしています

最小エージェントバージョン

WXP Insightsエージェント: 5.26.49以降

WXP Insights Analyticsエージェント: 4.2.2584以降

ワークフローの作成

ステップ1:トリガーの追加

すべてのワークフローはトリガーから始まらなければなりません:

  1. WXPにログインしてください。 ホームページ が表示されます。

  2. WXPの左側メニューから「 Labs 」をクリックします。 Labs ページが表示されます。

  3. Labsページでワークフローセクションにスクロールし、「Try Workflow」をクリックします。終了したワークフローが表示されます。

  4. 新しいワークフローを作成するには 「追加」 をクリックします。 「ワークフローを追加」 ダイアログボックスが表示されます。  

  5. ワークフローの追加ダイアログボックスでは、新しいワークフローを一から作成するか、既存のワークフローを複製・修正することができます。

  6. ゼロから作成する場合は、次のイベントをトリガーします:

    1. イベントトリガー(アラートベース): アラートが発生した際にワークフローが開始されます。利用可能なアラートオプションには、プラットフォーム上で作成または提供されている既存のアラートが含まれます。

    2. スケジュールトリガー: 管理者はワークフローの日付、時刻、ターゲットグループを定義できます。 表示されるグループオプションはWXPプラットフォームで作成されたグループに基づいています。

ステップ2:アクションの追加

トリガーを追加した後、ワークフローが何をすべきかを定義するために1つ以上のアクションを追加できます。

  • スクリプト:  表示されるスクリプトオプションは、WXPで作成されたかWXPが提供する既存のスクリプトです。

  • Webhook: ServiceNow、Teams、Slackなどのサードパーティシステムと連携します。Webhookは手動またはSwagger APIのエンドポイントURLを通じて設定してください。Webhookはワークフローで使用する前にテストが必要です。

  • デバイスアクション: デバイスアクションはドライバーの更新を行うために使用できます。例えば:

    • すべてのドライバーアップデートの展開

    • 重要なドライバーアップデートのみを展開します

    • 選ばれたドライバーカテゴリの全ドライバーまたは重要なドライバーアップデートの展開

ステップ3:分岐ロジックの追加

if/then/else条件を使って高度な論理パスを作成します。分岐はスクリプト、ウェブフック、ドライバ更新の出力に基づいて行うことができます。

現在の制限

  • ネスト分岐はサポートされていません

    • 別の枝の前後に配置された枝は、別々のもの(入れ子ではない)として扱われます。

  • 分岐の後にアクションを追加することはできません

  • ワークフローキャンバス上のノードを削除すると、その下の依存ノードも削除されます。

スケジュールトリガーのタイムゾーン挙動

この動作はスケジュールトリガーにのみ適用されます。ワークフローを作成する際、スケジュールされた時間は作成者のタイムゾーンに設定されます。しかし、実行は各ターゲットデバイスの現地タイムゾーンで行われます。例えば、9:00 AM PSTにワークフローをスケジューリングした場合、ESTのデバイスは12:00 PM ESTにワークフローを実行します。これにより、各受信者がどこにいても、ワークフローが意図された現地時間に実行されることが保証されます。

イベントトリガーのアラートとアクティビティビヘイビア

フリート対デバイスアラート

アラートによってトリガーされたワークフローの実行は、WXPの アクティビティ タブに反映されます。アラートの種類に基づくアクティビティの挙動:

  • フリートレベルアラート:フリート全体でアラートが発動した際に実行が表示されます。

  • デバイスレベルアラート:実行は各デバイスごとに個別に追跡されます

  • 注:

    • 公開前にすでにアラートが有効であれば、それらのデバイスはワークフロー対象の対象となります。

    • アラートルールの変更、つまり「トリガー条件」セクションが更新されると、新しい実行がトリガーされます。

聴衆の編集

  • 編集は、日付ベースのトリガーを使用するスケジュールベースのワークフローのみでサポートされています。

  • イベントベースのワークフローは公開後の編集対象はサポートされていません。

編集ルール

ワークフローの状態に基づいて、以下のルールが適用されます:

1. ワークフローがアクティブ(繰り返し、開始時間経過)
  • オーディエンス:この段階では、オーディエンスは編集可能です。

  • グループ:

    • グループの追加:グループが追加された場合、それらは現在の実行(完了していなければ)および将来の実行に含まれます。この操作は「アクティビティ」タブで確認でき、グループを作成したユーザーとグループ作成のタイムスタンプが表示されます。

    • グループの削除: グループが削除された場合、現在の実行および将来の実行の残りのデバイスからは削除されます。実行が完了したデバイスからは削除されません。この操作は アクティビティ タブでも確認できます。

2. ワークフローがアクティブ(開始時刻が経過していない)

オーディエンスは引き続き編集可能です。変更は今後のランに適用されます。すべてのアクションはユーザー情報と更新タイムスタンプとともに記録されます。

3. ワークフローがアクティブ(一度きり、開始時間経過)

オーディエンスはロックされ、ワークフローは最終決定されます。

ワークフローのステータス表示

WXPのワークフローリストページからステータスを確認できます。

以下のステータスがサポートされています。

現状

概要

編集可能性

ドラフト

未発表

完全に編集可能

現役

公開・実施または予定

編集はできません。ただし、日付ベースのワークフローではオーディエンスのみが編集可能です

キャンセル

手動で停止しました

編集不可

完了

処刑完了

編集不可

ワークフローKPIのレビュー

ワークフローが公開された後、ワークフローリストのページeでワークフロー名をクリックし、ワークフロー詳細ページのアクティビティタブに移動することでそのKPIにアクセスできます。KPIは実行タブの中に表示されています。

現状

スケジュールベース

イベントベース

進行中

少なくとも1台のデバイスで開始し、24時間のタイムアウトはしていません。

アラートはまだ解決されておらず、解決するまで有効です

完了

終わったか、期限切れか

警報は解決されました

執行状況の確認

ワークフローが公開された後、ワークフローリストのページでワークフロー名をクリックし、アクティビティタブに移動することで実行状況にアクセスできます。実行はテーブルに表示されます。

実行レベルステータス(実行ごとに)

  • 進行中: 上記と同じ基準

  • 完了: 完了または解決済み

  • キャンセル: 実行前にワークフローがキャンセルされました

デバイスレベルのKPIの見直し

デバイスレベルの状態(ワークフロー実行中)

デバイスレベルの状態は、個々のデバイスがワークフローのすべてのステップを正常に完了したか、または実行中に問題に直面したかを示します。これは、ワークフローリストのページにあるワークフロー名>アクティビティタブ>実行(デバイスレベルのアラートの場合は、デバイスは実行として扱われます)からアクセスできます。

ワークフローが公開された後、Workflowリストの「 アクティビティ タブ」>「 実行」>のワークフロー名をクリックすると、デバイスレベルのステータスにアクセスできます。デバイスレベルのアラートでは、各デバイスは別々の実行として扱われます。

注意: デバイスが任意のステップで致命的なエラーに遭遇した場合、ワークフローの次のステップに進みません。

ステータスタイプ

以下のステータスがデバイスレベルでサポートされています:

現状

概要

完了

デバイスはワークフローの最終段階に成功し、実行中に致命的なエラーが起こらなかった場合に「完了」とマークされます。

エラー

デバイスは最終ステップに到達しなかったり、致命的なエラーで実行が中断された場合にエラーとしてマーク されます。

進行中

実行が開始され、サーバーがまだ応答を受け取っておらず、24時間の実行ウィンドウが終了しておらず、致命的なエラーが発生していない場合、デバイスは進行中とマークされます。

未処理

デバイスが24時間のタイムアウトウィンドウ内に応答しない場合、または通信がないためワークフローステップが進めない場合、デバイスは未処理とマークされます。例えば、デバイスがオフラインまたは実行中に到達不能である場合があります。

中止

ワークフローがそのデバイスで実行開始前にキャンセルされた場合、そのデバイスはキャンセルされたとマーク されます。

注:

  • デバイスの実行結果は 「アクティビティ 」タブで確認できます。

  • 処刑は発生したときにのみ現れます

    • 定期的なワークフローは、今後の実行を事前に表示しません

  • デバイスレベルの洞察は以下の特定に役立ちます:

    • 故障点

    • オフラインデバイス

    • 実行のボトルネック

ワークフロービルダーのユースケース

1. アラートからServiceNowチケットを作成する

  • シナリオ: あなたの組織は、HP WXPで特定のアラートが発生した際に自動的にServiceNow(SNOW)インシデントを作成したいと考えています。

  • 解決策: 関連するアラートを選択してイベント ベースのトリガー(アラート )を使用してください。例:デバイスの健康状態、アプリのクラッシュ、パフォーマンスの問題などです。

    • アクション:Webhookアクションを追加し、WebhookをServiceNowエンドポイントと統合するように設定してください。Webhookペイロードにデバイスシリアル番号などの重要なデバイス詳細を含めることで、正確なチケット作成と追跡をサポートしましょう。これらのフィールドは、Variableリストを使って動的に入力できます。以下にアクセスできます:

      • デバイスレベルの属性などのグローバル変数です。

      • スクリプトの結果や過去のアクション出力などのステップ出力

これらの変数を使用することで一貫したフォーマットが確保され、より豊かでコンテキスト認識型の統合(例えばServiceNowチケット)が可能になります。

  • 結果:

    • アラートが発動すると、デバイスごとに自動的にServiceNowチケットが作成されます。

    • 手動介入なしの迅速なインシデント対応

注意: Webhookペイロードは事前にテストを行い、ServiceNowでのフィールドマッピングやチケット作成の検証を行ってください。

2. PowerPointクラッシュの自動修復+チケット作成

  • シナリオ: アラートはPowerPointクラッシュがフリートの一部に影響を及ぼしていることを示します。組織は影響を受けたデバイスを自動で修復し、故障時のみのチケットを作成したいと考えています。

  • 解決策: イベントベースのトリガー(アラート)を使いましょう。例えば、PowerPointのクラッシュがX%のデバイスに影響する場合です。

    1. アクション1:スクリプトアクションを実行して、影響を受けたデバイスを最新のMicrosoft Officeにアップデートします。

      1. 分岐ロジック(もし/それから):

        1. スクリプトの結果を評価する:

          1. 出口コード=0(スクリプト成功)の場合:

            1. エンドワークフロー(問題解決)

          2. その他(不合格):

            1. 次のステップへ進む

    2. アクション2: Webhook(ServiceNowチケット):

      1. デバイスがElse(いわゆる失敗条件)に該当する場合、WebhookをトリガーしてServiceNowチケットを作成します

        1. 以下が含まれます:

          1. デバイスの詳細

          2. スクリプト出力(トラブルシューティング用)

  • 結果:

    • デバイスは自動的に大規模に修復されます

    • 故障したデバイスだけがチケットを発生させ、ノイズを減らします

    • ITチームは全体ではなく例外に注目します

ユースケースを通じた主な利点

  • 手動のチケット作成を減らす

  • エスカレーション前の修復を自動化します

  • ServiceNowでチケット量を最小限に抑える

  • 応答時間とエンドユーザー体験の向上

詳細については「 ワークフローの概要 」記事をご参照ください。

お問い合わせ

サポートが必要な場合は、サポートケースを作成またはメールsupport@wxp.hp.comしてください。