Compartir a través de


Consideraciones sobre la automatización desatendida de Office en el entorno de RPA de Microsoft 365 para desatendido

Aunque Microsoft 365 para RPA desatendido proporciona una licencia que permite la automatización de Office sin ningún usuario presente, todas las versiones actuales de Office se diseñaron y probaron para ejecutarse como productos de usuario final en una estación de trabajo cliente con un usuario presente para interactuar con la interfaz de la aplicación. Los comportamientos inesperados resultantes del uso de aplicaciones sin un usuario presente no son defectos. Si quiere ejecutar Office en esta configuración, debe estar preparado para tener en cuenta estos comportamientos inesperados en la lógica de la aplicación.

En este artículo se describen algunas de las consideraciones para la automatización desatendida de Office para ayudarle si usa este enfoque. Sin embargo, tenga en cuenta que el uso de Office en esta configuración es estrictamente "TAL CUAL" y debe tener en cuenta estos comportamientos inesperados. La información que se proporciona aquí no es exhaustiva y no se garantiza que resuelva todos los problemas de todos los clientes. Le recomendamos que pruebe la solución exhaustivamente antes de realizar la implementación.

Problemas comunes en la automatización desatendida

Si quiere usar Office sin un usuario presente, tenga en cuenta las siguientes áreas en las que Office puede comportarse de forma diferente de lo esperado. Para que la solución se ejecute correctamente, debe solucionar estos problemas y minimizar sus efectos tanto como sea posible. Tenga en cuenta estos problemas cuidadosamente al compilar la aplicación.

Importante

Microsoft no recomienda actualmente ni admite la automatización de aplicaciones de Microsoft Office desde ninguna aplicación o componente cliente no interactivo desatendido (incluidos ASP, ASP.NET, DCOM y servicios NT), ya que Office puede presentar un comportamiento inestable o interbloqueo cuando Office se ejecuta en este entorno. Para obtener más información, vea Consideraciones para la automatización del lado servidor de Office.

Elementos interactivos de la interfaz de usuario

Las aplicaciones de Office asumen que se ejecutan de forma interactiva. Si se produce un error inesperado o si se necesita un parámetro no especificado para completar una función, Office está diseñado para preguntar al usuario con un cuadro de diálogo que pregunte al usuario cómo desea continuar. En la automatización desatendida, esto podría dar lugar a que la aplicación parezca "bloquearse" mientras la aplicación se detiene hasta que recibe esta entrada. Si va a automatizar Office a través de sus API públicas, puede suprimir muchas de estas alertas configurando propiedades como Application.DisplayAlerts y Application.AutomationSecurity correctamente. El código debe diseñarse para identificar y procesar alertas de bloqueo en cualquier momento.

Identidad de usuario

Las aplicaciones de Office requieren una identidad de usuario cuando se ejecutan las aplicaciones, incluso cuando la aplicación se inicia a través de la automatización. Esta identidad de usuario puede provocar cualquiera de las siguientes causas:

  • La presencia de una interfaz de usuario de inicio de sesión adicional que se debe controlar.
  • Archivos que no se pueden abrir ni editar en función de los permisos de acceso por usuario.
  • Cambios inesperados en los metadatos del archivo (por ejemplo, determinadas propiedades de archivo se actualizarán en función de la identidad de la identidad de usuario de la instancia de aplicación automatizada).

Diversos enfoques pueden ayudar a mitigar estos problemas; por ejemplo, ejecutar el Inspector de documentos para quitar metadatos. Considere si estos enfoques son adecuados en función de su escenario.

Seguridad del lado servidor

Al ejecutar Office desatendida y procesar contenido arbitrario de archivos, no hay disponibles protecciones adicionales específicas en ese entorno para evitar que las macros almacenadas en esos archivos se carguen y se ejecuten. Office no le protege frente a macros que se ejecutan involuntariamente desde el código ni de iniciar otro servidor que pueda ejecutar macros. Puede usar propiedades como Application.AutomationSecurity para mitigar este riesgo, pero debe asegurarse de que solo está cargando contenido de confianza.

Además, Office usa muchos componentes (como MAPI simple, WinInet y MSDAIPP) que pueden almacenar en caché la información de autenticación de cliente para acelerar el procesamiento. Cuando Office se está automatizando en el lado servidor y procesando varios archivos, si la información de autenticación se ha almacenado en caché para esa sesión, un cliente puede usar las credenciales almacenadas en caché de otro cliente. Por lo tanto, el cliente puede obtener permisos de acceso no concedidos suplantando a otros usuarios.

Cambios en la interfaz de usuario

Los elementos de la interfaz de usuario de Office son en gran medida estables, pero la ubicación específica de cualquier elemento de la interfaz de usuario no está garantizada y puede cambiar a medida que evoluciona el diseño del producto para incorporar comentarios del usuario y satisfacer las necesidades del cliente. La lógica de cualquier automatización debe tener en cuenta esto. Estos cambios pueden dar lugar a cambios de nomenclatura de botones o pestañas de grupo, movimiento de comandos entre pestañas, adición de nuevas pestañas o eliminación de comandos en alineación con nuestras directivas de desuso de características. Estos cambios pueden tener lugar en la interfaz de usuario, así como en la información de accesibilidad proporcionada por la aplicación, ya que esa información se modifica para mejorar la facilidad de uso y tener en cuenta los comentarios continuos de los clientes, y podría implementarse para diferentes usuarios en diferentes momentos.

Incluso sin cambios en el producto, las diferencias entre los entornos del sistema (como el tamaño de pantalla, la resolución y los PPP) pueden dar lugar a cambios en la ubicación de los elementos en pantalla. Cualquier enfoque que se base en coordenadas de pantalla para simular la entrada del usuario debe tener en cuenta estos cambios y adaptarse en consecuencia.

Subproceso único

Las aplicaciones de Office son aplicaciones basadas en STA no reentrantes que están diseñadas para proporcionar funcionalidad diversa pero que consume muchos recursos para un solo cliente. Las aplicaciones usan recursos globales, como archivos asignados a memoria, complementos o plantillas globales y servidores de automatización compartidos. Esto puede limitar el número de instancias que se pueden ejecutar simultáneamente y puede dar lugar a condiciones de carrera si las aplicaciones están configuradas en un entorno multicliente. Si tiene previsto ejecutar más de una instancia de cualquier aplicación de Office, debe planear aislarlas en el nivel de máquina virtual para garantizar la estabilidad de la solución resultante.

Resistencia y estabilidad

Incluso con las consideraciones anteriores, si las aplicaciones se automatizan de maneras que simulan la entrada del usuario o para las longitudes de sesión que superan drásticamente el uso interactivo, pueden encontrarse con problemas que no están presentes cuando se ejecutan de forma interactiva. Las soluciones que usan Office en este contexto deben crear mecanismos de forma proactiva para supervisar el estado de la aplicación y reiniciarlos (o la máquina virtual en la que se ejecutan) si es necesario.

Alternativas sugeridas

Microsoft recomienda encarecidamente algunas alternativas que no requieren que Office se instale y ejecute en el lado servidor y que puedan realizar tareas comunes de forma más eficaz y rápida que la automatización en esta configuración. Antes de implicar a Office como componente del lado servidor en el proyecto, considere alternativas.

Microsoft Graph

Microsoft Graph API proporciona acceso a los servicios, datos e inteligencia que están disponibles para los usuarios y soluciones como parte de la nube de Microsoft, incluidos muchos servicios que admiten las necesidades de automatización desatendida: acceso al correo, calendario, contactos o archivos de los usuarios, conversión de documentos, cálculo del libro de Excel y mucho más. Estos servicios están diseñados para el uso desatendido y el acceso a gran escala, y usan una sintaxis de API RESTful estándar. Para obtener más información sobre Microsoft Graph y cómo usarlo para trabajar con los datos de los usuarios, visite lo siguiente:

Formatos de archivo Open XML

Muchas tareas de automatización implican la creación o edición de documentos. Office admite formatos de archivo Open XML que permiten a los desarrolladores crear, editar, leer y transformar contenido de archivos mediante tecnologías XML y ZIP estándar, definidas en el estándar internacional ISO 29500. Estos formatos de archivo se pueden manipular a través de cualquier herramienta ZIP/XML, incluido el espacio de nombres System.IO.Package.IO en Microsoft .NET 3.x Framework. La edición directa de los formatos de archivo es el método recomendado y compatible para controlar los cambios en los archivos de Office desde un servicio.

Microsoft proporciona un SDK para manipular formatos de archivo Open XML desde .NET 3.x Framework. Para obtener más información sobre el SDK y cómo usar el SDK para crear o editar archivos Open XML, visite lo siguiente: