War diese Seite hilfreich?
Ihr Feedback ist uns wichtig. Teilen Sie uns Ihre Meinung mit.
Weiteres Feedback?
1500 verbleibende Zeichen
Auswählen einer API oder Technologie zum Entwickeln von Lösungen für Outlook 2013

Auswählen einer API oder Technologie zum Entwickeln von Lösungen für Outlook 2013

Office 2013

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

Microsoft unterstützt verschiedene APIs und Technologien, mit denen Microsoft Outlook erweitert werden kann:

  • 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 Apps für Office-Plattform, das Objektmodell, die PIA und die MAPI erläutert. Beachten Sie, dass Apps für Office 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 Apps für Office 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?

  • Wonach entscheiden Sie, welche API Sie verwenden sollten, wenn für Ihre Zwecke sowohl das Objektmodell als auch die MAPI geeignet ist?

In den folgenden Abschnitten dieses Artikels werden Auswahlkriterien beschrieben:

In diesem Abschnitt werden Kriterien beschrieben, anhand derer Sie die Apps für Office-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 Apps für Office-Plattform verwenden, um Webdienste und Inhalte in den Kontext von Rich-Office- und Webclients zu erweitern. Eine App für Office 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 Apps für Office 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: YouTube-Mail-App ist für die ausgewählte Nachricht aktiv, die eine URL zu einem Video auf YouTube.com enthält

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 Apps für Office-Plattform.

Funktionale Kriterien

Kriterium

Mail-Apps-Unterstützung in Apps für Office-Plattform

Anwendungsdomäne

Eine Mail-App kann quasi für jedes unterstützte Nachrichten- oder Terminelement im Exchange-Postfach des Benutzers verwendet werden, das der Benutzer ausgewählt hat und das die Aktivierungsbedingungen erfüllt. Von den Berechtigungen einer Mail-App hängt deren Zugriff auf die Eigenschaften und spezifischen Entitäten (wie eine E-Mail-Adresse oder Telefonnummer) ab, die für dieses Element vorhanden sind. So hat z. B. eine Mail-App, welche die Berechtigung Lese-/Schreibzugriff für Postfach anfordert, Lese- und Schreibrechte für alle Eigenschaften eines Elements im Postfach des Benutzers. Darüber hinaus kann sie alle Ordner oder Elemente erstellen und lesen und in diese schreiben, und sie kann ein Element von diesem Postfach aus versenden.

Übergeordnete Objekte

Die JavaScript-API für Office bietet einige Objekte auf oberster Ebene, die von allen Typen von Apps für Office gemeinsam verwendet werden: Office, Context und AysncResult. Die nächste Ebene in der API, die sich auf Mail-Apps bezieht und für diese spezifisch ist, umfasst die Objekte Mailbox, Item und UserProfile, welche den Abruf von Informationen über den Benutzer und das aktuell im Postfach des Benutzers ausgewählte Element unterstützen. Auf der Datenebene unterstützen die Objekte CustomProperties und RoamingSettings persistente Eigenschaften, die von der Mail-App für das ausgewählte Element bzw. 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 und Nachrichtenelemente wie E-Mail-Nachrichten, Besprechungsanfragen, Antworten und Absagen. Außerhalb dieser Ebene in der API befinden sich Eigenschaften auf Elementebene (wie 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 Mail-Apps für Outlook.

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 spätere Version dieser Tools verwenden und so Zeit bei der Entwicklung 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 Mail-Apps 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 Apps für Office 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 Apps für Office finden Sie unter Erstellen von Apps für Office und SharePoint. Eine spezielle Dokumentation für Mail-Apps finden Sie unter Mail-Apps für Outlook.

Lizenzbestimmungen für Entwicklung und Bereitstellung

Unter Lizenzieren von Apps für Office und SharePoint finden Sie Informationen zum App-Lizenzframework für Apps für Office.

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 Apps für Office-Laufzeit bietet die folgenden Vorteile, um zu verhindern, dass eine App die Umgebung des Benutzers beschädigt:

  • Isolation des Prozesses, 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

Bei 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.

Methoden für die Bereitstellung

Sie können Mail-Apps im Office Store oder einem Exchange-Katalog veröffentlichen, wodurch die App Benutzern auf diesem Exchange Server zur Verfügung gestellt wird. Administratoren oder Benutzer haben dann die Wahl, eine Mail-App vom Office Store oder Exchange-Katalog aus über das Exchange Admin Center (EAC) oder durch Ausführung von Windows PowerShell-Remote-Cmdlets zu installieren. Sie können das EAC über die Backstage-Ansicht von Outlook oder Outlook Web App aufrufen. Sie können sich alternativ auch direkt beim EAC für Ihr Postfach anmelden.

Weitere Informationen hierzu finden Sie unter Bereitstellen und Installieren von Mail-Apps zu Testzwecken in Outlook.

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 zur Erweiterung 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 Introduction to Interoperability Between COM and .NET und Architecture of the 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, die das Outlook-Objektmodell oder die Outlook-PIA verwenden, verarbeiten normalerweise benutzerspezifische Nachrichten, passen die Outlook-Benutzeroberfläche an oder erstellen benutzerdefinierte Elementtypen für spezialisierte Lösungen wie CRM-Lösungen (Customer Relationship Management), die in Outlook integriert sind. Das Outlook-Objektmodell oder die Outlook-PIA werden manchmal für die Nachrichtenverarbeitung in einem informellen Workflowprozess verwendet. Dies ist häufig dann der Fall, wenn auf dem Microsoft Exchange Server keine Anwendungsentwicklung erlaubt ist. Anders als bei browserbasierten Clients erlaubt ein Betrieb im Cachemodus die Verwendung von Outlook-Lösungen, wenn der Benutzer offline oder vom Unternehmensnetzwerk getrennt ist.

Ü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 das 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 die 64-Bit-Versionen von Outlook zu erstellen. Wenn Sie eine Lösung in Office-Entwicklungstools in Visual Studio 2010 oder Microsoft Visual Studio-Tools für das Microsoft Office System erstellen, werden durch Angabe der Option Beliebige CPU für die Zielplattform verwaltete Lösungen erstellt, die sowohl für 32-Bit- als auch für 64-Bit-Versionen von Outlook 2010 verwendet werden können.

Verwaltete Implementierung

Dank der Outlook-PIA kann das Outlook-Objektmodell in einer Umgebung mit verwaltetem Code verwendet werden. Diese wird durch ein umfassendes Paket von Klassenbibliotheken und Supporttechnologien unterstützt, mit denen viele der typischen Beschränkungen von VBA- und COM-Add-Ins überwunden werden können. Die PIA ist ein COM-Wrapper, der als Überbrückung zwischen den verwalteten und den COM-Umgebungen fungiert. Weitere Informationen finden Sie Why Use the 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 Kennzahlen eines Add-Ins, um zu ermitteln, ob das Add-In deaktiviert werden sollte:

  • Start

  • Herunterfahren

  • Wechseln zwischen Ordnern

  • Öffnen eines Elements

  • Invoke-Häufigkeit

Administratoren können anhand von Gruppenrichtlinien Benutzereinstellungen überschreiben und steuern, welche Add-Ins auf den Computern der Benutzer 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.

Methoden für die Bereitstellung

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. Weitere Informationen zur MAPI-Unterstützung für verwaltete Komponenten finden Sie im Knowledge Base-Artikel 266353: Supportrichtlinien für die Entwicklung von clientseitigen Messaginglösungen.

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

Entwickler, die auf das Programmieren mit der MAPI spezialisiert sind, sind u. U. schwer zu finden. Das Erlernen der Technologie kann zudem geraume Zeit in Anspruch nehmen. Neben den Microsoft-Communitys gibt es nur relativ wenige hochwertige Websites von Drittanbietern, die hilfreiche Informationen zur Entwicklung von Lösungen mithilfe der MAPI bieten.

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 benötigt Berechtigungen zum Zugriff auf die Daten im Exchange-Speicher. Exchange speichert Benutzer- und Verteilerlisteninformationen in Active Directory. Daher müssen Entwickler, die MAPI-Clientanwendungen erstellen, die auf diese Informationen zugreifen, diese Informationen abrufen und konfigurieren können.

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.

Methoden für die Bereitstellung

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.

Da Apps für Office 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 auf Exchange Server 2013 sowie in früheren Versionen von Outlook und Exchange verwenden. Mail-Apps hingegen können mit Outlook und Exchange ab Outlook 2013 und Exchange Server 2013 verwendet werden. Frühere Versionen werden nicht unterstützt.

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 Apps für Office-Plattform mit anderen Erweiterungstechnologien für Office finden Sie in Der Hintergrund zu Apps für Office und SharePoint.

Grundsätzlich sollten Sie das Objektmodell oder die PIA verwenden, wenn die betreffende Lösung die Outlook-Benutzeroberfläche anpasst oder die Geschäftslogik von Outlook verwendet. In Abbildung 2 werden die wichtigsten Basisszenarien gezeigt, für die Outlook-Lösungen das Objektmodell oder die PIA verwenden.

Hinweis Hinweis

Weitere Informationen zu den Szenarien erhalten Sie, indem Sie auf die betreffenden Kästchen in den folgenden Abbildungen klicken.

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

Anpassen der Outlook-Benutzeroberfläche Verwenden von Outlook-Elementen Anpassen von Elementeigenschaften, Feldern und Formularen

Verarbeiten von Outlook-Ereignissen Automatisieren von Outlook



Wenn Ihre Outlook-Lösung eines der in Abbildung 3 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 Abbildung 3 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).

Abbildung 3: Zusätzliche Szenarien, die vom Objektmodel oder der PIA seit Outlook 2007 unterstützt werden

Anpassen der Outlook-Benutzeroberfläche Anpassen von Formularbereichen Verwenden von PropertyAccessor zum Zugreifen auf Eigenschaften

Aufzählen und Anzeigen von Elementen in einem Ordner Kennzeichnen von Elementen als Aufgaben Freigeben von Kalendern, RSS-Feeds und Ordnern

Verwalten von Anlagen Verwalten von Regeln, Zeitzonen und Ansichten Hinzufügen oder Entfernen einer Kategorie

Detaillierte Informationen für ein Konto abrufen Verwalten von Exchange-Verteilerlisten und -Benutzern Speichern privater Daten für Lösungen



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 in Abbildung 4 gezeigten Szenarien zu unterstützen. Abbildung 4 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).

Abbildung 4: Weitere Szenarien, die vom Objektmodell oder der PIA seit Outlook 2010 unterstützt werden

Anpassen der Outlook 2010-Benutzeroberfläche Verwalten von Elementen in einer Unterhaltung Verwalten der Elementeauswahl in einem Explorer

Verwalten der Anlagenauswahl in einem Inspector Unterstützen mehrerer Exchange-Konten in einem Profil Erstellen einer Kontaktkarte für einen Adresseneintrag

Organisieren lösungsspezifischer Ordner



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 in Abbildung 5 gezeigten Szenarien zu unterstützen.

Abbildung 5: Zusätzliche Szenarien, die vom Objektmodel oder der PIA seit Outlook 2013 unterstützt werden

Anzeigeansicht für alle Kontakte im aktuellen Ordner Inlineantwort im Lesebereich Dialog zum Überprüfen von Adresse oder vollständigem Namen für Kontakt anzeigen

Ermitteln von Leseelementeigenschaften abgeschlossen

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 Outlook 2013 MAPI Reference 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).

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.

Hinweis Hinweis

Die Erläuterungen zur Automatisierung von Outlook in diesem und dem nächsten Abschnitt gehen über den Anwendungsbereich von Apps für Office 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 prozessexterne Lösung nur, wenn es notwendig ist (z. B. wenn Sie eine MAPI-Clientanwendung schreiben, die mithilfe der Datei "Tzmovelib.dll" Outlook-Kalendern für Kunden eine neue Basis zuweist, oder wenn Sie eine große Menge von Elementen 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 wird. 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 Instanz 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 als vertrauenswürdig behandelt, und die gesperrten Eigenschaften und Methoden lösen Sicherheitswarnungen aus. Weitere Informationen zum Outlook Object Model Guard finden Sie unter Sicherheitsverhalten des Outlook-Objektmodells (engl.).

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.

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: Der OSC, der im Personenbereich Daten aus sozialen Netzwerken 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.

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 Apps für Office-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.

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

Konten: primäres Exchange-Konto im Profil

Konten: mehrere Konten im Profil

Adressbuch und Exchange-Benutzer

Anhänge

Anhänge: Auswahl im Inspector

Automatisieren von Outlook

Kategorien

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

Unterhaltungen

Ereignisse

Explorer: Inlineantwort

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

Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2015 Microsoft