Consideraciones sobre la instalación

Este artículo identifica las principales áreas afectadas que debes tener en cuenta en cualquier nueva implementación de Orchestrator. Algunos de los elementos tratados en este artículo deben ser atendidos antes de cualquier actualización/instalación. Varios de ellos son validados por el instalador o por la Herramienta de configuración de la plataforma, en caso de que decidas utilizarla. Te recomendamos encarecidamente que descargues y utilices la Herramienta de configuración de la plataforma para validar tu entorno antes de una actualización.

.NET Core 3.1

Marco de destino

Para mantener la funcionalidad de los complementos del almacén de credenciales y de las extensiones NLog, el TargetFramework debe actualizarse desde el .NET Framework 4.7.2 anterior a un marco de trabajo de destino compatible. El marco de destino tanto de los almacenes de credenciales como de las extensiones NLog es comprobado por el instalador UiPathOrchestrator.msi.

Esta restricción también afecta a cualquier referencia que pueda tener un complemento o una extensión de NLog.

Marcos de destino admitidos
Estándar .NET	1.0	1.1	1.2	1.3	1.4	1.5	1.6
Estándar .NET	2.0 (recomendado)	2.1
.NET Core	3.0	3.1

Consejo:

Puede que necesites recompilar cualquier complemento del almacén de credenciales y las extensiones NLog que hayas desarrollado por tu cuenta.

Es posible que necesites identificar y copiar al directorio de Orchestrator otros archivos .dll destinados a los marcos de destino especificados. La mayoría de los destinos NLog son compatibles con los marcos de destino especificados. No obstante, debes asegurarte de copiar el .dllcorrecto. Por ejemplo, en caso de utilizar NLog.Targets.Splunk, es necesario que descargues el archivo .nupkg, que lo abras como .zip, navegues hasta la carpeta lib\) etstandard2.0 y utilices el archivo .dll desde allí.

Complementos del almacén de credenciales - CyberArk

En versiones anteriores de Orchestrator, el complemento del almacén de credenciales de CyberArk utilizaba una biblioteca que no es compatible con .NET Core. Orchestrator utiliza ahora la herramienta CLIPasswordSDK64.exe que viene con CyberArk AIM.

Consejo: El complemento busca CLIPasswordSDK64.exe en la ruta de instalación predeterminada de CyberArk AIM, es decir, en: C:\Program Files(x86)\CyberArk\ApplicationPasswordSdk\CLIPasswordSDK64.exe. Si CyberArk AIM no se ha instalado en la ruta predeterminada, debe añadirse una entrada de configuración en UiPath.Orchestrator.dll.config, para indicar la ruta correcta. La ruta puede especificarse en la sección appSettings en web.config antes de la instalación o bien el UiPath.Orchestrator.dll.config tras ella.

Ejemplo:

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

Configuración de proxy

En .NET Core hay dos mecanismos para especificar el proxy:

Utilizar variables de entorno

Las variables de entorno pueden establecerse como web.config utilizando la siguiente sintaxis: <environmentVariable name="[insert_variable_here]" value="[insert_address_here]" />, por ejemplo <environmentVariable name="HTTP_PROXY" value="http://127.0.0.1:8080" />.

Variable	Descripción
HTTP_PROXY	El servidor proxy utilizado en las solicitudes HTTP.
HTTPS_PROXY	El servidor proxy utilizado en las solicitudes HTTPS.
ALL_PROXY	El servidor proxy utilizado en las solicitudes HTTP o HTTPS en el caso de que HTTP_PROXY o HTTPS_PROXY no hayan sido definidos.
NO_PROXY	Una lista de los nombres de host, separados por comas, que deben excluirse del proxy.

Ejemplos:

• Sin autenticación: ALL_PROXY=http://localhost:8888
• Con autenticación: ALL_PROXY=http://user:password@localhost:8888

Utilizando el sistema proxy predeterminado (en ajustes de IE o ajustes de Windows proxy), si las variables del entorno no han sido establecidas

Consulta la documentación oficial de Microsoft aquí.

La configuración del proxy ya no se configura en web.config utilizando la etiqueta <defaultProxy>. Ejemplo de configuración que ya no es compatible:

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

Archivos de configuración

web.config

La mayoría de los ajustes de configuración de Orchestrator se han trasladado de web.config a UiPath.Orchestrator.dll.config: El nuevo archivo conserva la misma estructura que el antiguo archivo web.config y está ubicado en el mismo directorio. Recuerda que cambiar el archivo UiPath.Orchestrator.dll.config no hace que IIS se reinicie. Las siguientes secciones se han trasladado:

• cadenas de conexión
• Ajustes de la aplicación
• Configuración NLog
• Configuración de Quartz
• la clave de cifrado

web.config ha sido rediseñada para que contenga solo la configuración utilizada por IIS. Al actualizar, el instalador trasladará automáticamente las secciones mencionadas anteriormente al nuevo archivo de configuración. Transformará la configuración que se ha dejado en web.config para que coincida con lo que sea necesario para la versión más reciente de Orchestrator. La personalización del cliente, incluidos los verbos deshabilitados, los módulos habilitados/deshabilitados, las reglas de reescritura personalizadas, se conservan.

Consulta la documentación de web.config.

Consulta la documentación de UiPath.Orchestrator.dll.config.

IIS Manager

Las cadenas de conexión y los ajustes de la aplicación ya no serán visibles en el administrador de IIS. No se ofrece soporte para la utilización del administrador de IIS para editar las cadenas de conexión de Orchestrator.

Consejo: Debes editar el archivo de configuración.

Objetivos NLog

En los destinos NLog de tipo "Base de datos", la propiedad connectionStringName ha sido reemplazada por connectionString. Su valor debe seguir la siguiente sintaxis: connectionString="${ui-connection-strings:item=Default}", donde Default es el nombre de la cadena de conexión que deseas utilizar de la sección <connectionStrings>.

Consulta la documentación sobre Destinos de los registros de ejecución de Orchestrator.

Consejo: Si utilizas destinos NLog personalizados de tipo Database, la propiedad connectionStringName se cambia automáticamente a connectionString durante la actualización. Si introduces manualmente el destino en el archivo de configuración después de la instalación/actualización, utiliza la nueva propiedad con el valor correcto.

Protocolo SignalR

SignalR con WebSockets

Hemos actualizado la biblioteca SignalR a una versión más nueva que no es compatible con los clientes antiguos de UiPath Robot. Para seguir notificando a los Robots desatendidos cuando haya trabajos disponibles, se implementó un mecanismo de compatibilidad para simular el antiguo protocolo SignalR sobre Long Polling. Los Robots anteriores a 2020.10 se conectan a Orchestrator solo a través de Long Polling.

Consejo: Recomendamos actualizar tus Robots a 2020.10 para usar WebSockets, lo que hace las implementaciones de Robots a gran escala particularmente rentables.

Sesiones Sticky de Scaleouts de SignalR

Los scaleouts de SignalR requieren sesiones sticky para todos los protocolos que no sean WebSocket (por ejemplo, SSE y Long Polling).

Solo se habilita el transporte WebSocket de forma predeterminada, ya que Orchestrator da por hecho que las sesiones sticky no están habilitadas en el equilibrador de carga del cliente.

Consejo: Añade la clave <add key="Scalability.SignalR.RequireStickySessions" value="true" /> en UiPath.Orchestrator.dll.config para habilitar las sesiones adhesivas. Si se establece como true, se habilitan todos los transportes y Orchestrator supone que las sesiones sticky del equilibrador de carga están habilitadas. Habilitar las sesiones sticky en UiPath.Orchestrator.dll.config, sin habilitarlas en el equilibrador de carga, dará como resultado conexiones de SignalR fallidas.

Escalamiento de servidor SQL SignalR

El mecanismo de scaleout se cambia de SQL Server a Redis durante la instalación. Ya no puede deshabilitarse la autenticación SignalR para los Robots/actividades. Con este fin, el parámetro Scalability.SignalR.AuthenticationEnabled ha sido descartado.

Actividad de los elementos en la cola de espera

Puedes sufrir retrasos de hasta 30 segundos si utilizas una actividad Elemento en la cola de espera anterior a 2020.10.

Consejo: Actualiza a la versión de actividad más reciente para evitar este tipo de problemas.

Infraestructura NuGet

Hemos actualizado el protocolo interno de las fuentes NuGet de la v2 a la v3.

Repositorios heredados

Legacy ya no será un tipo de repositorio NuGet compatible. Al actualizar, todos los repositorios de tipo Legacy se migrarán a Composite.

La nueva ubicación del paquete depende de cómo configuraste los parámetros NuGet.Packages.Path y NuGet.Activities.Path en web.config para la versión anterior de Orchestrator.

• Si almacenaste los paquetes en las ubicaciones predeterminadas (~/NuGetPackages y ~/NuGetPackages/Activities), la nueva ubicación del paquete se convierte en RootPath=.\Storage.
• Si almacenaste los paquetes en una ubicación personalizada, durante la instalación se te pedirá que indiques una nueva ubicación de almacenamiento. En instalaciones silenciosas, los parámetros STORAGE_TYPE y STORAGE_LOCATION se vuelven obligatorios, a no ser que los especifiques en web.config antes de la actualización.

En v2020.10+, la ubicación del paquete se configura mediante los parámetros Storage.Type y Storage.Location en UiPath.Orchestrator.dll.config. Tras la actualización, todos los ajustes de la aplicación relacionados con Legacy quedarán obsoletos y ya no tendrán ningún efecto.

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

Importante: No pueden utilizarse comandos de copia/pega en la carpeta dedicada a los paquetes de los Compositerepositorios.

Biblioteca Swagger

Hemos realizado cambios significativos a la forma en que generamos el archivo swagger.json, que describe la API de Orchestrator. Si confías en un generador de bibliotecas cliente que utilice la descripción de la API en el archivo Swagger (por ejemplo, AutoRest, Swagger Codegen), el código generado será significativamente diferente.

Consejo: Podrías tener que actualizar cualquier otra herramienta personalizada que utilice el cliente autogenerado.

Cambios en la API

API con parámetros POST de formulario

Realizar solicitudes POST con parámetros en objetos de datos de forma ya no funciona.

Consejo: El único mecanismo compatible para realizar POSTsolicitudes a Orchestrator es incluir los parámetros de solicitud en un JSON en el cuerpo de la solicitud.