Aspectos que hay que tener en cuenta para realizar la automatización de Office en el servidor

Se aplica a: Productos OfficeAccess 2010Excel 2010

Resumen


Los desarrolladores pueden usar la automatización de Microsoft Office para crear soluciones personalizadas que utilicen las capacidades y características integradas en los productos de Office. Aunque este tipo de desarrollos mediante programación se puede implementar en un sistema cliente con relativa facilidad, pueden surgir diversas complicaciones si la automatización tiene lugar con código del lado servidor, como Páginas Active Server de Microsoft (ASP), ASP.NET, DCOM o un servicio de Windows NT.

En este artículo se tratan las complicaciones a las que se pueden enfrentar los desarrolladores: En el artículo también se ofrecen opciones alternativas a la automatización que pueden acelerar el rendimiento. Sin embargo, los desarrolladores deben tener en cuenta que las sugerencias que se proporcionan en este artículo son solo de carácter informativo. Microsoft no recomienda ni proporciona soporte técnico para la automatización de Office en el servidor.

Nota En este contexto, el controlador del sistema Microsoft 2007 Office y el motor de base de datos de Access 2010 se consideran componentes de Microsoft Office. El término "en el servidor" también se aplica al código que se ejecuta en una estación de trabajo Windows, si se ejecuta desde una estación de trabajo Windows distinta de la estación interactiva del usuario que haya iniciado la sesión. Por ejemplo, el código que el Programador de tareas inicia en la cuenta SYSTEM se ejecuta en el mismo entorno que el código ASP "en el servidor" o como código DCOM. Por lo tanto, es posible que se produzcan muchos de los problemas que se describen en este artículo. Para más información sobre las estaciones de trabajo Windows y COM, consulte las secciones "Más información" y "Referencias".

Más información


Todas las versiones actuales de Microsoft Office se han diseñado, probado y configurado para ejecutarse como productos de usuario final en una estación de trabajo cliente. Asumen un escritorio interactivo y un perfil de usuario. No proporcionan el nivel de reentrada o seguridad necesario para satisfacer las necesidades de los componentes de servidor diseñados para el funcionamiento desatendido.

Actualmente, Microsoft no recomienda, ni proporciona soporte técnico para, la automatización de las aplicaciones de Microsoft Office desde una aplicación o componente cliente desatendido no interactivo (como ASP, ASP.NET, DCOM y servicios de NT), ya que Office puede mostrar un comportamiento inestable y quedar interrumpido al ejecutarse en este entorno.

Si está creando una solución que se ejecuta en un contexto en el servidor, debería probar el uso de componentes que sean seguros para la ejecución desatendida. O bien, debería intentar buscar soluciones alternativas que permitan que al menos una parte del código se ejecute en el cliente. Si usa una aplicación de Office desde una solución en el servidor, es posible que esta no tenga muchas de las capacidades necesarias para que se ejecute correctamente. Asimismo, correría riesgo con la estabilidad de la solución global.

Problemas con el uso de la automatización de Office en el servidor

Los desarrolladores que intenten usar Office en una solución de servidor deben saber que existen cinco áreas principales en las que Office se comporta de una manera diferente a la esperada debido al entorno. Para que el código se ejecute correctamente, debe solucionar estos problemas y minimizar sus efectos lo más posible. Tenga muy en cuenta estos problemas al crear su aplicación. Una solución no puede resolver todos los problemas. Distintos diseños requieren que establezca prioridades para los elementos de manera diferente.

  • Identidad de usuario: las aplicaciones de Office asumen una identidad de usuario al ejecutarse, aunque las haya iniciado la automatización. Las aplicaciones intentan iniciar las barras de herramientas, menús, opciones, impresoras y algunos complementos según la configuración del subárbol del Registro correspondiente al usuario que inicie la aplicación. Muchos servicios se ejecutan en cuentas que no tienen perfiles de usuario (como la cuenta SYSTEM o las cuentas IWAM_[NombreServidor]). Por lo tanto, es posible que Office no se inicialice al iniciar. En esta situación, Office devuelve un error en la función CreateObject o CoCreateInstance. Incluso si la aplicación de Office se puede iniciar, es posible que otras características no funcionen correctamente si no existe ningún perfil de usuario.
  • Interactividad con el escritorio: las aplicaciones de Office presuponen que se ejecutan en un escritorio interactivo. En algunos casos, es posible que las aplicaciones se tengan que hacer visibles para que algunas funciones de automatización se ejecuten correctamente. Si se produce un error no esperado o se requiere un parámetro no especificado para completar una función, Office está diseñado para preguntar al usuario qué desea hacer mediante un cuadro de diálogo modal. Un cuadro de diálogo modal no puede descartarse en un escritorio no interactivo. Por lo tanto, ese subproceso deja de responder (se bloquea) de manera indefinida. Aunque algunas prácticas de creación de código pueden ayudar a reducir la probabilidad de que esto suceda, no se puede evitar del todo. Sólo por este motivo, la ejecución de aplicaciones de Office en un entorno de servidor resulta arriesgada e incompatible.
  • Reentrada y escalabilidad: los componentes de servidor tienen que ser componentes COM de subprocesos múltiples con alta capacidad de reentrada, con un mínimo de sobrecarga y un elevado rendimiento para muchos clientes. En casi todos los aspectos, las aplicaciones de Office son justo lo contrario. Las aplicaciones de Office son servidores de automatización sin reentrada basados en STA, diseñadas para proporcionar funcionalidad diversa pero consumidora de recursos para un único cliente. Las aplicaciones ofrecen poca escalabilidad como solución de servidor. Asimismo, las aplicaciones tienen límites fijos en cuanto a elementos importantes, como la memoria. Estos no se pueden modificar a través de la configuración. Lo que es más importante, las aplicaciones usan recursos globales, como archivos asignados en memoria, complementos o plantillas globales y servidores de automatización compartidos. Esto puede limitar el número de instancias que se ejecutan simultáneamente y puede resultar en condiciones de carrera si las aplicaciones se configuran en un entorno de varios clientes. Los desarrolladores que vayan a ejecutar más de una instancia de alguna aplicación de Office a la vez deben tener en cuenta la posibilidad de "agrupar" o serializar el acceso a la aplicación de Office para evitar posibles bloqueos o daños en los datos.
  • Resistencia y estabilidad: Office 2000, Office XP, Office 2003 y Office 2007 usan la tecnología de Microsoft Windows Installer (MSI) para que la instalación y reparación automática resulten más sencillas para el usuario final. MSI introduce el concepto de "instalación la primera vez que se utiliza". Esto permite que las características se instalen o configuren dinámicamente en el tiempo de ejecución del sistema o, más a menudo, para un usuario en particular. En un entorno de servidor, esto reduce el rendimiento y aumenta la probabilidad de que aparezca un cuadro de diálogo que pida al usuario la aprobación de la instalación o que proporcione un disco de instalación. Aunque esto se ha diseñado para aumentar la resistencia de Office como producto de usuario final, la implementación de las capacidades de MSI en Office resulta contraproducente en un entorno de servidor. Además, la estabilidad general de Office no se puede garantizar cuando se ejecute en el servidor porque no se diseñó ni probó para este tipo de uso. El uso de Office como un componente de servicio en un servidor de red puede reducir la estabilidad del equipo y, como consecuencia, de la red en general.
  • Seguridad en el servidor: las aplicaciones de Office nunca se pensaron para que se usen en el servidor. Por lo tanto, no tienen en cuenta los problemas de seguridad a los que se enfrentan los componentes distribuidos. Office no autentica las solicitudes entrantes. Tampoco protege contra macros ejecutadas involuntariamente o contra el inicio de otro servidor que pudiera ejecutar macros, desde su propio código de servidor. No abra archivos cargados en el servidor desde un sitio web anónimo. Según la configuración de seguridad establecida la última vez, el servidor puede ejecutar macros en un contexto de Administrador o Sistema con todos los privilegios y poner en peligro la red. Además, Office usa muchos componentes de cliente (como Simple MAPI, WinInet y MSDAIPP) que pueden almacenar en caché información de autenticación de cliente para poder acelerar el procesamiento. Si Office se automatiza en el servidor, es posible que una instancia preste servicio a más de un cliente. Si la información de autenticación se almacenó en caché para esa sesión, un cliente puede usar las credenciales en caché de otro cliente. Por lo tanto, el cliente podría obtener permisos de acceso no otorgados mediante la suplantación de otros usuarios.

Además de los problemas técnicos, también debe tener en cuenta las licencias. Las directrices actuales sobre licencias no permiten que las aplicaciones de Office se usen en un servidor para dar servicio a solicitudes de clientes, a menos que esos clientes tengan copias con licencia de Office. Los términos de licencia no permiten la utilización de la automatización en el servidor para proporcionar funcionalidad de Office a estaciones de trabajo sin licencia.

Además de estos problemas, uno de los siguientes errores comunes se podría producir al intentar automatizar Office en el servidor:

  • Las funciones CreateObject o CoCreateInstance devuelven uno de los siguientes mensajes de error en tiempo de ejecución y no se puede iniciar para automatización.
     
    Mensaje 1
    Se ha producido el error 429 en tiempo de ejecución: el componente ActiveX no puede crear el objeto
    Mensaje 2
    Error en tiempo de ejecución '70': permiso denegado
    Mensaje 3
    CO_E_SERVER_EXEC_FAILURE (0x80080005): Error en la ejecución de servidor
    Mensaje 4
    E_ACCESSDENIED (0x80070005): Acceso denegado
  • Al abrir un documento de Office, recibe uno de los siguientes mensajes de error:
     
    Mensaje 1
    Error en tiempo de ejecución '5981' (0x800A175D): No se puede abrir el almacenamiento de macros
    Mensaje 2
    Error en tiempo de ejecución '1004': error en el método '~' del objeto '~'
  • Las funciones CreateObject y CoCreateInstance dejan de responder y nunca finalizan, o tardan mucho tiempo para devolver los resultados. En algunos servidores, la creación es rápida, pero el error 1004 aparece en el registro de eventos de Windows que indican que la aplicación se detuvo.
  • En algunas funciones se produce un error inesperado o estas dejan de responder de manera indefinida debido a una alerta de usuario u otro cuadro de diálogo que requiere la atención del usuario.
  • La ejecución de varias solicitudes o pruebas de esfuerzo hace que el código dé error, deje de responder o se bloquee en la creación o terminación de una aplicación de Office. Cuando esto sucede, el proceso queda en ejecución en memoria y no se puede terminar o todas las instancias de la aplicación automatizada producen errores a partir de ese momento.

Pueden aparecer otros problemas o mensajes además de los enumerados aquí, pero normalmente ocurren como resultado de los cinco problemas que se describen en este artículo. 

Opciones alternativas a la automatización en el servidor

Microsoft recomienda encarecidamente que los desarrolladores busquen alternativas a la automatización de Office si necesitan desarrollar soluciones de servidor. Debido a las limitaciones del diseño de Office, los cambios en la configuración de Office no son suficientes para resolver todos los problemas. Microsoft recomienda varias alternativas que no requieren que Office se instale en el servidor y que pueden realizar las tareas más comunes de una manera más eficiente y rápida que la automatización. Antes de utilizar Office como un componente del servidor en su proyecto, tenga en cuenta las alternativas.

La mayoría de las tareas de automatización en el servidor implican la creación o modificación de documentos. Office 2007 admite nuevos formatos de archivo Open XML que permiten a los desarrolladores crear, editar, leer y transformar contenido de archivo en el servidor. Estos formatos de archivo usan el espacio de nombres System.IO.Package.IO en Microsoft .NET 3.x Framework para editar los archivos de Office sin usar las aplicaciones de cliente de Office en sí. Este es el método recomendado y admitido para la gestión de cambios en los archivos de Office desde un servicio.

Los formatos de archivo Open XML son un estándar público. 


Microsoft proporciona un SDK para manipular los formatos de archivo Open XML desde .NET 3.x Framework. Para más información sobre el SDK y cómo usarlo para crear o editar archivos Open XML, visite los siguientes sitios web de Microsoft Developer Network (MSDN):

Al transmitir archivos Open XML desde ASP o ASP.NET, debe proporcionar el tipo correcto de Extensión multipropósito de correo por Internet (MIME) para el contenido que desee transmitir. Para obtener un listado de los tipos MIME para los archivos de Office 2007, visite el siguiente sitio web:

Si solo se dirige a clientes anteriores a Office 2007 y no desea requerir el uso de Open XML en la solución, puede usar formatos de archivo de Office no binarios, como HTML, XML y RTF. Así, puede transmitir estos archivos a un cliente mediante un tipo MIME para que el texto resultante aparezca en Office. El documento se puede editar, guardar e incluso devolverse al servidor al usar de ASP en el servidor.

Para más información sobre cualquiera de estos temas y ejemplos sobre cómo implementarlos, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

198703 Cómo automatizar Excel desde VBScript de cliente
278973 ExcelADO muestra cómo usar ADO para leer y escribir datos en libros de Excel
286023 Cómo utilizar un componente ActiveX de VB para automatización de Word desde Internet Explorer
 

Si su empresa requiere la creación en el servidor de los formatos de archivo binario de Office 97, Office 2000, Office XP y Office 2003, hay proveedores externos que ofrecen componentes que pueden ayudarlo. Microsoft no proporciona este tipo de componentes, por lo que tendrá que crear una solución usted mismo o comprar una de un proveedor externo. Hay muchos productos de terceros disponibles. Debería investigar cada solución que mejor se adecue a sus necesidades empresariales.

Si desea crear su propia solución que edite los formatos de archivo binario de Office 97, Office 2000, Office XP y Office 2003 directamente, puede obtener las especificaciones de formato de archivo de manera gratuita según los términos de Microsoft Open Specification Promise (OSP). No hay soporte técnico disponible para la documentación o los productos que usted crea, pero hay documentación disponible. 


Las soluciones en el servidor también podrían dejar a los usuarios cargar archivos y luego hacer que el servidor presente los archivos para su visualización en Internet u otros soportes. Microsoft está trabajando para ofrecer estas características y proporciona una versión preliminar de esta capacidad en Microsoft Excel Services.

Excel Services es una nueva tecnología de servidor que se incluye en Microsoft Office SharePoint Server 2007 y que permite cargar, calcular y mostrar libros de Excel en Office SharePoint Server 2007. Para más información sobre Excel Services, visite los siguientes sitios web de Microsoft Developer Network (MSDN):

Word Automation Services es una nueva aplicación de servicio en SharePoint Server 2010. Word Automation Services proporciona una conversión desatendida en el servidor de documentos a formatos compatibles con la aplicación cliente Microsoft Word.Debe evaluar qué opción de las que se describen en este artículo satisface sus necesidades y cuál es la mejor manera de implementar la solución. No se garantiza que la información que se proporciona en este artículo solucione todos los problemas de todos los clientes. Se aconseja que realice pruebas exhaustivas de su solución antes de la implementación.