- Introdução
- Melhores práticas
- Modelagem de organização no Orchestrator
- Melhores Práticas de Automação
- Otimização da infraestrutura não assistida usando modelos de máquina
- Acessando a configuração do Unattended Robot
- Conceitos úteis na automação Unattended
- Como a automação Unattended é executada
- Organização de recursos com tags
- Réplica SomenteLeitura do Orchestrator
- Exportando grades em segundo plano
- Tenant
- Sobre o contexto do tenant
- Pesquisa de recursos em um tenant
- Gerenciamento de robôs
- Conectar Robôs ao Orchestrator
- Armazenamento de credenciais do robô no CyberArk
- Armazenamento de senhas do Unattended Robot no Azure Key Vault (somente leitura)
- Armazenamento de credenciais do Unattended Robot no HashiCorp Vault (somente leitura)
- Armazenando credenciais de Unattended Robots no AWS Secrets Manager (somente leitura)
- Exclusão de sessões não assistidas desconectadas e não responsivas
- Autenticação do robô
- Autenticação de robôs com credenciais de cliente
- Auditar
- Cloud Robots
- Contexto de Pastas
- Automações
- Processos
- Trabalhos
- Apps
- Gatilhos
- Logs
- Monitoramento
- Filas
- Ativos
- Armazenar Buckets
- Test Suite - Orchestrator
- Serviço Catálogo de recursos
- Autenticação
- Integrações
- Robôs Clássicos
- Solução de problemas
Conceitos úteis na automação Unattended
Automações Unattended dependem de vários componentes, e é útil compreendê-los. Os tópicos abaixo definem brevemente esses componentes, mas há mais detalhes disponíveis em cada etapa na qual os conceitos são usados.
Contas de Robots são úteis quando você precisa executar processos Unattended de back-office que não devem ser da responsabilidade de qualquer usuário específico. Esses são nossos equivalentes específicos de RPA de contas de serviço. Similares às contas que os serviços do Windows executam como identidades de aplicativos no modelo OAuth, elas são uma identidade sem usuário a ser usada para executar processos Unattended. Isso as torna ideais para operações altamente privilegiadas que precisam de credenciais.
Descubra como adicionar uma conta de Robot ao On-Premises Orchestrator.
Descubra como adicionar uma conta de Robot ao Cloud Orchestrator.
Quando você atribui uma conta de robô a uma pasta pai em uma hierarquia de pastas, a conta de robô obtém acesso automaticamente (com as funções atribuídas ao nível da pasta pai) a todas as subpastas criadas na pasta específica. Novas permissões podem ser adicionadas na subpasta acima daquelas atribuídas no nível da pasta pai, mas as funções herdadas não podem ser removidas. É possível que uma conta de Robot tenha um nível de acesso maior no nível da subpasta do que no nível da pasta pai, mas a recíproca não é verdadeira.
Conceder a uma conta de Robot acesso apenas a uma subpasta é possível, atribuindo-a diretamente no nível da subpasta. Dessa forma, a conta de Robot não terá visibilidade no nível pai, mas poderá acessar todos os recursos na subpasta e abaixo dela, de acordo com a definição da função atribuída. Atribuir uma conta de Robot no nível da subpasta não concede a ela acesso aos irmãos da pasta, ou seja, a outras pastas do mesmo nível, a menos que ela também seja explicitamente atribuída às outras pastas do mesmo nível, ou, se ela for atribuída no nível pai (o que lhe concederia acesso a todas as pastas abaixo dela, conforme mencionado anteriormente).
Se recursos de outras pastas forem necessários para executar os processos na pasta atual, você precisará assegurar que todas as contas de Robots sob as quais os processos específicos serão executados também sejam atribuídas como contas de Robots das pastas nas quais o restante dos recursos está localizado, com permissões suficientes para poder acessar/criar/modificar/excluir os recursos dessas pastas, conforme exigido pelos processos.
Você pode gerenciar várias contas de Robots adicionando-as a um grupo. Grupos são uma coleção de contas que devem ter acesso, configuração de Robots e necessidades de licenciamento semelhantes, e que você quer gerenciar em conjunto. Portanto, é recomendável agrupar apenas contas de Robots que compartilham as mesmas configurações e casos de uso. Por exemplo, se você tiver cinco contas de Robots que lidam com automações em primeiro plano em máquinas do Windows e 10 contas de Robots que lidam com automações em segundo plano em máquinas do Linux, você adicionaria cada categoria a seu próprio grupo, mas nunca as combinará.
Grupos podem ser muito úteis para aproveitar a escalabilidade no contexto de implantação de Robots e controle de permissões, eliminando, assim, a necessidade de configuração individual de contas de Robots.
Descubra como adicionar grupos ao On-Premises Orchestrator.
Descubra como adicionar grupos ao Cloud Orchestrator.
O UiPath Robot é a entidade de execução da UiPath®. Ele pode ser executado no modo de serviço ou no modo de usuário, dependendo do tipo de automação.
O Robô de Modo de Serviço é mais adequado em cenários de automação não assistida e implantações de plataforma de larga escala. Quando um processo é executado, o Executor do Robô é executado com os mesmos direitos que o usuário no qual ele está registrado.
O Serviço de Robôs da UiPath é o cérebro por trás de todas as operações realizadas durante a execução, e para execuções não assistidas, ele é iniciado no Sistema Local. Ele pode abrir sessões interativas do Windows e tem todos os direitos de um administrador de máquina. Assim, ele habilita o gerenciamento automático de sessão (como logon e logoff) para trabalhos não assistidos.
A instalação do Robot usando o UiPathStudio.msi implanta o Robot no modo de serviço por padrão. Ele também pode ser instalado a partir do Prompt de Comando.
A automação Unattended funciona melhor com Robots no modo de serviço instalados sob o sistema local. Unattended Robots também podem ser executados sob o usuário local (Robots no modo de usuário), mas essa não é a abordagem recomendada, já que o Robot não pode ser executado a menos que esse usuário específico tenha feito login nessa máquina.
O Robô de Modo de Serviço é instalado para todos os usuários de uma máquina. Quando o Robô de Modo de Serviço é instalado em máquinas do Windows Server, você pode executar trabalhos simultâneos não assistidos com o gerenciamento automático de sessão. Isso representa um cenário perfeito de automação não assistida É possível ter trabalhos simultâneos com o Robô de Modo de Usuário em um Windows Server, mas não o gerenciamento automático de sessão.
O Robot no modo de usuário é mais adequado em cenários de automação Attended. Ele é executado sob o usuário que o inicia, e tem os mesmos direitos daquele usuário específico.
Escolher a opção de instalação rápida no instalador do .msi implanta o Robot no modo de usuário por padrão.
O UiPath Assistant é a interface de seu Robot, permitindo que você interaja com projetos criados no Studio.
Entretanto, em cenários Unattended, o UiPath Assistant é usado apenas para fins de depuração, em casos em que um usuário se conecta à máquina Unattended para procurar e corrigir possíveis problemas.
Modelos de máquina são o tipo de máquina recomendado para automações Unattended. Os modelos de máquina facilitam a implantação de várias máquinas do host ao definir a configuração uma vez e, então, permitir que vários Robots se conectem ao Orchestrator. Eles habilitam você para conectar UiPath Robots implantados em várias máquinas do host no Orchestrator, independentemente dos nomes das máquinas do host ou dos usuários que fazem login nelas.
Modelos de máquina, como o seu nome sugere, funcionam como modelos cujas configurações se aplicam a grupos de máquinas de host com a mesma configuração física. Várias máquinas do host podem ser conectadas facilmente ao mesmo modelo por meio de uma chave ou de um conjunto de credenciais do cliente. A chave ou as credenciais do Robot são usadas por Robots para fazer login em máquinas do host e acessar recursos do Orchestrator.
Ao agrupar máquinas de host no mesmo modelo de máquina, recomendamos seguir estas práticas:
-
implantar as máquinas de host com base em um modelo compartilhado, ou pelo menos configurá-las como se compartilhassem um.
-
os mesmos aplicativos devem ser instalados nas máquinas; também é importante que eles sejam instalados nos mesmos caminhos em cada uma das máquinas e que compartilhem a mesma versão de aplicativo.
-
todos os usuários que fazem logon nos aplicativos nessas máquinas devem ter os mesmos direitos de acesso para esses aplicativos presentes nelas.
Um aspecto importante a ter em mente é que o algoritmo para iniciar automações Unattended pode iniciar um trabalho sob qualquer um dos usuários atribuídos a uma pasta (a menos que um usuário específico esteja selecionado manualmente) e, claro, em qualquer máquina do host atribuída ao modelo de máquina. Portanto, é importante que todas as contas que podem ser selecionadas para execução tenham uma conta correspondente em todas as máquinas atribuídas a essa pasta. Caso contrário, provavelmente ocorrerão erros. Para evitar isso, é importante garantir que os usuários que você deseja emparelhar com um modelo de máquina específico tenham sido criados em todas as máquinas no modelo ou que tenham modelos separados, cada uma com menos máquinas e os usuários associados, de modo que apenas combinações válidas sejam definidas para cada pasta.
Você tem as seguintes entidades:
-
Pasta F1 contendo
-
contas de Robots R1, R2, R3
-
modelo de máquina T1
-
-
Modelo de máquina T1 conectado às máquinas do host M1 e M2
Nesse cenário, você precisa garantir que tanto M1 quanto M2 tenham contas definidas com as mesmas credenciais como contras dos Robots R1, R2 e R3. Dessa forma, a automação pode ser executada sob qualquer combinação de Robot-máquina.
AllUsers
, ContactCenter
e ContactCenter_ITIssues
, então esse usuário compartilhará a mesma configuração que o restante dos usuários no ContactCenter_ITIssues
, e também deve compartilhar o mesmo modelo de máquina do Orchestrator do restante dos usuários acima mencionados. Também é aconselhável que sejam criados modelos de máquina, se possível, de acordo com a estrutura do Active Directory existente.
Para executar automações Unattended usando Unattended Robots, você precisa de uma licença de serviço dedicada. Isso é chamado de um runtime e é atribuído a um objeto de máquina usado para executar processos Unattended. Para fazer isso:
-
No nível do tenant, acesse Máquinas.
-
Selecione a máquina desejada e clique em Mais ações.
-
Na seção Detalhes dos runtimes, insira um número ou use a seta para cima para inserir um número de runtimes no campo Production (Unattended).
O número de runtimes atribuídos a um objeto de máquina representa a capacidade de execução de automações em cada máquina do host que está associada ao objeto de máquina simultaneamente. No que diz respeito à automação Unattended, o objeto de máquina preferido é o modelo de máquina.
Os runtimes são alocados no nível do tenant e, dessa forma, constituem o pool de runtimes do tenant. Quando uma máquina do host se conecta ao UiPath Orchestrator, o número de runtimes atribuídos ao seu objeto de máquina associado é recuperado do pool de tenants. O runtime é consumido durante a execução de um processo na máquina. Quando a máquina de host se desconecta, os runtimes retornarão ao pool do tenant.
Exemplo 1
Você tem um modelo de máquina ao qual você atribui três runtimes Unattended:
-
Se você conectar uma máquina do host a esse modelo de máquina, você pode executar três automações na máquina do host.
-
Se você conectar três máquinas do host a esse modelo de máquina, você pode executar três automações em cada uma das três máquinas do host, portanto, um total de nove automações.
Ao atribuir runtimes a um modelo de máquina, certifique-se de atribuir um número suficiente deles para cobrir todas as execuções Unattended/Testing/Nonproduction que podem acontecer simultaneamente em todas as pastas nas quais o modelo de máquina está definido. Isso também requer ter máquinas suficientes conectadas para cobrir todas as execuções simultâneas.
Exemplo 2
Você tem:
-
Dez trabalhos Unattended agendados para começar simultaneamente na Pasta A
-
Cinco trabalhos Unattended agendados para serem executados simultaneamente na Pasta B (sobrepondo-se aos 10 definidos na Pasta A)
-
um modelo de máquina, TemplateAB, atribuído tanto à Pasta A quanto à Pasta B
Então, você terá que atribuir 15 runtimes Unattended ao TemplateAB e, na verdade, terá 15 máquinas idênticas disponíveis e conectadas à chave da máquina do TemplateAB para assegurar que a execução seja possível para todos os agendamentos definidos.
A única exceção à regra acima são os processos em segundo plano, onde você precisa de runtimes suficientes atribuídos a seu modelo para todas as suas execuções de processos simultâneas, mas não tantas máquinas do host conectadas ao modelo, já que você pode executar praticamente tantos processos em segundo plano quantos precisar na mesma máquina, mas apenas um processo em primeiro plano (processo que requer a interface gráfica) ao mesmo tempo.
Exemplo 3
Para 10 processos em segundo plano simultâneos e um processo em primeiro plano, apenas uma máquina do host conectada a um modelo é suficiente, mas esse modelo específico precisa ter 11 runtimes atribuídos a ele. Se, entretanto, um segundo processo em primeiro plano for adicionado e ele tiver que ser executado ao mesmo tempo em que o primeiro processo em primeiro plano que foi definido, ou se o primeiro processo em primeiro plano precisar ser executado duas vezes simultaneamente, será necessária uma segunda máquina conectada ao modelo de máquina para que a execução de ambas as instâncias do processo em primeiro plano seja possível.
A seção Camadas dos Robots do Portal de Licenciamento da UiPath mostra a lista completa de runtimes disponíveis.
Os processos se baseiam em pacotes de automação do Studio. Eles são um recurso por pasta e só podem ser executados nas pastas nas quais foram implantados. Entretanto, eles podem ser iniciados por processos em outras pastas, desde que os usuários nessas pastas específicas tenham as permissões necessárias na pasta na qual o processo desejado está implantado.
Há dois tipos de processos com os quais você pode trabalhar:
-
Processos em segundo plano não necessitam de interações com a interface do usuário ou de intervenção humana.
-
Processos em primeiro plano precisam ser iniciados e/ou gerenciados na interface do usuário e só podem ser executados um de cada vez.
Observações:
-
Cada execução de um processo assim consome um runtime Unattended/NonProduction.
-
Você pode executar vários processos em segundo plano e um processo em primeiro plano simultaneamente.
Ao criar um projeto no Studio, os desenvolvedores devem configurar um atributo de compatibilidade que afeta a estrutura de destino subjacente do projeto de automação e do sistema operacional compatível. Isso está definido no Studio, no campo Compatibilidade.
A tabela a seguir mostra a versão do UiPath Robot necessária para executar processos de acordo com suas estruturas de destino e considerações sobre a compatibilidade do sistema operacional:
Estrutura de destino |
Sistema Operacional |
no mínimo 2021.8 |
.NET Framework 4.6.1 |
Windows - Legacy |
Qualquer |
.NET 5.0 ou superiores |
Windows |
2021.10+ |
.NET 5.0 ou superiores |
Multiplataforma |
2021.10+ |
Configurações de modelos de máquina
A UiPath pode gerenciar o pool de Robots em seu nome, no Automation Cloud, permitindo que você escolha tanto seu próprio nível de envolvimento quanto aquele que você atribui a nós.
Você pode se beneficiar desse funcionalidade criando um dos seguintes tipos de máquinas (nível do tenant > Máquinas > Adicionar máquina):
-
Pool de Elastic Robots - os Robots são gerenciados pela UiPath, e você decide o quanto do processo de orquestração você deseja terceirizar.
-
Cloud Robot - VM - a UiPath lida com o processo de orquestração e fornece a você uma máquina virtual na qual executará automações.