24.02.2015, 14:21 Uhr

Sharepoint und SAP in Minne vereint

Viele Unternehmen stehen vor der Entscheidung, SharePoint als Kollaborationsplattform einzusetzen. Wir beleuchten neben der strategischen Zusammenarbeit von SharePoint und SAP auch mögliche Anwendungsszenarien, um die heterogenen Systeme erfolgreich und zukunftsorientiert zu verbinden.
Die hier gezeigte Handlungsoptionen sollen dabei helfen, strategisch die richtige Entscheidung beim Verbinden der Systeme SharePoint und SAP zu treffen. Um die Praxis nicht aus den Augen zu verlieren, schliesst der Artikel mit einem Beispiel sowie einer ausführlichen Beschreibung der ERPConnect Services von Theobald Software ab. Viele Entscheider stellen sich die Frage, inwiefern SharePoint erfolgreich und zukunftsorientiert mit SAP integriert werden kann. Gibt es Möglichkeiten Daten flexibel, erweiterbar und vereinheitlicht in SharePoint darzustellen? Würde es nicht Sinn machen, Daten aus unterschiedlichen Systemen in SharePoint anzuzeigen und Prozesse im Hintergrund zu starten, ohne dass der Anwender mitbekommt, dass mehrere Systeme abgefragt werden? Somit besteht das Streben vieler Hersteller wie IBM, Microsoft, SAP oder Pirobase nach einer offenen Systemwelt, die mehr Interoperabilität gewährleistet und der veränderten Marktnachfrage gerecht wird. Denn obwohl die Zeit der geschlossenen Systeme längst vorbei ist, werden in vielen Unternehmen noch heterogene Systeme verwendet, welche erst noch mit anderen Systemen integriert werden müssen. SharePoint gewinnt in der jüngsten Vergangenheit immer mehr an Bedeutung. Noch vor wenigen Jahren haben sich viele Verantwortliche in Unternehmen die Frage gestellt, ob SharePoint die richtige Plattform für ihr Unternehmen ist, tatsächlich helfen kann, Kosten und Zeit zu minimieren und damit eventuell andere Systeme ablöst. Dieser Fragestellung haben sich bereits verschiedene Business Cases gewidmet, die die Wirtschaftlichkeit von SharePoint aufzeigen. Die neuen zentralen Fragestellungen der Verantwortlichen sind: Welche Bereiche von SharePoint sollen zuerst eingeführt werden, damit Fachbereiche oder IT-Bereiche optimiert werden? Wie könnte eine sinnvolle und nahtlose Integration mit anderen Systemen aussehen? Wie können Daten systemübergreifend genutzt und angezeigt werden? Hierbei stehen nicht nur die Systeme im Vordergrund sondern auch die Usability, unter anderem wie die Anwender zukünftig mit heterogenen Systemen arbeiten sollen. Macht es überhaupt noch Sinn, dass Anwender an mehreren Systemen arbeiten beziehungsweise sich an mehreren Systemen einloggen müssen? Viele Unternehmen gehen deswegen den Weg ein einheitliches Überportal, zum Beispiel als Intranet Plattform, zu entwickeln. Diese Plattformen zeigen konsolidierte Daten aus mehreren Systemen an oder steuern Prozesse an, ohne dass der Anwender mitbekommt, in welchem System der Prozess läuft. Es ist somit ein anwendungsübergreifender Zugriff auf strukturierte und unstrukturierte Unternehmensdaten möglich. Über Absprünge, integrierte Links, gelangt man über Single Sign-On (SSO), falls umgesetzt und gewünscht, in andere Systeme wie zum Beispiel in ein SAP-Portal. Viele sprechen dabei von Unternehmensprozessen und Unternehmensdaten ohne Systembrüche und ohne Absprünge zu den verschiedensten Plattformen. Hinter dem Begriff Portal verbergen sich einige wichtige Schlüsselpunkte: Sicherer und zentraler Einstiegspunkt für alle Anwender, einheitliche und intuitive User Experience (Look and Feel), rollenbasierter Zugriff auf Geschäftsprozesse und alle relevanten Informationen, Single Sign-On (SSO) sowie weitere Aspekte. Ein Überportal hingegen bündelt verschiedene Portale und stellt diese auf einer Webseite dar - ist sozusagen eine Sammlung verschiedener Portale. Nächste Seite: Herausforderungen bei der Integration mit SAP Herausforderungen bei der Integration mit SAP SharePoint ist in sich kein geschlossenes System und bietet somit grosse Flexibilität bezüglich der nahtlosen Integration mit anderen Systemen. Für Unternehmen relevante Fragen sind dabei, welche Möglichkeiten die Standard Bordmittel von SharePoint bieten, um SharePoint mit SAP zu verbinden. Was sind die Grenzen dieser Integration und muss ein Tool eingekauft werden, das mehr an Funktionalitäten und Möglichkeiten bietet? Es gibt heutzutage zahlreiche Third Party Tools auf dem Markt, welche ein Zusammenspiel zwischen SharePoint und SAP ermöglichen. Es bleibt zu beachten, dass für das Finden der passenden Lösung vorab genau analysiert werden muss, welche Vorrausetzungen überhaupt im Unternehmen gegeben sind und welche Anforderungen an die Integration bestehen. Es ist ebenso wichtig zu erfahren, wie mit den Daten umgegangen werden soll, das heisst, wie soll der Datenaustausch stattfinden und welche Daten sollen überhaupt angezeigt werden? Viele Unternehmen haben SAP im Einsatz und lassen dort komplexe Business Prozesse laufen, die sehr stark im System verzahnt sind. Es stellt sich dabei langfristig die Frage, ob die Verlagerung von Prozessen aus SAP nach SharePoint sinnvoll ist oder ob eher eine prozessübergreifende Lösung gefunden werden sollte. Es bleibt hierbei zu erwähnen, dass komplexe und verzahnte SAP-Prozesse nicht ohne weiteres aus SAP herausgelöst und in SharePoint überführt werden können. Hier stösst auch SharePoint schnell an Grenzen und der Einsatz von Third Party Tools kommt erneut zur Diskussion. Somit bleibt strategisch und aus Kostensicht betrachtet nur ein Weg übrig und zwar die Verknüpfung von SharePoint und SAP. Auch hinsichtlich Datenspeicherung, -management und -bearbeitung sollte gut überlegt werden, wie das neue Szenario zukünftig aufgebaut werden soll. Werfen wir zunächst einen Blick auf Verbindungsmöglichkeiten ohne Third Party Tools, bevor wir auf diese Tools eingehen und an einem Beispiel aufzeigen, wie einfach und schnell eine Verbindung hergestellt werden kann. Nächste Seite: SharePoint mit SAP aus Entwicklersicht verbinden SharePoint mit SAP aus Entwicklersicht verbinden Als Entwickler hat man die Möglichkeit mit Standardmitteln SharePoint mit SAP zu verbinden. Dabei kann auf SAP-Daten zur weiteren Verarbeitung oder einfach nur zum Anzeigen in SharePoint zugegriffen werden. Dies hat zum einen den Vorteil, dass am Anfang keine Lizenzkosten anfallen (bei einer Weiterverarbeitung der SAP-Daten können durchaus SAP-Lizenzkosten anfallen) und zum anderen den Nachteil, dass Entwicklungsaufwand betrieben werden muss, der wiederum Kosten verursacht. Tabelle 1: SharePoint mit SAP aus Entwicklersicht verbinden ! TABELLE ! Doch auch mit diesen Bordmitteln stösst man schnell an die Grenzen und sollte sich vorab durch eine detaillierte Analyse überlegen, ob hier nicht lieber ein Third Party Tool zum Einsatz kommen sollte. Im nächsten Abschnitt werden die aus meiner Sicht Key Player auf dem Markt näher betrachtet und ein praxisorientiertes Beispiel aufgezeigt. Nächste Seite: Aktuelle Key Player auf dem Markt Aktuelle Key Player auf dem Markt Die Anzahl der Third Party Tools auf dem Markt nimmt immer mehr zu. Es gibt verschiedene Tools, die eine nahtlose Integration zwischen SharePoint und SAP ermöglichen. Der Zugriff auf SAP-Daten und SAP-Funktionalitäten lässt sich sehr schnell realisieren, der Aufwand ist vergleichbar mit dem Hinzufügen eines WebParts in einer SharePoint WebSite. Damit erhält man schnell einen Überblick über relevante Daten - egal ob es sich hierbei um einen Einkaufsprozess oder um einen Urlaubsantrag handelt. Neben der Möglichkeit zur schnellen Umsetzung eines Pilotprojektes bieten Third Party Tools weitere Vorteile für die Nutzung im Enterprise Umfeld: Schnelle Bereitstellung der LösungGeringer Schulungsaufwand, da die Mitarbeiter zumeist schon mit der SharePoint Oberfläche vertraut sindMöglichkeit zur Integration seitens Fachbereich, da keine Notwendigkeit zum Schreiben eigener CodesEinfache Synchronisierung der Rollen bzw. BerechtigungenUnterstützung für SSO In der folgenden Tabelle werden vier Tools genauer vorgestellt. Tabelle 2: Third Party Tools zur Integration von SharePoint mit SAP ! TABELLE ! In den nachfolgenden Absätzen werden die ERPConnect Services von Theobald Software genauer unter die Lupe genommen und vorgestellt. Anhand eines praxisorientierten Beispiels lässt sich sehr gut zeigen, wie einfach es ist, SAP-Daten flexibel, erweiterbar und vereinheitlicht in SharePoint darzustellen. Nächste Seite: SharePoint mit SAP über den BCS Connector verbinden SharePoint mit SAP über den BCS Connector verbinden Für die richtige Wahl der Mittel sollte erst eine grundsätzliche Frage beantwortet werden, die oben kurz angesprochen wurde: Muss die Lösung programmiert werden oder soll es sich um eine No Code-Lösung handeln? SharePoint selbst ist mehr als ein Baukasten anzusehen, in dem vor allem Architekten, die eben nicht programmieren können oder sollen einen Business Case modellieren. Dies ist auch ein grosser Vorteil dieser Lösung, wie schon oben angesprochen. Trotzdem ist es möglich durch eigengeschriebenen Code Erweiterungen vorzunehmen und auf SAP-Daten zuzugreifen. Aber lassen Sie uns im ersten Beispiel gleich eine Lösung anschauen, die ohne jegliche Codierung auskommt. Auf SharePoint-Seite kann dazu von den Business Connectivity Services (BCS) Gebrauch gemacht werden. Dabei handelt sich um eine Technologie, die es erlaubt, sogenannte externe Inhaltstypen mit einer Entität in einem externen System zu koppeln. Konkret übersetzt auf den Fall von SAP als externes System könnte diese Entität ein Lieferant, ein Auftrag oder eine Lagerbuchung sein. Der Zugriff auf den externen Inhaltstyp erfolgt durch eine externe SharePoint-Liste. Die Daten liegen aber tatsächlich im SAP und sämtliche Datenänderungen reflektieren sich auch unmittelbar in der jeweiligen Liste. Abbildung 1 zeigt eine entsprechende simple Liste von SAP-Debitoren. Wie man am Kontextmenü sehen kann, ist die Liste auch beschreibbar gestaltet. Änderungen an einzelnen Einträgen werden also ins SAP-System zurückgeschrieben. Ansonsten handelt es sich um eine Standard-Liste, die als Grundlage für darauf aufbauende Applikationen dienen kann, zum Beispiel Formulare oder Workflows. Das Design des externen Inhaltstyps erfolgt durch den BCS Connector - ein Standalone-Tool, das lokal auf dem Desktop des Architekten installiert wird - analog dem SharePoint-Designer. Datengrundlage bildet in diesem Beispiel die Tabelle KNA1 aus SAP, die Kundenstammdaten enthält. Abbildung 2 zeigt den BCS Connector mit dem externen Inhaltstyp zum Designzeitpunkt. Das im Designer entworfene Modell kann eine oder mehrere Entitäten enthalten; jede Entität wiederum mehrere Attribute. Jede Entität führt beim Deployment zu genau einem externen Inhaltstyp, jedes Attribut zu einer Spalte desselben. Obgleich die Datenbeschaffung direkt aus der SAP-Tabelle erfolgt, muss das Rückschreiben natürlich andere Mechanismen nutzen. Auf SAP-Seite ist im Allgemeinen die Anlage und Änderung von Entitäten an ein grosses Gebilde von Business Regeln gekoppelt. Dabei spielt es keine Rolle, ob beispielsweise ein Debitor direkt in der SAP-Oberfläche oder durch externen Zugriff geändert wird. Die Regeln dürfen nicht ausgehebelt oder umgangen werden. Um dies sicherzustellen erfolgt das Rückschreiben mit Hilfe eines Funktionsbausteins. Im BCS Connector werden im unteren Bereich die Operationen definiert, die auf Listeneinträge angewendet werden können. Für das Rückschreiben in eine bestehende Entity heisst die Operation beispielsweise "Update Table Record". Hinter diese Operation wird dann der Verbuchungsbaustein gemappt. Auch für die Datenbeschaffung kann natürlich ein Funktionsbaustein genutzt werden für den Fall, dass sich die gewünschte Entität nicht einfach durch einen Tabellenzugriff herstellen lässt. Externe Listen sind in vielen Situationen ein pragmatischer, einfacher Weg, um SAP-Daten in SharePoint zu bringen. Werden die Anwendungsfälle aber etwas komplexer ist die Grenze des Machbaren sehr schnell erreicht. Insbesondere zusammenhängende Entitäten lassen sich nur schwer darstellen. Ein Beispiel dazu wäre ein Kundenauftrag mit einem Kopfsatz, aber mehreren Positionen. Eine mögliche Lösung dafür bietet der WebService Designer wie in Abbildung 3 dargestellt. Er erlaubt es, komplexe Zusammenspiele zwischen mehreren SAP-Funktionsbausteinen und/oder komplexen Datentypen grafisch zu modellieren. Der Ablauf wird gekapselt und bekommt nach aussen eine Signatur, die einfach zu verstehen und einzubinden ist. Nach dem Designvorgang wird der modellierte Webservice nach SharePoint deployed und steht dort als Endpunkt zur Verfügung, um in weiteren Anwendungen genutzt zu werden.Das Beispiel zeigt die Anlage von BANFen in SAP. Kern ist der Standard-Baustein BAPI_REQUISITION_CREATE. Neben den typischen Werten wie Lieferant, MaterialNr und Menge werden an dieser Stelle auch gleich Kontierungsanweisungen gesetzt. Der Baustein kann beliebig viele Meldungen zurückgeben. Der Prozessablauf ist so gestaltet, dass ein endgültiges Commit an SAP nur dann gesendet wird, wenn keine Fehler oder Warnungen von SAP zurückgegebenen werden. Ansonsten wird die Aktion zurückgerollt und die Fehlermeldung an den Aufrufer des Webservices übermittelt. Nachdem der WebService nach SharePoint deployed wurde, lässt er sich beliebig einbinden. Im vorliegenden Beispiel ist er in einen Nintex-Workflow eingebunden, der zunächst Details zur anzulegenden BANF prüft, vom Vorgesetzten eine Genehmigung abfragt, um dann diesen WebService zu starten. Sollte SAP die Anlage verweigern, weil zum Beispiel das Material im Auslauf begriffen ist und nicht mehr beschafft werden darf, wandert diese Information an den ursprünglichen Initiator des Workflows zurück. Es sei an dieser Stelle nochmal explizit darauf hingewiesen, dass dieser relativ komplexe Prozessablauf komplett ohne eine einzige Zeile Code auskommt. Der WebService Designer erlaubt zwar einen Export des Modells nach Visual Studio, um dort eigenen Code einzubringen, ist aber eigentlich ein Tool für Architekten und eben nicht für Entwickler. Letztes Beispiel in der Sammlung soll nun aber doch auch die Entwicklerseite ansprechen. Klassische Umgebung ist natürlich Visual Studio. Dort lässt sich alles bauen, was unter .NET zu Hause ist. Ein entsprechender Designer unterstützt den Entwickler dabei tatkräftig. Im Zuge von HTML5 und SharePoint-Apps, die möglicherweise heute schon darauf ausgelegt sein sollten, in einer Cloud-Umgebung zu laufen, ist aber der Zugriff von JavaScript aus die spannende Frage auf die es adäquate Antworten zu finden gilt. Selbstverständlich wäre es auch möglich, die oben beschriebenen WebServices von JavaScript zu nutzen, zumal es auch eine einfach zu implementierende OData Variante des Service gibt. Jedoch wollen wir uns im folgenden Beispiel einmal die rein generische Variante anschauen, also direkt in JavaScript einen SAP-Funktionsbaustein aufrufen und das Ergebnis sofort weiterverarbeiten. Der entsprechende Endpunkt in SharePoint _vti_bin/ERPConnectServiceRest.svc/CreateFunction liefert auf Anfrage den JSon-serialisierten Aufruf des Funktionsbausteins SD_RFC_CUSTOMER_GET. Der eigentliche Aufruf des im unten stehenden Bild programmierten Bausteins erfolgt dann gegen den Endpunkt ExecuteFunction und gibt zumindest einen Teil der Rückgabetabelle aus. Zweifellos ist das kein Beispiel aus dem wahren Leben, aber zumindest eines, das den Aufruf von Funktionsbausteinen aus JavaScript heraus eindrucksvoll zeigt. Abschliessend kann festgehalten werden, dass SAP-SharePoint Connectivity keinesfalls immer so komplex sein muss, wie es oft dargestellt wird. Die vorangegangenen Beispiele zeigen dies eindrucksvoll. Allerdings gilt es zu beachten, dass SAP generell immer ein gewisses Grundwissen über Funktionsbausteine und das Zusammenspiel der Prozesse erfordert. Hier hat noch kein Hersteller von Schnittstellensoftware den heiligen Gral gefunden. Gesunde Skepsis gegenüber vollmundigen Werbeversprechen ist mehr als angebracht. Ohne SAP-Wissen geht es nicht und daran wird sich auf absehbare Zeit auch nichts ändern. Nur die technischen Mittel können so gewählt werden, dass zumindest auf der Seite der Infrastruktur der Architekt und Entwickler so gut wie irgend möglich unterstützt wird. Nächste Seite: Fazit Fazit Dieser Artikel hatte zum Ziel aufzuzeigen, vor welchen Herausforderungen und Anforderungen Unternehmen stehen, wenn es um die Verbindung von Welten geht - speziell die Verbindung von SharePoint mit SAP. Es wurde die Sichtweise eines Entwicklers aufgezeigt, der Standard Bordmittel verwenden kann. Des Weiteren wurden verschiedene Third Party Tools besprochen, die aus meiner Sicht momentan die Key Player auf dem Markt sind. Nichtsdestotrotz sollten bevor die Entscheidung für ein Third Party Tool getroffen wird die Anforderungen genau unter die Lupe genommen werden, da es sich um eine langfristige Entscheidung und Investition handelt. Dies könnte auch in einer Art Vorstudie oder in einem Proof of Concept durchgeführt werden. Zum Schluss sollte durch das praxisorientierte Beispiel mit den ERPConnect Services gezeigt werden, wie schnell und einfach es ist, SharePoint mit SAP zu verbinden. Mit dem Einsatz eines Third Party Tools sind zwar Lizenzkosten verbunden, sie bieten jedoch einen klaren Vorteil: die Verbindung von SharePoint und SAP ohne Programmierkenntnisse. Dies ermöglicht jedem Mitarbeiter aus dem Fachbereich mit den entsprechenden Zugriffsrechten die Anzeige von Daten aus dem SAP-System zum Beispiel in einer SharePoint-Liste. Der Wandel geht hier immer weiter in Richtung "Arbeitsplatz der Zukunft". Im Vordergrund standen bisher mobile Endgeräte und Home Office Möglichkeiten durch stationäre Computer. Nun werden eher Möglichkeiten betrachtet, Daten aus verschiedenen Applikationen und Systemen in einem Überportal darzustellen. Der Vorteil liegt dabei klar auf der Hand: Mitarbeiter können an einer Plattform arbeiten und dabei Daten aus unterschiedlichen Systemen bearbeiten - auch Freigaben durchführen, die Suche nutzen, Workflows ansteuern etc. Auch Prozesse aus anderen Systemen können dabei angesprochen werden. Somit können Daten ich Echtzeit aus SharePoint heraus genutzt werden. Der Markt gibt sicherlich noch viel her. Bleiben wir gespannt, welche weiteren Tools uns in nächster Zeit begleiten werden. Wie am Anfang des Artikels angesprochen, gehen viele Unternehmen den Weg, heterogene Landschaften durch homogene zu ersetzen. Wie sieht es dann mit der Interoperabilität und mit der Unterstützung durch Third Party Tools aus? Es bleibt spannend. Zum Autor: Marc Zacherl ist Leiter des Departments Agile Business Solutions bei dem unabhängigen Beratungsunternehmen EXXETAAG. Er verfügt über langjährige Projekterfahrung in diversen Microsoft Projekten rund um die Themen .NET, SharePoint und CRM. Ein weiterer Schwerpunkt ist die technologische Strategieberatung in heterogegen Landschaften sowie Cloud Computing. Er veröffentlicht regelmäßig Artikel in namhaften Magazinen und referiert auf Konferenzen.


Das könnte Sie auch interessieren