Abril de 2022

18 de abril de 2022

Suporte para conexões com várias contas

Observação: essa funcionalidade está disponível apenas em espaços de trabalho pessoais.

Para acomodar projetos de automação em conexões com várias contas, implementamos uma nova funcionalidade que permite que proprietários de espaços de trabalho vejam essas contas e especifiquem uma delas para iniciar o trabalho. Você pode alterar a conta na aba Requisitos do pacote ao criar um processo ou editar um já existente. Um menu suspenso está disponível para cada conexão com várias contas, permitindo ver a lista completa de contas disponíveis e alterar a conta ativa conforme necessário.

Para gerenciar suas conexões ou adicionar novas, acesse o Integration Service clicando no botão .

Saiba mais sobre conexões no guia do Integration Service.

Da autenticação baseada em cookies à autenticação baseada em tokens

Migramos da autenticação baseada em cookies para a autenticação baseada em tokens. Após essa alteração, as tentativas de logon do usuário não são mais salvas no Orchestrator. Como resultado, o endpoint /odata/UserLoginAttempts({key}) e a seção Tentativas de logon correspondente na página Meu perfil do Orchestrator foram descontinuados e só retornam tentativas de logon feitas antes dessa alteração (ou seja, tentativas de logon com cookies). A partir de agora, as tentativas de logon feitas usando tokens de acesso podem ser acessadas exclusivamente via logs de auditoria no Automation Cloud. Entre em contato com o seu administrador para solicitar esses dados.

A autenticação baseada em tokens altera a maneira como o Orchestrator computa a última hora de logon de um usuário. A partir de agora, a última hora de logon é computada uma vez por hora para um usuário usando ativamente o Orchestrator.

Digamos que um usuário esteja usando o Orchestrator entre 14:10 e 15:00. Tendo sido autenticado às 14:10 significa que 14:10 é exibido como sua última hora de logon até a próxima verificação a cada hora. Usar o Orchestrator até 16:00 significa que 15:10 é exibido como a última hora de logon do usuário.

Aqui estão os locais na interface gráfica do Orchestrator onde você pode ver as alterações em como computamos a última hora de logon para os seus usuários:

• Página Atribuir funções (Tenant > Gerenciar acesso)

• Página Espaços de trabalho pessoais (Tenant > Pastas > Espaços de trabalho pessoais)

  Observação: como uma exceção para a nossa cadência típica de versões, esse recurso não fica disponível para usuários Enterprise uma semana após a data de lançamento da versão Community. Em vez disso, ele será disponibilizado aos usuários Enterprise na semana de 2 de maio.

Como autorizar chamadas de API no Swagger

Agora, é possível autorizar chamadas de API na interface gráfica do Swagger usando o OAuth2.

Consulte como obter um token de acesso, enviar solicitações ou revogar acesso.

Outras melhorias

Orquestração com robô elásticos

• Agora, adicionar um pool de robôs elásticos a uma pasta também adiciona o pool às subpastas. Dessa forma, qualquer trabalho de subpastas também pode ser executado usando a orquestração de robôs elásticos.
• Eliminados a restrição de ter apenas um pool por pasta. Sinta-se livre para escalar!

CyberArk CCP

• O Orchestrator agora é compatível com certificados .cer como os certificados de CA de raiz do servidor.
• Os erros de configuração de certificado agora contêm mais detalhes sobre a causa do problema.

5 de abril de 2022

Cloud Robots - Serverless (pré-visualização)

Esta funcionalidade está disponível apenas para usuários Community.

Já imaginou como seria sua vida se não houvesse a necessidade de se preocupar com a infraestrutura na qual suas automações são executadas?

Nos últimos dois meses, tornamos nossa prioridade fazer isso acontecer e, hoje, apresentamos os robôs do UiPath Automation CloudTM - Serverless, ou Cloud Robots - Serverless para abreviar.

Esses robôs de nuvem sem servidor facilitam a execução da automação em segundo plano, dispensando a preocupação com qualquer infraestrutura necessária.Eles fornecem total liberdade de provisionamento, gerenciamento, manutenção e dimensionamento de qualquer infraestrutura subjacente. A UiPath cuida de todo o trabalho nos bastidores, assim você não precisa lidar com contêineres, máquinas virtuais ou servidores físicos.

Conheça mais sobre os Automation Cloud Robots - Serverless e acesse instruções de como configurá-los.

4 de abril de 2022

Alterações de funções, edição da API

API: novo endpoint para atribuir funções

Um novo endpoint está agora disponível na API do Orchestrator para atribuir funções ou substituir as funções atribuídas para uma conta existente:

POST /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles

Esse endpoint é uma versão aprimorada se comparado aos nossos endpoints existentes de Usuários, porque atribui funções com base no ID da função em vez do nome da função, tornando-o mais confiável.

O novo endpoint pode ser encontrado no Swagger da API do Orchestrator, disponível em <OrchestratorURL>/swagger.

Guia de API: atribuição de funções

API: alterações impactantes

Em decorrência de outras melhorias recentes em funções (detalhes aqui e aqui) que resultaram na mudança do nome de algumas funções, toda chamada de API que referencia uma função renomeada precisa ser atualizada para usar o novo nome da função.

Isso afeta:

• As chamadas de API relacionadas a uma versão personalizada de uma função padrão, que foi renomeada para Role name — Personalizada
  Importante: essas chamadas continuam a funcionar sem causar alterações, mas o resultado não é o esperado. Por exemplo, a chamada agora atribui a função padrão em vez da versão personalizada da função.

• As chamadas de API relacionadas à função antiga Tenant Administrator, que agora é chamada de Orchestrator Administrator.

  Essas chamadas falhavam com um erro devido à incapacidade de encontrar uma função com o nome especificado.

Endpoints afetados

As seguintes solicitações podem atribuir uma função com base no nome da função:

• POST /odata/Users
• PUT /odata/Users({key})
• PATCH /odata/Users({key})
• POST /odata/Users({key})/UiPath.Server.Configuration.OData.ToggleRole

Remediação

Para resolver esse problema, use o novo endpoint para atribuir funções com base no ID da função em vez do nome da função.

Há duas maneiras para atualizar suas integrações que foram afetadas por essa alteração para que funcionem conforme o esperado:

A. Adicione uma segunda chamada de API (recomendado)

Você pode deixar suas solicitações de API existentes como estão, mas, após cada chamada que atribui funções, faça uma nova chamada para o novo endpoint para substituir as funções atribuídas pelas corrigidas.

Por exemplo, se você tiver uma solicitação POST para /odata/Users para criar uma conta de administrador de tenant — ou seja, como parte da criação da conta, a solicitação tenta atribuir a função Tenant Administrator, que foi renomeada para Orchestrator Administrator — então, após ela, você deve fazer uma nova solicitação POST para /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles que passa o ID da função para a função Orchestrator Administrator para que seja atribuída corretamente.

Para esse método de remediação: é necessário identificar as solicitações afetadas em sua integração e, em seguida, para cada solicitação identificada:

1. Anote o ID do usuário e os nomes das funções a serem atribuídas pela solicitação afetada.
2. Faça uma solicitação GET para /odata/Roles para recuperar a lista atual de funções.
3. Anote os IDs para os nomes das funções que você anotou anteriormente.

4. (Opcional, mas recomendado) Em sua integração, atualize a solicitação afetada para remover a propriedade do nome de função.

   Com essa alteração, a solicitação não atribui mais funções e a solicitação na próxima etapa processará a atribuição de funções a partir de agora.

   Você pode optar por não remover a propriedade de função desta solicitação, porque a solicitação na próxima etapa substitui qualquer função atribuída.

5. Imediatamente após a solicitação afetada, adicione uma solicitação POST para /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles, incluindo os IDs das funções no corpo da solicitação.
   O valor {key} deve ser o ID do usuário da solicitação afetada.

Isso garante que toda função que a solicitação afetada que você identificou teria atribuído seja substituída imediatamente pela função correta.

B. Atualizar os nomes das funções

Um método de remediação mais fácil porém menos eficiente é atualizar as solicitações afetadas com os novos nomes das funções.

Observação: embora esse método seja mais fácil, recomendamos que considere utilizar o método anterior em vez desse, porque ele reforça sua integração contra quaisquer alterações posteriores nos nomes das funções.

Para esse método de remediação, é necessário identificar as solicitações afetadas em sua integração e, em seguida, para cada solicitação identificada:

1. Faça uma solicitação GET para /odata/Roles para recuperar a lista atual de funções.
2. Anote os nomes atuais das funções que as solicitações afetadas atribuem.
3. Em sua integração, atualize os valores da propriedade nome da função na solicitação afetada com os nomes atualizados das funções.

API: aviso de descontinuação

Devido às alterações recentes e por querermos reter nossa capacidade de atualizar funções no futuro sem impactar você, estamos anunciando nossa intenção de descontinuar o uso da propriedade do nome de função na API do Orchestrator.

Continuaremos dando suporte a essa propriedade por pelo menos seis meses a partir de agora.

No entanto, recomendamos que você comece a fazer a transição para o novo endpoint para atribuir funções para evitar alterações interruptivas após a descontinuação.

Melhorias

Aumentamos o número máximo de caracteres permitidos para nomes de função de 32 para 64 caracteres.

Errata de 2 de novembro de 2022: a carga do webhook jobs.created para Caso de Teste agora exibe o ID do Robô específico e máquina usada para executar o trabalho.

Correções de bugs

Adicionamos as permissões de Exibir em Robôs como um requisito para iniciar ou criar trabalhos em pastas modernas. Como resultado, o botão do trabalho Iniciar fica inativo até que as permissões necessárias sejam atribuídas, e isso é exibido na dica de ferramenta do botão. Anteriormente, quando você iniciava ou criava trabalhos em pastas modernas, a mensagem de erro You are not authorized! (#0) era exibida.