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 Core 3.1

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
.NET Standard	1.0	1.1	1.2	1.3	1.4	1.5	1.6
.NET Standard	2.0 (recomendado)	2.1
.NET Core	3.0	3.1

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, mas você deve certificar-se de copiar o .dll correto. Por exemplo, se você usar o 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 o 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 a configuração do arquivo 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 torna grandes implantações de Robôs especialmente econômicas.

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.

Dica: Adicione a chave <add key="Scalability.SignalR.RequireStickySessions" value="true" /> em UiPath.Orchestrator.dll.config para habilitar as sessões adesivas. 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 Legacy sã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 Legacy estarã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.