Speichern einer Nachricht

Gilt für: Outlook 2013 | Outlook 2016

Bevor eine Nachricht gespeichert wird, rufen Clients in der Regel die IMAPIProp::SetProps-Methode der Nachricht auf, um zusätzlich zu den Nachrichtentexteigenschaften, Anlageneigenschaften, PR_SUBJECT (PidTagSubject) und eigenschaften, die der Empfängerliste zugeordnet sind, einige Eigenschaften festzulegen.

Legen Sie die eigenschaft PR_MESSAGE_CLASS (PidTagMessageClass) auf eine Zeichenfolge wie IPM fest. Beachten Sie, dass die Klasse der ausgehenden Nachricht beschreibt. Obwohl Clients PR_MESSAGE_CLASS für alle ausgehenden Nachrichten festlegen sollten, wird ein Standardwert vom Nachrichtenspeicheranbieter bereitgestellt, wenn Sie ihn nicht festlegen. Die Standardnachrichtenklasse für ausgehende Nachrichten ist IPM.

Legen Sie das MSGFLAG_UNSENT-Flag in der eigenschaft PR_MESSAGE_FLAGS (PidTagMessageFlags) fest. Legen Sie bei Bedarf auch die flags MSGFLAG_READ und MSGFLAG_UNMODIFIED fest. Durch Festlegen des MSGFLAG_UNMODIFIED kann eine Nachricht unter "Composition" eine übermittelte Nachricht simulieren. MSGFLAG_UNMODIFIED kann nur von Clients festgelegt werden, bevor eine Nachricht zum ersten Mal gespeichert wurde.

Wenn Sie bereit sind, eine permanente Kopie einer nicht gesendeten Nachricht zu erstellen, rufen Sie IMAPIProp::SaveChanges für die Nachricht und alle ihre Anlagen auf. Wenn Sie beabsichtigen, die Nachricht sofort zu senden, müssen Sie SaveChanges nicht aufrufen. Der Aufruf von SubmitMessage speichert die Nachricht intern als Teil ihrer Verarbeitung.

Beim Aufrufen von SaveChanges empfiehlt es sich, das flag KEEP_OPEN_READWRITE anzugeben, mit dem die Nachricht zu einem späteren Zeitpunkt geändert werden kann. Andere festlegbare Flags sind FORCE_SAVE, die angibt, dass die Nachricht oder Anlage nach dem Commit von Änderungen geschlossen werden soll, KEEP_OPEN_READONLY, was angibt, dass keine weiteren Änderungen vorgenommen werden, und das Flag, um dem Nachrichtenspeicheranbieter das Batchclientanforderungen MAPI_DEFERRED_ERRORS zu ermöglichen.

Es ist wichtig, dass Sie SaveChanges für jede Anlage in der Nachricht aufrufen, bevor Sie SaveChanges für die Nachricht aufrufen. Wenn Sie eine Anlage nicht speichern können, wird die Anlage nicht in die Nachricht eingeschlossen, wenn sie gesendet wird, und sie wird nicht in der Anlagetabelle der Nachricht angezeigt. Wenn Sie die Nachricht nach dem Speichern aller Anlagen nicht speichern können, gehen sowohl die Nachricht als auch die Anlagen verloren.

Wenn SaveChanges aufgerufen wird, aktualisiert der Nachrichtenspeicheranbieter die folgenden Eigenschaften:

• PR_DISPLAY_TO (PidTagDisplayTo) listet alle primären Empfänger auf.

• PR_DISPLAY_TO listet alle Empfänger von Co2-Kopien auf.

• PR_DISPLAY_BCC (PidTagDisplayBcc) listet alle Blindkopieempfänger auf.

• PR_LAST_MODIFICATION_TIME (PidTagLastModificationTime)

• PR_MESSAGE_FLAGS legt fest, MSGFLAG_HASATTACH, ob eine oder mehrere Anlagen gespeichert wurden, und löscht MSGFLAG_UNMODIFIED, um anzuzeigen, dass die Nachricht geändert wurde.

• PR_MESSAGE_SIZE (PidTagMessageSize) enthält die aktuellste Größe der Nachricht.

• PR_MESSAGE_ATTACHMENTS (PidTagMessageAttachments) bietet Zugriff auf die Anlagentabelle.

• PR_MESSAGE_RECIPIENTS (PidTagMessageRecipients) bietet Zugriff auf die Empfängertabelle.

Einige Nachrichteneigenschaften werden in der Regel von Clients oder Dienstanbietern bereitgestellt, wenn eine Nachricht erstellt wird. Wenn ein Client das Festlegen versäumt, liegt es an dem Nachrichtenspeicheranbieter, sie zum Zeitpunkt des Aufrufs von SaveChanges zu aktualisieren. Wenn beispielsweise die Eigenschaften PR_ENTRYID (PidTagEntryId) und PR_RECORD_KEY (PidTagRecordKey) einer Nachricht beim Erstellen der Nachricht festgelegt wurden, müssen sie nicht zur Speicherzeit geändert werden. Nachrichtenspeicheranbieter, die es versäumen, sie bei der Erstellung von Nachrichten festzulegen, müssen sie jedoch beim ersten Aufruf von SaveChanges festlegen.

Wenn SaveChanges MAPI_E_CORRUPT_DATA zurückgibt, gehen Sie davon aus, dass die zu speichernden Daten jetzt verloren gehen. Nachrichtenspeicheranbieter, die ein Client-Server-Modell für ihre Implementierung verwenden, geben diesen Wert möglicherweise zurück, wenn eine Netzwerkverbindung unterbrochen wird oder der Server nicht ausgeführt wird. Bevor Sie einen Fehler an den Benutzer zurückgeben, versuchen Sie, die Daten ein zweites Mal zu schreiben und zu speichern, indem Sie setProps aufrufen, gefolgt von einem weiteren Aufruf von SaveChanges. Wenn die Daten lokal zwischengespeichert werden, sollte dies kein Problem darstellen. Wenn jedoch kein lokaler Cache vorhanden ist oder der zweite SaveChanges-Aufruf fehlschlägt, zeigen Sie einen Fehler an, um den Benutzer auf das Problem hinzuweisen.