Introduktion

Arbetsflödesfunktionen i HP Workforce Experience Platform (WXP) är en lågkods-arbetsflödesorkestreringsfunktion utformad för storskalig IT-åtgärd. Det gör det möjligt för IT-administratörer att implementera automatiserade arbetsflöden över tusentals endpoints med hjälp av ett visuellt dra-och-släpp-gränssnitt, vilket hjälper team att gå från reaktiv ärendehantering till proaktiv åtgärd.

Beroenden och förutsättningar

Skriptkrav för förgrening

• Skript måste testas i förväg. Skriptutdata används för:

  • Förgreningslogik

  • Webhook-payloads / frågeparametrar

• Webhook måste testas i förväg. För närvarande stödjer vi endast stöd för JSON-inmatningar och klartext- eller JSON-utdata.

Plattforms- och versionskrav

Se till att följande krav uppfylls innan du skapar arbetsflöden:

Skapa ett arbetsflöde

Steg 1: Lägga till en utlösare

Varje arbetsflöde måste börja med en trigger:

1. Logga in på WXP. Startsidan  visas.

2. Från vänstermenyn i WXP, klicka på Labs. Labs-sidan visas.

3. På sidan Labs, scrolla till avsnittet Arbetsflöde och klicka på Försök Arbetsflöde. De avslutande arbetsflödena visas.

   

4. Klicka på Lägg till för att skapa ett nytt arbetsflöde. Dialogrutan Lägg till arbetsflöde visas.  

   

5. I dialogrutan Lägg till arbetsflöde kan du antingen skapa ett nytt arbetsflöde från grunden eller duplicera och ändra ett befintligt arbetsflöde.

   

6. När du skapar från grunden, trigga en händelse:

   1. Händelseutlösare (varningsbaserat): Arbetsflödet initieras när en varning inträffar. De tillgängliga varningsalternativen inkluderar de befintliga varningar som skapas eller tillhandahålls i plattformen.

   2. Schema-trigger: Administratörer kan definiera datum, tid och målgrupper för arbetsflödet. De grupperalternativ som visas baseras på de grupper som skapats i WXP-plattformen.

   

Steg 2: Lägg till åtgärder

Efter att ha lagt till en trigger kan du lägga till en eller flera åtgärder för att definiera vad arbetsflödet måste göra.

• Skript:  De skriptalternativ som visas är de redan existerande skripten som antingen skapas i WXP eller tillhandahålls av WXP.

• Webhook: Integrera med^{tredelssystem} , såsom ServiceNow, Teams och Slack. Konfigurera din webhook manuellt eller via Swagger API:s endpoint-URL. Testning krävs innan webhooken används i ett arbetsflöde.

• Enhetsåtgärd: En enhetsåtgärd kan användas för att utföra drivrutinsuppdateringar, såsom:

  • Distribuerar alla drivrutinsuppdateringar

  • Distribuerar endast kritiska drivrutinsuppdateringar

  • Distribuerar alla eller kritiska drivrutinsuppdateringar för utvalda drivrutinskategorier

Steg 3: Lägga till förgreningslogik

Använd if/then/else-villkor för att skapa avancerade logikvägar. Branching kan baseras på utdata från skript, webhooks eller drivrutinsuppdateringar.

Nuvarande begränsningar

• Nästlad förgrening stöds inte

  • En gren placerad före eller efter en annan gren behandlas som separat—inte inbäddad

• Du kan inte lägga till handlingar efter en gren

Tidszonsbeteende för schema-trigger

Detta beteende gäller endast för Schema-triggern. När du skapar ett arbetsflöde ställs den schemalagda tiden in i din (skaparens) tidszon. Dock sker exekveringen i den lokala tidszonen för varje målenhet. Till exempel, om du schemalägger ett arbetsflöde till 9:00 PST; enheterna i EST kommer att utföra arbetsflödet klockan 12:00 EST. Detta hjälper till att säkerställa att arbetsflöden körs vid avsedd lokal tid för varje mottagare, oavsett var de befinner sig.

Aviseringar och aktivitetsbeteende för händelseutlösare

Flotta vs. enhetsvarningar

Arbetsflödeskörningar som utlöses av varningar återspeglas i fliken Aktivitet i WXP. Aktivitetsbeteende baserat på typen av avisering:

• Flottnivåvarning: Utföranden visas när en varning utlöses över en flotta av enheter.

• Enhetsnivåvarning: Exekveringar spåras individuellt för varje enhet

• Notera:

  • Om en varning redan är aktiv innan publicering, inkluderas dessa enheter i arbetsflödespubliken.

  • Om en varningsregel ändras, det vill säga "Trigger Conditions"-sektionen i varningsregeln uppdateras, kan den utlösa nya exekveringar.

Redigering av publiken

• Redigering stöds endast för schemabaserade arbetsflöden som använder datumbaserade triggers.

• Redigeringspublik stöds inte för händelsebaserade arbetsflöden efter att de har publicerats.

Redigeringsregler

Följande regler gäller baserat på arbetsflödets status:

1. Arbetsflödet är aktivt (återkommande, starttid passerad)

• Publik: I det här skedet är publiken redigerbar.

• Grupper:

  • Lägga till grupper: Om grupper läggs till inkluderas de i Nuvarande exekvering (om inte slutförd) och Framtida exekveringar. Denna åtgärd kan ses i fliken Aktivitet , som visar användaren som skapade gruppen och tidsstämpeln för gruppskapandet.

  • Borttagning av grupper: Om grupper tas bort, tas de bort från de återstående enheterna i Current execution och från Future executions. De tas inte bort från enheter där exekveringen slutförs. Denna åtgärd kan också ses under fliken Aktivitet .

2. Arbetsflödet är aktivt (Starttiden har inte passerat)

Publiken kan fortfarande redigeras. Alla ändringar som görs kommer att gälla för den kommande omgången. Alla åtgärder loggas med användaruppgifter och uppdateringstidsstämpel.

3. Arbetsflödet är aktivt (Engångstid, starttid passerad)

Publiken är låst och arbetsflödet är färdigställt.

Visning av arbetsflödesstatusar

Du kan se statusen på sidan för arbetsflöden på WXP.

Följande statusar stöds.

Granskning av arbetsflödes-KPI:er

Efter att ett arbetsflöde har publicerats kan du komma åt dess KPI:er genom att klicka på arbetsflödesnamnet på sidan Arbetsflödeslista e och sedan navigera till fliken Aktivitet på sidan Arbetsflödesdetaljer. KPI:erna visas under fliken Utförande.

Granskning av exekveringsstatus

Efter att ett arbetsflöde har publicerats kan du komma åt exekveringsstatusar genom att klicka på arbetsflödets namn på sidan Arbetsflödeslistan och sedan navigera till fliken Aktivitet. Avrättningarna visas i en tabell.

Exekveringsnivåstatus (per exekvering)

• Pågående: Samma kriterier som ovan

• Slutfört: Färdigt eller löst

• Inställt: Arbetsflöde avbrutet före körning

Granskning av enhetsnivå-KPI:er

Enhetsnivåstatus (inom en arbetsflödesexekvering)

Status på enhetsnivå indikerar om en enskild enhet framgångsrikt har slutfört alla steg i ett arbetsflöde eller stött på ett problem under körningen. Detta nås efter publicering genom att klicka på arbetsflödesnamnet på sidan Arbetsflödeslista > fliken Aktivitet > Exekvering (vid en enhetsnivåvarning behandlas enheter som en exekvering).

Efter att ett arbetsflöde har publicerats kan du komma åt enhetsnivåstatus genom att klicka på arbetsflödets namn på sidan Arbetsflödeslistan > fliken Aktivitet , > Exekvering. För enhetsnivåvarningar behandlas varje enhet som en separat exekvering.

Notera: Om en enhet stöter på ett fatalt fel i något steg kommer den inte att gå vidare till nästa steg i arbetsflödet.

Statustyper

Följande statusar stöds på enhetsnivå:

Notera:

• Resultatet av enhetsexekvering syns i fliken Aktivitet .

• Avrättningar sker bara när de sker

  • Återkommande arbetsflöden visar inte framtida körningar i förväg

• Insikter på enhetsnivå hjälper till att identifiera:

  • Felpunkter

  • Offline-enheter

  • Flaskhalsar vid genomförande

Arbetsflödesbyggarens användningsfall

1. Skapa ett ServiceNow-ärende från en varning

• Scenario: Din organisation vill automatiskt skapa en ServiceNow (SNOW)-incident när en specifik varning utlöses i HP WXP.

• Lösning: Använd en händelsebaserad trigger (Alert) genom att välja relevant varning. Till exempel: enhetens hälsa, appkrasch, prestandaproblem)

  • Action: Lägg till en Webhook-åtgärd  och konfigurera webhooken för att integreras med din ServiceNow-endpoint. Se till att webhook-nyttolasten inkluderar viktiga enhetsdetaljer (såsom enhetens serienummer) för att stödja korrekt ärendeskapande och spårning. Du kan dynamiskt fylla i dessa fält med hjälp av vår variabellista som ger tillgång till:

    • Globala variabler, såsom attribut på enhetsnivå.

    • Stegutgångar, såsom skriptresultat eller tidigare åtgärdsutdata

Att använda dessa variabler säkerställer konsekvent formatering och möjliggör rikare, kontextmedvetna integrationer (såsom ServiceNow-ärenden).

• Resultat:

  • När varningen utlöses skapas automatiskt ett ServiceNow-ärende per enhet.

  • Snabbare incidentrespons utan manuell intervention

Notera: Se till att webhook-payloads testas i förväg för att validera fältkartläggningar och ärendeskapande i ServiceNow.

2. Automatiserad åtgärd + ärendehantering för PowerPoint-krascher

• Scenario: En varning indikerar att PowerPoint-krascher påverkar en andel av din flotta. Din organisation vill automatiskt åtgärda drabbade enheter och skapa ärenden endast vid fel.

• Lösning: Använd en händelsebaserad trigger (Alert). Till exempel kraschar PowerPoint och påverkar X % av enheterna.

  1. Åtgärd 1: Kör en skriptåtgärd för att uppdatera berörda enheter till den senaste versionen av Microsoft Office.

     1. Förgrenad logik (om/då):

        1. Utvärdera manusresultatet:

           1. Om utgångskod = 0 (skriptframgång):

              1. Slutarbetsflöde (problem löst)

           2. Annars (Misslyckades):

              1. Gå vidare till nästa steg

  2. Åtgärd 2 – Webhook (ServiceNow-ärende):

     1. Trigga en webhook för att skapa ett ServiceNow-ärende, om enheter omfattas av Else-villkoret (dvs. misslyckat).

        1. Inkludera:

           1. Enhetsdetaljer

           2. Skriptutdata (för felsökning)

• Resultat:

  • Enheter åtgärdas automatiskt i stor skala

  • Endast trasiga enheter genererar ärenden, vilket minskar bruset

  • IT-team fokuserar på undantag snarare än hela flottan

Viktiga fördelar över användningsområden

• Minskar manuell ärendeskapande

• Automatiserar åtgärd innan eskalering

• Minimerar biljettvolymen i ServiceNow

• Förbättrar svarstid och slutanvändarupplevelse

Relaterade resurser

För ytterligare information, se artikeln Översikt över arbetsflöden .