Introdução

O recurso Workflow no HP Workforce Experience Platform (WXP) é uma capacidade de orquestração de fluxos de trabalho low-code projetada para remediação em larga escala de TI. Ele permite que administradores de TI implantem fluxos de trabalho automatizados em milhares de endpoints usando uma interface visual de arrastar e soltar, ajudando as equipes a transitar do tratamento reativo de tickets para a remediação proativa.

Dependências e Pré-requisitos

Requisito de Script para Ramificação

• Os scripts devem ser testados antes. A saída de script é usada para:

  • Lógica de ramificação

  • Cargas úteis / parâmetros de consulta do Webhook

• Webhook deve ser testado antes. Atualmente, suportamos apenas entradas JSON e saídas em texto simples OU JSON.

Requisitos de Plataforma e Versão

Certifique-se de que os seguintes requisitos sejam atendidos antes de criar fluxos de trabalho:

Criando um Fluxo de Trabalho

Passo 1: Adicionando um gatilho

Todo fluxo de trabalho deve começar com um gatilho:

1. Faça login na WXP. A página inicial é exibida.

2. No menu esquerdo do WXP, clique em Labs. A página de Laboratórios é exibida.

3. Na página de Laboratórios , role até a seção de Fluxo de Trabalho e clique em Tentar Fluxo de Trabalho. O fluxo de trabalho que sai é exibido.

   

4. Clique em Adicionar para criar um novo fluxo de trabalho. A caixa de diálogo Adicionar fluxo de trabalho é exibida.  

   

5. Na caixa de diálogo Adicionar fluxo de trabalho , você pode criar um novo fluxo de trabalho do zero ou duplicar e modificar um fluxo de trabalho existente.

   

6. Ao criar do zero, acione um evento:

   1. Gatilho de Evento (Baseado em alerta): O fluxo de trabalho é iniciado quando ocorre um alerta. As opções de alerta disponíveis incluem os alertas existentes que são criados ou fornecidos na plataforma.

   2. Gatilho de Programação: Os administradores podem definir a data, hora e grupos-alvo para o fluxo de trabalho. As opções de grupos exibidas são baseadas nos grupos criados na plataforma WXP.

   

Passo 2: Adicionando Ações

Após adicionar um gatilho, você pode adicionar uma ou mais ações para definir o que o fluxo de trabalho deve fazer.

• Script:  As opções de script exibidas são os scripts pré-existentes que são criados no WXP ou fornecidos pelo WXP.

• Webhook: Integre com sistemas terceiros, como ServiceNow, Teams e Slack. Configure seu webhook manualmente ou através da URL do endpoint da API Swagger. Testes são necessários antes que o webhook seja usado em um fluxo de trabalho.

• Ação do dispositivo: Uma ação do dispositivo pode ser usada para realizar atualizações de drivers, tais como:

  • Implantação de todas as atualizações de drivers

  • Implantando apenas atualizações críticas de drivers

  • Implantação total ou de atualizações críticas de drivers para categorias selecionadas de drivers

Passo 3: Adição de Lógica de Ramificação

Use condições if/then/else para criar caminhos lógicos avançados. O ramificação pode ser baseado nas saídas de scripts, webhooks ou atualizações de drivers.

Limitações Atuais

• Ramificação aninhada não é suportada

  • Um ramo colocado antes ou depois de outro ramo é tratado como separado — não aninhado

• Você não pode adicionar ações após um ramo

Comportamento de fuso horário para o gatilho de cronograma

Esse comportamento só se aplica ao gatilho de agendamento. Ao criar um fluxo de trabalho, o horário agendado é definido no fuso horário do seu criador. No entanto, a execução ocorre no fuso horário local de cada dispositivo alvo. Por exemplo, se você agendar um fluxo de trabalho para 9:00 AM PST; os dispositivos no EST executarão o fluxo de trabalho às 12:00 EST. Isso ajuda a garantir que os fluxos de trabalho sejam executados no horário local pretendido para cada destinatário, independentemente de onde estejam localizados.

Alertas e Comportamento de Atividade para Gatilhos de Eventos

Alertas de Frota vs. Dispositivo

Execuções de workflow acionadas por alertas são refletidas na aba Atividade do WXP. Comportamento de atividade baseado no tipo de Alerta:

• Alerta em nível de frota: Execuções são mostradas quando um alerta é acionado em uma frota de dispositivos.

• Alerta em nível de dispositivo: As execuções são acompanhadas individualmente para cada dispositivo

• Nota:

  • Se um alerta já estiver ativo antes da publicação, esses dispositivos são incluídos no público do fluxo de trabalho.

  • Se uma regra de alerta mudar, ou seja, a seção "Condições de Disparo" da regra for atualizada, isso pode desencadear novas execuções.

Editando o Público

• A edição é suportada apenas para fluxos de trabalho baseados em agendamento que utilizam gatilhos baseados em datas.

• A edição de audiência não é suportada para fluxos de trabalho baseados em eventos após a publicação.

Regras de edição

As seguintes regras se aplicam com base no status do fluxo de trabalho:

1. Fluxo de trabalho ativo (recorrente, tempo de início passado)

• Público: Neste estágio, o público é editável.

• Grupos:

  • Adicionar Grupos: Se grupos forem adicionados, eles são incluídos em execuções atuais (se não concluídas) e futuras. Essa ação pode ser visualizada na aba Atividade , que mostra o usuário que criou o grupo e o carimbo de data de criação do grupo.

  • Remoção de Grupos: Se grupos forem removidos, eles são removidos dos dispositivos restantes na execução Atual e das execuções Futuras. Eles não são removidos dos dispositivos onde a execução é concluída. Essa ação também pode ser vista na aba Atividade .

2. O fluxo de trabalho está ativo (O tempo de início não passou)

O público ainda pode ser editado. Quaisquer mudanças feitas se aplicarão à próxima corrida. Todas as ações são registradas com os dados do usuário e o carimbo de data da atualização.

3. Fluxo de trabalho ativo (Uma Vez, Tempo de Início Passado)

O público está bloqueado e o fluxo de trabalho é finalizado.

Visualizando Status de Fluxo de Trabalho

Você pode ver o status na página de listagem de Workflows do WXP.

Os seguintes status são suportados.

Revisando KPIs de Fluxo de Trabalho

Após a publicação de um fluxo de trabalho, você pode acessar seus KPIs clicando no nome do fluxo de trabalho na página e da Lista de Workflow e navegando até a aba Atividade na página Detalhes do Workflow. Os KPIs são exibidos na aba Execuções.

Revisando os Status de Execução

Após a publicação de um fluxo de trabalho, você pode acessar os status de execução clicando no nome do fluxo de trabalho na página da lista de Workflow e então navegando até a aba Atividade. As execuções são exibidas em uma tabela.

Status do Nível de Execução (Por Execução)

• Em andamento: Mesmo critério de acima

• Concluído: Finalizado ou resolvido

• Cancelado: Fluxo de trabalho cancelado antes da execução

Revisão de KPIs em Nível de Dispositivo

Status em nível de dispositivo (dentro de uma execução de fluxo de trabalho)

O status em nível de dispositivo indica se um dispositivo individual completou com sucesso todas as etapas de um fluxo de trabalho ou encontrou algum problema durante a execução. Isso é acessado após a publicação clicando no nome do fluxo de trabalho na página da lista de workflow > na aba Atividade > Execução (no caso de um alerta em nível de dispositivo, você verá dispositivos tratados como uma execução).

Após a publicação de um fluxo de trabalho, você pode acessar o status em nível de dispositivo clicando no nome do fluxo de trabalho na página da lista de Workflow > aba Atividade , > Execução. Para alertas em nível de dispositivo, cada dispositivo é tratado como uma execução separada.

Nota: Se um dispositivo encontrar um erro fatal em qualquer etapa, ele não avançará para etapas subsequentes do fluxo de trabalho.

Tipos de status

Os seguintes status são suportados no nível do dispositivo:

Nota:

• Os resultados da execução do dispositivo são visíveis na aba Atividade .

• Execuções só aparecem quando ocorrem

  • Fluxos de trabalho recorrentes não mostram execuções futuras antecipadamente

• Insights em nível de dispositivo ajudam a identificar:

  • Pontos de falha

  • Dispositivos offline

  • Gargalos de execução

Casos de Uso do Construtor de Fluxos de Trabalho

1. Criando um Ticket ServiceNow a partir de um alerta

• Cenário: Sua organização quer criar automaticamente um incidente do ServiceNow (SNOW) quando um alerta específico é acionado no HP WXP.

• Solução: Use um gatilho baseado em evento (Alerta) selecionando o alerta relevante. Por exemplo: saúde do dispositivo, falha do aplicativo, problema de desempenho)

  • Ação: Adicione uma ação Webhook  e configure o webhook para integrar com seu endpoint ServiceNow. Certifique-se de que a carga útil do webhook inclua detalhes importantes do dispositivo (como o número de série do dispositivo) para apoiar a criação e o rastreamento precisos de tickets. Você pode preencher dinamicamente esses campos usando nossa lista de variáveis , que oferece acesso a:

    • Variáveis globais, como atributos em nível de dispositivo.

    • Resultados em etapas, como resultados de script ou saídas de ações anteriores

O uso dessas variáveis garante formatação consistente e possibilita integrações mais ricas e conscientes do contexto (como os tickets ServiceNow).

• Desfecho:

  • Quando o alerta é acionado, um chamado ServiceNow é criado automaticamente por dispositivo.

  • Resposta a incidentes mais rápida sem intervenção manual

Nota: Certifique-se de que as cargas úteis do webhook sejam testadas antecipadamente para validar mapeamentos de campos e criação de tickets no ServiceNow.

2. Remediação Automatizada + Chamados para Travamentos do PowerPoint

• Cenário: Um alerta indica que travamentos do PowerPoint estão afetando uma porcentagem da sua frota. Sua organização quer remediar automaticamente os dispositivos afetados e criar tickets apenas para falhas.

• Solução: Use um gatilho baseado em evento (Alerta). Por exemplo, travamentos do PowerPoint afetam X% dos dispositivos.

  1. Ação 1: Executar uma ação de script para atualizar os dispositivos afetados para a versão mais recente do Microsoft Office.

     1. Lógica de Ramificação (Se/Então):

        1. Avalie o resultado do roteiro:

           1. Se código de saída = 0 (sucesso do script):

              1. Fim do fluxo de trabalho (problema resolvido)

           2. Else (Reprovado):

              1. Prossiga para o próximo passo

  2. Ação 2 – Webhook (Ticket ServiceNow):

     1. Acione um webhook para criar um chamado ServiceNow, se os dispositivos estiverem sob a condição Else (ou seja, falhado)

        1. Inclua:

           1. Detalhes do dispositivo

           2. Saída de script (para solução de problemas)

• Desfecho:

  • Os dispositivos são automaticamente corrigidos em larga escala

  • Apenas dispositivos com falha geram chamados, reduzindo o ruído

  • As equipes de TI focam em exceções, e não em toda a frota

Principais benefícios em diferentes casos de uso

• Reduz a criação manual de tickets

• Automatiza a remediação antes da escalada

• Minimiza o volume de tickets no ServiceNow

• Melhora o tempo de resposta e a experiência do usuário final

Recursos Relacionados

Para informações adicionais, consulte o artigo Visão Geral do Fluxo de Trabalho .