Compartir a través de

Sincronización del buzón y EWS en Exchange

  • Artículo

Descubra cómo funciona la sincronización de los buzones cuando usa EWS para acceder a Exchange.

EWS en Exchange usa dos tipos de sincronización para recuperar el contenido del buzón y los cambios en el contenido del buzón:

  • Sincronización de la carpeta
  • Sincronización de elementos

En este artículo, aprenderá sobre los dos tipos de sincronización, cómo funciona la sincronización, los patrones de diseño de sincronización y las prácticas recomendadas de sincronización.

Sincronización de carpetas y elementos

La sincronización de carpetas sincroniza una estructura de carpetas, o una jerarquía de carpetas. La sincronización de elementos sincroniza los elementos de una carpeta. Cuando se sincronizan elementos, hay que sincronizar cada carpeta del buzón de forma independiente. Puede usar EWS o la API administrada de EWS en su aplicación para implementar tanto la sincronización de carpetas como de elementos.

Tabla 1. Operaciones de EWS y métodos de la API administrada de EWS para sincronizar carpetas y elementos

Operación de EWS Método de la API administrada de EWS
SyncFolderHierarchy Método ExchangeService.SyncFolderHierarchy
SyncFolderItems Método ExchangeService.SyncFolderItems

El alcance de la sincronización que se produce difiere según se trate de una sincronización inicial o en curso, como se indica a continuación:

  • Una sincronización inicial sincroniza todas las carpetas o elementos del servidor con el cliente. Tras la sincronización inicial, el cliente tiene un estado de sincronización que almacena para futuras sincronizaciones. El estado de sincronización representa todos los cambios en el servidor que el servidor comunicó al cliente.
  • Las sincronizaciones en curso sincronizan cualquier elemento o carpeta que se haya agregado, eliminado o modificado desde la sincronización anterior. El servidor usa el estado de sincronización para calcular los cambios que debe comunicar al cliente durante cada uno de los bucles de sincronización en curso.

Cada método u operación de sincronización devuelve una lista de cambios, no la carpeta o el mensaje real que ha cambiado. Los cambios en los elementos y carpetas se notifican mediante los siguientes tipos de cambio:

  • Crear: indica que se debe crear un nuevo elemento o carpeta en el cliente.
  • Actualizar: indica que un elemento o carpeta debe ser modificado en el cliente.
  • Eliminar: indica que un elemento o carpeta debe ser eliminado en el cliente.
  • ReadStateChange para EWS o ReadFlagChange para la API administrada de EWS: indica que el estado de lectura del elemento ha cambiado, ya sea de no leído a leído, o de leído a no leído.

En Exchange Online, Exchange Online como parte de Office 365 y las versiones de Exchange a partir de Exchange 2010 SP2, los elementos y las carpetas se devuelven en orden de más reciente a más antiguo. En versiones anteriores de Exchange, los elementos y las carpetas se devuelven de más antiguo a más reciente.

¿Cómo funciona la sincronización del EWS?

En pocas palabras, si va a sincronizar un buzón por primera vez, utilice el proceso que se muestra en la Figura 1. Aunque se pueden usar otros patrones de diseño de sincronización, recomendamos este enfoque para aplicaciones escalables.

Figura 1. Patrón de diseño de sincronización inicial

Ilustración que muestra el patrón de diseño de la sincronización inicial. El cliente llama a SyncFolderHierarchy y Load o GetItem para obtener las carpetas y después, llama a SyncFolderItems y LoadPropertiesForItems o GetItem para obtener los elementos de cada carpeta.

Si está usando un estado de sincronización existente en el cliente para sincronizar un buzón, le recomendamos que implemente el patrón de diseño que se muestra en la Figura 2.

Figura 2. Patrón de diseño de sincronización en curso

Ilustración que muestra el patrón de diseño de la sincronización continua. Un cliente recibe una notificación y llama a SyncFolderHierarchy o SyncFolderItems, obtiene las propiedades y después, actualiza el cliente o simplemente actualiza la marca de lectura en el cliente.

Patrones de diseño de sincronización

Puede usar uno de los dos patrones de diseño de sincronización en su aplicación para mantener sus buzones actualizados: la sincronización basada en notificaciones o el enfoque de sólo sincronización.

La sincronización basada en notificaciones, como se muestra en la Figura 2, se basa en las notificaciones para alertar al cliente para que realice una llamada a los métodos SyncFolderItems o SyncFolderHierarchy de la API administrada del EWS, o a las operaciones SyncFolderHierarchy o SyncFolderItems del EWS. Este tipo de sincronización se recomienda generalmente para aplicaciones escalables, pero podría no ser el mejor enfoque para todos. La sincronización basada en notificaciones tiene la siguiente ventaja::

Las notificaciones están optimizadas para reducir las llamadas a la base de datos de Exchange. Las colas de eventos y las suscripciones son administradas por el servidor de buzones (o el servidor de Acceso de cliente en Exchange 2010 y Exchange 2007); sin embargo, la administración de los eventos y las suscripciones usa menos recursos que la alternativa, que son llamadas de sincronización más frecuentes a la base de datos de Exchange. Además, Exchange cuenta con directivas de límite específicas para las notificaciones y las suscripciones, para proteger el consumo de recursos.

Sin embargo, el uso de la sincronización basada en notificaciones también presenta algunos inconvenientes:

  • Las notificaciones son ruidosas porque la mayoría de los escenarios implican múltiples notificaciones para una intención de usuario. Esto es especialmente cierto en el caso de la carpeta Calendario. Por ejemplo, cuando se recibe una convocatoria de reunión, se crean múltiples notificaciones de elementos y carpetas, incluyendo una notificación para crear el elemento y otra para modificarlo. Una forma de mitigar este inconveniente es crear un retraso de unos segundos en su llamada a Cargar, LoadPropertiesForItems, GetItem, o GetFolder. En el caso de una convocatoria de reunión, si se hicieran llamadas a la operación GetItem inmediatamente, se podría tener una llamada para crear el elemento y otra para modificarlo. En cambio, al retrasar la llamada, puede llamar a la operación GetItem una vez y obtener los cambios que abarcan la creación y la modificación del elemento al mismo tiempo.
  • Las notificaciones se ponen en cola en el servidor de buzones y las suscripciones se guardan en el servidor de buzones. Si el servidor del buzón que administra la suscripción no está disponible, perderá las nuevas notificaciones, su buzón no se sincronizará y tendrá que volver a suscribirse a las notificaciones.
  • Tendrá que planificar estrategias de mitigación en caso de que las notificaciones fallen. De esta manera, el segundo enfoque, el patrón de diseño de sólo sincronización, es más resistente que la sincronización basada en notificaciones, porque sólo requiere que el cliente mantenga el estado de sincronización - no hay problemas de afinidad con el servidor de buzón que administra la suscripción.

Si se implementa como se recomienda, el patrón de diseño de suscripción basado en notificaciones se basa en:

  • Notificaciones para determinar cuándo han cambiado los datos.
  • Los métodos SyncFolderHierarchy o SyncFolderItems de la API administrada de EWS, o las operaciones EWS SyncFolderHierarchy o SyncFolderItems para determinar qué ha cambiado, optimizando el número de eventos de sincronización devueltos. ¿Se ha creado, actualizado o eliminado un nuevo elemento? Eso es todo lo que necesita saber de estos métodos, no se confíe de ellos para la lista de propiedades de los cambios. (No haga una llamada a GetItem o LoadPropertiesForItems en todos los elementos o carpetas devueltas).
  • Usar los métodos Cargar o LoadPropertiesForItems en la API administrada de EWS, o la operación EWS GetItem para determinar cómo han cambiado los datos y recuperar las propiedades del servidor según sea necesario, organizando las solicitudes por lotes en función de la cantidad de datos que serán devueltas. A continuación, se comparan las propiedades en el cliente y las que acaba de devolver el servidor y, por último, se crea, elimina o modifica el elemento o la carpeta en el cliente.

El enfoque de sólo sincronización depende totalmente de los métodos de la API administrada EWS SyncFolderItems y SyncFolderHierarchy, o de las operaciones EWS SyncFolderHierarchy o SyncFolderItems, que puede llamar de forma continua o como un evento temporizado. Esta opción también tiene sus ventajas y desventajas. El enfoque de sólo sincronización es más resistente porque el estado de sincronización se almacena en el cliente a nivel de buzón y no se requiere una relación única entre el estado de sincronización y cualquier servidor de buzón que mantenga la suscripción de notificación. El enfoque de sincronización puede sobrevivir a una conmutación por error de los buzones debido a su independencia del servidor de buzones. Sin embargo, el enfoque de la sincronización aumenta la latencia para el usuario, ya que los elementos se sincronizan de forma cronometrada o intermitente, y no en tiempo real cuando llegan los elementos. Este enfoque también es más costoso, porque está haciendo llamadas a la base de datos de Exchange cuando es posible que no se haya producido ningún cambio.

Prácticas recomendadas de sincronización

Para aplicaciones altamente escalables, recomendamos que aplique las siguientes prácticas recomendadas para sincronizar los buzones de su aplicación:

  • Cuando llame al método SyncFolderItems o SyncFolderHierarchy de la API administrada de EWS utilice el valor IdOnly para el parámetro propertySet, o cuando utilice las operaciones EWS SyncFolderHierarchy o SyncFolderItems utilice el valor IdOnly para el valor BaseShape para reducir las llamadas a la base de datos de Exchange. Cuantas más propiedades se soliciten en el conjunto de propiedades de la llamada SyncFolderItems o SyncFolderHierarchy, más llamadas al backend se crearán. Se realiza una nueva llamada RPC por cada valor de propiedad solicitado, mientras que sólo se realiza una llamada RPC para recuperar todos los ItemIds de una solicitud, sin importar el número de resultados a reportar. Así, una solicitud IdOnly da lugar a una llamada a la base de datos, mientras que una solicitud de contenedor de propiedades para el asunto y el remitente da lugar a tres llamadas a la base de datos: una para el asunto, otra para el remitente y otra para el ItemId.

  • No llame a los métodos Cargar o LoadPropertiesForItems de la API administrada de EWS, ni a las operaciones GetItem o GetFolder de EWS, en cada elemento de una respuesta de sincronización. En su lugar, analice los resultados; busque los cambios que no requieren que se recuperen todas las propiedades, como los cambios de estado de lectura. Si una respuesta incluye un cambio de estado de lectura, basta con actualizar el indicador en el cliente y ya está; no es necesario obtener todas las propiedades del elemento. Y asegúrese de no duplicar esfuerzos haciendo cambios que se originan en el mismo cliente. Por ejemplo, si la respuesta de sincronización incluye la eliminación de un elemento, y la eliminación se produjo en el cliente local, no es necesario volver a eliminar el mensaje ni obtener todas las propiedades de ese elemento.

  • Para evitar limitaciones, haga lo siguiente:

    • Cuando llame al método LoadPropertiesForItems de la API administrada de EWS o a la operación GetItem de EWS para obtener los elementos en un lote, no incluya demasiados elementos en su solicitud; de lo contrario, podría verse limitado. Le recomendamos que incluya 10 artículos por lote.
    • No haga muchas solicitudes en tan poco tiempo. Esto también provocará una limitación, y aumentará el tiempo de respuesta, en lugar de acortarlo.
    • Si va a procesar por lotes los elementos, haga un lote de todos los elementos con los mismos valores para los atributos Id y ChangeKey del elemento FolderId.
    • Si queda limitado, deje de enviar solicitudes. El reenvío de solicitudes prolongará el esfuerzo de recuperación. En su lugar, espere a que expire el tiempo de espera y luego intente enviar sus solicitudes de sincronización de nuevo.

  • Dependiendo del tipo de evento de notificación recibido:

    • Para los eventos NewMail o Modificado, llame al método API administrada de EWS SyncFolderItems o a la operación EWS SyncFolderItems porque las notificaciones no proporcionan una ChangeKey, y las notificaciones no llaman a leer los cambios de estado.
    • En el caso de los eventos eliminados, si la suscripción a la notificación estaba activa antes de la sincronización anterior, basta con eliminar el evento localmente. No es necesario llamar al método SyncFolderItems de la API administrada de EWS ni a la operación EWS SyncFolderItems inmediatamente después de la eliminación.
    • Si un evento modificado fue causado por un cambio de estado de lectura, no llame al método LoadPropertiesForItems de la API administrada de EWS o a la operación GetItem de EWS , sólo cambie la bandera del elemento.

  • Para sincronizar los datos de la agenda, proceda como sigue:

    • Utilizar un enfoque similar al de la sincronización basada en notificaciones. Dado que SyncFolderItem no incluye ninguna lógica de calendario, utilice el método FindAppointments de la API administrada de EWS o la operación FindItem de EWS con el elemento CalendarView para ver las citas entre dos fechas y, a continuación, llame al método LoadPropertiesForItems de la API administrada de EWS o a la operación GetItem de EWS para recuperar las propiedades del elemento del calendario.

    • No se debe realizar un sondeo usando el método FindAppointments de la API administrada del EWS, ni la operación FindItem del EWS con un elemento CalendarView.

  • Al sincronizar las carpetas de búsqueda:

    • Utilizar un enfoque similar al de la sincronización basada en notificaciones.

    • Use las notificaciones para determinar cuándo cambian los datos.

    • Dado que no puede utilizar SyncFolderItem en una carpeta de búsqueda, utilice un método FindItems de la API administrada de EWS ordenado y paginado, o la operación FindItem de EWS con el elemento FractionalPageItemView y SortOrder establecido, para determinar qué ha cambiado.

    • Utilice el método LoadPropertiesForItems de la API administrada de EWS o la operación GetItem de EWS para recuperar los datos.

Sincronización filtrada

El método SyncFolderItems de la API administrada de EWS y la operación SyncFolderItems de EWS le permiten ignorar elementos específicos, basándose en sus ItemIds, estableciendo el parámetro ignoreItemIds en la API administrada de EWS o el elemento Ignorar en EWS. Esto es ideal cuando, por ejemplo, las personas comienzan a responder a todos los mensajes de correo electrónico enviados a todos en la empresa.

Se preguntará, ¿puedo filtrar mis notificaciones (y por lo tanto sólo activar la sincronización) si cambian propiedades específicas? Aunque parece razonable, como las suscripciones a las notificaciones se basan en el tipo de cambio (crear, actualizar, eliminar), y no en la propiedad que se actualiza, no se pueden filtrar las notificaciones de esta manera. En su lugar, puede hacer lo siguiente:

  • Utilice el patrón de diseño de suscripción basado en notificaciones.
  • Llame a los métodos SyncFolderItems y SyncFolderHierarchy de la API administrada de EWS repetidamente con el parámetro propertySet establecido en IdOnly para que su estado de sincronización sea actual. O si utiliza EWS, llame a las operaciones SyncFolderHierarchy y SyncFolderItems repetidamente con el valor de BaseShape establecido en IdOnly.
  • Descarte la respuesta (no la analice ni haga ninguna comparación de propiedades).
  • Utilice el método FindItems de la API administrada de EWS o la operación FindItem de EWS y la ordenación y la página para rellenar previamente los elementos del ámbito filtrado que le interesan.
  • Utilice su estado de sincronización para seguir llamando al método SyncFolderItems de la API administrada de EWS o a la operación EWS SyncFolderItems, pero sólo supervise los cambios en el conjunto de elementos filtrados. Si se crean nuevos elementos, tendrá que ver si esos nuevos elementos están dentro de su ámbito filtrado.

En esta sección

Vea también