Interagieren mit dem MAPI-Spooler

Gilt für: Outlook 2013 | Outlook 2016

Die Methoden in der IXPLogon : IUnknown-Schnittstelle werden vom MAPI-Spooler beim Aufrufen des Transportanbieters verwendet. Es sollte für die meisten Arten von Transportanbietern möglich sein, die meisten dieser Methoden zu implementieren, damit sie schnell zurückkehren. Dies ist wünschenswert, denn wenn die Rückgabe einer Methode lange dauert, sollte sie durch Aufrufe an den MAPI-Spooler unterbrochen werden, um die CPU für andere Aufgaben freizugeben.

Der MAPI-Spooler erledigt seine Arbeit und führt seine Aufrufe an Transportanbieter aus, wenn sich Vordergrundanwendungen im Leerlauf befinden. Nach dem optionalen Anzeigen von Dialogfeldern bei der ersten Anmeldung des Transportanbieters (gesteuert durch Flags, die von MAPI an den Transportanbieter übergeben werden), werden Transportanbieter im Hintergrund ausgeführt, es sei denn, der Client wird aufgerufen, um Sende- und Empfangswarteschlangen zu leeren. Das Leeren von Warteschlangen ist der einzige Zeitpunkt, zu dem ein Transportanbieter die CPU nicht freigeben muss, und dann nur, wenn der Benutzer darüber informiert wird, dass eine potenziell lange Aktion ausgeführt wird. Der MAPI-Spooler fordert in der Regel an, dass ein Transportanbieter seine Warteschlangen als Reaktion auf eine Benutzeraktion leert, sodass der Transportanbieter in der Regel nichts tun muss, um sicherzustellen, dass der Benutzer informiert wird.

Ein Transportanbieter kann unabhängig entscheiden, eine Warteschlange zu leeren und die STATUS_INBOUND_FLUSH und STATUS_OUTBOUND_FLUSH Bits in der eigenschaft PR_STATUS_CODE (PidTagStatusCode) seiner status Zeile zu verwenden, um den MAPI-Spooler darüber zu informieren, dass er Aufmerksamkeit benötigt, damit er den Auftrag erledigen kann. Die status Zeile wird mithilfe der IMAPISupport::ModifyStatusRow-Methode aktualisiert. In diesem Fall sollte der Transportanbieter wahrscheinlich eine Statusanzeige oder eine andere Schnittstelle anzeigen, um den Benutzer darüber zu informieren, dass eine lange Aktion ausgeführt wird.

Da die Netzwerkaktivität häufig mehr als 0,2 Sekunden dauert, sollten Transportanbieter nach Möglichkeit asynchrone Netzwerkanforderungen verwenden. Dies ermöglicht es ihnen, eine Anforderung zu initiieren, die CPU durch Einen Rückruf an den MAPI-Spooler freizugeben, und wenn der MAPI-Spooler ihnen erneut die Kontrolle erteilt, um zu überprüfen, ob ihre Netzwerkanforderung abgeschlossen wurde. Wenn sie noch nicht abgeschlossen ist, geben sie die CPU erneut frei, indem sie den MAPI-Spooler mit der IMAPISupport::SpoolerYield-Methode zurückrufen .

Während der Nachrichtenverarbeitung zwischen IXPLogon::SubmitMessage und IXPLogon::EndMessage und während IXPLogon::StartMessage führt der Transportanbieter in der Regel viele Aufrufe von Objekten durch, die vom MAPI-Spooler für ihn verfügbar gemacht werden. Im Rahmen der Behandlung dieser Objekte unterstützt der MAPI-Spooler den Transportanbieter dabei, sich als Hintergrundprozess angemessen zu verhalten, indem er bei Bedarf eigenständig ergibt. Ein Transportanbieter, der eine zeitkritische Verarbeitung erfordert, kann mithilfe der IMAPISupport::SpoolerNotify-Unterstützungsmethode einen kritischen Abschnitt für den MAPI-Spooler deklarieren. In diesem Fall wird die CPU nur bei expliziten SpoolerYield-Aufrufen des Transportanbieters freigegeben, bis der Transportanbieter die Verarbeitung kritischer Abschnitte mit einem weiteren Aufruf von SpoolerNotify beendet.

Hinweis

Dies ist nicht identisch mit einem kritischen Win32-Abschnitt. Dies sollte nur erfolgen, wenn der Transportanbieter eine Echtzeitsteuerung externer Ressourcen benötigt, z. B. das Lesen eingehender Daten aus einer Faxleitung. Da dies die Priorität des MAPI-Spoolerprozesses erhöht und dazu führen kann, dass die Arbeitsstation für die Dauer des Vorgangs nicht mehr reagiert, empfiehlt es sich, den Benutzer zu benachrichtigen, dass eine potenziell lange Aktion ausgeführt wird, und wenn möglich eine Statusanzeige bereitzustellen.