Auswählen einer API oder Technologie für die Entwicklung von Lösungen für Outlook

  • Artikel

In diesem Artikel werden die APIs und Technologien beschrieben, mit denen Sie Outlook 2013 und Outlook 2016 erweitern können, und Sie erhalten Entscheidungshilfen bei der Auswahl der geeigneten API oder Technologie für Ihr Szenario.

Microsoft unterstützt mehrere API‘s und Technologien, die Outlook erweitern:

  • Ab Office 2013 eröffnet die Apps für Office-Plattform Möglichkeiten der Erweiterung von Outlook-Funktionen über Outlook-Clients auf dem Desktop, dem Tablet-PC und dem Smartphone hinweg. Die Plattform umfasst eine JavaScript-API für Office und ein Schema für App-Manifeste.

  • Das Objektmodell, die entsprechende primäre Interop-Assembly (PIA) für Office und die Messaging-API (MAPI) sind die in Outlook-Lösungen gängigsten APIs.

  • In einigen Szenarien wird die MAPI durch Hilfs-APIs ergänzt.

  • Die OSC-Anbietererweiterung (Outlook Social Connector, Outlook Connector für soziale Netzwerke) und die Wetterleistenerweiterung dienen spezifischen Szenarien der entsprechenden Nischenmärkte.

In diesem Artikel werden die Auswahlkriterien für die Office-Add-Ins-Plattform, das Objektmodell, die PIA und die MAPI erläutert. Beachten Sie, dass Office-Add-Ins die JavaScript-API für Office verwenden und nicht das Objektmodell aufrufen und umgekehrt. Lösungen, in denen die anderen APIs verwendet werden, können eine oder mehrere APIs verwenden. Beispielsweise können in einem in C++ geschriebenen COM-Add-In das Objektmodell, die MAPI und Hilfs-APIs gleichzeitig genutzt werden.

Die Informationen in diesem Artikel sind dann besonders nützlich für Sie, wenn Sie mit Outlook auf der Benutzerebene vertraut sind und über allgemeine Kenntnisse in der Softwareentwicklung verfügen. Sie benötigen jedoch kein Detailwissen über die Features, die von diesen APIs oder Technologien unterstützt werden. Dieser Artikel hilft Ihnen, folgende Fragen zu beantworten:

  • Welche weiteren Kriterien sollten Sie bei der Auswahl einer API berücksichtigen, wenn Sie nur eine Vorstellung vom Zweck der zu entwickelnden Lösung, dem Zielmarkt und den verfügbaren Ressourcen haben?

  • Warum sollten Sie Office-Add-Ins in Betracht ziehen, und wann würden Sie Apps und keine Add-Ins erstellen?

  • Inwiefern beeinflusst es die Auswahl einer API, wenn die Lösung mit früheren Versionen von Outlook, einschließlich Outlook 2003, ausgeführt werden muss?

  • Welche API wäre am besten geeignet, wenn die Lösung Outlook-Ordner durchlaufen muss, die Tausende von Elementen enthalten, und Sie in der Lage sein müssen, diese Elemente zu ändern?

  • Ist das Outlook-Objektmodell die beste Wahl, wenn Ihre Lösung die Outlook-Geschäftslogik umfassend nutzt und mit anderen Office-Anwendungen interagiert?

  • Was können Sie mithilfe des Objektmodells und der MAPI in Outlook erweitern?

  • Wenn Sie entweder das Objektmodell oder MAPI verwenden können, um die Aufgabe zu erzielen, wie können Sie entscheiden, welche der API Sie verwenden sollen?

Festlegen von Bewertungskriterien

In diesem Abschnitt werden Kriterien beschrieben, anhand derer Sie die Office-Add-Ins-Plattform, das Objektmodell, die PIA und die MAPI miteinander vergleichen können, um herauszufinden, welche Methode Ihre Anforderungen am besten erfüllt. Dabei können die verschiedenen Kriterien je nach Projekt und verfügbaren Ressourcen mehr oder weniger ins Gewicht fallen.

In den Tabellen in diesem Abschnitt werden Bewertungskriterien beschrieben, die sich wie folgt kategorisieren lassen:

  • Funktionale Kriterien: Es wird beschrieben, was Sie mit der Technologie tun können und was nicht.

  • Entwicklungsbezogene Kriterien: Hier werden die Entwicklungstools oder Informationen erklärt, die Sie benötigen, um die Technologie verwenden zu können.

  • Sicherheitsbezogene Kriterien: Hier werden Sicherheitsaspekte und Informationen in Bezug auf Berechtigungen im Zusammenhang mit der Technologie erläutert.

  • Bereitstellungsspezifische Kriterien: Die empfohlenen Bereitstellungs- und Verteilungsmethoden für die Technologie werden beschrieben.

Objektive Bewertungskriterien für die Apps für Office-Plattform

Ab Office 2013 können Entwickler die Office-Add-Ins-Plattform verwenden, um Webdienste und Inhalte in den Kontext von Rich-Office- und Webclients zu erweitern. Eine Office-Add-In ist eine Webseite, die mit gängigen Webtechnologien entwickelt wurde, in einer Office-Clientanwendung (wie Outlook) gehostet wird und lokal oder in der Cloud ausgeführt werden kann. Von den wenigen Typen von Office-Add-Ins wird der Typ, der Outlook unterstützt, als Mail-App bezeichnet. Das Objektmodell, die PIA und die MAPI werden zwar häufig zur Automatisierung von Outlook auf Anwendungsebene verwendet, doch Sie können die JavaScript-API für Office verwenden, um mit den Inhalten und Eigenschaften einer E-Mail-Nachricht, einer Besprechungsanfrage oder eines Termins auf Elementebene zu interagieren. Sie können Mail-Apps im Office Store oder einem internen Exchange-Katalog veröffentlichen.

Endbenutzer und Administratoren können Mail-Apps in einem Exchange-Postfach installieren und im Rich-Outlook-Client sowie in Outlook Web App verwenden. Als Entwickler haben Sie die Wahl, Ihre Mail-App nur auf dem Desktop oder auch auf dem Tablet-PC oder dem Smartphone verfügbar zu machen. In Abbildung 1 ist ein Beispiel für eine YouTube-Mail-App dargestellt, die in Beispiel: Erstellen einer Mail-App in Outlook zum Wiedergeben von YouTube-Videos ausführlich beschrieben wird. Mithilfe der YouTube-Mail-App können Endbenutzer eine URL für ein YouTube-Video auswählen und das Video in Outlook oder Outlook Web App, auf dem Desktop oder auf dem Tablet-PC anzeigen.

Abbildung 1: Die YouTube-Mail-App ist für die ausgewählte Nachricht aktiv, die eine URL zu einem Video auf YouTube.com

YouTube-Mail-App in Outlook

Sobald ein Benutzer eine Mail-App installiert hat, kann die App in der App-Leiste verwendet werden, wenn der aktuelle Inhalt die von der App festgelegten Aktivierungsbedingungen erfüllt. Eine Mail-App erlaubt Ihnen, Regeln zum aktuell ausgewählten Element anzugeben, die eine Mail-App nur dann aktivieren, wenn bestimmte Regeln erfüllt sind. So ist die YouTube-Mail-App, mit der Sie ein YouTube-Video in Outlook wiedergeben können, nur dann relevant, wenn das ausgewählte Outlook-Element eine URL zu einem Video auf YouTube.com enthält. In diesem Fall würden Sie angeben, dass die App nur dann aktiv sein soll, wenn die ausgewählte Nachricht eine solche URL enthält.

Die folgenden Tabellen enthalten die Bewertungskriterien für die Office-Add-Ins-Plattform.

Funktionale Kriterien

Kriterium Mail-Apps-Unterstützung in Apps für Office-Plattform
Anwendungsdomäne Der Aktivitätsbereich einer Mail-App ist praktisch jedes unterstützte Nachrichten- oder Terminelement im Exchange-Postfach des Benutzers, das der Benutzer ausgewählt hat und das die Aktivierungsbedingungen erfüllt. Die Berechtigungen einer Mail-App bestimmen den Zugriff auf die Eigenschaften und bestimmten Entitäten (z. B. eine E-Mail-Adresse oder Telefonnummer), die für dieses Element vorhanden sind. Beispielsweise kann eine Mail-App, die die Lese-/Schreibberechtigung für das Postfach anfordert, alle Eigenschaften jedes Elements im Postfach des Benutzers lesen und schreiben. Erstellen, Lesen und Schreiben von Ordnern oder Elementen; und senden ein Element aus diesem Postfach.
Übergeordnete Objekte Die JavaScript-API für Office stellt einige Objekte auf der obersten Ebene bereit, die von allen Typen von Office-Add-ins gemeinsam verwendet werden: Office, Context und AysncResult. Die nächste Ebene in der API, die für E-Mail-Apps geeignet und spezifisch ist, umfasst die Objekte Mailbox, Item und UserProfile, die den Zugriff auf Informationen über Benutzer und Elemente unterstützen, die derzeit im Postfach des Benutzers ausgewählt sind. Auf Datenebene unterstützen die Objekte CustomProperties und RoamingSettings die permanenten Eigenschaften, die von der Mail-App für das ausgewählte Element und für das Postfach des Benutzers eingerichtet wurden. Objekte auf Elementebene umfassen die Objekte Appointment und Message, die von Item erben, und das Objekt MeetingRequest, das von Message erbt. Diese stellen die Typen von Outlook-Elementen dar, die E-Mail-Apps unterstützen: Kalenderelemente von Terminen und Besprechungen sowie Nachrichtenelemente wie E-Mail-Nachrichten, Besprechungsanfragen, Antworten und Absagen. Über diese Ebene in der API hinaus befinden sich Eigenschaften auf Elementebene (z. B. Appointment.subject) sowie Objekte und Eigenschaften, die bestimmte bekannte Entities-Objekte unterstützen (z. B. Contact, MeetingSuggestion, PhoneNumber und TaskSuggestion). Eine Übersicht über die bei Mail-Apps unterstützten Funktionen finden Sie unter Übersicht über Architektur und Features von Outlook-Add-Ins.
Datenzugriffsmodell In der JavaScript-API für Office werden die folgenden Funktionen als ein hierarchisch strukturierter Satz von Objekten dargestellt: die Laufzeitumgebung der App, Postfach und Profil des Benutzers und Daten zu einem Element.
Threadmodelle Jede Mail-App führt ihren eigenen Prozess getrennt vom Outlook-Prozess aus.
Anwendungsarchitekturen In Outlook ist eine Mail-App ein Satz von HTML- und JavaScript-Webseiten, die als separater Prozess in einem Webbrowsersteuerelement gehostet werden, das wiederum in einem App-Laufzeitprozess gehostet wird, der Sicherheit und Leistungsisolation bietet.
Remoteverwendung Mail-Apps verwenden die JavaScript-API für Office, um Daten zum aktuellen Benutzer, zum Postfach und zum ausgewählten Element abzurufen, die auf dem entsprechenden Exchange Server gespeichert sind. Sofern Mail-Apps über die entsprechenden Berechtigungen verfügen und die entsprechende Technik für domänenübergreifenden Zugriff verwenden, können Mail-Apps auch Exchange-Webdienste und andere externe Webdienste aufrufen, um ihre Funktionen zu erweitern.
Transaktionen Die JavaScript-API für Office unterstützt keine Transaktionen.
Verfügbarkeit Die JavaScript-API für Office ist ab Outlook 2013 für Postfächer auf Exchange Server 2013 verfügbar.

Entwicklungsbezogene Kriterien

Kriterium Mail-Apps-Unterstützung in Apps für Office-Plattform
Sprachen und Tools Sie können Mail-Apps mit jeder gängigen Webtechnologie, z. B. HTML5, JavaScript, CSS3, XML und REST-APIs, implementieren. Sie können Ihr bevorzugtes Webentwicklungstool verwenden. Alternativ können Sie Napa, Visual Studio 2012 oder eine höhere Version dieser Tools verwenden, um Zeit bei der Entwicklung zu sparen.
Verwaltete Implementierung Sofern in Ihrem Szenario geeignet, können Sie verwaltete .aspx-Seiten verwenden, um für Ihre Mail-Apps serverseitigen Code zu implementieren.
Skriptfähigkeit Die JavaScript-API für Office wird direkt in Skripts verwendet.
Test- und Debuggingtools Sie können ein beliebiges Webentwicklungstool verwenden. Napa und Visual Studio bieten eine integrierte Entwicklungsumgebung, die das Testen und Debugging von Apps erleichtert. Unter Problembehandlung für die Aktivierung von Outlook-Add-Ins und Beispiel: Debug-Eigenschaften von Outlook-Elementen finden Sie nähere Informationen zur Problembehandlung und zum Debugging bei Mail-Apps.
Verfügbarkeit von Experten Entwickler, die erfolgreich Office-Add-Ins entwickeln können, sind relativ leicht zu finden. Die Plattform ist für die Entwicklung sowohl im professionellen als auch im privaten Bereich gedacht.
Verfügbare Informationen Informationen zur Entwicklung und Veröffentlichung von Office-Add-Ins finden Sie unter Erstellen von Apps für Office und SharePoint. Eine spezielle Dokumentation für Mail-Apps finden Sie unter Outlook-Add-Ins.
Lizenzbestimmungen für Entwicklung und Bereitstellung Unter Lizenzieren von Office- und SharePoint-Add-Ins finden Sie Informationen zum App-Lizenzframework für Office-Add-Ins.

Sicherheitsbezogene Kriterien

Kriterium Mail-Apps-Unterstützung in Apps für Office-Plattform
Berechtigungen zur Entwurfszeit Für die Entwicklung von Mail-Apps benötigen Sie keine besonderen Berechtigungen.
Setupberechtigungen Endbenutzer und Administratoren können standardmäßig Mail-Apps mit niedriger Vertrauenswürdigkeit installieren, welche die Berechtigung Eingeschränkt oder Element lesen erfordern, und Administratoren können Mail-Apps mit hoher Vertrauenswürdigkeit installieren, welche die Berechtigung Lese-/Schreibzugriff für Postfach erfordern.
Laufzeitberechtigungen Mail-Apps fordern eine bestimmte Berechtigungsstufe an, die auf einem dreistufigen Berechtigungsmodell basiert: Eingeschränkt, Element lesen und Lese-/Schreibzugriff für Postfach.
Integrierte Sicherheitsfeatures Die Office-Add-Ins-Runtime bietet die folgenden Vorteile, um zu verhindern, dass eine App die Umgebung des Endbenutzers beschädigt: Isoliert den Prozess, in dem die App ausgeführt wird. Kein Ersetzen der .dll- oder .exe-Datei und keine ActiveX-Komponenten Apps können problemlos vom Endbenutzer installiert und deinstalliert werden. Der Administrator und der Endbenutzer können steuern, welche Mail-Apps verfügbar gemacht werden, und ob die angeforderte Berechtigung gewährt wird, bevor eine Mail-App installiert wird. Bei Rich-Clients wird die Nutzung von Speicherplatz und CPU gesteuert, um Dienstausfälle und bösartige Angriffe zu verhindern.
Features zur Sicherheitsüberwachung Für Mail-Apps werden die folgenden Ressourcen überwacht: CPU-Kernauslastung. Speicherauslastung Anzahl der Abstürze Dauer der Sperrung einer Anwendung Reaktionszeit für reguläre Ausdrücke Häufigkeit der Neubewertung regulärer Ausdrücke Administratoren können Standardeinstellungen, welche die Ressourcenauslastung steuern, überschreiben.

Bereitstellungspezifische Kriterien

Kriterium Mail-Apps-Unterstützung in Apps für Office-Plattform
Anforderungen an die Serverplattform Das Postfach des Benutzers, für das eine Mail-App installiert wird, muss sich auf Exchange Server 2013 oder einer höheren Version befinden.
Anforderungen an die Clientplattform Damit eine Mail-App auf dem Outlook-Rich-Client ausgeführt wird, müssen Outlook 2013 und Internet Explorer 9 oder eine höhere Version dieser Anwendungen auf dem lokalen Computer installiert sein.
Bereitstellungsmethoden Sie können Mail-Apps im Office Store oder in einem Exchange-Katalog veröffentlichen, der die App für Benutzer auf diesem Exchange Server zur Verfügung stellt. Administratoren oder Benutzer können dann eine Mail-App aus dem Office Store oder Exchange-Katalog installieren, indem sie entweder das Exchange Admin Center (EAC) verwenden oder Windows PowerShell-Remote-Cmdlets ausführen. Sie können über Ansicht „Outlook-Backstage“ oder die Outlook Web App auf das EAC zugreifen oder sich direkt beim EAC für Ihr Postfach anmelden. Weitere Informationen hierzu finden Sie unter Bereitstellen und Installieren von Outlook-Add-Ins zu Testzwecken.
Hinweise zur Bereitstellung Sobald Sie eine Mail-App in Outlook oder Outlook Web App installieren, ist die Mail-App für dieses Postfach auf beiden Outlook-Clients verfügbar.

Objektive Bewertungskriterien für das Objektmodell und die PIA

Auf dem Clientcomputer ausgeführte Lösungen können das Outlook-Objektmodell oder die Outlook-PIA verwenden, um Outlook-Elemente wie Kontakte, Nachrichten, Kalenderelemente, Besprechungsanfragen und Aufgaben programmgesteuert aufzurufen. Anders als die MAPI können das Outlook-Objektmodell und die PIA bei Änderungen der Outlook-Benutzeroberfläche, wie einer Änderung des aktuellen Ordners oder der Anzeige eines Outlook-Inspectors, Ereignisbenachrichtigungen bereitstellen.

Hinweis

[!HINWEIS] Für eine Lösung für den Zugriff auf Daten, die in einem Microsoft Exchange-Postfach oder einer Persönlichen Ordner-Datei (PST) gespeichert sind, muss Outlook auf dem Clientcomputer installiert und konfiguriert sein, auf dem die Anwendung ausgeführt wird. > Das Outlook-Objektmodell und die PIA unterstützen die gleichen Funktionen zum Erweitern von Outlook. Die PIA definiert verwaltete Schnittstellen, die dem COM-basierten Objektmodell zugeordnet sind und mit denen eine verwaltete Lösung interagieren kann. In den restlichen Erläuterungen in diesem Abschnitt beziehen sich die meisten der funktions-, sicherheits- und bereitstellungsbezogenen Kriterien gleichermaßen auf das Objektmodell wie auf die PIA. Weitere Informationen dazu, wie die PIA die Interoperabilität zwischen COM und dem .NET Framework erleichtert, finden Sie unter Einführung in die Interoperabilität zwischen COM und .NET und Architektur der Outlook-PIA.

In den folgenden Tabellen sind Bewertungskriterien für das Outlook-Objektmodell und die Outlook-PIA aufgeführt.

Funktionsbezogene Kriterien

Kriterium Outlook-Objektmodell oder PIA
Anwendungsdomäne Add-Ins oder eigenständige Anwendungen, in denen das Outlook-Objektmodell oder die PIA verwendet wird, dienen typischerweise zum Behandeln von benutzerspezifischen Nachrichten, Anpassen der Outlook-Benutzeroberfläche oder Erstellen von benutzerdefinierten Elementtypen für spezialisierte Lösungen wie etwa CRM-Lösungen (Customer Relationship Management, Kundenbeziehungsmanagement), die mit Outlook integriert sind. Das Outlook-Objektmodell oder die PIA wird manchmal für die Nachrichtenverarbeitung in einem informellen Workflowprozess verwendet, besonders dann, wenn die Anwendungsentwicklung auf Microsoft Exchange Server nicht erlaubt ist. Anders als browserbasierte Clients können Outlook-Lösungen dank des Cache-Modus auch dann ausgeführt werden, wenn der Benutzer offline ist oder keine Verbindung mit dem Unternehmensnetzwerk hat.
Übergeordnete Objekte Das Objekt auf oberster Ebene im Outlook-Objektmodell und der Outlook-PIA ist das Application-Outlook-Objekt. Die Objekte Explorers, Conversation, Inspectors, Views, NavigationPane, SolutionsModule, FormRegion und verwandte Objekte stellen Elemente der Outlook-Benutzeroberfläche dar. Die Objekte NameSpace, Stores, Folders, Accounts, AccountSelector, AddressEntries, ExchangeUser und verwandte Objekte unterstützt die Erweiterung von Sitzungen, Profilen, Benutzerkonten, Nachrichtenspeichern und Ordnern in Outlook. Auf der Datenebene stellen eine Reihe von Objekte auf Elementebene, wie MailItem, AppointmentItem, ContactItem und TaskItem die integrierten Outlook-Elementtypen dar. Die Objekte PropertyAccessor, Table, Search, ItemProperties, UserDefinedProperties, Attachments, Categories, Recipients, RecurrencePattern, Reminders, Rules und verwandte Objekte unterstützen die Anpassung und Bearbeitung von Objekten auf Elementebene.
Datenzugriffsmodell Im Outlook-Objektmodell und in der Outlook-PIA werden alle Daten als hierarchisch strukturierter Satz von Objekten und Sammlungen dargestellt.
Threadmodelle Alle Aufrufe des Outlook-Objektmodells und der Outlook-PIA werden im Haupt-Vordergrundthread von Outlook ausgeführt. Das einzige vom Outlook-Objektmodell unterstützte Threadmodell ist Single-Thread Apartment (STA). Das Aufrufen des Outlook-Objektmodells oder der Outlook-PIA aus einem Hintergrundthread wird nicht unterstützt und kann Fehler und unerwartete Ergebnisse in einer Lösung verursachen.
Anwendungsarchitekturen In COM-Add-Ins und anderen Microsoft Office-Anwendungen wird typischerweise das Outlook-Objektmodell zum Erweitern von Outlook verwendet. Verwaltete Lösungen können die Outlook-PIA und die COM-Interoperabilitätsschicht von Visual Studio und .NET Framework verwenden, um auf das Outlook-Objektmodell zuzugreifen. Visual Studio bietet Vorlagen sowie zusätzliche Klassenbibliotheken und Manifeste, um Anpassungen von Office-Dokumenten und -Anwendungen zu erleichtern. Weitere Informationen zum Entwickeln von verwalteten Add-Ins für Outlook mithilfe von Visual Studio finden Sie unter Architecture of Application-Level Add-Ins und Outlook Solutions. Das Outlook-Objektmodell unterstützt auch VBA-Makros (Visual Basic für Anwendungen) und Windows Scripting Host (WSH), aber keine Windows-Dienstanwendungen.
Remoteverwendung Das Outlook-Objektmodell und die Outlook-PIA können nur auf einem Computer genutzt werden, auf dem Outlook installiert ist. Mithilfe des Outlook-Objektmodells kann auf in Exchange gespeicherte Informationen, die in der Outlook-Anwendung zur Verfügung stehen, zugegriffen werden.
Transaktionen Das Outlook-Objektmodell und die Outlook-PIA unterstützen keine Transaktionen.
Verfügbarkeit Das Outlook-Objektmodell ist derzeit in allen Versionen von Outlook verfügbar. Die PIA steht in Versionen von Outlook ab Outlook 2003 zur Verfügung. Mit jeder neuen Version von Outlook wurden Erweiterungen und Verbesserungen hinzugefügt.

Entwicklungsbezogene Kriterien

Kriterium Outlook-Objektmodell oder Outlook-PIA
Sprachen und Tools Sie können auf dem Outlook-Objektmodell basierende Anwendungen sowohl in einer beliebigen COM- oder automatisierungskompatiblen Sprache implementieren, z. B. Visual Basic oder C#, als auch in Nicht-COM-Sprachen, etwa systemeigenes C oder C++. Microsoft Office-Entwicklungstools in Microsoft Visual Studio 2010 sind die bevorzugten Tools für die Entwicklung verwalteter Add-Ins für Outlook 2010 und Outlook 2007. Microsoft Visual Studio 2005-Tools für Microsoft Office System sind die bevorzugten Tools für Outlook 2003. Sie können auch Office-Entwicklungstools in Visual Studio 2010 verwenden, um Lösungen für 32-Bit- und 64-Bit-Versionen von Outlook zu erstellen. Wenn Sie eine Projektmappe in Office-Entwicklungstools in Visual Studio 2010 oder Microsoft Visual Studio-Tools für Microsoft Office System erstellen, führt die Angabe der Option Beliebige CPU für die Zielplattform zu verwalteten Lösungen, die sowohl für 32-Bit- als auch für 64-Bit-Versionen von Outlook 2010 funktionieren.
Verwaltete Implementierung Die Outlook-PIA ermöglicht die Verwendung des Outlook-Objektmodells in einer Umgebung mit verwaltetem Code, die von einer Vielzahl von Klassenbibliotheken und Supporttechnologien unterstützt wird, die viele Einschränkungen von VBA- und COM-Add-Ins berücksichtigen. Die PIA ist ein COM-Wrapper, der als Brücke zwischen den verwalteten und COM-Umgebungen fungiert. Weitere Informationen finden Sie unter Gründe für die Verwendung der Outlook-PIA.
Skriptfähigkeit Das Outlook-Objektmodell kann in Skripts verwendet werden.
Test- und Debuggingtools Wenn Sie das Outlook-Objektmodell oder die Outlook-PIA nutzen möchten, benötigen Sie keine besonderen Debuggingtools. Andererseits können Sie Visual Studio verwenden, um eine integrierte Entwicklungsumgebung bereitzustellen, die das Testen und Debuggen von Anwendungen erleichtert.
Verfügbarkeit von Experten Entwickler, die erfolgreich Anwendungen mithilfe des Outlook-Objektmodells oder der Outlook-PIA entwickeln können, sind relativ leicht zu finden. Das Outlook-Objektmodell und die Outlook-PIA sind für Add-Ins vorgesehen, die mit gängigen Entwicklungstools wie etwa Visual Studio erstellt werden. Diese Tools bieten Entwurfszeitumgebungen, die den Entwicklungsprozess vereinfachen.
Verfügbare Informationen Informationen zum Programmieren mithilfe des Outlook-Objektmodells finden Sie in Ressourcen sowohl von Microsoft als auch von Drittanbietern. Weitere Informationen zum Outlook-Objektmodell finden Sie in der Outlook 2010-Entwicklerreferenz. Weitere Informationen zur Outlook-PIA finden Sie in der Referenz zur primären Interopassembly von Outlook 2010. Beispiele für verwaltete Outlook-Lösungen, die mithilfe von Office-Entwicklungstools in Visual Studio entwickelt wurden, finden Sie unter Outlook-Lösungen mit Visual Studio.
Lizenzbestimmungen für Entwicklung und Bereitstellung Lesen Sie in den Lizenzvereinbarungen für Ihr Exchange- und Microsoft Developer Network (MSDN)-Abonnement nach, welche zusätzlichen Lizenzen Sie u. U. für die Verwendung von Outlook und des Outlook-Objektmodells in Ihren Anwendungen benötigen.

Sicherheitsbezogene Kriterien

Kriterium Outlook-Objektmodell oder PIA
Berechtigungen zur Entwurfszeit Für die Entwicklung von Anwendungen mithilfe des Outlook-Objektmodells oder der Outlook-PIA benötigen Sie keine besonderen Berechtigungen.
Setupberechtigungen Zum Installieren von Anwendungen, in denen das Outlook-Objektmodell oder die Outlook-PIA verwendet wird, benötigen Sie keine besonderen Berechtigungen. Allerdings benötigen Sie die Berechtigungen eines lokalen Administrators, um Office und Outlook zu installieren.
Laufzeitberechtigungen Zum Ausführen von Anwendungen, in denen das Outlook-Objektmodell oder die Outlook-PIA verwendet wird, benötigen Sie keine besonderen Berechtigungen.
Integrierte Sicherheitsfeatures Das Outlook-Objektmodell und die Outlook-PIA kommunizieren mit Exchange über die MAPI und mit Active Directory über die Active Directory Service Interfaces (ADSI). Anhand des aktuellen Sicherheitskontexts des Benutzers, der die Anwendung ausführt, wird ermittelt, auf welche Ressourcen dieser Code zugreifen kann. Standardmäßig gelten Add-Ins als vertrauenswürdig für den vollständigen Zugriff auf alle Objekte, Eigenschaften und Methoden im Outlook-Objektmodell oder in der PIA. IT-Administratoren können steuern, welche Add-Ins und Objekte auf das Outlook-Objektmodell oder die Outlook-PIA zugreifen können. Das Outlook-Objektmodell und die Outlook-PIA verhindern, dass Code, der außerhalb des Outlook-Prozesses ausgeführt wird, auf sichere Objekte und Methoden zugreifen kann.
Features zur Sicherheitsüberwachung Outlook überwacht die folgenden Metriken eines Add-Ins, um zu bestimmen, ob das Add-In deaktiviert werden soll: Ordner wird vom Start heruntergefahren Element geöffnet Aufrufhäufigkeit Administratoren können gruppenrichtlinien verwenden, um Benutzereinstellungen außer Kraft zu setzen und die Add-Ins zu steuern, die auf den Computern des Benutzers ausgeführt werden. Weitere Informationen finden Sie unter Leistungskriterien für die Aktivierung von Add-Ins.

Bereitstellungsbezogene Kriterien

Kriterium Outlook-Objektmodell oder PIA
Anforderungen an die Serverplattform Das Outlook-Objektmodell und die Outlook-PIA sind clientseitige Technologien.
Anforderungen an die Clientplattform Für Anwendungen, in denen das Outlook-Objektmodell oder die Outlook-PIA zum Aufrufen von Exchange-Daten verwendet werden, muss Outlook auf dem lokalen Computer installiert sein.
Bereitstellungsmethoden Anwendungen, in denen das Outlook-Objektmodell oder die Outlook-PIA verwendet werden, werden mithilfe herkömmlicher Software für die Anwendungsinstallation verteilt.
Hinweise zur Bereitstellung Da Outlook nicht auf dem Exchange Server installiert werden soll, können Anwendungen, in denen das Outlook-Objektmodell oder die Outlook-PIA verwendet werden, nicht auf dem Exchange Server ausgeführt werden.

Objektive Bewertungskriterien für die MAPI

Sie können die MAPI verwenden, um Elemente in öffentlichen und privaten Speichern abzurufen und auf die Eigenschaften zuzugreifen, die mit jedem Element gespeichert sind. Alle Versionen von Outlook verwenden die MAPI. Sie können Clients erstellen, welche die MAPI verwenden, ebenso wie MAPI-Server und MAPI-Formularhandler. Die Informationen in diesem Abschnitt beziehen sich nur auf MAPI-Clientanwendungen.

Hinweis

[!HINWEIS] Die MAPI ist ein ausgereifter Mechanismus zum Abrufen von Informationen in Exchange oder in einer Persönlichen Ordner-Datei (PST), und die MAPI bietet einige Funktionen, die in keiner anderen API verfügbar sind. Die MAPI ist jedoch nicht gut geeignet für die Verwendung außerhalb eines Intranets, hält während der MAPI-Sitzung eine offene Verbindung und kann schwer zu erlernen sein. Die MAPI erzwingt keine Outlook-Geschäftslogik, sodass Sie besonders darauf achten müssen, dass Outlook-Geschäftslogik aufrechterhalten wird.

In den folgenden Tabellen sind Bewertungskriterien für die MAPI aufgeführt.

Funktionsbezogene Kriterien

Kriterium MAPI
Anwendungsdomäne Clientanwendungen, in denen die MAPI verwendet wird, greifen auf ein Benutzerpostfach oder auf in Exchange gespeicherte Informationen in einem öffentlichen Ordner sowie auf in Active Directory gespeicherte Benutzerverzeichnisinformationen zu. Clientanwendungen, welche die MAPI verwenden, sind typischerweise E-Mail-Clients wie Outlook und Anwendungen, die eine komplexe E-Mail-Verarbeitung erfordern.
Übergeordnete Objekte Alle MAPI-Objekte werden über die IMAPISession: IUnknown-Schnittstelle bezogen. Das Sitzungsobjekt stellt den Clientzugriff auf Objekte für die Verwendung von MAPI-Profilen, Statusinformationen, Nachrichtenspeichertabellen und Adressbüchern sowie die Verwaltung von Nachrichtendienstanbietern bereit. Die Nachrichtenspeichertabellen enthalten Objekte für den Nachrichtenspeicher, Ordner, Nachrichten, Anlagen und Empfänger. Die Adressbuchtabellen enthalten Objekte für Messagingbenutzer und Verteilerlisten.
Datenzugriffsmodell In der MAPI werden Nachrichten und Benutzer als hierarchisch strukturierter Satz von Objekten dargestellt.
Threadmodelle Hierfür gelten keine besonderen Beschränkungen. Allerdings sollten in Anwendungen, die Free-Threading verwenden, wegen des hohen Aufwands für das Marshalling von Objekten MAPI-Objekte nicht in den Threads gemeinsam verwendet werden. Die MAPI und MAPI-Dienstanbieter verwenden Free-Threading.
Anwendungsarchitekturen MAPI-Clientanwendungen sind in der Regel auf Windows Forms basierende Clientanwendungen. Sie können die MAPI jedoch auch zum Schreiben von n-stufigen Anwendungen nutzen.
Remoteverwendung Die MAPI kommuniziert über Remoteprozeduraufrufe (Remote Procedure Calls, RPCs) mit dem Exchange Server. Mithilfe von Sperren wird typischerweise verhindert, dass RPCs Internetfirewalls durchqueren.
Transaktionen Die MAPI unterstützt keine Transaktionen.
Verfügbarkeit Derzeit wird mit allen Versionen von Windows ein MAPI-Stub ausgeliefert. Office installiert bei der Installation von Outlook ein eigenes MAPI-Subsystem. Gegenwärtig sind keine Änderungen an der MAPI zu erwarten.

Entwicklungsbezogene Kriterien

Kriterium MAPI
Sprachen und Tools Mithilfe von C oder C++ können Sie direkt auf die MAPI zugreifen. Andere Sprachen, die auf die C/C++-Aufrufkonvention zugreifen können, können unter Umständen auf die MAPI zugreifen. Die Verwendung von verwalteten Sprachen wie etwa Visual Basic oder C# wird nicht unterstützt. Für 32-Bit- und 64-Bit-Versionen von Outlook müssen Sie separate MAPI-Lösungen kompilieren.
Verwaltete Implementierung Die MAPI ist eine nicht verwaltete Komponente. Die Verwendung der MAPI wird unter der COM-Interoperabilitätsschicht von Visual Studio und .NET Framework nicht unterstützt.
Skriptfähigkeit Die MAPI kann nicht direkt in Skripts verwendet werden.
Test- und Debuggingtools Zum Debuggen von Anwendungen, in denen die MAPI verwendet wird, benötigen Sie keine besonderen Debuggingtools. Allerdings können Sie MFCMAPI verwenden. MFCMAPI stellt mithilfe der MAPI Zugriff auf MAPI-Speicher über eine grafische Benutzeroberfläche bereit und erleichtert die Analyse von Problemen beim Erweitern von Outlook anhand der MAPI.
Verfügbarkeit von Experten Erfahrene MAPI-Programmierer können schwer zu finden sein, und das Erlernen der Technologie kann viel Zeit in Anspruch nehmen. Zusätzlich zu den Microsoft-Communitys gibt es nur eine kleine Anzahl hochwertiger Websites von Drittanbietern, die hilfreiche MAPI-Entwicklungsinformationen bereitstellen.
Verfügbare Informationen Es sind sowohl Bücher von Microsoft als auch Publikationen von Drittanbietern zum Thema MAPI-Programmierung erhältlich.
Lizenzbestimmungen für Entwicklung und Bereitstellung Zum Entwickeln von Anwendungen, in denen die MAPI verwendet wird, sind keine besonderen Lizenzen erforderlich.

Sicherheitsbezogene Kriterien

Kriterium MAPI
Berechtigungen zur Entwurfszeit Der Entwickler muss über Berechtigungen für den Zugriff auf die Daten im Exchange-Speicher verfügen. Exchange speichert Benutzer- und Verteilerlisteninformationen in Active Directory, sodass Entwickler, die MAPI-Clientanwendungen erstellen, die auf diese Informationen zugreifen, die Möglichkeit haben müssen, diese Informationen abzurufen und festzulegen.
Setupberechtigungen Für das Setup von MAPI-basierten Anwendungen muss der Benutzer in der Regel ein lokaler Administrator sein oder über Berechtigungen zum Installieren von Software verfügen.
Laufzeitberechtigungen Für das Ausführen einer MAPI-basierten Anwendung benötigt der Benutzer normalerweise nur ausreichende Berechtigungen zum Zugriff auf die Daten in einem Exchange-Speicher oder einer PST-Datei.
Integrierte Sicherheitsfeatures MAPI-Profile können auf den meisten Plattformen mit Kennwortschutz versehen werden.

Bereitstellungsbezogene Kriterien

Kriterium MAPI
Anforderungen an die Serverplattform Der Exchange-Server, auf dem Benutzerdaten für die Benutzer der MAPI-Clientanwendung gespeichert werden, muss korrekt für den Zugriff durch MAPI-Clients konfiguriert sein.
Anforderungen an die Clientplattform Das Installationsprogramm der Clientanwendung sollte mithilfe der Datei "Mapisvc.inf" sicherstellen, dass die richtige MAPI-Version auf dem Computer vorhanden und korrekt konfiguriert ist.
Bereitstellungsmethoden Anwendungen, in denen die MAPI verwendet wird, können mithilfe von standardmäßigen Softwareverteilungstechnologien auf Clientcomputern bereitgestellt werden.
Hinweise zur Bereitstellung Das Installationsprogramm sollte sicherstellen, dass die korrekte MAPI-Version verfügbar ist.

Argumente für die Apps für Office-Plattform

Da Office-Add-Ins Webtechnologien verwenden, sind sie am besten dafür geeignet, eine Verbindung zu in der Cloud oder lokal gehosteten Diensten herzustellen, und die Dienste in den Kontext des Rich-Client und Webclient zu integrieren. Durch die Anforderung geeigneter Berechtigungen erlauben Mail-Apps auch das Lesen, Schreiben und Senden von Elementen in einem Postfach.

Im Folgenden sind allgemeine Gründe dafür aufgeführt, warum Mail-Apps für Entwickler die bessere Wahl sind als Add-Ins:

  • Sie können vorhandenes Know-how im Bereich von Webtechnologien wie HTML, JavaScript und CSS nutzen und von deren Vorteilen profitieren. Für Poweruser und neue Entwickler ist die Anlaufzeit mit XML, HTML und JavaScript erheblich kürzer als mit COM-basierten APIs, einschließlich des Objektmodells und der MAPI.

  • Sie können ein einfaches Webentwicklungsmodell verwenden, um Ihre Mail-App (einschließlich der Webdienste, die von der App verwendet werden) auf Ihrem Webbrowser zu aktualisieren, ohne dass eine komplizierte Installation auf dem Outlook-Client erforderlich ist. Updates für die Mail-App (mit Ausnahme des App-Manifests) erfordern keine Aktualisierung auf dem Office-Client. Sie können den Code und die Benutzeroberfläche der Mail-App bequem einfach auf dem Webserver aktualisieren. Dies stellt einen erheblichen Vorteil gegenüber den administrativen Aufwand dar, der mit der Aktualisierung von Add-Ins verbunden ist.

  • Sie können eine gängige Webentwicklungsplattform für Mail-Apps verwenden, die auf dem Outlook-Rich-Client und in der Outlook Web App auf dem Desktop, dem Tablet und dem Smartphone ausgeführt werden können. Add-Ins verwenden dagegen das Objektmodell für den Outlook-Rich-Client und können daher nur auf diesem Rich-Client auf einem Desktop-PC ausgeführt werden.

  • Sie profitieren davon, dass Sie Apps rasch erstellen und über die Office Store veröffentlichen können.

  • Das dreistufige Berechtigungsmodell bietet Benutzern und Administratoren mehr Sicherheit und Datenschutz in Mail-Apps als Add-Ins, welche uneingeschränkten Zugriff auf den Inhalt aller Konten im Benutzerprofil haben. Dies fördert wiederum die Nutzung von Apps durch die Benutzer.

  • Je nach Ihren Szenarien gibt es Features, die nur Mail-Apps aufweisen und die von Add-Ins nicht unterstützt werden:

    • Sie können festlegen, dass eine Mail-App nur bei bestimmten Kontexten aktiviert wird (Beispiel: Outlook zeigt die App nur dann in der App-Leiste an, wenn die Nachrichtenklasse des vom Benutzer ausgewählten Termins "IPM.Appointment.Contoso" lautet, oder wenn der Text einer E-Mail eine Paketverfolgungsnummer oder einen Kundenkennzeichner enthält).

    • Sie können eine Mail-App aktivieren, wenn die ausgewählte Nachricht einige bekannte Entitäten enthält, wie z. B. Adresse, Kontakt, E-Mail-Adresse, Besprechungsvorschlag oder Aufgabenvorschlag.

    • Sie können von den Vorteilen einer Authentifizierung durch Identitätstoken und von Exchange-Webdiensten profitieren.

Die folgenden Features werden allerdings nur von Add-Ins bereitgestellt, sodass diese u. U. in manchen Fällen die geeignetere Wahl als Mail-Apps sind:

  • Sie können Outlook mit Add-Ins auf Anwendungsebene erweitern oder automatisieren, da das Objektmodell und die PIA eine umfassende Integration mit Outlook-Features (wie allen Outlook-Elementtypen, Benutzeroberfläche, Sitzungen und Regeln) bieten. Auf der Elementebene können Add-Ins mit einem Element im Lesen- oder Verfassenmodus interagieren. Mit Mail-Apps können Sie Outlook nicht auf der Anwendungsebene automatisieren, und Sie können die Funktionen von Outlook nur im Kontext des Lesemodus der unterstützten Elemente (Nachrichten und Termine) im Postfach des Benutzers erweitern.

  • Sie können benutzerdefinierte Geschäftslogik für einen neuen Elementtyp angeben.

  • Sie können benutzerdefinierte Befehle im Menüband und in der Backstage-Ansicht ändern und hinzufügen.

  • Sie können benutzerdefinierte Formularseiten oder Formularbereiche anzeigen.

  • Sie können Ereignisse wie das Senden eines Elements oder das Ändern von Eigenschaften eines Elements ermitteln.

  • Sie können Add-Ins in Outlook 2013 und Exchange Server 2013 sowie in früheren Versionen von Outlook und Exchange verwenden. Auf der anderen Seite funktionieren Mail-Apps ab Outlook 2013 und Exchange Server 2013 mit Outlook und Exchange, aber nicht mit früheren Versionen.

Weitere Informationen zu Szenarien, die vom Objektmodell und der PIA unterstützt werden, finden Sie im nächsten Abschnitt, Argumente für das Objektmodell oder die PIA. Einen Vergleich der Office-Add-Ins-Plattform mit anderen Erweiterungstechnologien für Office finden Sie in Der Hintergrund zu Apps für Office und SharePoint.

Entscheidungsfaktoren für das Objektmodell oder die PIA

Die wichtigsten Basisszenarien, die vom Outlook-Objektmodell oder von der PIA unterstützt werden

Verwenden Sie im Allgemeinen das Objektmodell oder die PIA, wenn Ihre Lösung die Outlook-Benutzeroberfläche anpasst oder auf der Geschäftslogik von Outlook basiert. Im Folgenden werden die wichtigsten Basisszenarien gezeigt, für die Outlook-Lösungen das Objektmodell oder die PIA verwenden.

Szenarien, die vom Outlook-Objektmodell oder PIA seit Outlook 2007 unterstützt werden

Wenn Ihre Outlook-Lösung neben den Grundszenarien eines der in der folgenden Liste gezeigten Szenarien unterstützt und mit Outlook 2007 oder einer späteren Version ausgeführt werden soll, nicht jedoch mit einer früheren Version, können Sie auch das Objektmodell oder die PIA verwenden. In diesem Abschnitt werden die Hauptobjekte oder -mitglieder gezeigt, mit denen Sie im Outlook-Objektmodell die einzelnen Szenarien erweitern können (ausgenommen die IDTExtensibility2 -Schnittstelle im Visual Studio-Automatisierungsobjektmodell und die IRibbonExtensibility-Schnittstelle im Office-Objektmodell, die Sie in das Outlook-Objektmodell integrieren können).

Szenarien, die vom Outlook-Objektmodell oder PIA seit Outlook 2010 unterstützt werden

Wenn Ihre Outlook-Lösung mit Outlook 2010 und nicht mit früheren Versionen ausgeführt werden soll, können Sie das Objektmodell oder die PIA verwenden, um die im nächsten Abschnitt gezeigten Szenarien zu unterstützen. Dieser Abschnitt gibt die Hauptobjekte oder -mitglieder an, mit denen Sie im Outlook-Objektmodell die einzelnen Szenarien erweitern können (ausgenommen die Schnittstellen IRibbonControl, IRibbonExtensibility und IRibbonUI im Office-Objektmodell, die Sie in das Outlook-Objektmodell integrieren können).

Szenarien, die vom Outlook-Objektmodell oder PIA seit Outlook 2013 unterstützt werden

Wenn Ihre Outlook-Lösung mit Outlook 2013 und nicht mit früheren Versionen ausgeführt werden soll, können Sie das Objektmodell oder die PIA verwenden, um die im Folgenden gezeigten Szenarien zu unterstützen.

Entscheidungsfaktoren für MAPI

Grundsätzlich verwenden Sie die MAPI, um auf Daten auf einem MAPI-basierten Server wie etwa dem Microsoft Exchange-Server zuzugreifen und Aufgaben wie die folgenden auszuführen:

  • Erstellen eines benutzerdefinierten Dienstanbieters, z. B. eines Adressbuch-, Transport- oder Speicheranbieters

  • Erstellen eines Senkenprozesses

  • Erstellen oder Bearbeiten eines Profils

  • Ausführen einer Anwendung als Windows NT-Dienst

  • Ausführen von Aufgaben in einem Hintergrundthread. Beispielsweise kann durch das Auflisten einer großen Menge von Elementen in einem Ordner und Ändern der Eigenschaften der Elemente in einem Hintergrundthread die Leistung optimiert werden.

Weitere Informationen sowie Codebeispiele finden Sie in der MAPI-Referenz für Outlook und unter MFCMAPI.

Zudem ist Folgendes zu beachten: Wenn Ihre Lösung mit einer früheren Version von Outlook als Outlook 2007 ausgeführt wird und Szenarien wie die folgenden auf Ihre Lösung zutreffen, sollten Sie die MAPI verwenden, um diese Szenarien zu erweitern.

  • Festlegen und Abrufen integrierter Eigenschaften auf Elementebene, die nicht im Objektmodell offengelegt werden
  • Verwalten von Konten, Anlagen, Exchange-Verteilerlisten, Exchange-Benutzer oder Speicher
  • Speichern privater Daten für Lösungen
  • Verwalten eines Nachrichtenspeichers für ein Konto

Seit Outlook 2007 unterstützt das Objektmodell eine Reihe von Features, die in Versionen vor Outlook 2007 nicht vorhanden waren, sodass Entwickler damals auf die MAPI oder andere APIs wie etwa Microsoft-Datenobjekte für die Zusammenarbeit (Collaboration Data Objects, CDO) 1.2.1 und Microsoft Exchange-Clienterweiterungen zurückgreifen mussten. Wenn also eines oder mehrere der Szenarien in der obigen Liste auf Ihre Lösung zutreffen, die Lösung aber mit Outlook 2007 oder Outlook 2010 ausgeführt wird, können und sollten Sie das Outlook-Objektmodell oder die PIA verwenden, um diese Szenarien zu unterstützen. Weitere Informationen zu Erweiterungen in Outlook 2007, mit denen Outlook-Entwicklungstechnologien zusammengeführt werden, finden Sie in What's New for Developers in Outlook 2007 (Part 1 of 2).

Argumente für die Hilfs-APIs

Die Outlook-Hilfs-APIs können in manchen Szenarien, in denen das Objektmodell oder die MAPI keine Lösung bieten, mit der Outlook-Geschäftslogik oder der MAPI integriert werden. Verwenden Sie die Outlook-Hilfs-APIs in folgenden Szenarien:

  • Kontoverwaltung: Verwalten von Kontoinformationen, Bearbeiten von Konten, Senden von Benachrichtigungen bei Kontoänderungen und Schützen von Konten vor unerwünschten E-Mail-Nachrichten (Spam)
  • Verschlechterung der Datenqualität: Umschließen eines Objekts mit einem bevorzugten Zeichenformat, anstatt es in seinem nativen Format offenzulegen
  • Zuweisen einer neuen Basis für Kalender und Zeitzonenunterstützung: Zuweisen einer neuen Basis zu Outlook-Kalendern, um Sommerzeit zu unterstützen
  • Frei/Gebucht-Status: Bereitstellen von Frei/Gebucht-Informationen in Kalendern
  • Kontaktbilder: Festlegen der Anzeige des Bilds für einen Kontakt in Outlook
  • Aktualität von Elementen: Feststellen, ob für ein Outlook-Element noch nicht gespeicherte Änderungen vorliegen
  • Kategorisieren von Elementen: Kategorisieren eines Outlook-Elements, nachdem dieses gesendet wurde

Weitere Informationen zu den Hilfs-APIs finden Sie im Abschnitt Weitere Ressourcen: Hilfs-APIs.

Automatisieren von Outlook mit prozessinternen gegenüber prozessexternen Lösungen

Hinweis

Die Erläuterungen zur Automatisierung von Outlook in diesem und dem nächsten Abschnitt gehen über den Anwendungsbereich von Office-Add-Ins hinaus. Diese sind darauf ausgelegt, die Funktionen des Office-Clients oder der Office-Webanwendung zu erweitern, jedoch nicht zu automatisieren.

Outlook unterstützt die Automatisierung, indem es Add-Ins verwendet, die im gleichen Vordergrundprozess wie der Outlook-Prozess ausgeführt werden, und eigenständige Lösungen, die in einem eigenen, separaten Prozess außerhalb des Outlook-Prozesses ausgeführt werden. Verwenden Sie für die Interaktion mit Outlook über das Objektmodell, PIA oder MAPI und – was weniger häufig vorkommt – über eine Hilfs-API (wie etwa HrProcessConvActionForSentItem) grundsätzlich ein Add-In. Verwenden Sie eine Out-of-Process-Lösung nur, wenn dies erforderlich ist (z. B. wenn Sie eine MAPI-Clientanwendung schreiben, die die Tzmovelib.dll-Datei verwendet, um Outlook-Kalender für Kunden zu rebasen, oder wenn Sie zahlreiche Elemente in einem Ordner auflisten und die Eigenschaften der Elemente in einem Hintergrundthread ändern, um die Leistung zu optimieren).

Add-Ins sind die bevorzugte Lösung zum Automatisieren von Outlook, da Outlook nur dem Application-Objekt vertraut, das während des OnConnection(Object, ext_ConnectMode, Object, Array) -Ereignisses des Add-Ins an das Add-In übergeben wurde. Sie können die Anzeige von Sicherheitswarnungen des Object Model Guard verhindern, indem Sie alle Objekte, Eigenschaften und Methoden von diesem Application-Objekt ableiten. Wenn das Add-In eine neue instance des Application-Objekts erstellt, vertraut Outlook diesem Objekt nicht, auch wenn das Add-In in der Liste der vertrauenswürdigen Add-Ins enthalten ist. Von einem solchen Application-Objekt abgeleitete Objekte, Eigenschaften und Methoden werden nicht vertrauenswürdig, und die blockierten Eigenschaften und Methoden rufen Sicherheitswarnungen auf. Weitere Informationen zum Outlook Object Model Guard finden Sie unter Security Behavior of the Outlook Object Model.

Automatisieren von Outlook mit verwalteten gegenüber nicht verwalteten Lösungen

Outlook unterstützt die Automatisierung durch Add-Ins und eigenständige Anwendungen, die in verwalteten oder nicht verwalteten Sprachen programmiert wurden. Die gängigeren verwalteten Sprachen sind C# und Visual Basic. C++- und Delphi-Tools werden bei der nicht verwalteten Entwicklung häufiger eingesetzt. Welches Fachwissen verfügbar ist, ist eine der Überlegungen, die bei der Wahl zwischen verwalteter und nicht verwalteter Entwicklung den Ausschlag geben.

Wenn in Ihrer Lösung nur das Objektmodell verwendet wird, können Sie eine verwaltete Lösung mithilfe der PIA oder der Office-Entwicklungstools in Visual Studio entwickeln. Die Office-Entwicklungstools in Visual Studio bieten Projektvorlagen und visuelle Designer, die das Erstellen von benutzerdefinierten Schnittstellen und das Entwickeln von Office-Lösungen vereinfachen.

Andererseits unterstützt Microsoft die Verwendung der MAPI in verwaltetem Code nicht, da die MAPI Jahre vor Microsoft .NET Framework entwickelt wurde und Microsoft keine verwalteten Wrapper für die MAPI bereitstellt. Wenn Sie die MAPI verwenden, müssen Sie eine nicht verwaltete Lösung entwickeln. Weitere Informationen finden Sie unter Supportrichtlinien für die Entwicklung von clientseitigen Messaginglösungen.

Nischen-APIs und -Technologien

Der Outlook Connector für soziale Netzwerke (Outlook Social Connector, OSC) und die Wetterleiste unterstützen die Erweiterung sehr spezieller Szenarien in Outlook.

OSC-Anbietererweiterung

Die OSC-Anbietererweiterung (Outlook Connector für soziale Netzwerke) unterstützt die Entwicklung eines Anbieters für ein soziales Netzwerk, damit Benutzer in Outlook und anderen Office-Clientanwendungen Aktualisierungen von Informationen über Freunde und Aktivitäten in diesem sozialen Netzwerk ansehen können. In Abbildung 6 ist der OSC dargestellt, der im Personenbereich die Aktivitäten einer Person auf sozialen Netzwerkwebsites anzeigt.

Abbildung 6 Die OSC, die Daten sozialer Netzwerke im bereich "Personen" anzeigt

Bereich des Outlook Connector für soziale Netzwerke

Mit dem OSC in Outlook können Benutzer im Personenbereich eine Zusammenstellung der E-Mails, Anlagen und Besprechungsanfragen einer Person in Outlook anzeigen. In einer Organisationsumgebung können Benutzer, die über eine Microsoft SharePoint-Website zusammenarbeiten, Dokumentaktualisierungen und andere Websiteaktivitäten dieser Person auf der SharePoint-Website sehen. Die Erweiterbarkeit über den OSC-Anbieter unterstützt das Entwickeln eines Anbieters für den OSC zum Synchronisieren und Sichtbarmachen von Aktualisierungen in sozialen Netzwerken in Outlook. Gängige OSC-Anbieter (wie Facebook und LinkedIn) werden standardmäßig mit Outlook installiert. Je nachdem, welche OSC-Anbieter ein Outlook-Benutzer installiert hat, kann der Benutzer im Personenbereich Aktualisierungen wie etwa Fotos, Statusinformationen und Aktivitäten in den betreffenden sozialen Netzwerken sehen.

Erweiterbarkeit der Wetterleiste

Die Wetterleiste erlaubt Entwicklern ab Outlook 2013, für die Wetterleiste den Wetterwebdienst eines Drittanbieters zu integrieren, um für einen vom Benutzer ausgewählten Ort aktuelle Wetterdaten bereitzustellen. Die Wetterleiste in Outlook zeigt aktuelle Wetterdaten und eine Vorhersage für einen geographischen Ort an. Ein Benutzer kann einen oder mehrere Orte auswählen und im Kalendermodul in der Wetterleiste bequem Wetterdaten anzeigen. In Abbildung 7 wird gezeigt, wie die Wetterleiste eine 3-Tage-Wettervorhersage für New York, NY, anzeigt.

Abbildung 7: Wetterleiste in Outlook

Wetterleiste mit Vorhersage für New York.

Outlook verwendet standardmäßig von MSN Wetter bereitgestellte Wetterdaten. Die Wetterleiste unterstützt Wetterdaten-Webdienste von Drittanbietern, die für die Kommunikation mit Outlook einem definierten Protokoll folgen. Solange der Wetterdatendienst eines Drittanbieters dieses Protokoll unterstützt, können Benutzer diesen Wetterdatendienst auswählen, um Wetterdaten in der Wetterleiste anzuzeigen.

Im Abschnitt Weitere Ressourcen: wichtige Referenzen, Ressourcen und Codebeispiele finden Sie weitere Informationen zur Verwendung der Erweiterbarkeit des OSC-Anbieters und der Erweiterbarkeit der Wetterleiste.

Schlussbemerkung

Um herauszufinden, welche API oder Technologie für Ihre Lösung am besten geeignet ist, müssen Sie zuerst die Ziele der Lösung definieren:

  • Die Versionen von Outlook, die Ihre Lösung unterstützen soll

  • Die wichtigsten Szenarien für Ihre Lösung. Interagiert Ihre Lösung in erster Linie mit den Inhalten und Eigenschaften eines Nachrichten- oder Terminelements? Oder automatisiert Ihre Lösung Outlook auf einer Anwendungsebene? Wenn ja, umfassen diese Szenarien das Auflisten, Filtern oder Ändern von Ordnern, die eine große Menge von Outlook-Elementen enthalten?

Prüfen Sie zuerst, ob die Mail-App-Unterstützung in der Office-Add-Ins-Plattform Ihre Anforderungen erfüllt. Ermitteln Sie anhand des Abschnitts "Funktionsbezogene Kriterien" unter Objektive Bewertungskriterien für die Apps für Office-Plattform, ob Ihre Szenarios von den wichtigsten Objekten und Features unterstützt werden. Prüfen Sie anhand des Abschnitts Argumente für die Apps für Office-Plattform, ob Mail-Apps für Ihre Szenarien besser geeignet sind als Add-Ins. Allgemein gilt: Entwickeln Sie Ihre Lösung als App, wenn möglich, um von der Unterstützung der Plattform über Outlook-Clients und verschiedene Formfaktoren hinweg zu profitieren.

Wenn Ihre Szenarien eine über Nachrichten- und Terminelemente hinausgehende Erweiterung erfordern oder Sie Outlook auf der Anwendungsebene automatisieren müssen, prüfen Sie, ob die Szenarien im Abschnitt Argumente für das Objektmodell oder die PIA Ihre Anforderungen abdecken. Wenn das Objektmodell (oder die PIA) Ihrer Outlook-Zielversionen Ihre Szenarien unterstützt und Ihre Lösung keine Ordner mit vielen Elementen bearbeitet, sollten Sie Ihre Lösung - in einer verwalteten oder nicht verwalteten Sprache - als ein Add-In implementieren.

Wenn das Objektmodell (oder die PIA) einer vorgesehenen Outlook-Version einige Ihrer Szenarien nicht unterstützt, klären Sie, ob die Szenarien im Abschnitt Argumente für die MAPI oder Argumente für die Hilfs-APIs Ihre Anforderungen erfüllen. Wenn die MAPI Ihre Anforderungen erfüllt, sollten Sie die Lösung in nicht verwaltetem Code implementieren. Wenn eine Hilfs-API eines Ihrer Szenarien abdeckt, können Sie verwalteten oder nicht verwalteten Code verwenden.

Wenn in Ihrer Lösung die MAPI verwendet wird, müssen Sie sie in nicht verwaltetem Code implementieren, z. B. in C++. Abgesehen davon hängt die Entscheidung, ob zum Erstellen der Lösung verwalteter oder nicht verwalteter Code verwendet werden soll, generell von den verfügbaren Ressourcen und deren Fachwissen ab. Wenn es darum geht, ob die Lösung als Add-In oder als eigenständige Anwendung implementiert werden soll, sollten Sie sich für ein Add-In entscheiden, um das ständige Aufrufen des Outlook Object Model Guard durch den Benutzer zu vermeiden, es sei denn, in Ihrem Szenario müssen Ordner bearbeitet werden, die große Mengen von Elementen enthalten. Im letzteren Fall können Sie durch Implementieren der Lösung als Hintergrundthread die Leistung von Outlook optimieren.

Wenn Ihre Szenarien das Anzeigen von Informationen oder Aktualisierungen in sozialen Netzwerken in Outlook umfasst, sollten Sie die OSC-Anbietererweiterung nutzen, um eine COM-sichtbare DLL zu erstellen. Dies können Sie in einer verwalteten oder in einer nicht verwalteten Sprache tun.

Wenn Sie sich dafür interessieren, für die Wetterleiste einen Wetterdatendienst eines Drittanbieters zu verwenden, können Sie dem von der Wetterleistenerweiterung definierten Protokoll folgen und die entsprechenden Webdienste bereitstellen. Sie können diese Webdienste in einer verwalteten Sprache erstellen.

Nachdem Sie die für Ihre Lösung zu verwendenden APIs oder Technologien ausgewählt haben, können Sie sich im Abschnitt Weitere Ressourcen: wichtige Referenzen, Ressourcen und Codebeispiele über zusätzliche Dokumentation und Beispielcode informieren.

Office-Add-Ins-Plattformübersicht bietet eine gute Einführung in Office-Add-Ins, einschließlich der Architektur und des Entwicklungslebenszyklus.

Schauen Sie unter Outlook-add-ins, um eine detaillierte Übersicht über die Ressourcen zur Entwicklung von e-Mail-apps zu erhalten.

Siehe auch: Objektmodell und PIA

In den folgenden Ressourcen finden Sie weitere Informationen zur Verwendung des Objektmodells und der PIA.

Konten: mehrere Konten im Profil

Adressbuch und Exchange-Benutzer

Anlagen

Anhänge: Auswahl im Inspector

Automatisieren von Outlook

Kategorien

Kontakte: Prüfen der Adresse und des vollständigen Namens

Unterhaltungen

Veranstaltungen

Explorer: Inline-Antwort

Elemente: grundlegende Eigenschaften, Felder und Formulare

Elemente: Anpassen von Eigenschaften

Elemente: Aufzählung, Filterung und Sortierung

Elemente: als Aufgaben kennzeichnen

Siehe hierzu die folgenden aufgabenbezogenen Eigenschaften in einigen Elementobjekten wie etwa dem MailItem-Objekt:

Elemente: Auswahl im Explorer

Sonstiges: Visitenkarten, Regeln und Ansichten

Sicherheit

Freigabe

Lösungen: lösungsspezifische Ordner

Lösungen: Speichern von Daten

Benutzeroberfläche: Anpassen von Formularbereichen

Benutzeroberfläche: Anpassen ab Outlook 2007

Benutzeroberfläche: Anpassen ab Outlook 2010

Benutzeroberfläche: lösungsspezifische Ordner

Siehe auch: Hilfs-APIs

In den folgenden Ressourcen finden Sie weitere Informationen zu den Outlook-Hilfs-APIs.

Kontoverwaltung

Kategorisieren von Elementen

Kontakt-Bilder

Daten-Beeinträchtigung

Frei/Gebucht-Status

Elements-Währung

Verwalten von Kalendern

Siehe auch: Primärverweise, Ressourcen und -Codebeispiele

In den folgenden Ressourcen finden Sie weitere Informationen zu den wichtigsten Outlook-Referenzen, -Ressourcen und -Codebeispielen.

Wichtige Referenzen und Ressourcen

Codebeispiele