Quebras de API gerenciadas do EWS Corpo de mensagem HTML de compromisso na atualização
Estou usando o EWS Java 1.2, embora o 2.0 em C # mostre exatamente os mesmos problemas e o Exchange 2010 SP3, portanto, um bug específico no SP2 antes do rollup 3 em relação aos corpos das mensagens não é o problema.
Longa história curta: EWS + Exchange = dor. Usando o EWS no Exchange, você pode criar um compromisso. Você pode especificar que o corpo da mensagem do Compromisso seja HTML e dê um monte de HTML para acompanhar. Isso fará algum tipo de conversão HTML -> RTF que destrói o HTML quando você o visualiza em um desktop ou cliente da Web do Outlook. Ok, bem, podemos adaptar o HTML a algo que não é comido no processo e ainda parece decente.
Exceto que, quando você atualiza o Compromisso com uma alteração no corpo da mensagem, ele REALMENTE consome a formatação HTML. Não importa se é o mesmo HTML que você deu quando foi criado. O segundo salvamento irá destruí-lo, deixando pouco mais que negrito, quebra de linha e abas. É como se estivesse exibindo o texto sem formatação com algumas pequenas partes de formatação ou exibindo um RTF muito simplificado de HTML convertido. O que é realmente enlouquecedor é que isso só acontece quando você atualiza o corpo.
A coisa é, eu dei uma olhada nestes compromissos (e MeetingRequests relacionados, que são montados da mesma forma) em ambos MFCMAPI e no EWS, verificando as propriedades estendidas. Quando o compromisso é criado pela primeira vez, somente o corpo RTF é preenchido. Os corpos de texto simples e HTML são nulos, o RTF está em sincronia e o valor do corpo nativo é 2, o que significa que ele deve exibir RTF. Ok, isso faz sentido.
Na atualização, todos os três tipos de corpo estão presentes. O RTF está fora de sincronia. O valor do corpo nativo é 3, o que significa que ele deve exibir HTML. Eu verifiquei no MFCMAPI. O corpo do texto sem formatação e o corpo RTF mostram erros de memória, mas a abertura da propriedade mostrará corretamente. O corpo do HTML está presente. Há uma razão ZERO para que isso aconteça de acordo com a documentação. O algoritmo Best Body afirma que, se a propriedade do corpo nativo for preenchida, então é isso que será usado e tudo é feito. Bem, isso obviamente não está acontecendo. Se não estiver obtendo esse valor por algum motivo, ele passará por uma cadeia condicional. Bem, a cadeia condicional mostra que o corpo HTML deve ser exibido nesse caso. MFCMAPI concorda quando o item é exportado, pois mostra o corpo nativo como o corpo HTML. OWA irá exibi-lo bem. Mas o Outlook 2010/2013? Não.
Estou no fim da minha sagacidade aqui. Não consigo fazer com que o desktop Outlook exiba o corpo corretamente, não importa o que eu faça. Parece ser algo fundamentalmente quebrado serverside, mas não há bugs conhecidos listados (além do problema SP2 pré-rollup 3 acima, que não é o caso aqui) e não consigo encontrar qualquer documentação que explica por que a atualização quebra tão seriamente. O melhor que consegui fazer foi definir o pidTagBodyHtml diretamente na criação e quebrá-lo desde o início. Pelo menos é consistente.
EDIT: Eu implementei o algoritmo de descompressão RTF para espiar dentro. Com certeza, o corpo da mensagem RTF para um novo compromisso e o corpo da mensagem RTF para um compromisso atualizado (em que o corpo foi atualizado com um praticamente idêntico) são muito diferentes! O Exchange está seguindo dois caminhos de código separados no lado do servidor e está quebrando o formato do corpo! A única solução possível que vejo é também implementar os algoritmos de compactação e formatação e construir manualmente um corpo RTF válido no cliente, o que não é exatamente um feito pequeno.