Considerações de instalação

Este artigo identifica as principais áreas afetadas das quais você deve estar ciente em uma nova implantação do Orchestrator. Deve-se cuidar de alguns dos itens abordados neste artigo antes de uma atualização/instalação. Vários deles são validados pelo instalador ou pela Ferramenta de Configuração de Plataforma, se você escolher usá-la. É altamente recomendável que você baixe e use a Ferramenta de Configuração da Plataforma para validar seu ambiente antes de uma atualização.

.NET 8

Estrutura de destino

Para manter a funcionalidade de Plug-ins de Armazenamento de Credenciais e de extensões do NLog, a TargetFramework deve ser atualizada em relação à .NET Framework 4.7.2 anterior para um estrutura de destino compatível. A estrutura de destino dos dois Armazenamentos de Credenciais e das extensões do NLog é verificada pelo instalador do UiPathOrchestrator.msi.

Essa restrição também se aplica a quaisquer referências que uma extensão de plug-in ou NLog possa ter.

Estruturas de destino compatíveis	Versões Compatíveis
.NET Standard	1.0 - 1.6
.NET Standard	2.0 (recomendado)
.NET	8.0

Dica:

Você pode precisar recompilar quaisquer plug-ins de Armazenamento de Credenciais e extensões do NLog que você desenvolveu internamente. Você pode precisar identificar e copiar para o diretório do Orchestrator, de outros arquivos .dll , de acordo com as estruturas de destino especificadas. A maioria dos destinos do NLog é compatível com as estruturas de destino especificadas; no entanto, você deve certificar-se de copiar o .dll correto. Por exemplo, se você usar NLog.Targets.Splunk, precisa baixar o arquivo .nupkg , abri-lo como .zip, navegar até a pasta lib\) etstandard2.0 e usar o arquivo .dll a partir de lá.

Plug-ins de repositório de credenciais — CyberArk

Em versões mais antigas do Orchestrator, o plug-in de armazenamento de credenciais do CyberArk usou uma biblioteca que não é compatível com o .NET Core. O Orchestrator agora usa a ferramenta CLIPasswordSDK64.exe, que vem com o AIM do CyberArk.

Dica:

O plug-in pesquisa CLIPasswordSDK64.exe no caminho de instalação padrão do CyberArk AIM, ou seja, C:\Program Files(x86)\CyberArk\ApplicationPasswordSdk\CLIPasswordSDK64.exe. Se o CyberArk AIM não estiver instalado no caminho padrão, deve ser adicionada uma entrada de configuração no UiPath.Orchestrator.dll.config, apontando para o caminho real. O caminho pode ser especificado na seção appSettings em web.config antes da instalação, ou em UiPath.Orchestrator.dll.config após a instalação.

Exemplo:

<add key="Plugins.SecureStores.CyberArk.CLIPasswordSDKExePath" value="D:\CustomFolder\CLIPasswordSDK64.exe" />

Proxy Configuration

No .NET Core, há dois mecanismos para especificar o proxy:

Uso de variáveis de ambiente

As variáveis de ambiente podem ser definidas em web.config usando a seguinte sintaxe: <environmentVariable name="[insert_variable_here]" value="[insert_address_here]" />, por exemplo <environmentVariable name="HTTP_PROXY" value="http://127.0.0.1:8080" />.

Variável	Description
HTTP_PROXY	O servidor de proxy usado em solicitações HTTP.
HTTPS_PROXY	O servidor de proxy usado em solicitações HTTPS.
ALL_PROXY	O servidor de proxy usado em solicitações HTTP e/ou HTTPS caso HTTP_PROXY ou HTTPS_PROXY não estejam definidos.
NO_PROXY	Uma lista separada por vírgulas de nomes de host que deve ser excluída do proxy.

Exemplos:

• Sem autenticação: ALL_PROXY=http://localhost:8888
• Com autenticação: ALL_PROXY=http://user:password@localhost:8888

Usando o sistema de proxy padrão (configurações do IE ou configurações do Windows Proxy), se as variáveis de ambiente não estiverem definidas.

Veja a documentação oficial da Microsoft aqui.

A configuração do proxy não está mais configurada em web.config usando a tag <defaultProxy>. Exemplo de configuração que não é mais compatível:

<system.net>
    <defaultProxy>
      <proxy usesystemdefault="True" proxyaddress="http://<ip>:<port>" bypassonlocal="True"/>
    </defaultProxy>
  </system.net>

Arquivos de configuração

web.config

A maioria das configurações do Orchestrator foi movida de web.config para UiPath.Orchestrator.dll.config. O novo arquivo mantém a mesma estrutura que o arquivo web.config antigo e está localizado no mesmo diretório. Lembre-se de que alterar o arquivo UiPath.Orchestrator.dll.config não reinicia o IIS. As seguintes seções foram movidas:

• strings de conexão
• Configurações de Aplicativo
• Configuração do NLog
• Configuração de Quartz
• a chave de criptografia

web.config foi reformulado para conter apenas a configuração usada pelo IIS. Após a atualização, o instalador moverá automaticamente as seções mencionadas acima para o novo arquivo de configuração. Isso transformará a configuração deixada em web.config para corresponder ao que é necessário para a versão mais recente do Orchestrator. A personalização do cliente, incluindo verbos desabilitados, módulos habilitados/desabilitados e regras de regravação personalizadas, é preservada.

Verifique os documentos do web.config .

Verifique os documentos do UiPath.Orchestrator.dll.config .

IIS Manager

As configurações de aplicativos e strings de conexão não são mais visíveis no IIS Manager. O uso do Gerenciador de IIS para editar as strings de conexão do Orchestrator ou as configurações do aplicativo não é compatível.

Dica:

Você precisa editar o arquivo de configuração diretamente.

NLog Targets

Para destinos do NLog do tipo "Banco de dados", a propriedade connectionStringName foi substituída por connectionString. Seu valor deve usar a seguinte sintaxe: connectionString="${ui-connection-strings:item=Default}", onde Default é o nome da string de conexão que você deseja usar a partir da seção <connectionStrings>.

Veja os documentos em Destinos dos logs de execução do Orchestrator.

Dica:

Se você estiver usando destinos personalizados do NLog do tipo Database, a propriedade connectionStringName será alterada automaticamente para connectionString durante a atualização. Se você estiver inserindo manualmente o destino no arquivo de configuração após a instalação/atualização, use a nova propriedade com o valor correto.

Protocolo do SignalR

SignalR com WebSockets

Nós atualizamos a biblioteca do SignalR para uma versão mais recente, que não é compatível com os clientes do Robô mais antigos. Para manter a notificação de Robôs não assistidos quando os trabalhos estão disponíveis, um mecanismo de compatibilidade foi implementado, simulando o protocolo antigo do SignalR sobre Long Polling. Robôs mais antigos do que a versão 2020.10 se conectam ao Orchestrator apenas por meio de Long Polling.

Dica:

É recomendável atualizar seus Robôs para a versão 2020.10 para usar o WebSockets, o que a torna especialmente econômica para grandes implantações de Robôs.

Sessões fixas de Scaleouts do SignalR

Os scaleouts do SignalR requerem sessões fixas para todos os protocolos diferentes do WebSocket (ou seja, SSE e Long Polling).

Por padrão, apenas o transporte de WebSocket está habilitado, já que o Orchestrator supõe que sessões fixas não estão habilitadas no balanceador de carga do cliente.

Figure 1. Scalability settings

Dica:

Adicione a chave <add key="Scalability.SignalR.RequireStickySessions" value="true" /> em UiPath.Orchestrator.dll.config para habilitar as sessões fixas. Se estiver definido como true, todos os transportes estão habilitados e o Orchestrator supõe que sessões fixas estão habilitadas no balanceador de carga. Habilitar as sessões fixas em UiPath.Orchestrator.dll.config sem habilitá-las no balanceador de carga resultará em conexões do SignalR com falha.

Expansão do SignalR com o SQL Server

O mecanismo de Scaleouts é alternado do SQL Server para o Redis durante a instalação. Desabilitar a autenticação do SignalR para Robôs/atividades não é mais compatível. Para isso, o parâmetro Scalability.SignalR.AuthenticationEnabled foi descontinuado.

Atividade “Wait Queue Item”

Você pode encontrar atrasos de até 30 segundos se usar uma atividade Esperar Item da Fila anterior à versão 2020.10.

Dica:

Faça a atualização para a versão da atividade mais recente para evitar esses problemas.

Infraestrutura do NuGet

Atualizamos o protocolo interno de feeds do NuGet da v2 para a v3.

Repositórios legados

Legacy não é mais um tipo de repositório do NuGet compatível. Após a atualização, todos os repositórios do tipo Legacysão migrados para Composite.

O novo local do pacote depende de como você configurou os parâmetros NuGet.Packages.Path e NuGet.Activities.Path em web.config para a versão anterior do Orchestrator.

• Se você armazenar os pacotes nos locais padrão (~/NuGetPackages e ~/NuGetPackages/Activities), o novo local do pacote será RootPath=.\Storage.
• Se você tiver armazenado os pacotes em um local personalizado, durante a instalação será solicitado que você informe um novo local de armazenamento. Para instalações silenciosas, os parâmetros STORAGE_TYPE e STORAGE_LOCATION se tornam obrigatórios, a menos que você os especifique em web.config antes da atualização.

Na versão v2020.10+, o local do pacote está configurado usando os parâmetros Storage.Type e Storage.Location em UiPath.Orchestrator.dll.config. Após a atualização, todas as configurações de aplicativos relacionadas a Legacyestarão obsoletas e não estarão mais em vigor.

• NuGet.Packages.Path
• NuGet.Activities.Path
• Nuget.EnableRedisNodeCoordination
• Nuget.EnableNugetServerLogging
• NuGet.EnableFileSystemMonitoring
• NuGet.Repository.Type

Importante:

O uso de comandos de copiar-colar na pasta dedicada de pacotes não é compatível com repositórios de Composite .

Biblioteca Swagger

Fizemos alterações significativas na forma como geramos o swagger.jsonarquivo , que descreve a API do Orchestrator. Se você utiliza um gerador de biblioteca de cliente que usa a descrição de API no arquivo Swagger (por exemplo, AutoRest, Swagger Codegen), o código gerado será significativamente diferente.

Dica:

Você pode ter que atualizar quaisquer outras ferramentas personalizadas que usem o cliente gerado automaticamente.

Mudanças no API

APIs com parâmetros POST de formulário

Fazer solicitações de POST com parâmetros em objetos de dados do formulário não funciona mais.

Dica:

O único mecanismo compatível para fazer solicitações de POST para o Orchestrator é incluir os parâmetros de solicitação em um JSON no corpo da solicitação.