Introducción

La función de flujo de trabajo en HP Workforce Experience Platform (WXP) es una capacidad de orquestación de flujos de trabajo low-code diseñada para la remediación a gran escala de TI. Permite a los administradores de TI desplegar flujos de trabajo automatizados en miles de endpoints mediante una interfaz visual de arrastrar y soltar, ayudando a los equipos a pasar de la gestión reactiva de tickets a la remediación proactiva.

Dependencias y requisitos previos

Requisito de script para ramificación

• Los guiones deben probarse antes. La salida de scripts se utiliza para:

  • Lógica de ramificación

  • Cargas útiles de Webhook / parámetros de consulta

• Webhook debe ser probado antes. Actualmente, solo soportamos entradas JSON y texto plano O salidas JSON.

Requisitos de plataforma y versión

Asegúrate de que se cumplan los siguientes requisitos antes de crear flujos de trabajo:

Creando un flujo de trabajo

Paso 1: Añadir un disparador

Todo flujo de trabajo debe comenzar con un desencadenante:

1. Inicia sesión en WXP. Se muestra la página principal .

2. Desde el menú izquierdo de WXP, haz clic en Labs. Se muestra la página de Laboratorios .

3. En la página de Laboratorios , desplázate hasta la sección de Flujo de trabajo y haz clic en Probar Flujo de Trabajo. Se muestran los flujos de trabajo que salen.

   

4. Haz clic en Añadir para crear un nuevo flujo de trabajo. Se muestra el cuadro de diálogo Añadir flujo de trabajo .  

   

5. En el cuadro de diálogo Añadir flujo de trabajo , puedes crear un nuevo flujo de trabajo desde cero o duplicar y modificar un flujo de trabajo existente.

   

6. Al crear desde cero, activa un evento:

   1. Disparador de evento (basado en alertas): El flujo de trabajo se inicia cuando ocurre una alerta. Las opciones de alerta disponibles incluyen las alertas existentes que se crean o proporcionan en la plataforma.

   2. Activador de programación: Los administradores pueden definir la fecha, hora y grupos objetivo para el flujo de trabajo. Las opciones de grupo que se muestran se basan en los grupos creados en la plataforma WXP.

   

Paso 2: Añadir acciones

Después de añadir un disparador, puedes añadir una o más acciones para definir qué debe hacer el flujo de trabajo.

• Guion:  Las opciones de guion que se muestran son los scripts preexistentes que se crean en WXP o que se proporcionan en WXP.

• Webhook: Integra con sistemas de^{tercera parte,} como ServiceNow, Teams y Slack. Configura tu webhook manualmente o a través de la URL del endpoint de la API Swagger. Se requieren pruebas antes de utilizar el webhook en un flujo de trabajo.

• Acción del dispositivo: Una acción de dispositivo puede usarse para realizar actualizaciones de controladores, tales como:

  • Despliegue de todas las actualizaciones de controladores

  • Despliegue solo actualizaciones críticas de controladores

  • Despliegue total o actualizaciones críticas de controladores para categorías seleccionadas de controladores

Paso 3: Añadir lógica de ramificación

Utiliza condiciones if/then/else para crear rutas lógicas avanzadas. El ramificación puede basarse en las salidas de scripts, webhooks o actualizaciones de controladores.

Limitaciones actuales

• No se soporta el ramificado anidado

  • Una rama colocada antes o después de otra rama se considera separada, no anidada

• No puedes añadir acciones tras una rama

Comportamiento de huso horario para el desencadenante de horario

Este comportamiento solo se aplica al desencadenante programado. Al crear un flujo de trabajo, la hora programada se establece en la zona horaria de tu creador. Sin embargo, la ejecución se realiza en la zona horaria local de cada dispositivo objetivo. Por ejemplo, si programas un flujo de trabajo para las 9:00 AM PST; los dispositivos en EST ejecutarán el flujo de trabajo a las 12:00 PM EST. Esto ayuda a garantizar que los flujos de trabajo se ejecuten a la hora local prevista para cada destinatario, independientemente de dónde se encuentren.

Alertas y comportamiento de actividad para el desencadenante de eventos

Alertas de flota vs. dispositivo

Las ejecuciones de flujo de trabajo activadas por alertas se reflejan en la pestaña de Actividad de WXP. Comportamiento de actividad basado en el tipo de alerta:

• Alerta a nivel de flota: Las ejecuciones se muestran cuando se activa una alerta en una flota de dispositivos.

• Alerta a nivel de dispositivo: Las ejecuciones se registran individualmente para cada dispositivo

• Nota:

  • Si una alerta ya está activa antes de publicarse, esos dispositivos se incluyen en la audiencia del flujo de trabajo.

  • Si una regla de alerta cambia, es decir, la sección "Condiciones de activación" de la regla se actualiza, puede desencadenar nuevas ejecuciones.

Edición del público

• La edición solo se soporta para flujos de trabajo basados en horarios que usan disparadores basados en fechas.

• No se admite la edición de audiencia para flujos de trabajo basados en eventos una vez publicados.

Reglas de edición

Las siguientes reglas se aplican según el estado del flujo de trabajo:

1. El flujo de trabajo está activo (recurrente, tiempo de inicio pasado)

• Público: En esta etapa, el público es editable.

• Grupos:

  • Añadir grupos: Si se añaden grupos, se incluyen en ejecuciones actuales (si no se completan) y en futuras. Esta acción puede verse en la pestaña Actividad , que muestra el usuario que creó el grupo y la marca de tiempo de la creación del grupo.

  • Eliminación de grupos: Si se eliminan grupos, se eliminan de los dispositivos restantes en la ejecución actual y de las ejecuciones futuras. No se eliminan de los dispositivos donde se ha completado la ejecución. Esta acción también puede verse en la pestaña Actividad .

2. El flujo de trabajo está activo (el tiempo de inicio no ha pasado)

El público aún puede ser editado. Cualquier cambio que se haga se aplicará a la próxima partida. Todas las acciones se registran con los datos del usuario y la hora de la actualización.

3. El flujo de trabajo está activo (Una vez, Hora de Inicio Pasada)

La audiencia está bloqueada y el flujo de trabajo finalizado.

Visualización de los estados de los flujos de trabajo

Puedes ver el estado en la página de Flujos de Trabajo de WXP.

Se admiten los siguientes estados.

Revisión de KPIs de flujo de trabajo

Después de publicar un flujo de trabajo, puedes acceder a sus KPIs haciendo clic en el nombre del flujo de trabajo en la página e de la Lista de Flujo de Trabajo y luego navegando a la pestaña de Actividad en la página de Detalles del Flujo de Trabajo. Los KPIs se muestran en la pestaña de Ejecuciones.

Revisión del estado de ejecución

Una vez publicado un flujo de trabajo, puedes acceder a los estados de ejecución haciendo clic en el nombre del flujo de trabajo en la página de la lista de flujos de trabajo y luego navegando a la pestaña de Actividad. Las ejecuciones se muestran en una tabla.

Estado del nivel de ejecución (por ejecución)

• En progreso: Mismo criterio que antes

• Completado: Terminado o resuelto

• Cancelado: Flujo de trabajo cancelado antes de la ejecución

Revisión de KPIs a nivel de dispositivo

Estado a nivel de dispositivo (dentro de una ejecución de flujo de trabajo)

El estado a nivel de dispositivo indica si un dispositivo individual completó con éxito todos los pasos de un flujo de trabajo o si encontró un problema durante la ejecución. Esto se accede tras la publicación haciendo clic en el nombre del flujo de trabajo en la página de lista de flujos de trabajo > la pestaña de Actividad > Ejecución (en caso de una alerta a nivel de dispositivo, los dispositivos se tratarán como una ejecución).

Una vez publicado un flujo de trabajo, puedes acceder al estado a nivel de dispositivo haciendo clic en el nombre del flujo de trabajo en la página de lista de flujos de trabajo > pestaña de Actividad > Ejecución. Para las alertas a nivel de dispositivo, cada dispositivo se trata como una ejecución separada.

Nota: Si un dispositivo encuentra un error fatal en cualquier paso, no continuará con los siguientes pasos del flujo de trabajo.

Tipos de estado

Se soportan los siguientes estados a nivel de dispositivo:

Nota:

• Los resultados de la ejecución del dispositivo son visibles en la pestaña Actividad .

• Las ejecuciones solo aparecen cuando ocurren

  • Los flujos de trabajo recurrentes no mostrarán las ejecuciones futuras con antelación

• Los análisis a nivel de dispositivo ayudan a identificar:

  • Puntos de fallo

  • Dispositivos offline

  • Cuellos de botella en la ejecución

Casos de uso del Workflow Builder

1. Creación de un ticket de ServiceNow a partir de una alerta

• Escenario: Tu organización quiere crear automáticamente un incidente de ServiceNow (SNOW) cuando se activa una alerta específica en HP WXP.

• Solución: Utiliza un disparador basado en eventos (Alerta) seleccionando la alerta correspondiente. Por ejemplo: estado de salud del dispositivo, fallo de la app, problemas de rendimiento)

  • Acción: Añade una acción de Webhook  y configura el webhook para que se integre con tu endpoint de ServiceNow. Asegúrate de que la carga útil del webhook incluya detalles clave del dispositivo (como el número de serie del dispositivo) para facilitar la creación y seguimiento precisos de tickets. Puedes rellenar dinámicamente estos campos usando nuestra lista de Variables , que proporciona acceso a:

    • Variables globales, como atributos a nivel de dispositivo.

    • Salidas escalonadas, como resultados de scripts o salidas de acciones anteriores

El uso de estas variables garantiza un formato consistente y permite integraciones más ricas y conscientes del contexto (como los tickets de ServiceNow).

• Resultado:

  • Cuando se activa la alerta, se crea automáticamente un ticket de ServiceNow por dispositivo.

  • Respuesta a incidentes más rápida sin intervención manual

Nota: Asegúrate de que las cargas útiles de webhook se prueben de antemano para validar los mapeos de campo y la creación de tickets en ServiceNow.

2. Remediación automatizada + Venta de tickets por fallos de PowerPoint

• Escenario: Una alerta indica que los fallos de PowerPoint están afectando a un porcentaje de tu flota. Tu organización quiere remediar automáticamente los dispositivos afectados y crear tickets solo para fallos.

• Solución: Utiliza un disparador basado en eventos (Alerta). Por ejemplo, PowerPoint se cierra y afecta al X% de dispositivos.

  1. Acción 1: Ejecutar una acción de script para actualizar los dispositivos afectados a la última versión de Microsoft Office.

     1. Lógica de ramificación (si/entonces):

        1. Evalúa el resultado del guion:

           1. Si código de salida = 0 (éxito del guion):

              1. Fin del flujo de trabajo (problema resuelto)

           2. Si no, (suspendido):

              1. Proceder al siguiente paso

  2. Acción 2 – Webhook (Ticket ServiceNow):

     1. Activa un webhook para crear un ticket de ServiceNow, si los dispositivos están bajo la condición Else (es decir, fallido)

        1. Incluye:

           1. Detalles del dispositivo

           2. Salida de script (para resolución de problemas)

• Resultado:

  • Los dispositivos se remedian automáticamente a gran escala

  • Solo los dispositivos que fallan generan tickets, reduciendo el ruido

  • Los equipos de TI se centran en las excepciones en lugar de en toda la flota

Beneficios clave en todos los casos de uso

• Reduce la creación manual de tickets

• Automatiza la remediación antes de la escalada

• Minimiza el volumen de tickets en ServiceNow

• Mejora el tiempo de respuesta y la experiencia del usuario final

Recursos relacionados

Para más información, consulte el artículo Resumen del flujo de trabajo .