Documentation Index

Fetch the complete documentation index at: https://learn.workforceexperience.hp.com/llms.txt

Use this file to discover all available pages before exploring further.

Automatisierung von Arbeitsabläufen in WXP

Prev Next

Einleitung

Die Workflow-Funktion in der HP Workforce Experience Platform (WXP) ist eine Low-Code-Workflow-Orchestrierungsfunktion, die für groß angelegte IT-Sanierungen entwickelt wurde. Es ermöglicht IT-Administratoren, automatisierte Arbeitsabläufe über Tausende von Endpunkten über eine visuelle Drag-and-Drop-Oberfläche zu bereitstellen, was Teams hilft, von reaktiver Ticketbearbeitung zu proaktiver Behebung zu wechseln.

Abhängigkeiten und Voraussetzungen

Skriptanforderung für Verzweigungen

  • Skripte müssen im Voraus getestet werden. Skriptausgabe wird verwendet für:

    • Verzweigungs-Logik

    • Webhook-Payloads / Abfrageparameter

  • Webhook muss vorher getestet werden. Derzeit unterstützen wir nur JSON-Eingaben und Klartext ODER JSON-Ausgaben.

Plattform- und Versionsanforderungen

Stellen Sie sicher, dass die folgenden Anforderungen erfüllt sind, bevor Sie Workflows erstellen:

Unterstütztes Betriebssystem

Windows-Unterstützung nur für Warnungen (Ereignisauslöser), Skripte, Treiber-Updates-Knoten

Webhooks sind geräte-OS-agnostisch

Groups (Schedule Trigger) unterstützen Linux, Mac und Windows OS

Minimum Agent-Version

HP Insights Agent: 26.05.49 oder später

HP Insights Analytics Agent: 4.2.2584 oder später

Erstellung eines Arbeitsablaufs

Schritt 1: Hinzufügen eines Auslösers

Jeder Workflow muss mit einem Auslöser beginnen:

  1. Melden Sie sich bei WXP an. Die Startseite wird angezeigt.

  2. Klicken Sie im linken Menü von WXP auf Labs. Die Laborseite wird angezeigt.

  3. Scrollen Sie auf der Labs-Seite zum Abschnitt Workflow und klicken Sie auf Workflow versuchen. Der beendende Workflow wird angezeigt.

  4. Klicken Sie auf Hinzufügen , um einen neuen Workflow zu erstellen. Das Dialogfeld "Workflow hinzufügen" wird angezeigt.  

  5. Im Dialogfeld "Workflow hinzufügen " können Sie entweder einen neuen Workflow von Grund auf erstellen oder einen bestehenden Workflow duplizieren und ändern.

  6. Beim Erstellen von Grund auf lösen Sie ein Ereignis aus:

    1. Event Trigger (Warnbasiert): Der Workflow wird gestartet, wenn eine Warnung auftritt. Die verfügbaren Benachrichtigungsoptionen umfassen die bestehenden Benachrichtigungen, die in der Plattform erstellt oder bereitgestellt werden.

    2. Schedule-Trigger: Administratoren können Datum, Uhrzeit und Zielgruppen für den Workflow festlegen. Die angezeigten Gruppenoptionen basieren auf den in der WXP-Plattform erstellten Gruppen.

Schritt 2: Aktionen hinzufügen

Nach dem Hinzufügen eines Triggers können Sie eine oder mehrere Aktionen hinzufügen, um zu definieren, was der Workflow tun muss.

  • Skript:  Die angezeigten Skriptoptionen sind die bereits vorhandenen Skripte, die entweder in WXP erstellt oder von WXP bereitgestellt werden.

  • Webhook: Integrieren Sie sie in3-Komponenten-Systeme wie ServiceNow, Teams und Slack. Konfigurieren Sie Ihren Webhook manuell oder über die Swagger API-Endpunkt-URL. Testen sind erforderlich, bevor der Webhook in einem Workflow verwendet wird.

  • Geräteaktion: Eine Geräteaktion kann verwendet werden, um Treiberaktualisierungen durchzuführen, wie zum Beispiel:

    • Bereitstellung aller Treiber-Updates

    • Nur kritische Treiber-Updates werden bereitgestellt

    • Bereitstellung aller oder kritischer Treiber-Updates für ausgewählte Treiberkategorien

Schritt 3: Verzweigungslogik hinzufügen

Verwenden Sie if/then/else-Bedingungen , um fortgeschrittene Logikpfade zu erstellen. Das Verzweigen kann auf den Ausgaben von Skripten, Webhooks oder Treiber-Updates basieren.

Aktuelle Einschränkungen

  • Verschachtelte Verzweigung wird nicht unterstützt

    • Ein Ast, der vor oder nach einem anderen Ast platziert wird, wird als separat behandelt – nicht als verschachtelt

  • Du kannst nach einem Zweig keine Aktionen hinzufügen

Zeitzonenverhalten für Zeitplan-Auslöser

Dieses Verhalten gilt nur für den Schedule-Auslöser. Beim Erstellen eines Workflows wird die geplante Zeit in der Zeitzone deines (Erstellers) festgelegt. Die Ausführung erfolgt jedoch in der lokalen Zeitzone jedes Zielgeräts. Zum Beispiel, wenn du einen Workflow für 9:00 Uhr PST planst; die Geräte in EST führen den Workflow um 12:00 Uhr EST aus. Dies hilft sicherzustellen, dass Arbeitsabläufe zur vorgesehenen lokalen Zeit für jeden Empfänger ausgeführt werden, unabhängig davon, wo er sich befindet.

Warnungen und Aktivitätsverhalten für Ereignisauslöser

Flotten- vs. Gerätewarnungen

Workflow-Ausführungen, die durch Warnungen ausgelöst werden, werden im Tab Aktivität von WXP wiedergegeben. Aktivitätsverhalten basierend auf der Art des Alarms:

  • Flottenalarm: Ausführen werden angezeigt, wenn ein Alarm über eine Flotte von Geräten ausgelöst wird.

  • Geräte-Alarm: Die Ausführung wird für jedes Gerät einzeln nachverfolgt

  • Hinweis:

    • Wenn ein Alarm bereits vor der Veröffentlichung aktiv ist, werden diese Geräte in die Workflow-Zielgruppe einbezogen.

    • Wenn sich eine Alarmregel ändert, also der Abschnitt "Trigger Conditions" der Alarmregel aktualisiert wird, kann sie neue Ausführungen auslösen.

Bearbeitung des Publikums

  • Das Bearbeiten wird nur für zeitplanbasierte Workflows unterstützt, die datumsbasierte Trigger verwenden.

  • Das Bearbeiten der Zielgruppe wird für ereignisbasierte Workflows nach deren Veröffentlichung nicht mehr unterstützt.

Bearbeitungsregeln

Die folgenden Regeln gelten basierend auf dem Status des Workflows:

1. Arbeitsablauf ist aktiv (wiederkehrend, Startzeit verstrichen)
  • Publikum: In dieser Phase ist das Publikum bearbeitbar.

  • Gruppen:

    • Hinzufügen von Gruppen: Wenn Gruppen hinzugefügt werden, sind sie in die aktuelle Ausführung (falls nicht abgeschlossen) und in zukünftige Ausführungen enthalten. Diese Aktion kann im Reiter Aktivität angezeigt werden, der den Benutzer anzeigt, der die Gruppe erstellt hat, sowie den Zeitstempel der Gruppenerstellung.

    • Entfernung von Gruppen: Wenn Gruppen entfernt werden, werden sie von den verbleibenden Geräten in der aktuellen Ausführung und aus zukünftigen Ausführungen entfernt. Sie werden nicht von Geräten entfernt, an denen die Ausführung abgeschlossen ist. Diese Aktion kann auch im Reiter Aktivität angesehen werden.

2. Arbeitsablauf ist aktiv (Startzeit ist noch nicht abgelaufen)

Das Publikum kann weiterhin bearbeitet werden. Alle vorgenommenen Änderungen gelten für den kommenden Lauf. Alle Aktionen werden mit Benutzerdaten und dem Zeitstempel des Updates protokolliert.

3. Arbeitsablauf ist aktiv (Einmal, Startzeit vergangen)

Die Zielgruppe ist gesperrt und der Workflow ist finalisiert.

Workflow-Status anzeigen

Sie können den Status auf der Workflows-Liste von WXP einsehen.

Die folgenden Statusstufen werden unterstützt.

Status

Beschreibung

Bearbeitungsfähigkeit

Entwurf

Nicht veröffentlicht

Vollständig bearbeitbar

Aktiv

Veröffentlicht und laufend oder geplant

Nicht bearbeitbar, außer für die Zielgruppe nur in datenbasierten Workflows

Abgesagt

Manuell gestoppt

Nicht bearbeitbar

Abgeschlossen

Hinrichtung beendet

Nicht bearbeitbar

Überprüfung von Workflow-KPIs

Nachdem ein Workflow veröffentlicht wurde, können Sie auf dessen KPIs zugreifen, indem Sie auf der Seite Workflow List auf den Workflow-Namen klicken und dann zum Reiter Aktivität auf der Seite Workflow-Details navigieren. Die KPIs werden unter dem Reiter Executions angezeigt.

Status

Dienstplanbasiert

Veranstaltungsbasiert

In Arbeit

Ich habe auf mindestens einem Gerät angefangen und es ist noch nicht abgelaufen (24-Stunden-Auszeit).

Der Alarm ist noch ungelöst und bleibt bis zur Auflösung aktiv

Abgeschlossen

Beendet oder zeitlich abgelaufen

Der Alarm ist gelöst

Überprüfung von Ausführungsstatusen

Nachdem ein Workflow veröffentlicht wurde, können Sie auf den Ausführungsstatus zugreifen, indem Sie auf der Workflow-Listenseite auf den Namen des Workflows klicken und dann zum Reiter Aktivität navigieren. Die Hinrichtungen werden in einer Tabelle dargestellt.

Ausführungsstatus (pro Ausführung)

  • In Arbeit: Gleiche Kriterien wie oben

  • Abgeschlossen: Abgeschlossen oder gelöst

  • Abgesagt: Workflow vor der Ausführung abgebrochen

Überprüfung von KPIs auf Geräteebene

Status auf Geräteebene (innerhalb einer Workflow-Ausführung)

Der Status auf Geräteebene zeigt an, ob ein einzelnes Gerät alle Schritte in einem Workflow erfolgreich abgeschlossen hat oder während der Ausführung ein Problem aufgetreten ist. Dieser wird nach der Veröffentlichung erreicht, indem man auf den Workflow-Namen auf der Workflow-Listenseite > Aktivitätstab > Ausführung klickt (im Falle eines Geräte-Alarms werden Geräte als Ausführung behandelt).

Nachdem ein Workflow veröffentlicht wurde, können Sie den Status auf Geräteebene aufrufen, indem Sie auf der Workflow-Listenseite > Reiter Aktivität > Ausführung klicken. Bei Alarmen auf Geräteebene wird jedes Gerät als separate Ausführung behandelt.

Hinweis: Wenn ein Gerät an einem Schritt einen fatalen Fehler erlebt, wird es nicht zu den nächsten Schritten im Workflow übergehen.

Statustypen

Die folgenden Statusse werden auf Geräteebene unterstützt:

Status

Beschreibung

Abgeschlossen

Das Gerät wird als Abgeschlossen markiert, wenn es den letzten Schritt des Workflows erfolgreich erreicht hat und während der Ausführung keine fatalen Fehler auftreten.

Fehlerhaft

Das Gerät wird als fehlerhaft markiert, wenn es den letzten Schritt nicht erreicht oder wenn ein fataler Fehler die Ausführung unterbricht.

In Arbeit

Das Gerät ist als in Bearbeitung markiert, wenn die Ausführung begonnen hat, der Server noch keine Antwort erhalten hat, das 24-Stunden-Ausführungsfenster noch nicht abgelaufen ist und kein fataler Fehler aufgetreten ist.

Nicht verarbeitet

Das Gerät wird als nicht verarbeitet markiert, wenn es innerhalb des 24-Stunden-Zeitfensters nicht antwortet oder wenn der Workflow-Schritt nicht fortgesetzt werden kann, weil keine Kommunikation stattfindet. Zum Beispiel kann das Gerät während der Ausführung offline oder nicht erreichbar sein.

Eingestellt

Das Gerät wird als Cancelled markiert , wenn der Workflow abgebrochen wird, bevor die Ausführung auf diesem Gerät beginnt.

Hinweis:

  • Die Ergebnisse der Geräteausführung sind im Reiter Aktivität sichtbar.

  • Hinrichtungen treten nur dann auf, wenn sie stattfinden

    • Wiederkehrende Workflows zeigen keine zukünftigen Ausführungen im Voraus an

  • Einblicke auf Geräteebene helfen, Folgendes zu identifizieren:

    • Versagenspunkte

    • Offline-Geräte

    • Hinrichtungsengpässe

Anwendungsfälle von Workflow Builder

1. Erstellung eines ServiceNow-Tickets aus einer Warnung

  • Szenario: Ihre Organisation möchte automatisch einen ServiceNow (SNOW)-Vorfall erstellen, wenn ein bestimmter Alarm in HP WXP ausgelöst wird.

  • Lösung: Verwenden Sie einen ereignisbasierten Trigger (Alert), indem Sie die entsprechende Warnung auswählen. Zum Beispiel: Gerätezustand, App-Absturz, Leistungsprobleme)

    • Action: Füge eine Webhook-Aktion  hinzu und konfiguriere den Webhook so, dass er mit deinem ServiceNow-Endpunkt integriert wird. Stellen Sie sicher, dass die Webhook-Nutzlast wichtige Gerätedetails (wie die Geräteseriennummer) enthält, um eine genaue Ticketerstellung und -verfolgung zu unterstützen. Sie können diese Felder dynamisch mit unserer Variablenliste ausfüllen, die Zugriff zufolge bietet:

      • Globale Variablen, wie zum Beispiel Geräteebenen-Attribute.

      • Schrittausgaben, wie Skriptergebnisse oder frühere Aktionsausgaben

Die Verwendung dieser Variablen gewährleistet eine konsistente Formatierung und ermöglicht reichhaltigere, kontextbewusste Integrationen (wie ServiceNow-Tickets).

  • Ergebnis:

    • Wenn die Warnung ausgelöst wird, wird pro Gerät automatisch ein ServiceNow-Ticket erstellt.

    • Schnellere Einsatzreaktion ohne manuelles Eingreifen

Hinweis: Stellen Sie sicher, dass Webhook-Payloads im Voraus getestet werden, um Feldkartierungen und Ticketerstellung in ServiceNow zu validieren.

2. Automatisierte Behebung + Ticketing bei PowerPoint-Abstürzen

  • Szenario: Eine Warnung zeigt an, dass PowerPoint-Abstürze einen Prozentsatz Ihrer Flotte betreffen. Ihre Organisation möchte betroffene Geräte automatisch beheben und Tickets nur bei Ausfällen erstellen.

  • Lösung: Verwenden Sie einen ereignisbasierten Trigger (Alert). Zum Beispiel stürzt PowerPoint ab und betrifft X % der Geräte.

    1. Aktion 1: Führen Sie eine Skriptaktion aus, um betroffene Geräte auf die neueste Version von Microsoft Office zu aktualisieren.

      1. Verzweigungslogik (wenn/dann):

        1. Bewerten Sie das Ergebnis des Skripts:

          1. Wenn Exit-Code = 0 (Skripterfolg):

            1. Ende des Arbeitsablaufs (Problem gelöst)

          2. Sonst (gescheitert):

            1. Gehen Sie zum nächsten Schritt weiter

    2. Aktion 2 – Webhook (ServiceNow-Ticket):

      1. Löse einen Webhook aus, um ein ServiceNow-Ticket zu erstellen, falls Geräte unter die Else-Bedingung fallen (auch Failed genannt)

        1. Enthalten Sie:

          1. Gerätedetails

          2. Skriptausgabe (zur Fehlerbehebung)

  • Ergebnis:

    • Geräte werden automatisch im großen Maßstab saniert

    • Nur fehlgeschlagene Geräte erzeugen Tickets, was den Rausch reduziert

    • IT-Teams konzentrieren sich auf Ausnahmen und nicht auf die gesamte Flotte

Wichtige Vorteile über Anwendungsfälle hinweg

  • Reduziert die manuelle Ticketerstellung

  • Automatisiert Sanierung vor der Eskalation

  • Minimiert das Ticketvolumen in ServiceNow

  • Verbessert die Antwortzeit und das Endnutzererlebnis

Weitere Informationen finden Sie im Artikel Übersicht über Arbeitsablauf .

Kontaktieren Sie uns

Für jegliche Unterstützung erstellen Sie bitte einen Support-Fall oder eine E-Mailsupport@wxp.hp.com.