Neben all dem Hype rund um Software für Services und all den Innovationen im Bereich der Cloud Services bleibt das Thema der Serviceorientierung und Connectivity innerhalb eines Unternehmens nach wie vor hoch spannend. In diesem Blog Artikel möchte ich auf dieses Thema im Zusammenhang mit dem Microsoft Office SharePoint Server 2007 (MOSS) eingehen.

MOSS ist eine äußerst erfolgreiches Serverprodukt, welches bereits out-of-the-box zahlreiche Informationen für die Informationsspeicherung und Verarbeitung bietet. Bei Gesprächen über dieses Produkt komme ich jedoch relativ schnell zu dem Punkt an dem Interessierte die Fragen stellen wie: „…und wie bekomme ich Geschäftsdaten in die SharePoint Umgebung?“ oder „… und wie binde ich SharePoint an mein SAP System an?“.

Leider lässt sich diese Frage ohne eine detaillierte Kenntnis der vorhandenen IT Infrastruktur nicht so einfach beantworten. Grundsätzlich sind zwei Fragen zu beantworten:

• Welche Systeme und Schnittstellen sind in der IT-Landschaft vorhanden bzw. sollen eingesetzt werden?
• Auf welcher Architekturschicht soll eine Integration erfolgen?

Zunächst muss man sich ein Bild über die bestehenden Systeme und vorhandene Schnittstellen verschaffen. Bei einem vorhandenen SAP System stellt sich die Frage, ob ein SAP-System in „Reinform“ (d.h. ohne weitergehende Integrationstechnologien), SAP Netweaver/XI (oder eine andere Technologie, die SAP-Funktionen als WebServices anbieten kann) oder sogar ein SAP-Portal vorhanden ist.

Beim Microsoft-Technologiestack rund um SharePoint stellt sich die Frage, ob SharePoint alleine, SharePoint mit BizTalk-Adaptoren oder gar ein Gespann aus SharePoint und BizTalk zum Einsatz kommt. Je nach vorhandenen Technologien auf SAP- oder Microsoft-Seite ergeben sich unterschiedliche Anbindungsmöglichkeiten, die in folgender Abbildung skizziert sind.

Abb: Anbindung von Microsoft Office SharePoint Server (MOSS) an Backend-Systeme

Wenngleich diese Abbildung die tatsächlichen Möglichkeiten sehr vereinfacht, werden - so denke ich - die Alternativen deutlich:

Spalte A: SharePoint-SAP Integration

Soll ein ein SAP-System ohne spezielle Integrationskomponenten an SharePoint angebunden werden ergeben sich, je nach vorhandenem Microsoft-Technologiestack folgende Optionen:

• Eigenentwicklung mit Partnerlösungen
  der früher bekannte .NET Connector für SAP wird leider nicht weiterentwickelt. An dessen Stelle sind Partnerlösungen getreten, die eine .NET-Entwicklung von Integrationsfunktionen unterstützen (z.B. ERPConnect.net)
• Eigenentwicklung mit einem BizTalk Adapter für SAP
  Ein solcher Adapter ermöglicht es, aus .NET Programmen, die ihre Kommunikation über Windows Communication Foundation (WCF) regeln, über WCF auf SAP zuzugreifen. Hierüber ist es dann möglich SharePoint-Erweiterungen (WebParts, Features etc.) mit SAP-Zugriffen zu entwickeln.
• Einsatz eines BizTalk Servers
  Sicherlich die mächtigste Variante der Integration eines SAP-Systems. Hierbei können sowohl die Möglichkeiten der BizTalk Adapter (siehe oben) als auch die Möglichkeit des BizTalk-Servers SAP-Funktionen als WebServices anbieten zu können, genutzt werden. Über die Webservices-Variante ist es dann auch möglich, SAP-Daten und -Funktionen über MOSS-Konfiguration zu integrieren. So ist es beispielsweise möglich SAP-Funktionen über den Business Data Catalog oder Excel Services abzugreifen. Eine Positionierung des BizTalk Servers als Integrationspunkt hat darüber hinaus den Vorteil, dass dieser dann seine Stärken bei Integration zusätzlicher Systeme, Business Process Management (BPM), Business Activity Monitoring (BAM) etc. ausspielen kann und eine übergreifende Prozess- und Datensicht bietet.

Eine Integration ist über diese Varianten nur auf unteren Architekturschichten (Integrationsschicht, Anwendungssicht) möglich. 

Spalte B: SharePoint-SAP Netweaver/XI

Mit SAP Netweaver/XI stehen auf SAP-Seite Erweiterungen zur Verfügung, die SAP-Funktionen bereits als Webservices anbieten können. Dies erweitert das Möglichkeitenspektrum dahingehend, dass MOSS auch ohne BizTalk Adapter bzw. BizTalk Server über Webservices mit SAP kommunizieren kann (wenngleich ohne BizTalk die Möglichkeiten eines MOSS-SAP-übegreifenden Business Process Managements (BPM) entfallen).

Auch hier ist die Integration auf untere Architekturschichten fokussiert.

Spalte C: SharePoint-SAP Portal

In dieser Variante ist das Spektrum der Möglichkeiten am größten. Neben den bisher vorliegenden Möglichkeiten kann das SAP Portal webbasierte GUI-Elemente (iViews, Portlets etc.) anbieten. Dies ermöglicht es, auf der Präsentationsschicht Inhalte von SAP in SharePoint zu integrieren. Dies ist beispielsweise über iView-, WSRP- oder PageView-Webparts möglich.

Fazit

Grundsätzlich gibt es eine breite Palette an Möglichkeiten, SharePoint mit SAP- (bzw. allgemein Backend-)Daten und Funktionen zu versorgen. Sowohl auf Microsoft-Stack- als auch auf SAP-Seite muss analysiert werden, welche Technologien vorhanden sind bzw. eingesetzt werden sollen, ob die Integration über Konfiguration (BDC, Excel Services) oder Entwicklung (WCF, BizTalk Technologie, Webservices) und auf welcher Architekturschicht (Frontend-, Anwendungs- oder Integrationsschicht) erfolgen soll.

In meinen beiden letzten Blogs zu Software plus Services und dem dadurch erweiterten Handlungsspielraum für Unternehmen habe ich bereit einiges zu Microsofts S+S Strategie geschrieben. In diesem Blog möchte ich kurz etwas zum Services-Spektrum, welches von Microsoft für Anwender und Entwickler bereitgestellt wird, schreiben.

Drei Kategorien von Services: Finished, Attached, Building Block

Hinsichtlich der angebotenen Services unterscheidet Microsoft drei Kategorien von Services: Finished Services stellen vollständige Anwendungen dar, die Anwendern (von Partnern oder Microsoft gehostet) als Dienste angeboten werden. Die Anwendungslogik wird vollständig vom Dienst bereitgestellt, der Anwender greift auf diesen über einen Thin Client (Webbrowser) zu. Die zweite Kategorie sind Attached Services, keine eigenständigen Anwendungen darstellen, sondern bestehende Client- oder Server-Anwendungen um Zusatzfunktionen erweitern. Building Block Services sind die dritte Servicekategorie. Entwickler können diese Dienste nutzen, um eigene Anwendungen zu erstellen, die dann wiederum entweder lokal betrieben werden und die Services im Internet aufrufen oder selbst bei einem Service Provider betrieben werden. Die folgende Tabelle stellt diese Servicekategorien gegenüber und listet jeweils weitere Details auf:

Tabelle: Kategorien von Microsoft Services für Anwender und Entwickler

Mit diesem Services-Spektrum kann Microsoft die ganze Bandbreite von der Entwicklung eigener Software durch Anwender (bzw. deren Unternehmen) bis hin zum Bezug von Software als Service (Software as a Service, SaaS) abdecken. Auch bei der Eigenentwicklung von Anwendungen oder Anwendungsteilen können Unternehmen (oder ISVs) die Software für den Vor-Ort-Betrieb auslegen, oder auf eine Online Plattform (Platform as a Service, Paas) zurückgreifen, bei der der Betrieb dann von Microsoft-Partnern oder Microsoft selbst erfolgt. Folgende Abbildung bringt die Konzepte "Vor-Ort-Software", "SaaS" und "PaaS" in den Kontext, den ich bereits in meinem Blog zum Handlungsspielraum von Unternehmen beschrieben habe.

Abbildung: Software vs. Software as a Service vs. Platform as a Service von Microsoft

Weitere Informationen

• http://www.microsoft.com/softwareplusservices/