Compartir a través de

Seleccionar una API o tecnología para desarrollar soluciones de Outlook

  • Artículo

En este artículo se describen las API y las tecnologías que puede usar para ampliar Outlook 2013 y Outlook 2016 y se ofrece ayuda para decidir cuál será la API o tecnología adecuada para su escenario.

Microsoft admite diversas API y tecnologías que amplían Outlook:

  • A partir de Office 2013, la plataforma de aplicaciones para Office presenta oportunidades para ampliar la funcionalidad de Outlook en los clientes de Outlook en equipos de escritorio, tabletas y smartphones. La plataforma incluye una API de JavaScript para Office y un esquema para los manifiestos de aplicación.

  • El modelo de objetos, el ensamblado de interoperabilidad primario (PIA) de Outlook correspondiente y la API de mensajería (MAPI) han sido las API usadas con más frecuencia en las soluciones de Outlook.

  • Las API auxiliares complementan a MAPI en algunos escenarios.

  • La extensibilidad de proveedores de Outlook Social Connector (OSC) y la extensibilidad de Barra de meteorología sirven para escenarios específicos de sus mercados nicho.

En este artículo se explican los criterios de selección para la plataforma de Complementos de Office, el modelo de objetos, PIA y MAPI. Tenga en cuenta que las Complementos de Office usan la API de JavaScript para Office y que no llaman al modelo de objetos, y viceversa. Las soluciones que usan las otras API pueden usar una o más API. Por ejemplo, un complemento COM escrito en C++ puede usar el modelo de objetos, MAPI y API auxiliares en la misma solución.

Para sacar el máximo provecho de este artículo, debe estar familiarizado con Outlook en el nivel de usuario y tener conocimientos sobre el desarrollo de software en general. Sin embargo, no es necesario tener conocimientos exhaustivos sobre las características que admiten estas API o tecnologías. El artículo ayuda a responder las preguntas siguientes:

  • Si solo tiene una idea general acerca de los objetivos de la solución, el mercado objetivo y los recursos disponibles, ¿qué otros criterios debe tener en cuenta para seleccionar una API?

  • ¿Por qué tendría en cuenta las Complementos de Office y cuándo decidiría crear aplicaciones en lugar de complementos?

  • Si la solución se tiene que ejecutar en versiones anteriores de Outlook, incluido Outlook 2003, ¿cómo afecta esto a su elección de API?

  • Si la solución tiene que iterar en carpetas de Outlook que contienen miles de elementos y debe ser capaz de modificar estos elementos, ¿qué API funcionaría mejor?

  • Si la solución depende en gran medida de la lógica de negocios de Outlook e interactúa con otras aplicaciones de Office, ¿el modelo de objetos de Outlook es la mejor opción?

  • ¿Qué elementos de Outlook le permiten ampliar el modelo de objetos y MAPI?

  • Si puede usar el modelo de objetos o MAPI para completar la tarea, ¿cómo debe decidir qué API usar?

Criterios de evaluación objetivos

En esta sección se describen los criterios que puede usar para comparar la plataforma de Complementos de Office, el modelo de objetos, PIA y MAPI para determinar cuál satisface mejor sus necesidades. Distintos criterios pueden ser más o menos importantes, en función de los proyectos y recursos disponibles.

Las tablas de esta sección definen criterios de evaluación en las siguientes categorías:

  • Criterios funcionales: describe qué se puede y no se puede hacer con la tecnología.

  • Criterios de desarrollo: describe las herramientas de desarrollo o la información que necesita para usar la tecnología.

  • Criterios de seguridad: describe los problemas de seguridad y permisos relacionados con la tecnología.

  • Criterios de implementación: describe los métodos recomendados de implementación y distribución de la tecnología.

Criterios de evaluación objetiva de la plataforma de aplicaciones para Office

A partir de Office 2013, los desarrolladores pueden usar la plataforma de Complementos de Office para ampliar los servicios web y el contenido en el contexto de clientes enriquecidos y web de Office. Una Complemento de Office es una página web desarrollada con tecnologías web habituales, hospedada dentro de una aplicación cliente de Office (como Outlook) y que puede ejecutarse localmente o en la nube. De los tipos de Complementos de Office, el que es compatible con Outlook se denomina aplicaciones de correo. Aunque el modelo de objetos, PIA y MAPI se usan a menudo para automatizar Outlook en el nivel de aplicación, puede usar la API de JavaScript para Office para interactuar en el nivel de elemento con el contenido y las propiedades de un mensaje de correo electrónico, convocatoria de reunión. Puede publicar aplicaciones de correo en la Tienda Office o en un catálogo interno de Exchange.

Los usuarios finales y los administradores pueden instalar aplicaciones de correo en un buzón de Exchange y usar aplicaciones de correo en el cliente enriquecido y en Outlook Web App. Como desarrollador, puede hacer que la aplicación de correo esté disponible solo en equipos de escritorio o también en tabletas o smartphones. En la Figura 1 se muestra un ejemplo de una aplicación de correo de YouTube, que se describe detalladamente en Procedimiento para crear una aplicación de correo para Outlook 2013 Preview para ver vídeos de YouTube. La aplicación de correo de YouTube permite a los usuarios finales seleccionar una dirección URL de un vídeo de YouTube y ver el vídeo en Outlook u Outlook Web App, en un equipo de escritorio o una tableta.

Figura 1. La aplicación de correo de YouTube está activa para el mensaje seleccionado, que contiene una dirección URL de un vídeo de YouTube.com.

Aplicación de correo de YouTube en Outlook

Cuando un usuario instala una aplicación de correo, la aplicación está disponible para usarla en la barra de aplicaciones si el contexto actual coincide con las condiciones de activación especificadas por la aplicación. Las aplicaciones de correo le permiten especificar reglas sobre el elemento seleccionado que activan una aplicación de correo solo si se cumplen ciertas condiciones. Por ejemplo, la aplicación de correo de YouTube que permite reproducir un vídeo de YouTube en Outlook es importante solo cuando el elemento de Outlook seleccionado contiene una dirección URL a un vídeo de YouTube.com. En este caso, sería necesario especificar que la aplicación esté activada solo cuando el mensaje seleccionado contiene dicha dirección URL.

En las tablas siguientes se muestran los criterios de evaluación de la plataforma de Complementos de Office.

Criterios funcionales

Criterios Compatibilidad con aplicaciones de correo en la plataforma de aplicaciones para Office
Dominio de aplicación El ámbito de actividad de una aplicación de correo es prácticamente cualquier elemento de mensaje o cita admitido en el buzón de Exchange del usuario que haya seleccionado el usuario y que cumpla las condiciones de activación. Los permisos de una aplicación de correo determinan su acceso a las propiedades y las entidades específicas (por ejemplo, una dirección de correo electrónico o un número de teléfono) que existen para ese elemento. Por ejemplo, una aplicación web que solicita el permiso lectura/escritura de buzón puede leer y escribir todas las propiedades de cualquier elemento del buzón del usuario, crear, leer y escribir en cualquier carpeta o elemento, y enviar un elemento de dicho buzón.
Objetos principales La API de JavaScript para Office proporciona unos cuantos objetos en el nivel superior que comparten todos los tipos de Complementos de Office: Office, Context y AysncResult. El nivel siguiente de la API aplicable y específico de las aplicaciones de correo incluye los objetos Mailbox, Item y UserProfile, que admiten el acceso a la información sobre el usuario y el elemento seleccionado actualmente en el buzón del usuario. En el nivel de datos, los objetos CustomProperties y RoamingSettings admiten la persistencia de propiedades configuradas por la aplicación de correo para el elemento seleccionado y para el buzón del usuario, respectivamente. Los objetos de nivel de elemento incluyen los objetos Appointment y Message que heredan de Item y el objeto MeetingRequest que hereda de Message. Estos objetos representan los tipos de elementos de Outlook que son compatibles con las aplicaciones de correo: elementos de calendario de citas y reuniones, y elementos de mensaje como mensajes de correo electrónico, convocatorias de reunión, respuestas y cancelaciones. Además de este nivel, en la API encontramos propiedades de nivel de elemento (como Appointment.subject), así como objetos y propiedades que admiten ciertos objetos Entities conocidos (por ejemplo, Contact, MeetingSuggestion, PhoneNumber y TaskSuggestion). Vea Aspectos básicos para el desarrollo de aplicaciones de correo en Outlook 2013 Preview para obtener un resume de las características compatibles con las aplicaciones de correo.
Modelo de acceso a datos La API de JavaScript para Office representa las siguientes características como un conjunto jerárquico de objetos: entorno en tiempo de ejecución de la aplicación, buzón y perfil del usuario y datos acerca de un elemento.
Modelos de subprocesos Cada aplicación de correo se ejecuta en su propio proceso independiente del proceso de Outlook.
Arquitecturas de aplicación En Outlook, una aplicación de correo es un conjunto de páginas HTML y JavaScript hospedadas como proceso independiente dentro de un control de explorador web que, a su vez, está hospedado dentro de un proceso en tiempo de ejecución de una aplicación que proporciona seguridad y aislamiento para rendimiento.
Uso remoto Las aplicaciones de correo usan la API de JavaScript para Office para tener acceso a datos sobre el usuario actual, el buzón y el elemento seleccionado almacenado en el servidor Exchange correspondiente. Siempre que tengan los permisos adecuados y usen la técnica apropiada para el acceso entre dominios, las aplicaciones de correo también pueden llamar a servicios Web Exchange y a otros servicios web de terceros para ampliar su funcionalidad.
Transacciones La API de JavaScript para Office no admite transacciones.
Disponibilidad La API de JavaScript para Office está disponible para los buzones de Exchange Server 2013, a partir Outlook 2013.

Criterios de desarrollo

Criterios Compatibilidad con aplicaciones de correo en la plataforma de aplicaciones para Office
Lenguajes y herramientas Puede implementar aplicaciones de correo con cualquier tecnología web habitual, como HTML5, JavaScript, CSS3, XML y API de REST. Puede usar la herramienta de desarrollo web que prefiera. Como alternativa, con Napa, Visual Studio 2012 o una versión posterior de estas herramientas, logrará ahorrar tiempo en el desarrollo.
Implementación administrada Cuando resulte apropiado en su escenario, puede usar páginas .aspx administradas para implementar código de servidor en las aplicaciones de correo.
Permite scripts La API de JavaScript para Office se usa directamente en scripts.
Herramientas de prueba y depuración Puede usar las herramientas de desarrollo web que prefiera. Napa y Visual Studio proporcionan un entorno de desarrollo integrado que facilita las pruebas y depuración de aplicaciones. Solucionar problemas relacionados con la activación de los complementos de Outlook y Procedimiento para depurar propiedades en elementos de Outlook proporcionan más ayuda para solucionar problemas de aplicaciones de correo y depurarlas.
Disponibilidad de expertos Es relativamente fácil encontrar programadores que tengan el nivel de experiencia en desarrollo web necesario para Complementos de Office. La plataforma está pensada para desarrolladores tanto profesionales como no profesionales.
Información disponible Encontrará información sobre cómo desarrollar y publicar Complementos de Office en Crear aplicaciones para Office y SharePoint. Encontrará documentación específica sobre las aplicaciones de correo en Aplicaciones de correo para Outlook 2013 Preview.
Licencias de desarrollador e implementación Consulte Licencias de complementos de Office y SharePoint para obtener información sobre el marco de licencias de aplicaciones para Complementos de Office.

Criterios de seguridad

Criterios Compatibilidad con aplicaciones de correo en la plataforma de aplicaciones para Office
Permisos en tiempo de diseño No se necesitan permisos especiales para desarrollar aplicaciones de correo.
Permisos de instalación De manera predeterminada, los usuarios finales y los administradores pueden instalar aplicaciones de correo de nivel de confianza bajo que requieran el permiso Restringido o Leer elemento, y los administradores pueden instalar aplicaciones de nivel de confianza alto que requieran el permiso Buzón de lectura y escritura.
Permisos en tiempo de ejecución Las aplicaciones de correo solicitan un nivel de permisos específico que se basa en un modelo de permisos de tres niveles: Restringido, Leer elemento y Buzón de lectura y escritura.
Características de seguridad integradas El tiempo de ejecución de complementos de Office proporciona las siguientes ventajas para evitar que una aplicación dañe el entorno del usuario final: aísla el proceso en el que se ejecuta la aplicación. No implica el reemplazo de archivos .dll o .exe ni de componentes ActiveX. Facilita la instalación o desinstalación de aplicaciones por parte del usuario final. El administrador y los usuarios finales tienen control sobre las aplicaciones de correo que están disponibles y si se debe conceder el permiso solicitado antes de instalar una aplicación de correo. En el caso de los clientes enriquecidos, regula el uso de memoria y CPU para evitar ataques maliciosos por denegación servicio.
Características de supervisión de seguridad En el caso de las aplicaciones de correo, se supervisan los siguientes recursos: uso del núcleo de CPU. Uso de memoria. Número de bloqueos. Duración de bloqueo de una aplicación. Tiempo de respuesta de expresiones regulares. Número de veces que se vuelven a evaluar las expresiones regulares. Los administradores pueden reemplazar la configuración predeterminada que rige el uso de recursos.

Criterios de implementación

Criterios Compatibilidad con aplicaciones de correo en la plataforma de aplicaciones para Office
Requisitos de plataforma del servidor El buzón del usuario para el que se instale una aplicación de correo debe estar en Exchange Server 2013 o una versión posterior.
Requisitos de plataforma del cliente Para que una aplicación de correo se ejecute en el cliente enriquecido de Outlook, Outlook 2013 e Internet Explorer 9, o una versión posterior de estas aplicaciones, debe estar instalada en el equipo local.
Métodos de implementación Puede publicar aplicaciones de correo en la Tienda Office o en un catálogo de Exchange que ponga la aplicación a disposición de los usuarios en ese servidor Exchange. A continuación, los administradores pueden decidir instalar una aplicación de correo desde la Tienda Office o el catálogo de Exchange, por medio del Centro de administración de Exchange (EAC) o de cmdlets de Windows PowerShell remotos. Puede acceder al EAC desde la vista Backstage de Outlook o desde Outlook Web App, o iniciando sesión directamente en el EAC del buzón. Para obtener más información, vea Implementar e instalar aplicaciones de correo para probar en Outlook 2013 Preview.
Notas de implementación Una vez que se instala una aplicación de correo en Outlook o Outlook Web App, la aplicación de correo está disponible para ese buzón en ambos clientes de Outlook.

Criterios de evaluación objetiva para el modelo de objetos y PIA

Las soluciones que se ejecutan en el equipo cliente pueden usar el modelo de objetos o PIA de Outlook para obtener acceso mediante programación a los elementos de Outlook, como los contactos, los mensajes, los elementos de calendario, las convocatorias de reunión y las tareas. A diferencia de MAPI, el modelo de objetos y PIA de Outlook pueden proporcionar notificaciones de eventos para los cambios en la interfaz de usuario de Outlook, como cambiar la carpeta actual o mostrar un inspector de Outlook.

Nota:

[!NOTA] Para que una solución pueda tener acceso a los datos almacenados en un buzón de Microsoft Exchange o un archivo de carpetas temporales (.pst), Outlook debe estar instalado y configurado en el equipo cliente en el que se ejecuta la aplicación. > El modelo de objetos y pia de Outlook admiten la misma funcionalidad para ampliar Outlook. PIA define las interfaces administradas que se asignan al modelo de objetos basado en COM y con las que puede interactuar una solución administrada. En los temas restantes de esta sección, la mayoría de los criterios funcionales, de seguridad y de implementación se aplican al modelo de objetos y PIA de la misma manera. Para obtener más información sobre cómo el PIA facilita la interoperabilidad entre COM y .NET Framework, consulte Introducción a la interoperabilidad entre COM y .NET y Arquitectura del PIA de Outlook.

En las tablas siguientes se muestran los criterios de evaluación para el modelo de objetos y PIA de Outlook.

Criterios funcionales

Criterios Modelo de objetos o PIA de Outlook
Dominio de aplicación Los complementos o las aplicaciones independientes que usan el modelo de objetos o PIA de Outlook suelen encargarse de mensajes específicos del usuario, personalizar la interfaz de usuario de Outlook o crear tipos de elementos personalizados para soluciones especializadas, como soluciones de administración de relaciones con el cliente (CRM) que se integran con Outlook. A veces, el modelo de objetos o PIA de Outlook se usan para procesar mensajes en un proceso de flujo de trabajo informal, especialmente cuando no se permite el desarrollo de aplicaciones en el servidor Microsoft Exchange. A diferencia de los clientes basados en explorador, el funcionamiento en modo en caché permite a las soluciones de Outlook funcionar cuando el usuario está sin conexión o desconectado de la red corporativa.
Objetos principales El objeto de nivel superior del modelo de objetos y PIA de Outlook es el objeto Application de Outlook. Explorers, Conversation, Inspectors, Views, NavigationPane, SolutionsModule, FormRegion y los objetos relacionados representan elementos de la interfaz de usuario de Outlook. Los objetos NameSpace, Stores, Folders, Accounts, AccountSelector, AddressEntries, ExchangeUsery los objetos relacionados admiten la ampliación de las sesiones, los perfiles, las cuentas de usuario, los almacenes de mensajes y las carpetas de Outlook. En el nivel de datos, una serie de objetos de nivel de elemento, como MailItem, AppointmentItem, ContactItem y TaskItem, representan los tipos de elementos integrados de Outlook. Los objetos PropertyAccessor, Table, Search, ItemProperties, UserDefinedProperties, Attachments, Categories, Recipients, RecurrencePattern, Reminders, Rules y los objetos relacionados admiten la personalización y la manipulación de objetos de nivel de elemento.
Modelo de acceso a datos El modelo de objetos y PIA de Outlook representan todos los datos como un conjunto jerárquico de objetos y colecciones.
Modelos de subprocesos Todas las llamadas al modelo de objetos y PIA de Outlook se ejecutan en el subproceso en primer plano principal de Outlook. El único modelo de subprocesamiento que admite el modelo de objetos de Outlook es un contenedor uniproceso (STA). Llamar al modelo de objetos o PIA de Outlook desde un subproceso en segundo plano no es compatible y puede llevar a errores y resultados inesperados en la solución.
Arquitecturas de aplicación Por lo general, los complementos COM y otras aplicaciones de Office usan el modelo de objetos de Outlook para ampliar Outlook. Las soluciones administradas pueden usar PIA de Outlook y la capa de interoperabilidad COM de Visual Studio y .NET Framework para tener acceso al modelo de objetos de Outlook. Visual Studio proporciona plantillas y bibliotecas de clases y manifiestos adicionales para facilitar las personalizaciones de documentos y aplicaciones de Office. Para obtener más información sobre el uso de Visual Studio para desarrollar complementos administrados para Outlook, vea Architecture of Application-Level Add-Ins y Outlook Solutions. El modelo de objetos de Outlook también es compatible con macros de Visual Basic para Aplicaciones (VBA) y Windows Scripting Host (WSH), pero no es compatible con las aplicaciones de servicios de Windows.
Uso remoto El modelo de objetos y PIA de Outlook pueden usarse solo en un equipo en el que Outlook esté instalado. El modelo de objetos de Outlook puede usarse para tener acceso a la información almacenada en Exchange que está disponible en la aplicación de Outlook.
Transacciones El modelo de objetos y PIA de Outlook no admiten transacciones.
Disponibilidad El modelo de objetos de Outlook está disponible actualmente en todas las versiones de Outlook. PIA está disponible en las versiones de Outlook a partir de Outlook 2003. Ha habido ampliaciones y mejoras con cada nueva versión de Outlook.

Criterios de desarrollo

Criterios Modelo de objetos o PIA de Outlook
Lenguajes y herramientas Puede implementar aplicaciones del modelo de objetos de Outlook con cualquier lenguaje compatible con automatización o COM, como Visual Basic o C#, así como con lenguajes no COM, como C o C++ nativos. Herramientas de desarrollo de Microsoft Office en Microsoft Visual Studio 2010 son las herramientas preferentes para desarrollar complementos administrados para Outlook 2010 y Outlook 2007. Microsoft Visual Studio 2005 Tools para Microsoft Office System son las herramientas preferentes para Outlook 2003. También puede usar Herramientas de desarrollo de Office en Visual Studio 2010 para crear soluciones para las versiones de 32 y 64 bits de Outlook. Al crear una solución en Herramientas de desarrollo de Office en Visual Studio 2010 o Microsoft Visual Studio Tools para Microsoft Office System, si especifica la opción Cualquier CPU para la plataforma de destino, las soluciones administradas funcionarán tanto en las versiones de 32 bits como en las de 64 bits de Outlook 2010.
Implementación administrada El PIA de Outlook permite usar el modelo de objetos de Outlook en un entorno de código administrado, que es compatible con un amplio conjunto de bibliotecas de clases y tecnologías de soporte técnico que abordan muchas limitaciones de los complementos VBA y COM. Pia es un contenedor COM que actúa como un puente entre los entornos administrados y COM. Para más información, vea Why Use the Outlook PIA.
Permite scripts El modelo de objetos de Outlook se puede usar en scripts.
Herramientas de prueba y depuración No se necesitan herramientas de depuración especiales para usar el modelo de objetos o PIA de Outlook. Por otra parte, puede usar Visual Studio para proporcionar un entorno de desarrollo integrado que facilita la depuración y las pruebas de aplicaciones.
Disponibilidad de expertos Es relativamente fácil encontrar desarrolladores que puedan desarrollar correctamente aplicaciones mediante el modelo de objetos o PIA de Outlook. El modelo de objetos y PIA de Outlook están pensados para complementos creados con herramientas de desarrollo de amplia disponibilidad, como Visual Studio. Estas herramientas ofrecen entornos en tiempo de diseño que simplifican el proceso de desarrollo.
Información disponible También hay información sobre la programación con el modelo de objetos de Outlook disponible en los recursos de Microsoft y de terceros. Para obtener más información sobre el modelo de objetos de Outlook, vea la Referencia del desarrollador de Outlook 2010. Para obtener más información sobre PIA de Outlook, vea la Referencia del ensamblado de interoperabilidad primario de Outlook 2010. Para ver ejemplos de soluciones administradas de Outlook desarrolladas con las herramientas de desarrollo de Office en Visual Studio, vea Soluciones de Outlook con Visual Studio.
Licencias de desarrollador e implementación Consulte los acuerdos de licencias de suscripción a Exchange y Microsoft Developer Network (MSDN) para determinar si se necesitan licencias adicionales para Outlook y el uso del modelo de objetos de Outlook en las aplicaciones.

Criterios de seguridad

Criterios Modelo de objetos o PIA de Outlook
Permisos en tiempo de diseño No se necesitan permisos especiales para desarrollar aplicaciones mediante el modelo de objetos o PIA de Outlook.
Permisos de instalación No se necesitan permisos especiales para instalar aplicaciones que usan el modelo de objetos o PIA de Outlook. Sin embargo, se necesitan derechos de administrador local para instalar Office y Outlook.
Permisos en tiempo de ejecución No se necesitan permisos especiales para ejecutar aplicaciones que usan el modelo de objetos o PIA de Outlook.
Características de seguridad integradas El modelo de objetos y PIA de Outlook se comunican con Exchange mediante MAPI y con Active Directory mediante las interfaces ADSI. El contexto de seguridad actual del usuario que está ejecutando la aplicación se usa para determinar a qué recursos puede tener acceso el código. De manera predeterminada, los complementos son de confianza para obtener acceso completo a todos los objetos, propiedades y métodos del modelo de objetos o PIA de Outlook. Los administradores de TI pueden controlar los objetos y complementos que pueden tener acceso al modelo de objetos o PIA de Outlook. El modelo de objetos y PIA de Outlook evitan que el código que se ejecuta fuera del proceso de Outlook tenga acceso a métodos y objetos seguros.
Características de supervisión de seguridad Outlook supervisa las siguientes métricas de un complemento para determinar si debe deshabilitar el complemento: Modificador de carpeta de apagado de inicio Elemento abierto Invocar frecuencia Los administradores pueden usar la directiva de grupo para invalidar la configuración del usuario y controlar los complementos que se ejecutan en los equipos del usuario. Para obtener más información, vea Criterios de rendimiento para mantener los complementos habilitados.

Criterios de implementación

Criterios Modelo de objetos o PIA de Outlook
Requisitos de plataforma del servidor El modelo de objetos y PIA de Outlook son tecnologías de cliente.
Requisitos de plataforma del cliente Las aplicaciones que usan el modelo de objetos o PIA de Outlook para tener acceso a los datos de Exchange requieren que Outlook esté instalado en el equipo local.
Métodos de implementación Las aplicaciones que usan el modelo de objetos o PIA de Outlook se distribuyen mediante software de instalación de aplicaciones estándar.
Notas de implementación Como Outlook no debe instalarse en el Exchange Server, las aplicaciones que usan el modelo de objetos o PIA de Outlook no se pueden ejecutar en Exchange Server.

Criterios de evaluación objetiva de MAPI

Puede usar MAPI para obtener acceso a elementos y carpetas en almacenes públicos y privados, así como acceso a las propiedades que se almacenan con cada elemento. Todas las versiones de Outlook usan MAPI. Puede crear clientes que usen MAPI, así como crear servidores MAPI y controladores de formularios MAPI. La información de esta sección solo se aplica a las aplicaciones de cliente MAPI.

Nota:

[!NOTA] MAPI es un mecanismo avanzado que se usa para tener acceso a la información de Exchange o de un archivo de carpetas personales (.pst) y proporciona algunas capacidades que no están disponibles en ninguna otra API. Sin embargo, MAPI no funciona fuera de una intranet, mantiene una conexión abierta durante la sesión de MAPI y puede ser difícil de aprender. MAPI no exige la lógica empresarial de Outlook, por lo que debe tener especial cuidado para garantizar que se mantenga la lógica empresarial de Outlook.

En las tablas siguientes se muestran los criterios de evaluación de MAPI.

Criterios funcionales

Criterios MAPI
Dominio de aplicación Las aplicaciones cliente que usan MAPI para tener acceso a un buzón de usuario o información de carpetas públicas de Exchange almacenada, y a información de directorio de usuario almacenada en Active Directory. Las aplicaciones cliente que usan MAPI suelen ser clientes de correo electrónico, como Outlook y aplicaciones que requieren procesamiento de correo electrónico complejo.
Objetos principales Los objetos de MAPI se obtienen por medio de la interfaz IMAPISession: IUnknown. El objeto de sesión proporciona el acceso del cliente a objetos para trabajar con perfiles, estado, administración del proveedor de servicio de mensajes, tablas del almacén de mensajes y libretas de direcciones de MAPI. La tabla del almacén de mensajes contiene objetos para el almacén de mensajes, carpetas, mensajes, datos adjuntos y destinatarios. Las tablas de la libreta de direcciones contienen objetos para enviar mensajes a usuarios y listas de distribución.
Modelo de acceso a datos MAPI representa los mensajes y los usuarios como un conjunto jerárquico de objetos.
Modelos de subprocesos No hay ninguna prohibición de subprocesos específica. No obstante, las aplicaciones que usan el subprocesamiento libre deben evitar compartir objetos MAPI entre subprocesos debido a los altos costos del cálculo de referencias del objeto. MAPI y los proveedores de servicios MAPI usan el subprocesamiento libre.
Arquitecturas de aplicación Las aplicaciones de cliente MAPI suelen ser aplicaciones cliente basadas en Windows Forms. Sin embargo, puede usar MAPI para escribir aplicaciones de n niveles.
Uso remoto MAPI usa llamadas a procedimiento remoto (RPC) para comunicarse con Exchange Server. Por lo general, las RPC se bloquean intencionadamente para que no pasen a través de firewalls de Internet.
Transacciones MAPI no admite transacciones.
Disponibilidad En la actualidad, se incluye código auxiliar MAPI en todas las versiones de Windows. Office instala su propio subsistema MAPI cuando instala Outlook. No se prevén cambios en MAPI en este momento.

Criterios de desarrollo

Criterios MAPI
Lenguajes y herramientas Puede tener acceso directo a MAPI mediante C o C++. Otros lenguajes que puedan tener acceso a la convención de llamada de C o C++ podrían tener acceso a MAPI. No se admite el uso de lenguajes administrados, como Visual Basic o C#. Debe compilar soluciones MAPI independientes para las versiones de 32 bits y de 64 bits de Outlook.
Implementación administrada MAPI es un componente no administrado. No se admite el uso de MAPI en la capa de interoperabilidad COM de Visual Studio y .NET Framework.
Permite scripts MAPI no se puede usar directamente en scripts.
Herramientas de prueba y depuración No se necesitan herramientas de depuración especiales para depurar las aplicaciones que usan MAPI. Por otra parte, puede usar MFCMAPI. MFCMAPI usa MAPI para proporcionar acceso a los almacenes de MAPI por medio de una interfaz gráfica de usuario y facilita la investigación de problemas al ampliar Outlook por medio de MAPI.
Disponibilidad de expertos Puede resultar difícil encontrar programadores de MAPI expertos y puede tardarse bastante tiempo en dominar la tecnología. Además de las Comunidades de Microsoft, solo hay unos cuantos sitios web de terceros de alta calidad que proporcionen información útil de desarrollo de MAPI.
Información disponible Hay disponibles libros tanto de Microsoft como de terceros que describen la programación de MAPI.
Licencias de desarrollador e implementación No se requieren licencias espaciales para desarrollar aplicaciones que usan MAPI.

Criterios de seguridad

Criterios MAPI
Permisos en tiempo de diseño El desarrollador debe tener permisos de acceso a los datos del almacén de Exchange. Exchange almacena información de usuarios y listas de distribución en Active Directory, de modo que los desarrolladores que creen aplicaciones cliente MAPI que tengan acceso a esa información deben poder recuperar y establecer esa información.
Permisos de instalación Para configurar las aplicaciones basadas en MAPI normalmente se requiere que el usuario sea administrador local o que tenga derechos para instalar software.
Permisos en tiempo de ejecución Para ejecutar una aplicación basada en MAPI normalmente solo se requiere que el usuario tenga permisos suficientes para tener acceso a los datos de un almacén de Exchange o un archivo de carpetas personales (.pst).
Características de seguridad integradas Los perfiles de MAPI se pueden proteger mediante contraseña en la mayoría de plataformas.

Criterios de implementación

Criterios MAPI
Requisitos de plataforma del servidor El servidor Exchange en el que se almacenan los datos de usuario para los usuarios de la aplicación cliente MAPI debe configurarse correctamente para permitir el acceso de los clientes MAPI.
Requisitos de plataforma del cliente El instalador de la aplicación cliente debe comprobar que la versión correcta de MAPI esté disponible en el equipo y que esté configurada correctamente con el archivo Mapisvc.inf.
Métodos de implementación Las aplicaciones que usan MAPI se pueden implementar en los equipos cliente mediante el uso de tecnologías de distribución de software estándar.
Notas de implementación El instalador debe comprobar que la versión correcta de MAPI esté disponible.

Factores de decisión para la plataforma de aplicaciones para Office

Como las Complementos de Office usan tecnologías web, se recomiendan para conectarse a servicios locales o en la nube y para traer los servicios al contexto del cliente enriquecido y el cliente web. Al solicitar los permisos adecuados, las aplicaciones de correo también permiten leer, escribir o enviar elementos de un buzón.

A continuación se indican los motivos habituales por los que las aplicaciones de correo son una mejor opción para los desarrolladores que los complementos:

  • Puede usar los conocimientos existentes y las ventajas de las tecnologías web como HTML, JavaScript y CSS. Para usuarios avanzados y desarrolladores principiantes, XML, HTML y JavaScript requieren menos tiempo de aprendizaje que las API basadas en COM, incluidos el modelo de objetos y MAPI.

  • Puede usar un modelo de implementación web sencillo para actualizar la aplicación de correo (incluidos los servicios web que usa la aplicación) en el servidor web sin instalaciones complejas en el cliente de Outlook. De hecho, las actualizaciones de la aplicación de correo, a excepción del manifiesto de la aplicación, no requieren ninguna actualización del cliente de Office. Puede actualizar la interfaz de usuario o el código de la aplicación de correo cómodamente en el servidor web. Esto supone una ventaja significativa respecto a la carga administrativa de la actualización de complementos.

  • Puede usar una plataforma de desarrollo web común para aplicaciones de correo que puedan itinerar entre el cliente enriquecido de Outlook y Outlook Web App en equipos de escritorio, tabletas y smartphones. Por otra parte, los complementos usan el modelo de objetos para el cliente enriquecido de Outlook y, por lo tanto, se pueden ejecutar solo en ese cliente enriquecido en un factor de forma de escritorio.

  • Puede disfrutar de un tiempo de procesamiento rápido en el desarrollo y la publicación de aplicaciones a través de la Tienda Office.

  • Debido al modelo de permisos de tres niveles, los usuarios y los administradores tienen la sensación de que la seguridad y la privacidad son mejores en las aplicaciones que en los complementos, que tienen acceso total al contenido de cada una de las cuentas del perfil del usuario. Esto, a su vez, favorece el consumo de aplicaciones por parte de los usuarios.

  • En función de los escenarios, hay características específicas de las aplicaciones de correo que puede aprovechar y que no son compatibles con los complementos:

    • Puede especificar que una aplicación de correo se active solo en ciertos contextos (por ejemplo, Outlook muestra la aplicación en la barra de aplicaciones solo si la clase de mensaje de la cita seleccionada por el usuario es IPM.Appointment.Contoso o si el cuerpo de un correo electrónico contiene un número de seguimiento de paquete o un identificador de cliente).

    • Puede activar una aplicación de correo si el mensaje seleccionado contiene algunas entidades conocidas, como una dirección, un contacto, una dirección de correo electrónico, una sugerencia de reunión o una sugerencia de tarea.

    • Puede aprovechar la autenticación por medio de tokens de identidad y de los servicios Web Exchange.

No obstante, las siguientes características son exclusivas de los complementos y pueden hacer que sean una opción más apropiada que las aplicaciones de correo en algunas circunstancias:

  • Puede usar complementos para ampliar o automatizar Outlook en el nivel de aplicación, porque el modelo de objetos y PIA tienen una amplia integración con las características de Outlook (como todos los tipos de elementos, la interfaz de usuario, las sesiones y las reglas de Outlook). En el nivel de elemento, los complementos pueden interactuar con un elemento en modo de lectura o de redacción. Con las aplicaciones de correo, no puede automatizar Outlook en el nivel de aplicación y puede ampliar la funcionalidad de Outlook en el contexto únicamente del modo de lectura de los elementos compatibles (mensajes y citas) del buzón del usuario.

  • Puede especificar la lógica de negocios personalizada para un nuevo tipo de elemento.

  • Puede modificar y agregar comandos personalizados en la cinta y la vista Backstage.

  • Puede mostrar una página de formulario o un área de formulario personalizada.

  • Puede detectar eventos como el envío de un elemento o la modificación de las propiedades de un elemento.

  • Puede usar complementos Outlook 2013 y Exchange Server 2013, así como en las versiones anteriores de Outlook y Exchange. Por otro lado, las aplicaciones de correo funcionan con Outlook y Exchange a partir de Outlook 2013 y Exchange Server 2013, pero no versiones anteriores.

Para obtener más información acerca de los escenarios compatibles con el modelo de objetos y PIA, vea la siguiente sección, Factores de decisión para el modelo de objetos o PIA. Pera ver una comparación de la plataforma de Complementos de Office con otras tecnologías de extensibilidad para Office, vea la entrada de blog sobre los antecedentes de las aplicaciones para Office y SharePoint.

Factores de decisión para el modelo de objetos o PIA

Escenarios principales de línea base admitidos por el modelo de objetos de Outlook o PIA

Por lo general, utilice el modelo de objetos o PIA si la solución personaliza la interfaz de usuario de Outlook o se basa en la lógica empresarial de Outlook. A continuación se indican los principales escenarios básicos para los que las soluciones de Outlook usan el modelo de objetos o el PIA.

Escenarios admitidos por el modelo de objetos o PIA desde Outlook 2007

Además de los escenarios básicos, si su solución de Outlook es compatible con cualquiera de los escenarios que se muestran en la siguiente lista y la solución está pensada para ejecutarse en Outlook 2007 o posterior, pero no en versiones anteriores, también puede usar el modelo de objetos o el PIA. En esta sección se especifican los principales objetos o miembros que se pueden usar en el modelo de objetos de Outlook para ampliar cada escenario (con la excepción de la interfaz IDTExtensibility2 en el modelo de objetos de automatización de Visual Studio y la interfaz IRibbonExtensibility en el modelo de objetos de Office, que se puede integrar con el modelo de objetos de Outlook).

Escenarios admitidos por el modelo de objetos o PIA desde Outlook 2010

Si tiene previsto que su solución se ejecute en Outlook 2010 y no en versiones anteriores, puede usar el modelo de objetos o PIA para admitir los escenarios mostrados en la siguiente sección. En esta sección se especifican los principales objetos o miembros que se pueden usar en el modelo de objetos de Outlook para ampliar cada escenario (con la excepción de las interfaces IRibbonControl, IRibbonExtensibility, and IRibbonUI que hay en el modelo de objetos de Office, que se pueden integrar con el modelo de objetos de Outlook).

Escenarios admitidos por el modelo de objetos o PIA desde Outlook 2013

Si tiene previsto que su solución se ejecute en Outlook 2013 y no en versiones anteriores, puede usar el modelo de objetos o PIA para admitir los escenarios mostrados en los siguientes recursos.

Factores de decisión de MAPI

En general, use MAPI para tener acceso a datos de un servidor basado en MAPI, como el servidor Microsoft Exchange y para realizar tareas como las siguientes:

  • Crear un proveedor de servicios personalizado, como un proveedor de libretas de direcciones, un proveedor de transporte o un proveedor de almacén.

  • Crear un proceso de receptor.

  • Crear o manipular un perfil.

  • Ejecutar una aplicación como un servicio de Windows NT.

  • Ejecutar tareas en un subproceso en segundo plano. Por ejemplo, enumerar varios elementos en una carpeta y modificar las propiedades de los elementos en un subproceso de segundo plano pueden optimizar el rendimiento.

Para obtener más información y ejemplos de código, vea la Referencia MAPI de Outlook y MFCMAPI.

Además, si la solución se ejecuta en una versión de Outlook anterior a Outlook 2007 y se aplican escenarios como los siguientes a la solución, debe usar MAPI para ampliar esos escenarios.

  • Establecer y obtener propiedades de elemento integradas que no se exponen en el modelo de objetos.
  • Administrar cuentas, datos adjuntos, listas de distribución de Exchange, usuarios de Exchange o almacenes.
  • Almacenar datos privados para soluciones.
  • Administrar un almacén de mensajes de una cuenta.

Desde Outlook 2007, el modelo de objetos ha admitido una serie de características para las que, antes de Outlook 2007, los desarrolladores tenían que recurrir a MAPI u otras API como Objetos para colaboración de datos (CDO) de Microsoft 1.2.1 y Extensiones de clientes de Microsoft Exchange. Por tanto, si cualquiera de los escenarios de la lista anterior se aplica a su solución, pero esta se ejecuta en Outlook 2007 u Outlook 2010, puede y debe usar el modelo de objetos o PIA de Outlook para admitir estos escenarios. Para obtener más información acerca de las mejoras de Outlook 2007 que unifican las tecnologías de desarrollo de Outlook, vea What's New for Developers in Outlook 2007 (Part 1 of 2).

Factores de decisión para las API auxiliares

Las API auxiliares de Outlook pueden integrarse con la lógica de negocios de Outlook o MAPI en algunos escenarios donde el modelo de objetos o MAPI no proporcionan una solución. Use las API auxiliares de Outlook en los escenarios siguientes:

  • Administración de cuentas: administrar información de cuentas, manipular cuentas, proporcionar notificaciones de cambios en la cuenta y proteger las cuentas contra correo no deseado.
  • Degradación de datos: encapsular un objeto en un formato de carácter preferido en lugar de exponer el objeto en su formato nativo.
  • Reorganización de calendarios y compatibilidad con zonas horarias: reorganizar calendarios de Outlook para admitir el horario de verano.
  • Estado de disponibilidad: proporcionar información de disponibilidad en los calendarios.
  • Imágenes de contactos: determinar si se muestra de la imagen de un contacto en Outlook.
  • Moneda del elemento: determinar si un elemento de Outlook tiene cambios sin guardar.
  • Clasificar un elemento: clasificar un elemento de Outlook después de enviarlo.

Para obtener más información acerca de las API auxiliares, vea la sección Recursos adicionales: API auxiliares.

Automatización de Outlook con soluciones dentro del proceso o fuera del proceso

Nota:

La explicación sobre la automatización de Outlook que se incluye en esta sección y la siguiente queda fuera del ámbito de las Complementos de Office, cuya finalidad es ampliar la funcionalidad del cliente de Office o la aplicación web, pero no automatizarlos.

Outlook admite la automatización por medio de complementos que ejecutan el primer proceso en primer plano que el proceso de Outlook y por medio de soluciones independientes que se ejecutan en su propio proceso independiente fuera del proceso de Outlook. Por lo general, para automatizar Outlook, use un complemento para interactuar con Outlook a través del modelo de objetos, PIA o MAPI y, en escenarios menos habituales, a través de una API auxiliar (como HrProcessConvActionForSentItem). Use una solución fuera del proceso solo cuando sea necesario (por ejemplo, cuando escriba una aplicación cliente MAPI que use el archivo Tzmovelib.dll para reorganizar los calendarios de Outlook para clientes o para enumerar numerosos elementos en una carpeta y sus propiedades en un subproceso en segundo plano para optimizar el rendimiento).

Los complementos son la solución preferida para automatizar Outlook, ya que Outlook solo confía en el objeto Application pasado al complemento durante el evento OnConnection(Object, ext_ConnectMode, Object, Array) del complemento. Puede evitar visualizar advertencias de seguridad de la protección del modelo de objetos derivando todos los objetos, las propiedades y los métodos desde este objeto Application. Si el complemento crea una nueva instancia del objeto Application , Outlook no confía en ese objeto, incluso si el complemento está en la lista de complementos de confianza. Los objetos, propiedades y métodos derivados de este objeto Application no serán de confianza y las propiedades y métodos bloqueados invocarán advertencias de seguridad. Para obtener más información acerca de la protección del modelo de objetos, vea Security Behavior of the Outlook Object Model.

Automatización de Outlook con soluciones administradas y no administradas

Outlook admite la automatización con complementos y aplicaciones independientes, escritos en lenguajes administrados y no administrados. Los lenguajes administrados que se usan más habitualmente son C# y Visual Basic. Las herramientas de C++ y Delphi son más habituales en el desarrollo no administrado. Hay que tener en cuenta los conocimientos al elegir entre el desarrollo administrado y no administrado.

Si la solución solo usa el modelo de objetos, puede considerar la posibilidad de desarrollar una solución administrada por medio de PIA o de las herramientas de desarrollo de Office en Visual Studio. Las herramientas de desarrollo de Office en Visual Studio proporcionan plantillas de proyecto y diseñadores visuales que simplifican la creación de interfaces de usuario personalizadas y el desarrollo de soluciones de Office.

Por otra parte, como MAPI se desarrolló años antes que .NET Framework y Microsoft no proporciona contenedores administrados para MAPI, Microsoft no admite el uso de MAPI en el código administrado. Si usa MAPI, debe desarrollar una solución no administrada. Para obtener más información, vea las directrices de compatibilidad para el desarrollo de mensajería de cliente.

API y tecnologías de nicho

Outlook Social Connector (OSC) y la Barra de meteorología admiten la ampliación de escenarios muy concretos en Outlook.

Extensibilidad de proveedores de Outlook Social Connector (OSC)

La extensibilidad de proveedores de Outlook Social Connector (OSC) admite el desarrollo de un proveedor para una red social que permita a los usuarios ver, en Outlook y otras aplicaciones cliente de Office, actualizaciones de amigos y actividades en esa red social. En la Figura 6 se muestra OSC con las actividades de una persona en los sitios de redes sociales en el panel de personas.

Figura 6. OSC con datos de redes sociales en el panel de personas

Panel Outlook Social Connector

OSC en Outlook permite a los usuarios ver, en el panel de personas, una agregación de mensajes de correo electrónico, archivos adjuntos y convocatorias de reunión de una persona en Outlook. En un entorno de organización, los usuarios que colaboran en un sitio de SharePoint pueden ver actualizaciones de documentos y otras actividades del sitio de esta persona en el sitio de SharePoint. La extensibilidad de proveedores de Outlook Social Connector admite el desarrollo de un proveedor para que OSC sincronice y muestre actualizaciones de redes sociales en Outlook. Los proveedores de OSC habituales comunes (como Facebook y Linkedln) se instalan de manera predeterminada con Outlook. En función de los sitios de redes sociales en los que haya iniciado sesión un usuario de Outlook, el usuario puede ver, en el panel de personas, actualizaciones como fotos, estados y actividades en las redes sociales correspondientes.

Extensibilidad de la Barra de meteorología

A partir de Outlook 2013, la Barra de meteorología permite a los desarrolladores conectar un servicio web de meteorología de terceros para proporcionar datos de las condiciones meteorológicas para una ubicación elegida por el usuario. La Barra de meteorología de Outlook muestra las condiciones meteorológicas y la previsión del tiempo para una ubicación geográfica. Un usuario puede elegir una o varias ubicaciones y ver cómodamente los datos meteorológicos en la Barra de meteorología en el módulo de calendario. En la Figura 7 se muestra la Barra de meteorología con una previsión a tres días para Nueva York.

Figura 7. Barra de meteorología en Outlook

Barra de tiempo con la previsión para Nueva York

De manera predeterminada, Outlook usa datos meteorológicos proporcionados por MSN Clima. La Barra de meteorología es compatible con servicios web de datos meteorológicos de terceros que sigan un protocolo definido para comunicarse con Outlook. Siempre que un servicio de datos meteorológicos de terceros sea compatible con este protocolo, los usuarios podrán elegir dicho servicio para proporcionar datos meteorológicos en la Barra de meteorología.

Vea la sección Recursos adicionales: referencias y recursos principales y ejemplos de código para obtener más información sobre el uso de la extensibilidad de proveedores de OSC y la Barra de meteorología.

Conclusión

Para determinar la mejor API o tecnología para su solución, primero debe definir los objetivos de la solución:

  • Las versiones de Outlook que desea que admita su solución.

  • Los escenarios de alta prioridad de la solución. ¿La solución interactúa principalmente con el contenido y las propiedades de un elemento de mensaje o de cita? ¿O automatiza Outlook en el nivel de aplicación? Si es así, ¿estos escenarios implican enumerar, filtrar o modificar carpetas que contienen muchos elementos de Outlook?

En primer lugar, compruebe si la compatibilidad con aplicaciones de correo en la plataforma de Complementos de Office satisface sus necesidades. Vea la sección Criterios funcionales en Criterios de evaluación objetiva de la plataforma de aplicaciones para Office para determinar si los objetos y las características principales admiten sus escenarios. Vea la sección Factores de decisión para la plataforma de aplicaciones para Office para comprobar si las aplicaciones de correo son una opción mejor que los complementos para sus escenarios. En general, desarrolle la solución como una aplicación, si es posible, para aprovechar la compatibilidad de la plataforma en clientes de Outlook de distintos factores de forma.

Si sus escenarios requieren una ampliación de más envergadura que los elementos de mensaje y cita o que Outlook se automatice en el nivel de aplicación, intente averiguar con qué escenarios de la sección Factores de decisión para el modelo de objetos o PIA coinciden sus escenarios. Si el modelo de objetos (o PIA) de las versiones de destino de Outlook admite sus escenarios y la solución no manipula carpetas con muchos elementos, debería implementar la solución como complemento, en un lenguaje administrado o no administrado.

Si el modelo de objetos (o PIA) de una versión de destino de Outlook no admite algunos de sus escenarios, compruebe si los escenarios de la sección Factores de decisión para MAPI o Factores de decisión para las API auxiliares satisfacen sus necesidades. Si MAPI satisface sus necesidades, debe implementar la solución en código no administrado. Si una API auxiliar resuelve uno de los escenarios, puede usar código administrado o no administrado.

Si la solución usa MAPI, debe implementarla en código no administrado, como C++. De lo contrario, la decisión de usar código administrado o no administrado para crear la solución suele depender de los recursos disponibles y su experiencia. En lo que concierne a la decisión de si implementar la solución como un complemento o como una aplicación independiente, elija un complemento para evitar que el usuario invoque constantemente la protección del modelo de objetos, a menos que el escenario requiera manipular carpetas que contengan numerosos elementos. En este último escenario, implementar la solución para que se ejecute como un subproceso en segundo plano puede optimizar el rendimiento de Outlook.

Si los escenarios incluyen mostrar información o actualizaciones de redes sociales en Outlook, debe usar la extensibilidad de proveedores de OSC para crear un archivo DLL visible para COM. Puede hacerlo en un lenguaje administrado o en un lenguaje no administrado.

Si le interesa conectar un servicio de datos meteorológicos de terceros a la Barra de meteorología, puede seguir el protocolo definido por la extensibilidad de la Barra de meteorología y proporcionar los servicios web apropiados. Puede crear estos servicios web en un lenguaje administrado.

En cuanto haya decidido cuáles serán las API o las tecnologías que usará en la solución, puede consultar información adicional y ejemplos de código en la sección Recursos adicionales: referencias y recursos principales y ejemplos de código para obtener más información.

En Empezar a crear aplicaciones para Office se proporciona una buena introducción a las Complementos de Office, incluidos la arquitectura y el ciclo de vida de desarrollo.

Vea Complementos de Outlook para obtener una guía detallada de recursos sobre el desarrollo de aplicaciones de correo.

Vea también: Modelo de objeto y PIA

Los siguientes recursos proporcionan más información acerca de cómo usar el modelo de objetos y PIA.

Cuentas: varias cuentas en el perfil

Libreta de direcciones y usuarios de Exchange

Datos adjuntos

Archivos adjuntos: selección en el inspector

Automatización de Outlook

Categories

Contactos: comprobar la dirección y el nombre completo

Conversaciones

Eventos

Explorador: respuesta en línea

Elementos: propiedades básicas, campos y formularios

Elementos: personalización de propiedades

Elementos: enumerar, filtrar y ordenar

Elementos: marcar como tareas

Vea las siguientes propiedades relacionadas con tareas en algunos objetos de elementos como el objeto MailItem:

Elementos: selección en el explorador

Varios: tarjetas de presentación, reglas y vistas

Seguridad

Uso compartido

Soluciones: carpetas específicas de soluciones

Soluciones: almacenamiento de datos

Interfaz de usuario: personalización de las áreas de formulario

Interfaz de usuario: personalización desde Outlook 2007

Interfaz de usuario: personalización desde Outlook 2010

Interfaz de usuario: carpetas específicas de soluciones

Vea también: API auxiliares

Los siguientes recursos proporcionan más información acerca de las API auxiliares de Outlook.

Administración de cuentas

Clasificar elementos

Imágenes de contacto

Degradación de datos

Estado de disponibilidad

Divisa de elemento

Fusionar mediante cambio de base calendarios

Vea también: Principales referencias, recursos y ejemplos de código

Los siguientes recursos proporcionan más información acerca de las referencias y recursos principales de Outlook, así como ejemplos de código.

Referencias y recursos principales

Ejemplos de código