Ich verwende EWS Java 1.2, obwohl 2.0 in C # genau dieselben Probleme aufweist, und Exchange 2010 SP3, sodass ein bestimmter Fehler in SP2 vor Rollup 3 in Bezug auf Nachrichtentexte nicht das Problem ist.

Lange Rede, kurzer Sinn: EWS + Austausch = Schmerz. Mit EWS in Exchange können Sie einen Termin erstellen. Sie können festlegen, dass der Nachrichtentext des Termins HTML sein soll, und ihm eine entsprechende Menge HTML geben. Dadurch wird eine Art HTML -> RTF-Konvertierung durchgeführt, die den HTML-Code zerstört, wenn Sie ihn auf einem Outlook-Desktop oder in einem Webclient anzeigen. Okay, nun, wir können den HTML-Code auf etwas zuschneiden, das dabei nicht aufgefressen wird und trotzdem anständig aussieht.

Wenn Sie den Termin jedoch mit einer Änderung des Nachrichtentexts aktualisieren, wird die HTML-Formatierung WIRKLICH übernommen. Es spielt keine Rolle, ob es sich um dasselbe HTML handelt, das Sie bei der Erstellung angegeben haben. Der zweite Speichervorgang zerstört es und hinterlässt nur fett gedruckten Text, Zeilenumbrüche und Tabulatoren. Es ist, als würde entweder der reine Text mit ein paar kleinen Formatierungen angezeigt, oder es wird eine sehr reduzierte RTF-Datei aus konvertiertem HTML angezeigt. Was wirklich verrückt ist, ist, dass es nur passiert, wenn Sie den Körper aktualisieren.

Die Sache ist, ich habe mir diese Termine (und verwandte MeetingRequests, die auf die gleiche Weise gemulcht werden) sowohl in MFCMAPI als auch in EWS angesehen, indem ich die erweiterten Eigenschaften überprüfte. Beim erstmaligen Erstellen des Termins wird nur der RTF-Text ausgefüllt. Der Nur-Text- und der HTML-Textkörper sind null, die RTF-Datei ist synchron und der native Textkörperwert ist 2. Dies bedeutet, dass RTF angezeigt werden soll. Okay, das macht Sinn.

Beim Update sind alle drei Körpertypen vorhanden. Der RTF ist nicht synchron. Der native Body-Wert ist 3, was bedeutet, dass HTML angezeigt werden soll. Ich habe MFCMAPI eingecheckt. Sowohl der Nur-Text-Body als auch der RTF-Body weisen Speicherfehler auf, das Öffnen der Eigenschaft zeigt sie jedoch korrekt an. Der HTML-Body ist vorhanden. Es gibt keinen Grund dafür, dass dies gemäß der Dokumentation geschehen sollte. Der Best-Body-Algorithmus gibt an, dass, wenn die native Body-Eigenschaft ausgefüllt ist, diese verwendet wird und alles erledigt ist. Nun, das passiert offensichtlich nicht. Wenn dieser Wert aus irgendeinem Grund nicht erreicht wird, durchläuft er eine bedingte Kette. Nun, die bedingte Kette zeigt, dass in diesem Fall der HTML-Body angezeigt werden sollte. MFCMAPI stimmt zu, wenn das Element exportiert wird, da der native Text als HTML-Text angezeigt wird. OWA zeigt es gut an. Aber Outlook 2010/2013? Nee.

Ich bin hier am Ende meines Witzes. Ich kann Desktop Outlook nicht dazu bringen, den Körper richtig anzuzeigen, egal was ich tue. Es scheint sich um einen grundlegend kaputten Server zu handeln, aber es sind keine Fehler bekannt (abgesehen von dem oben erwähnten Problem mit SP2 vor Rollup 3, das hier nicht der Fall ist), und ich kann keine Dokumentation finden, die erklärt, warum das Update diesen Fehler verursacht schlecht. Das Beste, was ich tun konnte, ist, das pidTagBodyHtml direkt bei der Erstellung festzulegen und es von Anfang an kaputt zu machen. Zumindest ist das konsequent.

EDIT: Ich habe den RTF-Dekomprimierungsalgorithmus implementiert, um einen Blick hinein zu werfen. Der RTF-Nachrichtentext für einen neuen Termin und der RTF-Nachrichtentext für einen aktualisierten Termin (in dem der Text mit einem praktisch identischen aktualisiert wurde) sind sehr unterschiedlich! Exchange folgt zwei separaten Codepfaden auf der Serverseite und bricht das Body-Format! Die einzige mögliche Lösung, die ich sehe, besteht darin, auch die Komprimierungs- und Formatierungsalgorithmen zu implementieren und manuell einen gültigen RTF-Body im Client zu erstellen, was nicht gerade eine Kleinigkeit ist.