Introduzione

La funzione Workflow in HP Workforce Experience Platform (WXP) è una capacità di orchestrazione di workflow low-code progettata per una bonifica IT su larga scala. Permette agli amministratori IT di implementare flussi di lavoro automatizzati su migliaia di endpoint utilizzando un'interfaccia visiva drag-and-drop, aiutando i team a passare dalla gestione reattiva dei ticket a una remediazione proattiva.

Dipendenze e Prerequisiti

Requisito di script per il ramificamento

• Gli script devono essere testati prima. L'output script viene utilizzato per:

  • Logica ramificata

  • Payload Webhook / parametri di query

• Webhook deve essere testato prima. Attualmente, supportiamo solo input JSON e output in testo semplice O JSON.

Requisiti di piattaforma e versione

Assicurati che i seguenti requisiti siano soddisfatti prima di creare flussi di lavoro:

Creare un flusso di lavoro

Passo 1: Aggiungere un trigger

Ogni flusso di lavoro deve iniziare con un trigger:

1. Accedi a WXP. Viene visualizzata la Home page.

2. Dal menu sinistro di WXP, clicca su Labs. Viene visualizzata la pagina Labs .

3. Nella pagina Labs , scorri fino alla sezione Workflow e clicca su Prova Workflow. Il flusso di lavoro in uscita viene visualizzato.

   

4. Clicca su Aggiungi per creare un nuovo flusso di lavoro. Viene visualizzata la finestra di dialogo Aggiungi workflow .  

   

5. Nella finestra di dialogo Aggiungi workflow , puoi creare un nuovo workflow da zero oppure duplicare e modificare un workflow esistente.

   

6. Quando crei da zero, attiva un evento:

   1. Trigger di evento (basato su avvisi): Il flusso di lavoro viene avviato quando si verifica un avviso. Le opzioni di avviso disponibili includono gli avvisi esistenti creati o forniti sulla piattaforma.

   2. Trigger di programmazione: Gli amministratori possono definire data, ora e gruppi target per il flusso di lavoro. Le opzioni di gruppo visualizzate si basano sui gruppi creati sulla piattaforma WXP.

   

Passo 2: Aggiunta di azioni

Dopo aver aggiunto un trigger, puoi aggiungere una o più azioni per definire cosa deve fare il workflow.

• Script:  Le opzioni di script visualizzate sono gli script preesistenti che sono creati in WXP o forniti da WXP.

• Webhook: Integra con sistemi di terze^parti, come ServiceNow, Teams e Slack. Configura il tuo webhook manualmente o tramite l'URL dell'endpoint dell'API Swagger. Il test è necessario prima che il webhook venga utilizzato in un flusso di lavoro.

• Azione del dispositivo: Un'azione del dispositivo può essere utilizzata per eseguire aggiornamenti dei driver, ad esempio:

  • Distribuzione di tutti gli aggiornamenti dei driver

  • Distribuzione solo degli aggiornamenti critici dei driver

  • Distribuzione di aggiornamenti totali o critici dei driver per categorie selezionate di driver

Passo 3: Aggiunta della logica di ramificazione

Usa le condizioni if/allora/else per creare percorsi logici avanzati. Il ramificamento può basarsi sugli output di script, webhook o aggiornamenti dei driver.

Limitazioni attuali

• Il ramificamento annidato non è supportato

  • Un ramo posto prima o dopo un altro ramo è considerato separato—non annidato

• Non puoi aggiungere azioni dopo un ramo

Comportamento del fuso orario per il trigger del programma

Questo comportamento si applica solo al trigger di programmazione. Quando si crea un flusso di lavoro, l'orario programmato viene impostato nel fuso orario del tuo (creatore). Tuttavia, l'esecuzione avviene nel fuso orario locale di ciascun dispositivo target. Ad esempio, se programmi un flusso di lavoro alle 9:00 AM PST; i dispositivi in EST eseguiranno il flusso di lavoro alle 12:00 PM EST. Questo aiuta a garantire che i flussi di lavoro vengano eseguiti all'ora locale prevista per ogni destinatario, indipendentemente da dove si trovi.

Avvisi e comportamento di attività per il trigger di eventi

Allerti Flotta vs. Dispositivi

Le esecuzioni del workflow attivate dagli avvisi sono riflesse nella scheda Attività di WXP. Comportamento dell'attività basato sul tipo di Allerta:

• Allerta a livello di flotta: Le esecuzioni vengono mostrate quando un allarme viene attivato su una flotta di dispositivi.

• Allerta a livello di dispositivo: Le esecuzioni vengono tracciate individualmente per ciascun dispositivo

• Nota:

  • Se un avviso è già attivo prima della pubblicazione, quei dispositivi vengono inclusi nel pubblico del flusso di lavoro.

  • Se una regola di allerta cambia, cioè la sezione "Condizioni di attivazione" della regola viene aggiornata, può attivare nuove esecuzioni.

Montaggio del pubblico

• La modifica è supportata solo per flussi di lavoro basati su programmazione che utilizzano trigger basati su data.

• L'editing del pubblico non è supportato per i flussi di lavoro basati su eventi dopo la pubblicazione.

Regole di modifica

Le seguenti regole si applicano in base allo stato del flusso di lavoro:

1. Il flusso di lavoro è attivo (ricorrente, ora di inizio trascorso)

• Pubblico: A questo punto, il pubblico è modificabile.

• Gruppi:

  • Aggiunta di gruppi: Se vengono aggiunti gruppi, sono inclusi nelle esecuzioni attuali (se non completate) e nelle esecuzioni future. Questa azione può essere visualizzata nella scheda Attività , che mostra l'utente che ha creato il gruppo e il timestamp della creazione del gruppo.

  • Rimozione dei gruppi: Se i gruppi vengono rimossi, vengono rimossi dai dispositivi rimanenti nell'esecuzione corrente e dalle esecuzioni future. Non vengono rimossi dai dispositivi in cui l'esecuzione è completata. Questa azione può essere visualizzata anche nella scheda Attività .

2. Il flusso di lavoro è attivo (l'ora di inizio non è ancora passata)

Il pubblico può ancora essere modificato. Qualsiasi modifica apportata si applicherà anche alla prossima corsa. Tutte le azioni sono registrate con i dati utente e l'orario dell'aggiornamento.

3. Il flusso di lavoro è attivo (una tantum, ora di inizio passata)

Il pubblico è bloccato e il flusso di lavoro è finalizzato.

Visualizzazione degli stati del flusso di lavoro

Puoi visualizzare lo stato dalla pagina Workflows di WXP.

Sono supportati i seguenti stati.

Revisione dei KPI del Workflow

Dopo la pubblicazione di un workflow, puoi accedere ai suoi KPI cliccando sul nome del workflow nella pagina e della Lista Workflow e poi navigando nella scheda Attività nella pagina Dettagli del Workflow. I KPI sono visualizzati nella scheda Esecuzioni.

Revisione degli stati di esecuzione

Dopo la pubblicazione di un flusso di lavoro, puoi accedere agli stati di esecuzione cliccando sul nome del flusso di lavoro nella pagina della lista Workflow e poi navigando nella scheda Attività. Le esecuzioni sono esposte in una tabella.

Stato del livello di esecuzione (per esecuzione)

• In corso: Stessi criteri di sopra

• Completato: Concluso o risolto

• Cancellato: Flusso di lavoro cancellato prima dell'esecuzione

Revisione dei KPI a livello di dispositivo

Stato a livello di dispositivo (all'interno di un'esecuzione di workflow)

Lo stato a livello di dispositivo indica se un singolo dispositivo ha completato con successo tutti i passaggi di un flusso di lavoro o ha incontrato un problema durante l'esecuzione. Questo si accede dopo la pubblicazione cliccando sul nome del workflow nella pagina elenco workflow > nella scheda Attività > Esecuzione (nel caso di un avviso a livello di dispositivo si trattano i dispositivi come esecuzione).

Dopo la pubblicazione di un flusso di lavoro, puoi accedere allo stato a livello di dispositivo cliccando sul nome del flusso di lavoro nella pagina elenco Workflow > scheda Attività , > Esecuzione. Per gli avvisi a livello di dispositivo, ogni dispositivo viene trattato come un'esecuzione separata.

Nota: Se un dispositivo incontra un errore fatale in qualsiasi fase, non procederà con le fasi successive del flusso di lavoro.

Tipi di status

I seguenti stati sono supportati a livello di dispositivo:

Nota:

• I risultati dell'esecuzione del dispositivo sono visibili nella scheda Attività .

• Le esecuzioni compaiono solo quando avvengono

  • I flussi di lavoro ricorrenti non mostreranno in anticipo le esecuzioni future

• Le analisi a livello di dispositivo aiutano a identificare:

  • Punti di guasto

  • Dispositivi offline

  • Colli di bottiglia nell'esecuzione

Casi d'uso del Workflow Builder

1. Creazione di un ticket ServiceNow da un avviso

• Scenario: La tua organizzazione vuole creare automaticamente un incidente ServiceNow (SNOW) quando viene attivato un avviso specifico in HP WXP.

• Soluzione: Usa un trigger basato su eventi (Alert) selezionando l'avviso pertinente. Ad esempio: salute del dispositivo, crash dell'app, problemi di prestazioni)

  • Azione: Aggiungi un'azione Webhook  e configura il webhook per integrarsi con il tuo endpoint ServiceNow. Assicurati che il payload del webhook includa dettagli chiave del dispositivo (come il numero di serie del dispositivo) per supportare una creazione e un tracciamento accurati dei ticket. Puoi popolare dinamicamente questi campi utilizzando la nostra lista Variabili che offre accesso a:

    • Variabili globali, come attributi a livello di dispositivo.

    • Output a passaggi, come i risultati degli script o gli output delle azioni precedenti

L'uso di queste variabili garantisce una formattazione coerente e consente integrazioni più ricche e consapevoli del contesto (come i ticket ServiceNow).

• Risultato:

  • Quando l'avviso viene attivato, un ticket ServiceNow viene creato automaticamente per ogni dispositivo.

  • Risposta agli incidenti più rapida senza interventi manuali

Nota: Assicurati che i payload dei webhook siano testati in anticipo per validare le mappature di campo e la creazione dei ticket in ServiceNow.

2. Rimedio automatico + Gestione dei ticket per crash di PowerPoint

• Scenario: Un avviso indica che i crash di PowerPoint stanno influenzando una percentuale della tua flotta. La tua organizzazione vuole risolvere automaticamente i dispositivi interessati e creare ticket solo per i guasti.

• Soluzione: Usa un trigger basato su eventi (Alert). Ad esempio, PowerPoint si blocca e coinvolge X% dei dispositivi.

  1. Azione 1: Eseguire un'azione script per aggiornare i dispositivi interessati all'ultima versione di Microsoft Office.

     1. Logica di ramificazione (se/allora):

        1. Valuta il risultato della sceneggiatura:

           1. Se codice di uscita = 0 (successo dello script):

              1. Fine flusso di lavoro (problema risolto)

           2. Altrimenti (fallito):

              1. Procedi al passo successivo

  2. Azione 2 – Webhook (Biglietto ServiceNow):

     1. Attiva un webhook per creare un ticket ServiceNow, se i dispositivi rientrano nella condizione Else (cioè fallito)

        1. Include:

           1. Dettagli del dispositivo

           2. Output script (per la risoluzione dei problemi)

• Risultato:

  • I dispositivi vengono automaticamente rimossi su larga scala

  • Solo i dispositivi guasti generano ticket, riducendo il rumore

  • I team IT si concentrano sulle eccezioni piuttosto che sull'intera flotta

Principali benefici in diversi casi d'uso

• Riduce la creazione manuale dei ticket

• Automatizza la bonifica prima dell'escalation

• Minimizza il volume dei ticket in ServiceNow

• Migliora i tempi di risposta e l'esperienza dell'utente finale

Risorse correlate

Per ulteriori informazioni, consulta l'articolo Panoramica del flusso di lavoro .