Estoy usando EWS Java 1.2, aunque 2.0 en C # muestra exactamente los mismos problemas, y Exchange 2010 SP3, por lo que no es el problema un error en particular en SP2 antes del paquete acumulativo 3 en relación con los cuerpos del mensaje.

Larga historia corta: EWS + Exchange = dolor. Usando EWS en Exchange, puede crear una cita. Puede especificar que el cuerpo del mensaje de la Cita sea HTML y darle un montón de HTML para que lo acompañe. Esto hará algún tipo de HTML -> conversión RTF que destruye el HTML cuando lo ves en un escritorio de Outlook o en un cliente web. Bien, bien, podemos adaptar el HTML a algo que no se consume en el proceso y aún parece decente.

Excepto que cuando actualiza la Cita con un cambio en el cuerpo del mensaje, REALMENTE come el formato HTML. No importa si es el mismo HTML que le diste cuando se creó. El segundo guardado lo destruirá, dejando poco más que texto en negrita, saltos de línea y pestañas. Es como si estuviera mostrando el texto sin formato con unos pocos fragmentos pequeños de formato o mostrando un RTF muy reducido de HTML convertido. Lo que es realmente enloquecedor es que solo sucede una vez que actualizas el cuerpo.

La cuestión es que he echado un vistazo a estas citas (y a las solicitudes de reunión relacionadas, que se procesan de la misma manera) tanto en MFCMAPI como en EWS al verificar las propiedades extendidas. Cuando se crea la cita por primera vez, solo se rellena el cuerpo RTF. El texto sin formato y los cuerpos HTML son nulos, el RTF está sincronizado y el valor del cuerpo nativo es 2, lo que significa que debería mostrar RTF. Está bien, eso tiene sentido.

En la actualización, los tres tipos de cuerpo están presentes. El RTF no está sincronizado. El valor del cuerpo nativo es 3, lo que significa que debe mostrar HTML. Me registré en MFCMAPI. Tanto el cuerpo de texto sin formato como el cuerpo de RTF muestran errores de memoria, pero al abrir la propiedad se mostrará correctamente. El cuerpo HTML está presente. Hay CERO razón por la que esto debería suceder de acuerdo con la documentación. El algoritmo de Best Body indica que si la propiedad del cuerpo nativo está poblada, entonces eso es lo que se usará y todo está hecho. Bueno, eso obviamente no está sucediendo. Si no obtiene ese valor por alguna razón, entonces pasará por una cadena condicional. Bueno, la cadena condicional muestra que el cuerpo HTML debe mostrarse en este caso. MFCMAPI acepta cuando el elemento exportado, ya que muestra que el cuerpo nativo es el cuerpo HTML. OWA lo mostrará muy bien. ¿Pero Outlook 2010/2013? No

Estoy al final de mi ingenio aquí. No puedo obtener Outlook de escritorio para mostrar el cuerpo correctamente sin importar lo que haga. Parece que hay algo fundamentalmente dañado en el servidor, pero no hay errores conocidos en la lista (aparte del mencionado problema de pre-rollup 3 del SP2, que no es el caso aquí) y no puedo encontrar ninguna documentación que explique por qué la actualización lo rompe tan mal. Lo mejor que he podido hacer es establecer el pidTagBodyHtml directamente en la creación y romperlo desde el principio. Al menos eso es consistente.

EDITAR: He implementado el algoritmo de descompresión RTF para mirar dentro. Por supuesto, el cuerpo del mensaje RTF para una nueva cita y el cuerpo del mensaje RTF para una cita actualizada (en la que el cuerpo fue actualizado con una prácticamente idéntica) son muy diferentes. ¡Exchange está siguiendo dos rutas de código separadas del servidor y está rompiendo el formato del cuerpo! La única solución posible que veo es implementar también los algoritmos de compresión y formato y construir manualmente un cuerpo RTF válido en el cliente, que no es exactamente una hazaña pequeña.