Melhores práticas

Abordagens recomendadas para adotar o ScreenPlay em fluxos de trabalho de Automação de Interface Gráfica novos ou existentes e práticas para mantê-los rápidos e eficientes em escala.

Abordagens recomendadas para adotar o ScreenPlay, esteja você integrando-o a fluxos de trabalho de Automação de Interface Gráfica existentes ou criando novas automações orientadas por agentes e para manter essas automações rápidas e econômicas depois de executadas em escala.

Onde o ScreenPlay pertence em uma automação

O ScreenPlay é projetado para se destacar em pontos específicos de alto atrito, também conhecidos como cenários de agência controlados, representando áreas pequenas e críticas de automação onde as ferramentas tradicionais são mais frágeis. Em vez de substituir fluxos de trabalho inteiros, o ScreenPlay traz a execução por agentes para as partes que mais precisam deles:

• Seletores frágeis que quebram facilmente.
• Estruturas complexas de interface gráfica e elementos dinâmicos.
• Elementos de interface gráfica difíceis de alcançar, como pop-ups, listas virtualizadas, tabelas incorporadas ou controles personalizados.

O corolário é também importante. Na automação unattended, você precisa confiar em uma execução que não está observando, e as partes determinísticas de um fluxo de trabalho são as únicas que se comportam de forma idêntica todas as vezes. Eles também são os mais rápidos e mais barato de executar, que é o que os torna viáveis em milhares de execuções.

O objetivo é um fluxo de trabalho máxima determinista e mínimo de agentes: Automação de Interface Gráfica clássica onde a interface for estável e as etapas forem conhecidas, e o ScreenPlay onde a execução por agentes for a única maneira de atender de forma confiável à necessidade do negócio.

Introdução

Os caminhos a seguir estão disponíveis, dependendo de seu contexto.

Atualizando automações problemáticas

Você pode usar as atividades do ScreenPlay para corrigir etapas problemáticas do seu UIAutomation atual, como:

• Seletores que falham repetidamente.
• Automações que são interrompidas após alterações na interface do usuário.
• Lógica excessivamente complexa escrita para tarefas simples.

Você pode definir as ações que usa por meio de prompts de idioma natural em vez de seletores frágeis ou lógica longa e personalizada. Isso ajuda a simplificar o desenvolvimento e também a tornar sua automação mais resiliente ao longo do período.

Criando uma automação a partir do zero com granularidade

Se você iniciar um UIAutomation do zero, poderá criá-lo inteiramente usando o ScreenPlay com nível de detalhe.

Cada atividade do ScreenPlay deve corresponder a uma etapa pequena e com escopo bem definido em seu processo, idealmente duas ou três etapas que naturalmente se complementam.

Essa abordagem granular tem os seguintes benefícios:

• Maximiza a precisão.
• Mantém o agente focado.
• Evita sobrecarregar o modelo com muito contexto.

Dependendo da complexidade de cada etapa, você pode escolher o modelo de IA apropriado, equilibrando a eficiência de custo e a capacidade.

Criação com um agente de codificação

Você também pode criar a automação com um agente de codificação de IA usando as Habilidades do agente da UiPath, que ensinam ao agente a criar, executar, testar e implantar automações da UiPath a partir do seu ambiente de desenvolvimento. Para o catálogo e as instruções de instalação, consulte o repositório de Habilidades do agente da UiPath.

As habilidades de criação concentram-se na geração de RPA, portanto, o que o agente de codificação produz é determinístico por padrão, que é a linha de base que você deseja. A abordagem recomendada é revisar o fluxo de trabalho gerado e adicionar atividades ScreenPlay nos pontos em que a abordagem por agentes é necessária.

Essas adições devem permanecer deliberadas e em poucos. Cada um é um local onde o comportamento deixa de ser garantido e onde o tempo de execução e o consumo de tokens aumentam.

Projetando para velocidade e custo em escala

Uma automação que é executada algumas vezes por dia e uma que é executada milhares de vezes têm economia muito diferente. As práticas a seguir reduzem a latência e o consumo de tokens sem entregar a confiabilidade.

Mantendo a superfície agêntica pequena

Essa é a decisão de maior impacto e é tomada no momento do design, em vez de ajustada posteriormente. Cada etapa que pode ser expressa de forma determinista é uma etapa que não custa nenhuma chamada de modelo, não adiciona latência e não pode variar entre execuções.

A linha de base determinística vem em primeiro lugar, com etapas de agentes adicionadas apenas onde elas conquistam seu lugar.

Escolha do modelo certo para cada etapa

Os modelos disponíveis no menu suspenso Modelo continuam sendo mais rápidos e mais capazes ao mesmo tempo, portanto, velocidade e qualidade são muito menos compensadas do que costumavam ser.

Como cada atividade do ScreenPlay carrega sua própria seleção de modelos, você pode corresponder o modelo à dificuldade da etapa: um modelo de nível Básico rápido para interações de rotina, um modelo de nível Padrão para as etapas que realmente precisam de mais raciocínio. Para obter a lista completa de modelos disponíveis, consulte ScreenPlay.

Se sua automação foi criada com base em um modelo mais antigo, revisitar a seleção é uma das melhorias de velocidade mais barato disponíveis.

Agrupamento de várias ações na mesma tela

O recurso de agentes do ScreenPlay pode executar várias ações na mesma tela em um único lote, em vez de uma ação por chamada de modelo. Quanto menos idas e voltas do modelo significam menor latência de ponta a ponta, e a diferença é mais visível em telas densas de ação, como formulários longos.

Esse não é o comportamento padrão. Por padrão, o aproveitamento executa uma ação de cada vez, e o lote acontece apenas quando a solicitação da tarefa solicita explicitamente. O totalmente honrado por essas indicações quando as ações têm como alvo a mesma tela.

Por exemplo, em vez de:

Fill in the customer details form.

use:

Fill in the customer details form. Fill in all the fields visible on the screen in one go, then submit.

O lote aplica-se apenas a ações que podem ser executadas na tela visível no momento. As etapas que exigem navegação, uma transição de página ou uma alteração de aplicativo ainda são executadas sequencialmente, porque o modelo precisa observar a nova tela antes de decidir o que fazer em seguida.

Quando parar a otimização

A otimização apenas para tempo de execução e consumo de tokens pode levar você a implementações determinísticas que são frágeis e dispendiosas de manter ativas. Um fluxo de trabalho com muito seletor que interrompe cada pequena alteração na interface gráfica pode gastar mais ao longo de sua vida útil do que os tokens que economizou.

O Healing Agent limita essa lacuna, mas não a fecha. Suas estratégias de recuperação são um conjunto definido e limitado, e todas funcionam no nível da reidentificação de um elemento de destino para uma atividade que já existe:

• Atributos do seletor alterados.
• Tempo.
• Posição da âncora.
• Títulos do AppCard.
• O fallback do Seletor Semântico de tempo de design.

O Healing Agent também aplica estratégias baseadas em IA para:

• Pop-ups obstruindo o elemento de destino.
• Rótulos reformulados semanticamente.
• Computer Vision.

Isso cobre uma grande parte do desvio diário da interface gráfica, mas não pode consumir alterações na própria interação, como uma nova caixa de diálogo de confirmação, um conjunto reordenado de telas, um campo que se move para outra etapa ou um fluxo que agora requer uma sequência diferente de ações.

Habilitar o Healing Agent não é um substituto para projetar bem o fluxo de trabalho e não mantém uma implementação determinística frágeis indefinidamente ativa.

Para as partes de um aplicativo em que você espera esse tipo de mudança, o ScreenPlay é a melhor resposta. Descrever o resultado em linguagem natural e permitir que o agente processe a interação no runtime remove a carga de manutenção dessas etapas, ao custo da chamada do modelo. Vale a pena revisitar quais etapas exibição são dignas de tal tratamento à medida que os aplicativos de destino evoluem.