Montag, 2. Juli 2012

Central Email Management mit SharePoint - Better Collaboration

Exchange ist eine tolle Groupware und Email noch immer das beliebste Kommunikationsmittel. Mit Internetzugang kann ich "Email", ob mobil oder im Büro - ich weiß wies geht und es geht einfach. Von schnellen und kurzen Mitteilungen bis zu ausgefeilten Konzepten kann alles mit Emails an die selbst zusammengestellte Zielgruppe geschickt werden. Das Ganze ist dezentral und Jeder hat sein eigenes Emailsystem, man muss keinen Partner, Kunden oder Kollegen erst Zugriff auf die interne Infrastruktur geben. Sobald allerdings wichtige Informationen per Email verschickt werden, die besser zentral aufgehoben sind, wird die dezentrale Emaillösung zum Problem. Bei großen Projekten und Aufträgen mit Beteiligung interner Kollegen, Lieferanten, Partnern und Kunden möchte man auch die Informationen aus Emails zentral bereit stellen - und das möglichst zuverlässig, einfach und immer für das aktuelle Projektteam. Informationen in Postfächern genügen diesem Anspruch nicht.
In verschiedenen Kundenprojekten wurde ich mit dieser Anforderung konfrontiert und ein Interesse an einer Lösung ist fast bei jedem SharePoint Anwender vorhanden. Daher möchte ich diesen Artikel nutzen um meine Erfahrungen mit zentraler Emailverwaltung in SharePoint zu teilen.


Die Anforderung


Zuerst eine kleine Analyse der Möglichkeiten, Emails in SharePoint zu verwenden. Die folgende Abbildung zeigt verschiedene, vorstellbare Kommunikationswege, auf denen Emails geschickt werden oder geschickt werden sollen. Der Partner ( Kunde, Lieferant ... ) kommt aus der Wolke, die Infrastruktur des Kunden kennen wir nicht und wollen wir auch nicht kennenlernen - er kann Emails senden, das genügt uns. Seine Emails gehen entweder den orangnen Weg, den blauen Weg oder den grünen Weg.



Der Klassiker des Kommunikationswegs ist hier sicher der orangne Weg. Orange wird die Email direkt vom Partner aus der Wolke an den internen "A" geschickt. Die eingegangene Email liegt genau so lokal bei "A" wie die Antwort von "A" an den Partner. Natürlich kann die Email von "A" weiter gesendet werden, sie gehört aber alleine "A".
Wenn "A" einen SharePoint Server zur Verfügung hat, kann er seine Email dort auch ablegen. Oder der SharePoint hat "eingehende" Emails konfiguriert, so dass eine Dokumentenbibliothek selbst Emails empfangen kann. So kann die Email den blauen Weg gehen. Der blaue Weg hat den Vorteil, dass die Emails im SharePoint zentral liegen und ein Projektteam die Inhalte lesen kann. Das betrifft den Text der Emails und auch deren Anhänge. Der Partner aus der Wolke schickt seine Email dann am besten nicht mehr an einen einzelnen Ansprechpartner sondern an eine "Projektemailadresse", die an der Dokumentenbibliothek hinterlegt ist. Zumutbar ist dieses vorgehen allemal, Email-Verteiler sind ja keine Besonderheit, ob die Email bei einzelnen Personen landet oder auf dem SharePoit kann dem Anwender ja egal sein.
Das Problem mit dem blauen Weg ist allerdings die Antwort. Auch wenn der Eingang im SharePoint zentral abgelegt ist, wir die Antwort über einen lokalen Client - meistens Outlook - verschickt und liegt dann nicht mehr im SharePoint, sondern in den "Gesendeten Objekten" lokal bei "A" oder "B" und wäre somit nicht mehr im Zugriff des Projektteams.. Die Antworten und der Kommunikationsverlauf gehen verloren. Beim grünen Weg ist diese Problemstellung behoben, hier kann SharePoint nämlich selbst Antworten schicken. Eine Email liegt in SharePoint, der Benutzer öffnet die Email, drückt auf "Antworten", schreibt seine Antwort und sendet die Email weg - und die Antwort liegt automatisch im SharePoint. Dieser grüne Weg ist oftmals die Anforderung, jedoch ist er mit den gegeben Funktionalitäten nicht zu erreichen.


Die Lösung


Ein Gruppenpostfach, an dem jeder Projektmitglied berechtigt wird, ist nicht die Lösung der Anforderung. SharePoint bietet für Zusammenarbeit viele Möglichkeiten und Funktionalitäten, die auch auf die Email- Kommunikation angewendet werden sollen. Solche Funktionalitäten sind:
  • Zusätzliche Metadaten wie "Anmerkung", "Erläuterung" oder "Wiedervorlagedatum" an einer Email.
  • Genehmigungs- und Freigabeprozesse für eine Email durch Projektleiter und andere Verantwortliche.
  • Definierte Betreffzeilen durch berechnete Felder.
  • Erweiterte Kommunikationspartnerverwaltung.
  • Versionierung.
  • Berechtigungskonzepte auf Emailbasis.
  • Inhaltsorganisation, um Emails nach bestimmten Regeln einzusortieren.
  • Und vieles mehr...
Damit der Kommunikationsfluss auch im SharePoint verbleibt, dürfen keine lokalen Clients wie zum Beispiel Microsoft Outlook zum Einsatz kommen. Die gängigen Dateiformate für Emails wie "MSG" und "EML" werden daher durch SharePoint Listeneinträge ersetzt. Ein Listeneintrag bietet alles, was eine Email ausmacht und noch mehr Metainformationen. Der Emal Body ist ein Richtext Feld, die Betreffzeile ein berechnetes Feld und der Empfänger ein Naschlagefeld auf die Empfängerliste. Auf einem SharePoint Listeneintrag lassen sich alle SharePoint Funktionalitäten wie Freigabeworkflows oder Versionierung nach belieben konfigurieren. Die Herausforderung an die Entwicklung steckt vor allem vom Parsen einer eingegangenen Email in einen SharePoint Listeneintrag und das Erzeugen einer Email aus einem SharePoint Listeneintrag. Die Emails werden vom Mailsystem im Dropfolder des Webservers abgelegt und warten darauf, von einem TimerJob abgeholt und einsortiert zu werden. Wie die Emails auf den SharePoint Server gelangen ist für das Feature "eingehende Emails" von SharePoint genügend beschrieben.
Es empfiehlt sich der Einsatz einer zusätzlichen Komponente wie Apose email for .net. Wenn der Eingang und Ausgang einer Email aus SharePoint umgesetzt ist, wurde die Grundlage für den grünen Weg geschaffen. Der Erweiterung des grünen Wegs durch individuelle Anforderungen wie regelbasierte Inhaltsorganisation kann nach belieben erweitert werden.

Natürlich liegt auch bei einer Lösung für den grünen Weg der Teufel im Detail - man merkt erst, was Outlook alles leistet, wenn man einen gewissen Teil der Funktionalität im SharePoint abbilden möchte. Falls jemand also Projekterfahrung in diesem Bereich sammeln konnte, freue ich mich genau so über einen Austausch wie mit einem Interessenten, der eine solche Lösung anstrebt!

Goof luck,

Andreas

4 Kommentare:

  1. Prima Artikel. Wir haben bei der E-Mail-Verarbeitung mit SharePoint auch schon vor der einen oder anderen Hürde gestanden, zum Beispiel der Verarbeitung von Inline Images oder Outlook E-Mails im RTF Format. Ein direkter Austausch wäre sicher interessant
    Dirk Löhn

    AntwortenLöschen
  2. @dirk: Hast du auch schon ein ähmliches Tool wie Apose getestet?

    AntwortenLöschen
  3. @Andreas: Wir haben für unser Ticketsystem eigene Email event handler geschrieben, die .eml Email-Dateien auslesen und Betreff, Body sowie (inline) Attachments verarbeiten und in SharePoint-Listen übertragen.
    Interessant ist http://www.limilabs.com/mail , außerdem nutzen wir das http://htmlagilitypack.codeplex.com/

    AntwortenLöschen