Ein Whitepaper der avato consulting ag

Am Beispiel SAP und salesforce.com

Integration Cloud-basierter Anwendungen

update

Seite 2 / 23

update

© 2015 avato consulting ag

Autor:

Joachim Weide

avato consulting ag

Siemensstr. 24-26, 63755 Alzenau/Germany

Telefon: +49 6023 967490

www.avato-consulting.com

Seite 3 / 23

update

Inhalt

1 Management Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Integration: salesforce.com und SAP Landschaft . . . . . . . . . . . . . . . 5 2.1 Definition der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Vorgehensweise und Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 SAP PI zur Einbindung externer Cloud-Lösungen . . . . . . . . . . . . . . . 8 3.1 SAP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 IDoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.2 Business Application Programming Interface (BAPI) . . . . . . . . . . . . . . . . . 11

3.1.3 RFC Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.4 Batch Interface (XBP und Batch Data Communication) . . . . . . . . . . . . . . . . 12

3.1.5 Andere Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Middleware-Produkte und Integrationsmethode . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 Regeln für die Cloud-Integration mit SAP und PI . . . . . . . . . . . . . . . . . . . . . . . . 13

4 salesforce.com SAP Integration . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1 Middleware-Integration salesforce.com und SAP PI . . . . . . . . . . . . . . . . . . . . . . 14

4.1.1 Event Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.2 Protocol Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.3 Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.4 Queuing und Pufferung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.5 Synchrones Transportprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.6 Asynchrones Transportprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.7 Service Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.8 Transaktional (ACID Prinzip) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.9 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.10 ETL: Extraktion, Transformation, Laden der Daten . . . . . . . . . . . . . . . . . . 17

4.1.11 Encryption, Sicherheit, Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Middleware-Bewertung und Beispiel eines Pattern . . . . . . . . . . . . . . . . . . . . . . 18

4.3 Integrations-Pattern Force.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.1 Datenintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3.2 Prozessintegration (BPM in SAP und salesforce.com) . . . . . . . . . . . . . . . . . 20

5 Fazit und nächste Schritte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Seite 4 / 23

update

1 Management Abstract

Zahlreiche Unternehmen entwickeln Strategien Services aus der Cloud zu beziehen und diese in bestehende Geschäftsprozesse und -anwendungen zu integrieren. Unterschiedliche Motivation spielen hierbei eine Rolle: Kostenreduktion, schneller und flexiblere Reaktionsmöglichkeiten auf Marktveränderungen oder vereinzelt auch neue Geschäftsmodelle. Cloud Services mit ihren verschiedenen Angeboten gewinnen immer mehr an Bedeutung in den Unternehmen als alternative Serviceangebote genutzt zu werden und ersetzen sogar be-stehende Anwendungen.

Ziel dieses Whitepapers ist nicht ein Vergleich verschiedener Cloud-Technologien, sondern dem Leser einen Leitfaden zu geben, wie ein Cloud-Integrationsprojekt angegangen werden kann. Zudem soll ein Blick auf den Betrieb einer hybriden Cloud-Landschaft geworfen werden, der zusätzliche Anforderungen aufwirft.

Services auf Basis des Software as a Service-Ansatzes sind dabei besonders kritisch zu bewerten, da hier in die bestehende Applikationslandschaft integriert wird und Themen wie Sicherheit nur eines von vielen Punkten sind, die es zu bewerten gilt. Im Rahmen einer Projektarbeit wurden Methoden entwickelt, Unternehmen bei der Einführung solcher hybriden Cloud-Lösungen zu unterstützen.

Oftmals ist die Integration in bestehende SAP Anwendungen ein erster Schritt. Als Praxisbeispiel dient ein internationales Chemieunternehmen, das Cloud Services beziehen möchte und diese in den SAP Betrieb inte-griert.

Das Unternehmen hat neben den SAP Anwendungen als CRM Lösung salesforce.com gewählt und stellt schrittweise im Rahmen der Harmonisierung der SAP Landschaft alle Lokationen und Business Units auf das neue System um. Im Rahmen des Whitepapers soll dieses Projekt in seinen verschiedenen Phasen vorgestellt werden.

Fragen wie die Cloud-Fähigkeit der Anwendung, Middleware-Integration und Integrationsszenarien werden erörtert. Der Fokus wird hierbei auf die Planung und Vorgehensweise gelegt. Da auch SAP wie zahlreiche an-dere Anbieter immer mehr Services ausschließlich aus der Cloud anbieten wird, eignet sich der hier beschrie-bene Projektansatz als Modell für viele andere Szenarien. Beispiele für die SAP Cloud-Strategie sind Success-factors, Ariba und die HANA Enterprise Cloud.

Unternehmen, die zukünftig solche Services beziehen wollen, stehen vor technische und betriebliche Heraus-forderungen, die in einem reinen On-Premise-Betrieb so nicht existieren. Vor allem Security-Fragen stellen dabei eine große Herausforderung dar. Aber auch die Integration der Kommunikationsinfrastruktur bis zu den Schnittstellen der Anwendungen muss vollkommen neu überdacht werden.

Ein seit Jahren sehr erfolgreiches Modell eines rein Cloud-basierten Service ist salesforce.com. An diesem Beispiel lassen sich alle Aspekte der Integration mit SAP darstellen und vergleichbare Ansätze mit anderen SaaS Angeboten beurteilen.

Seite 5 / 23

update

2 Integration: salesforce.com und SAP Landschaft

2.2 Vorgehensweise und Methode

Der erste Schritt ist eine klare Definition und Abbildung der CRM Prozesse in der Schnittstelle zum SAP ERP sowie der Anforderungen aus Sicht der Geschäftsanwendungen. Hierzu werden die Prozessabläufe analysiert und die beteiligten Komponenten und Daten bewertet. Diese fachlichen Anforderungen und Anwendungen definieren das Integrationsmuster.

salesforce.com spricht im Force.com Guide über Integrations-Pattern, die sehr unterschiedlich ausfallen kön-nen – abhängig davon, wie der CRM Prozess applikationsseitig abgebildet wird.

2.1 Analyse und Dokumentation der existierenden Systemlandschaft

Eine Matrix kann Business Vorteile und technische Vorteile bewerten. Bewertungsfaktoren können sein:

Business Aspekte

• Einfachheit der Umsetzung: Schnelle Realisierung, zeitnahe, messbare Ergebnissen

• Vorgefertigte Anwendungsszenarien (fertige Prozesse, die ohne Programmieraufwand realisiert werden können)

• Anpassungsfähigkeit an zukünftige Anforderungen des Business

• Geringer Schulungsaufwand der Mitarbeiter

• Guter Return of Investment

• Nutzen bestehender Assets

• Produktivität: Robuste Plattform mit hoher Verfügbarkeit

• Standardisierte, industriekonforme Architektur

• Unterstützung von Compliance Anforderungen der Industrie

Technische Sicht

• Unterstützung unterschiedlicher technischer Integrationsmethoden und Technologien

• Nutzung standardisierter Konnektoren zum SAP System

• Vorgefertigte technische Integrations-Templates auf Basis von SAP BAPIs

• Integration in das SAP Business Process Management

• Einfache Abbildung von Endpunkten der Anwendungen, die miteinander in Kommunikation treten

Seite 6 / 23

update

• Verarbeitung von Massendaten, Bulkload und Batch-Verarbeitung

• Robuste Kommunikationswege zwischen dem On-Premise- und dem Cloud-System

• Sicherheit der Datenkommunikation und Support von Standard Security auf allen Ebenen der Kommuni-kation

• Reduktion der Komplexität

• Hohe Verfügbarkeit und definierte Servicelevel

• Metadata Repository

• Session Management zwischen dem Cloud- und dem On-Premise-System

• Einbindung in das fachliche Monitoring aus Sicht der Anwendung, Aktivitäts-Monitoring und technische Monitoring-Funktionen

• Grafische User Interfaces für die Prozessdefinition, Mapping der Endpunkte und der Remote-Prozesse

• Error Handling und Messaging

• Regelbasierte Verarbeitung

All diese Aspekte sind Beispiele für Projektanforderungen, die auch für andere Unternehmen gelten. Diese Anforderungen münden anschließend in die Auswahl geeigneter Middleware. Die Anbieter können sich in der Art der Technologie erheblich unterscheiden und auch bestimmte SAP-typische Software-Komponenten spie-len eine Rolle bei der Auswahl. Eine SAP Landschaft hat bestimmte technische Vorrausetzungen, die es zu beachten gilt. Nicht alle Lösungsanbieter nutzen diese Technologie vollständig, sodass im Betrieb zusätzliche Aufwände entstehen können.

Um die richtige Wahl zu treffen, bewertet man zunächst die Applikationen und ihre Integration in die Ge-schäftsanwendung. Dies dient dazu im Design der Anwendung potentielle Unzulänglichkeiten zu erkennen, damit diese im Cloud-Betrieb nicht zu Ausfällen der Plattform führen.

Zur Auswahl der richtigen Middleware sind zudem eine Analyse der Machbarkeit und eine Transformations-planung für die Migration der Anwendung in den hybriden Cloud-Betrieb erforderlich. Die Anforderungen der Middleware müssen hier beurteilt und gegebenenfalls umgesetzt werden. Im Fall von SaaS werden alle Layer der Anwendung beurteilt und in die Integrationsplanung eingebunden. Je nach Tiefe der CRM Integration in den SAP Stack können unterschiedliche Anforderungen bestehen. Im Falle der hybriden Cloud wird das CRM Teil des Applikationsprozesses, der vollständig in den Ablauf der Applikation eingebettet wird. Damit unter-liegt der Cloud-CRM-Prozess auch den gleichen betrieblichen Anforderungen wie der On-Premise-Teil läuft. Betriebskonzepte sollten auf den neuen Service angepasst und in das Servicemanagement eingebunden wer-den.

Die unterschiedlichen Hersteller liefern teilweise fertige Integrations-Templates, aber nicht alle unterstützen eine vollständige Einbindung in den SAP Geschäftsprozess. An dieser Stelle werden nur Lösungen und Tech-nologien betrachtet, die eine gute Integration in das SAP anbieten.

Seite 7 / 23

update

Im Rahmen der Untersuchung spielt die Prozessintegrationsumgebung der SAP eine wichtige Rolle, da sie seit der Einführung der Netweaver Architektur das Standardwerkzeug bei SAP Integrationen ist.

• PI: SAP eigene Integrationsplattform, die seit der Einführung der Netweaver Architektur die zentrale Middleware für die SAP Plattform darstellt

• PI + XBP 3.0 Batch Interface: Für das CRM spielt die Verarbeitung von Massendaten eine wichtige Rolle. Es muss entschieden werden, ob Daten online (direkt oder durch Massendatenverarbeitung) eingebun-den werden. Ein solches Szenario stellt besondere Anforderungen an die Integrationsplattform.

• Cast Iron: Dieses Produkt nutzt Integrations-Pattern und bietet sogenannte Business Applikation Interfa-ces (BAPIs) der SAP Welt. Es hat eine eigene Message Engine und kann entweder als Cloud-Lösung oder On-Premise betrieben werden. Das Produkt hat eine gewisse Marktdominanz und viele Unternehmen nutzen diese IBM Technologie.

• Informatica: Diese Plattform für CRM Integration hat ihren Ursprung in der ETL Technologie - also Daten-integration von Third Party in SAP Landschaften. Mittlerweile wird sie auch in der Cloud angeboten und bietet diverse Wege der Integration. Neben Cast Iron ist die Informatica Lösung ein gesetzter Standard am Markt. Stärken liegen in ihrer ETL-Fähigkeit und der Vielzahl von unterstützten SAP Interface.

• Magicsoftware: Diese Software bietet vielfältige Interfaces an und unterstützt eine PI Einbindung - je nach Anforderung der Prozesse im CRM. Magicsoftware ist spezialisiert auf die Integration unterschiedlicher Plattformen und Applikationen.

• Seeburger: Dies ist der Klassiker bezüglich SAP PI Einbindung und ETL Verarbeitung.

• Andere Anbieter: Werden hier nicht näher betrachtet.

Wichtig ist die Anforderungen der Anwendung prozessgetrieben zu bewerten und als Bewertungskriterien einzubinden sowie Abhängigkeiten zu dokumentieren und fachliche Anwendungsfälle in die Beurteilung ein-zubringen.

Seite 8 / 23

update

3 Die SAP Prozess Integrationsplattform PI als Middleware zur Einbin-dung externer Cloud-Lösungen

Die Netweaver Technologie als Integrationsplattform erlaubt die Integration über standardisierte Adapter in das SAP. Hier lassen sich verschiedene Adapter und Interfaces nutzen. Wichtig ist die Prozessintegration-Engi-ne PI oder auch die neue Prozessorchestrierung PO der SAP.

Integrationsszenarien kann man mit PI beschreiben. PI bildet externe Anwendungen über Message Queuing ab und bindet die Applikationssteuerung und Ausführung ein. PI / PO ist seit Jahren ein zentraler Baustein in der Entwicklung externer Services, die über Adapter direkt mit SAP kommunizieren können.

Die Komponenten PI/PO aus dem SAP Stack helfen also externe Cloud Services einzubinden. Durch die asyn-chrone und synchrone Verarbeitung von Message Queues ist die Einbindung von salesforce.com gut möglich. Diese Art der Kommunikation wird seitens salesforce.com unterstützt. Jedoch bietet salesforce.com keine Prozessintegration an, die vergleichbar mit SAP PI ist. salesforce.com liefert die technische Adapterentwick-lung mit Force.com sowie eine eigene Entwicklungsumgebung APEX. In wieweit Unternehmen hier auf eigene Entwicklung zurückgreifen sollten, muss individuell entschieden werden, da Integrationen hohe Entwick-lungsanforderungen stellen. Aus diesem Grund enthält SAP PI für Third Party Hersteller die Adapter-Engine. Hierdurch entstehen vorgefertigte Adapter, die die Unternehmen nutzen können. Eigenentwicklungen ber-gen viele Risiken in Betrieb, Maintenance sowie in der Weiterentwicklung. Daher ist es durchaus sinnvoll Third Party Adapter in die Architektur einzubinden.

Inwieweit neben PI andere Integrationsschnittstellen notwendig sind, muss von Fall zu Fall entschieden wer-den. Zudem ist es durchaus sinnvoll typische Anwendungsfälle zwischen ERP und CRM zu definieren, die die Integrations-Patterns im Force.com nutzen. Diese Integrations-Patterns sind anwendungsorientierte, vorge-fertigte Templates und bilden auf unterschiedlichen Techniken die Basis für die CRM Integration. Darüber hi-naus wird betrachtet wie diese anschließend in den Ablauf der Message-Verarbeitung eingebunden werden. Dazu ist es hilfreich die Prozessintegration des PO zu verstehen. Als SAP Netweaver entwickelt wurde, sollten externe Komponenten aus Sicht der Anwendung und des Business Prozesses abgebildet werden können – also alle Transaktionen von beteiligten Anwendungen, die die Geschäftsprozesse unterstützen und deren Ablauf mittels eines Workflows eindeutig beschrieben ist. Zwei Dinge werden hier unterschieden: Auf der einen Seite steht das Business Aktivitäten Management und auf der anderen Seite das technische Monitoring der Anwendungsbausteine und der SAP Interface. Der Zugriff auf interne Monitoring-Objekte ist nur einge-schränkt möglich. Im Beispielprojekt ist die Anwendungslandschaft des Unternehmens stark SAP orientiert – abgesehen vom salesforce.com CRM.

Eine SAP Landschaft enthält eine Vielzahl verbundener Komponenten. Genauer gesagt: SAP PI ist die zentrale Architektur, um Services abzubilden, Messages von Komponente zu Komponente zu senden sowie um exter-ne Systeme über das Adapter Framework in das SAP Business Prozess Management zu integrieren.

Seite 9 / 23

update

Ein zentrales Kriterium ist die Fähigkeit externe Services mit SAP Anwendungen zu verbinden. Das BPM der SAP Netweaver Architektur ist Teil des Solution Managers und bildet den Backbone des SAP Prozessmanage-ments.

Vereinfacht dargestellt besteht PI im Kern aus zwei Komponenten - dem Integrationsserver (Integration Engi-ne) und dem Adapter Framework. Der Integrationsserver verbindet die beteiligten Applikationsprozesse über Message Queues und ordnet die Komponenten der Prozesskommunikation zu. Das Adapter Framework dient dem Anschluss unterschiedlicher Fremdsysteme und Datenformate. Im Beispielprojekt lässt sich salesforce.com CRM mittels PI gut in die SAP Landschaft integrieren. Durch den Einsatz von Business Prozess Manage-ment und des Solution Managers erhält man eine End-to-End Sicht der Prozesse.

Die Abbildung stellt einen groben Aufbau der Plattform dar. Der Integrationsserver mit seiner Run Time-Um-gebung nutzt Message Queues, um Informationen an angeschlossene Anwendungen zu senden. Er stellt die Hauptkomponente des PI dar und enthält die Business Prozess Engine sowie die Adapter Engine. Diese steu-ert abhängige Prozessabläufe, indem sie Jobs synchronisiert und Wartezustände setzt. Auf diese Weise wer-den Informationen zwischen Prozessen korrekt verarbeitet. Dies kann unter Umständen eine sehr komplexe Struktur ergeben. Zudem spiel der Orchestrator PO eine Rolle. Hier werden die Abläufe aus Sicht vordefinier-ter Regeln abgearbeitet. Der PO setzt Prioritäten und synchronisiert parallele/sequentielle Abläufe im Work-flow. Externe Abhängigkeiten sind durch das Interface Monitoring eingebunden, sodass die semantische Inte-grität der Daten erhalten bleibt.

Im Integration Directory findet das Design der Services und ihre Abbildung im SAP statt. Dazu kommt die Ab-bildung/das Mapping der Endpunkte in der Message-Verarbeitung. Das Enterprise Service Repository ist die

Seite 10 / 23

update

zentrale Stelle, wo alle Services gespeichert werden. Die Run Time Workbench hilft beim Testen der Kompo-nenten und Abläufe und liefert außerdem Monitoring-Funktionalität für das SAP Applikationsmanagement im Solution Manager. Einige Unternehmen nutzen noch das ältere Computing Center Management System CCMS mit seinen vielen Transaktionen für die verschiedenen Aufgaben im Applikationsmanagement und Service Reporting.

Eine weitere wichtige Komponente ist die Advanced Adapter Engine, die verantwortlich ist für die Verarbei-tung und das Management der Messages durch Regeln im BPM. Dies funktioniert aber nur auf der JAVA Seite und nicht im ABAP Stack.

Die PI Integrationsseite verbindet also die beteiligten Partner über Message Queues mit allen notwendigen Endpunkten der Kommunikation. Auf diese Weise entsteht ein Kommunikationssystem, das Informationen über Web Services austauscht und Inbound oder Outbound arbeitet. Die Protokolle und Methoden der Pro-zesskommunikation sind XLM Messages, WSDL und SOAP. In der Vergangenheit wurde zudem ccBPM genutzt, das nun zum zentralen Steuerungsorgan wurde und das Abbilden (Mapping) der Endpunkte der Messages und Daten übernimmt. Dazu kommen Aufgaben im Business Prozess Management und in der Verarbeitung von Regeln aus dem Business Rules Management.

Der Solution Manager hat eine eigene Monitoring-Komponente (BPMon), die sich die Verantwortung für das BPM im SAP Stack mit dem PO teilt. Möchte das Unternehmen diese Funktionalität nutzen, dann ist PI ein unverzichtbarer Baustein für das Cloud-CRM-Integrationsszenario mit salesforce.com. Anders als Third Party Hersteller liefert PI leider kaum/keine fertigen Anwendungsszenarien. Somit bleibt es dem Kunden überlas-sen bei der Cloud-Einbindung eigene Entwicklung zu leisten.

Es ist also möglich Applikationsszenarien out-of-the-box nutzen, um Cloud-CRM zu integrieren – aber ist es auch möglich bestimmte Services zu nutzen, um ESR Cross Components zu neuen Anwendungen zu orchest-rieren? Hier bewegen wir uns in Richtung Mashups – ein Angebot eines weiteren Herstellers.

Der Solution Manager kann hier eingebunden sein, wenn das Prozess-Monitoring applikationsseitig über-nommen oder die Jobs asynchron im Batch ausgeführt werden. Massendaten sollten nicht über das MQ Sys-tem laufen. In manchen Fällen entstehen Laufzeitprobleme und das CRM limitiert die Datenmenge/Datensät-ze auf 200 Records pro Aufruf. Das ist für Massendaten nicht sinnvoll. Daher bieten Hersteller alternativ die asynchrone Batch-Integration an. Hier wird das SAP XBP 3.0 Interface der Batch-Verarbeitung genutzt. Dieses Interface gehört zum Solution Monitoring des Solution Managers und ist seit Jahren fester Teil der SAP Verar-beitung. Wichtige Funktionalitäten sind das Triggern von Jobs sowie die Steuerung der Abhängigkeiten von Job-Ketten und Massendaten. Es gibt die Möglichkeit Trigger zusetzen, um PI asynchron mit dem Batch zu steuern sowie zum Öffnen oder Schließen der Queue. Des Weiteren besitzt das Interface die Möglichkeit ex-terne Jobketten einzubinden, um kritische Abhängigkeiten außerhalb der SAP Landschaft zu erkennen. Job-historie ist der Teil des Interface, welches Lasten auf Grund gespeicherter Profile bewertet, die im zentralen Monitor erfasst sind. Die Effizienz des Applikationsmanagements wird demnach erhöht, indem Cloud-Verar-beitung in den Job-Ablauf eingebunden wird.

Seite 11 / 23

update

Es ist demnach möglich den Cloud-Prozess in das SAP Applikationsmanagement zu integrieren und mit der hybriden Cloud ein SAP Service Management Reporting abzubilden. Compliance und Sicherheit müssen be-rücksichtigt werden, können sich jedoch von Industrie zu Industrie unterscheiden.

In der SAP Applikationsinfrastruktur lassen sich im Zusammenspiel mit PI und Solution Manager Trigger set-zen, da beide das zentrale Alert Framework nutzen. Die Anforderungen der salesforce.com Integration-Pat-tern sind damit erfüllbar. Asynchrone und synchrone Verarbeitung ist dank PI/PO kein Problem, jedoch sollte entsprechendes Know-how im Unternehmen sein.

Wie bereits beschrieben, existiert neben PI/PO eine Vielzahl anderer Möglichkeiten der Integration. Das Un-ternehmen muss individuell die Entscheidung treffen, welcher Anbieter in Frage kommt. Als Entscheidungs-hilfe werden im Folgenden die wichtigsten Interfaces und Mechanismen vorgestellt.

3.1 Interfaces

Das verwendete Integrationsverfahren sollte von SAP zertifiziert sein und auch in Zukunft weiterentwickelt werden. Im Kundenprojekt werden PI, IDocs sowie Business Applikation Interfaces „BAPIs“ verwendet.

3.1.1 IDocDer Begriff IDoc steht für Intermediate Document. Dies ist ein typischer Weg, um SAP Applikationen in einem SAP Format zu versenden. Anwendungen, die von außen auf SAP zugreifen oder Daten an SAP Anwendungen senden, nutzen ebenfalls IDocs. Aus Sicht der Datenübertragung und der Datenkommunikation verfolgen XML und IDocs gleiche Ziele.

IDoc ist in der Lage XML Messages zu kapseln und einem ABAP Programm zu übergeben. Es gibt jedoch einen erheblichen Unterschied. XML Daten besitzen Beschreibungen der Inhalte in Form von Metadaten. Der Hea-der der IDocs dagegen enthält Informationen zum Ersteller und Erstellungsdauer. XMP Files besitzen eine Baumstruktur, während IDocs Tabellen nutzen. IDocs beschreiben zudem wie sie verarbeitet werden, wie der Prozess aussieht, und haben die Möglichkeit zu debuggen und zur Automation.

3.1.3 RFC Calls

BAPIs sind im SAP Kontext standardisierte Programmstrukturen, die mit SAP Businessanwendungen kommu-nizieren können. Sie erlauben Kommunikation innerhalb von SAP und mit der Non-SAP Welt. Hierunter fällt auch die Abbildung von Programmlogik und Methoden, die auf den Daten zur Anwendung kommen. Speziel-le Prozessbeschreibungssprachen wie BPEL können dabei im Einsatz sein, um die Prozesse zu beschreiben und zu managen.

3.1.2 Business Application Programming Interface (BAPI)

Remote Function Calls ermöglichen den Zugriff auf Standardtransaktionen. Beispiele sind die typischen Sys-temmonitore, die SAP Daten aus dem CCMS oder Solution Management über RFC Verbindungen replizieren.

Seite 12 / 23

update

3.1.4 Batch Interface (XBP und Batch Data Communication)In vielen Industrieanwendungen der SAP spielt Hintergrundverarbeitung eine große Rolle und wird sicher nicht durch HANA und Cloud verschwinden, sondern auch in Zukunft einen Stellenwert als Interface-Option behalten. Im SAP werden im Batch XBP und BDC genutzt. Beide beschreiben Prozessketten und Abläufe von Jobketten, die entweder ent- oder gekoppelt vom jeweiligen Online-Betrieb arbeiten. Bei einer Cloud-Anbin-dung sollte diese Option in die Beurteilung einfließen, da Begrenzungen bezüglich der Verarbeitung von Mas-sendaten in der Cloud und der verbindenden Middleware bestehen können.

3.1.5 Andere AdapterDaneben existieren folgende Integrationsadapter:

• File Transfer (FTP)

• JDBC (Database Integration)

• JMS (Message Systems wie MQ Series)

• SOAP (Standard bei Web Services)

• Http

• Mail

3.2 Middleware-Produkte und Integrationsmethode

Die Integration in eine bestehende SAP Landschaft schafft Anforderungen, die sich von anderen Integrationen unterscheiden. Das hat damit zu tun, dass SAP eine komplexe Applikationsinfrastruktur nutzt, um SAP aus Sicht der Anwendung und der damit verbundenen Geschäftsprozesse zu betreiben. Eine große Herausforde-rung liegt in der Servicebereitstellung aus der Cloud. Es gilt diese in einen hybriden Cloud-Betrieb einzubin-den. Je nach Tiefe der Prozessintegration können sich Aufwand und Komplexität erhöhen. Eine PI Integration in das SAP Business Prozess Management mit allen Facetten ist keine einfache Aufgabe. Eine sorgfältige Be-wertung und Machbarkeit stehen im Vordergrund bei der Evaluation der verschiedenen Integrationsoptio-nen.

In unseren Kundenbeispielen gehen wir aus Sicht der Anwendung vor, die das Zusammenspiel der unter-schiedlichen Komponenten beeinflussen. Diese Bedingungen und Einsatzszenarien bestimmen die Integrati-onsmuster. Diese Vorgehensweise hilft den Grad und die Tiefe der Integration zu bewerten.

Manche Hersteller nutzen anstelle von SAP PI eigene Prozessintegrationstechnologie, die ebenfalls Message Queues nutzt. Diese übt jedoch keine Kontrolle im SAP System aus. Ein Beispiel für dieses Verfahren ist Cast Iron. Hier gibt es keine Notwendigkeit PI als Message System zu nutzen. Stattdessen integriert man mittels BAPIs. End-to-End Monitoring ist möglich, indem RFC oder andere Verbindungen überwacht werden. Ein Bu-siness Prozess Management wie mit PI ist jedoch nur schwer realisierbar.

Seite 13 / 23

update

Ob BPM notwendig ist, muss der Kunde individuell entscheiden und hängt sehr stark vom Einsatzszenario ab. Eine allgemeingültige Empfehlung gibt es hier nicht.

Andere Hersteller nutzen die klassische IDoc Verarbeitung und sprechen Business Applikationen direkt an. Zudem gibt es Software-Anbieter wie Magicsoftware, die PI und klassische Integrationswege nutzen. Alle haben jedoch gemeinsame Integrationsprinzipien, die im Folgenden dargestellt werden.

3.3 Regeln für die Cloud-Integration mit SAP und PI

Im Zusammenhang mit der Einführung von Cloud-SaaS-Szenarien spielt der Einsatz einer Integrationsplatt-form und Strategie eine entscheidende Rolle. Wie können externe Services in bestehende eingebunden wer-den? Diese Diskussion war bereits im Gange, als die SAP Enterprise Servicearchitektur vorgestellt wurde. Hier hat sich mit dem Einsatz von SaaS mit Cloud im Kern nichts geändert. Es stellt sich nun erneut die Frage: Wie sieht ein Enterprise Servicebus aus, der alle internen und externen Services verbindet? Dies lässt sich redu-zieren - auf die Nutzung einer bestimmten Middleware im Sinne eines Servicebusses, der bestimmte Anfor-derungen erfüllt. Natürlich kommen die Cloud-spezifischen Themen wie Sicherheit dazu. Diese lassen sich aber fachlich lösen. SAP bietet leider eine Vielzahl verschiedener Konnektoren und Integrationen an, z.B. für Ariba, Successfactors, HANA Enterprise Cloud und Third Party mittels PI.

Die folgende Diskussion um die spezifischen Anforderungen der Middleware im Zusammenhang mit sales-force.com ist ein gutes Beispiel, wie man sich dem Thema Cloud-Integration nähern kann.

Seite 14 / 23

update

4 salesforce.com SAP Integration

Der erste Schritt ist die Beschreibung der Abhängigkeiten der beteiligten Systeme – in diesem Fall SAP und salesforce.com. Es sind die Business Szenarien, die hier untersucht werden, um anschließend die richtige Art des Integrations-Pattern zu definieren. Hier findet man im Salesfoce.com Guide gute Hinweise und Beispiele, die man für diese Aufgabe nutzen kann.

Das Ergebnis ist eine Übersicht über die applikationsseitige Verbindung der unterschiedlichen Services in die Steuerungsprozesse der SAP Anwendungen.

Da die unterschiedlichen Anwendungsszenarien die Art der Integration maßgeblich festlegen, wird im Folgen-den das Augenmerk auf die Integrationsplattform gelegt.

4.1 Middleware-Integration salesforce.com und SAP PI

Aus Sicht der Anwendungsintegration ist die Verbindung einer SaaS Cloud „salesforce.com“ (SFDC) nicht we-sentlich anders als eine Non-Cloud Integration. Technisch gesehen sind vergleichbare Themen zu bearbeiten. In den Punkten Governance und Betriebskonzept unterscheiden sich die Ansätze jedoch maßgeblich.

Da SAP und salesforce über eine Integrationsschnittstelle kommunizieren, kann man folgende Regeln als prin-zipielle Vorgehensweise der Cloud-Serviceeinbindung nutzen.

4.1.1 Event HandlingDas Event Handling muss bei Einsatz einer Cloud Events zwischen beiden Systemen erkennen und auf Ereig-nisse reagieren. Das bedeutet im Einzelnen:

• Wohin werden Events weitergeleitet, wer hat die Kontrolle?

• Ausführen und Automatisieren der Aktionen

• Analyse der Logs, Durchführung von Wiederherstellungsaktionen und Senden von Informationen an die beteiligten Systeme

• Prozess Monitoring und SLR

• Erhalten eines Events von einem anderen am Prozess beteiligten Systems

• Provider Management

Im Falle der SFDC Plattform wird dies durch Force.com realisiert. Es wird jedoch eine Middleware benötigt, die mit Force.com alle Event Handling Aufgaben übernimmt.

Seite 15 / 23

update

4.1.2 Protocol ConversionHierunter versteht man die Um- und Übersetzung von Protokoll zu Protokoll zwischen den beteiligten Syste-men, damit das Zusammenspiel der Transaktionen und ihr Kontext aufrechterhalten bleiben. Es kann not-wendig sein bestimmte SAP-typische Business Applikation Interfaces zu integrieren. Bezüglich SFDC gibt es keine Mechanismen, die diese Aufgabe nativ übernehmen. Stattdessen wird XML genutzt.

SAP bietet eine Prozessintegration an, die diese Protokollumsetzung realisiert. Diese Prozessintegration ver-bindet die internen Prozessabläufe auf Basis von Message Queuing (MQ).

Diese MQs stehen On-Premise zur Verfügung und werden mit dem SaaS System gekoppelt. Hier liegt also der wesentliche Unterschied zur Non-Cloud Integration. Fazit: Die Middleware muss in der Lage sein Clouds zu integrieren.

4.1.3 TransformationNeben der Protokollkonvertierung ist die Transformation der Datenformate notwendig, die zwischen den Systemkomponenten ausgetauscht werden. Die Transaktionen, die im Verbund arbeiten, müssen die Bedeu-tung der Daten und Formate kennen, damit das Zusammenspiel reibungslos funktioniert. Man spricht hier von einem Mapping der Datenformate zwischen den Sendern und Empfängern. Hier besteht kein Unterschied - die Aufgabe bleibt die gleiche wie im Non-Cloud-Betrieb.

4.1.4 Queuing und PufferungDas Prinzip der Message-Verarbeitung basiert auf synchroner oder asynchroner Kommunikation. In den meis-ten Fällen ist die Kommunikation asynchron. Der Grund dafür liegt in der Fähigkeit temporären Storage zu nutzen, um die Queue in einem Zustand zu speichern, sobald der empfangende Prozess nicht erreichbar ist. Somit können Prozesse weiter arbeiten und andere Aufgaben übernehmen, bis die Prozesse per Trigger infor-miert werden, dass die Weiterverarbeitung wieder anlaufen kann. Bei salesforce.com sind solche Mechanis-men eingeschränkt vorhanden und im Wesentlichen wird Outbound Message Verarbeitung unterstützt. Kom-plexe Prozesskommunikation zwischen Systemen, wo Management und Prozessorchestration gefordert sind, ist Teil der Middleware.

Die Entscheidung, ob man einen Orchestrator nutzt, hängt von der Art der Applikationsverarbeitung ab und wird über die Beschreibung von Regeln für die beteiligten Komponenten erledigt. Damit ist der BPM der zen-trale Prozess im PI, der diese Abhängigkeiten löst.

Damit steigt aber auch die Komplexität bei der Cloud-Integration. Sicherheit und Zugriff von externen Ser-vices müssen analysiert werden.

Bei einer SAP PI Integration kann die Notwendigkeit bestehen die Cloud-Anwendung salesforce.com in das Prozess Monitoring des internen Message Queuing Systems zu integrieren. Andere Teile der Verarbeitung müssen in das Business Activity Monitoring integriert werden.

Seite 16 / 23

update

4.1.5 Synchrones TransportprotokollBei der synchronen Verarbeitung wartet der eine Prozess auf den anderen – solange, bis der Request verar-beitet wurde oder die Message erhalten wurde. Es ist üblich pro Prozess nur eine einzige Message zu verar-beiten. Das Risiko in der synchronen Prozessverarbeitung ist hoch, dass Blockierungs- und Deadlock-Zustände entstehen. Im schlimmsten Fall bringen sie das System und die damit verbundenen Anwendungen zum Still-stand.

4.1.6 Asynchrones TransportprotokollDas asynchrone Verfahren nutzt einen Thread im Prozess und setzt einen Callback Trigger, damit der verarbei-tende Prozess weiterlaufen kann. Ein weiterer Thread, der die Nachrichten bearbeitet, wartet auf Antworten der asynchronen Threads und verteilt die Antworten an die Prozesse, für die die Nachrichten bestimmt sind. Das Verfahren ist mit Mehraufwand verbunden, da es sich hier um eine komplexe Prozesskommunikation und Synchronisation handelt - und ist damit Teil einer Middleware. Bei externen Clouds muss darauf geachtet werden die Antwortzeiten und Übertragungspakete nicht nur sicher im Kontext der Datenintegrität zu verar-beiten. Auch auf Durchsatz und Antwortzeit von Messages ist zu bewerten und zu organisieren. Üblicherwei-se sind hier Beschränkungen bezüglich des maximalen Datenvolumens pro Message gegeben.

4.1.7 Service OrchestrationService Orchestration bezeichnet die Steuerung und Koordination einer Menge von Endpunkten in einem Message Queuing Framework. Sie ähnelt der Prozess Integration der SAP Infrastruktur, wo ein zentraler Pro-zess Orchestrator diese Aufgabe übernimmt. Bezüglich des Business Prozess Managements der SAP Land-schaft ist es wichtig die beteiligten SAP und Non-SAP Anwendungen aus Sicht der Anwendung zu managen. Diese Funktionalität ist Teil einer Middleware und nicht Teil des Cloud-CRMs von salesforce.com. Abläufe zwischen den beteiligten Komponenten sind Teil des Business Prozesses und müssen gemäß Servicevereinba-rung bereitgestellt und integriert werden.

Service Orchestration ist somit eher Aufgabe des Prozessmanagements und müsste mit der Automation der Betriebsarchitektur verbunden sein. Dies ist Teil des Cloud-Bereitstellungsprozesses gemäß der NIST Anforde-rung.

4.1.8 Transaktional (ACID Prinzip)Der Begriff kann auf das ACID Konzept reduziert werden. Transaktionen laufen autonom, konsistent, isoliert und werden dauerhaft gespeichert. Das gilt auch für den integrierten Cloud-Betrieb. Es werden alle Transak-tionen verschlüsselt und zuverlässig im Transaktionsmanagement eingebunden. Dazu zählt auch ein stabiles Session Handling aus Sicht der User, die mit dem On-Premise- und dem Cloud-System arbeiten. Wird nun salesforce.com in einen komplexen Verbund eingebettet, wo wie in einem SAP Landscape verschiedene Sys-teme vorhanden sind, ist eine Middleware notwendig. Zwar ist salesforce.com transaktional konzipiert, je-doch nicht in der Lage übergreifendes Transaktionsmanagement zu gewährleisten. Das heißt im Fehlerfall: Was muss im Falle des Rollbacks einer Transaktion getan werden, um alle Änderungen in den beteiligten Systemen rückgängig zu machen? salesforce.com ist keine Anwendung, die typischerweise als verteilte An-

Seite 17 / 23

update

4.1.9 RoutingIn einer serviceorientierten Welt, wo XML Messages über Message Queuing verteilt werden, ist das Routing der Teil, wo die Identifikation, der Message Inhalt, die Regel der Verarbeitung und die Priorität mitgeteilt werden. Das Routing geschieht von Komponente zu Komponente in der verteilten Transaktionsarchitektur. Dies ist auch im Umgang mit Cloud-Anwendungen zu beachten und abzubilden. Im Falle von salesforce.com wird das Routing in der Middleware abgebildet.

wendung läuft. Sie kann nur Teil einer solchen sein, muss dann jedoch in das Systemmanagement der verteil-ten Anwendung integriert werden. Dies führt zu zentralem Monitoring und Management einer komplexen Anwendungslandschaft.

4.1.10 ETL: Extraktion, Transformation, Laden der DatenDas ETL Thema ist zentral und kümmert sich um das Laden und Bereitstellen von Daten. Daten müssen für alle gleiche Bedeutung haben und werden über einen gemeinsamen Identifier beschrieben - auch wenn sie in den Originaldaten der Systeme andere Identifikationsschlüssel haben.

In der Prozessorchestrierung nutzt man Mapping-Verfahren, damit die richtigen Inhalte der Messages zu den entsprechenden Prozessen gesendet werden. Dies sollte in der Middleware abgebildet sein, da bei vielen Sourcen und Prozessen die Komplexität der Interfaces und Endpunkte schnell unübersichtlich wird. Es kann passieren, dass sie nicht mehr effizient betrieben werden können.

4.1.11 Encryption, Sicherheit, RollenBei der salesforce.com Integration liefert die Middleware Möglichkeiten die Datenkommunikation zu ver-schlüsseln und durch Einsatz von Rollen und unterschiedlicher Netzwerkportadressen einen Sicherheitsstan-dard zu realisieren. Dieses Thema ist jedoch nicht salesforce.com-spezifisch, sondern gilt für alle Arten der Software-Integration mit unternehmenskritischen Daten. SAP bietet bei der Integration spezielle Ports, über die die Kommunikation der beteiligten Anwendungsprozesse ablaufen kann. Die Sicherheitsanforderungen der SaaS Cloud bestehen aus verschiedenen Aspekten, wie z.B. Datentransfer, Zugangskontrolle und Ver-schlüsselung der Nachrichten und Daten. Die Datenkommunikation der beteiligten Systeme beruht auf Web Service und wird über Message Queues aufgebaut werden. Das bedeutet: Externe wie interne Systeme emp-fangen oder senden Daten / Nachrichten, nutzen definierte Schnittstellen (APIs) und müssen gemäß der Un-ternehmenssicherheitsrichtlinien bewertet und gesteuert werden. Im Fall von salesforce.com werden die Daten gemäß internationaler Standards verschlüsselt übertragen.

Sicherheitskonzepte sind Teil der Analyse, bevor die Entscheidung über den Cloud-Betrieb und seine Integra-tion getroffen wird. Hilfreich sind hier Mechanismen und Best Practices aus der ITIL und Cobit Definition, die Rahmenwerke liefern, um alle Aspekte des Compliance-, Risk- und Sicherheitsmanagement im Unternehmen zu definieren.

In bestimmten Industrien werden interne Cloud-Anwendungen permanent kontrolliert und protokolliert, um alle ablaufenden Transaktionen zu jedem Zeitpunkt auf mögliche Integritätsverletzungen oder Missbrauch zu untersuchen. Das ist in einem hybriden Betrieb umso komplexer, da externe Komponenten in der Servicear-

Seite 18 / 23

update

chitektur integriert sind. Die hybride Cloud mit einer SaaS Lösung wird Teil des internen Betriebskonzeptes. Hierfür muss eine Hosting Referenz Architektur sowie ein Governance Modell definiert werden. Das gilt für alle Disziplinen des Betriebs, also auch für die Bereitstellung und Definition der Services. Wichtige Anforde-rungen stellt das SaaS Modell an die Integration mittels einer Middleware. Diese muss die Verfügbarkeit der Anwendungen sicherstellen.

4.2 Middleware-Bewertung und Beispiel eines Pattern

Um den richtigen Ansatz der Integration zu finden, macht es Sinn die Anwendungsszenarien zu betrachten, um daraus das passende Muster der Prozesskommunikation zu wählen. Eine direkte Integration mit sales-force.com ohne Middleware ist nicht praktikabel aus den verschiedenen erläuterten Gesichtspunkten. Beide Systeme können in einer Verbindung betrieben werden, wo Anwendungen permanent im Austausch mitein-ander stehen - vergleichbar mit einem Online-Transaktionssystem, wo unternehmenskritische Anwendungen Daten austauschen und Antwortzeit, Verfügbarkeit sowie Sicherstellung der semantischen Datenintegrität von Bedeutung sind. Hier ist das CRM keine Ausnahme. Es kommen folgende Fragestellungen und Schwierig-keiten auf:

• Ist es notwendig, dass der Remote Prozess in salesforce.com auf die SAP Antwort wartet? Oder kann er in der Verarbeitung fortfahren und bekommt einen Trigger, sobald die Information vorliegt? Soll die Kom-munikation synchron oder asynchron erfolgen? Bei synchroner Verarbeitung im Remote System kann diese Situation entstehen: Eine folgende Nachricht ist Teil der gleichen Transaktion, auf die salesforce.com warten muss.

• Ein anderes Szenario beschreibt zusammenhängende Verarbeitung in einer Transaktion, wo mehr als eine Nachricht gesendet wird und diese in einem logischen Zusammenhang stehen.

• Innerhalb der Transaktionen oder auch mit weiteren externen Transaktionen bestehen Abhängigkeiten.

• Wie groß sind die Nachrichten? Sind sie relativ klein oder handelt es sich um große Nachrichten, die über das MQ gesendet werden?

• Werden die Nachrichten über Events/Trigger ausgeführt, oder durch ein User Interface?

Beispiel einer synchronen Verarbeitung: Im ERP werden die Kundenaufträge erfasst und ausgeführt sowie Rechnungen und Bestellungen abgearbeitet. Angenommen eine Order wird in salesforce.com erfasst. Da der Prospekt zum Kunden wird, ruft salesforce.com den Prozess im ERP auf. Ziel ist, den Kunden anzulegen, die-sen aus salesforce.com zu entfernen und wie üblich den Orderprozess im ERP auszuführen. Die Synchronisa-tion umfasst mehrere Arbeitsschritte - angefangen vom Aufruf in das Remote System ERP, das Warten auf das erfolgreiche Erstellen der Order bis hin zur Nachricht, dass die Oder erstellt ist. Um nun auch aus Sicht der Daten und Prozesse Integrität sicherzustellen, erfolgt das synchrone Senden der Information, z.B. Ordernum-mer und Orderstatus, an salesforce.com.

Seite 19 / 23

update

Somit wird geprüft, ob die Transaktion erfolgreich und richtig erfolgt ist. Dieses Beispiel kann wie folgt reali-siert werden:

• Im UI salesforce.com wird ein Event ausgelöst, um eine bestimmte Transaktion durchzuführen

• In salesforce.com: SFDC erhält durch den Apex Controller einen Event aus dem Browser (einen sogenann-ten http Post), der die Verarbeitung startet. Der Event wird aus dem UI ausgelöst.

• Ein Web Service wird im Zusammenspiel mit Apex aufgerufen, der sich mit dem Remote System kommu-niziert. Das bedeutet, die Message Queue wird angesprochen und muss „offen“ sein.

• Die Antwort des Remote Systems wird an den Apex Controller gesendet, der seinerseits die Antwort im salesforce.com verarbeitet - also die Veränderungen der Daten durchführt. Die Kontrolle geht zurück an die aufrufende Web Page. Um im Fehlerfall Daten zurückzusetzen, wird ein eindeutiger Identifier erzeugt, der gespeichert wird. Das ist vergleichbar dem Redo Log von Datenbanken.

Dieses einfache Beispiel zeigt: Es laufen im synchronen Betrieb der MQ Verarbeitung einige Schritte ab, die gemäß der ACID Anforderungen erfüllt werden müssen. Bei komplexeren Szenarien wird der Aufwand ent-sprechend höher und muss im Systemdesign zwischen dem SAP PI/PO abgebildet werden. Das heißt: Daten, die über Endpunkte miteinander verbunden sind, werden in einem sogenannten Prozess Mapping logisch miteinander verbunden. Die Orchestration beschreibt den Ablauf der Verarbeitung im Zusammenspiel von Daten und Prozessen. Die Systeme werden dem Prozessmonitor mitgeteilt, indem Funktionsbausteine des Business Monitors eingeschaltet werden (BPMon im Solution Manager).Falls die Nachrichten groß sind oder große Mengen verarbeitet werden, wird asynchron das Batch Interface mit abgebildet, um den Betrieb beider Systeme performant zu halten. Hier spielt der Trigger Mechanismus eine entscheidende Rolle. Dieser steuert mittels des Alert Interface und des Regelwerks Arbeitsabläufe. Hier gibt es nun im SAP Landscape ein neues Interface, welches zentral alle Hintergrundaktivitäten abbildet und im Zusammenspiel der verschiedenen SAP Komponenten die Abläufe der Online- und Hintergrundverarbeitung sicherstellt.

4.3 Integrations-Pattern Force.com

salesforce.com (SFDC) nutzt im Cloud-Betrieb die Plattform Force.com, welche dem Nutzer eine Basis liefert, um unterschiedliche Software-Systeme zu integrieren. SFDC spricht hier von Patterns, wie diese über die Da-ten und Kommunikationsschnittstelle mit dem On-Premise-System arbeitet. Man unterscheidet daten- oder prozessgetriebene Kommunikation. salesforce.com besitzt grundlegende Mechanismen der Verarbeitung, die im Falle der Integration wichtig sind und in der Betrachtung und Beurteilung der unterschiedlichen An-wendungsabläufe zu beachten sind.

Pattern:

1. Remote Process (Invocation – Request and Reply): Im ersten Fall wird von SFDC ein Prozess gestartet, der im remote System zur Ausführung kommt. Der Prozess wartet, bis die Abarbeitung des remote Prozess beendet ist. Zudem überprüft er den Zustand und die Antwort des Prozesses.

Seite 20 / 23

update

2. Remote Process Invocation – Fire and Forget: In diesem Fall wird ein remote Prozess im Fremdsystem gestartet, aber der auslösende Prozess in SFDC wartet nicht auf die Beendigung der Verarbeitung. Statt-dessen quittiert er die Anfrage und gibt die Kontrolle wieder an SFDC, läuft weiter und liefert das Ergebnis zurück, sobald die remote Verarbeitung beendet ist.

3. Batch Data Synchronisierung: Hier werden Massendaten übertragen, die sinnvollerweise nicht über eine Message Queue gesendet werden. Bei Massen-Updates ist dieses Pattern einsetzbar und kann mit der Queue-Verarbeitung synchronisiert werden. Dieses Pattern funktioniert in beide Richtungen - also von SFDC und nach SFDC. Bei SAP ist die Hintergrundverarbeitung eine wichtige Technologie, um Massenda-ten ins SAP System zu bringen und um komplexe Planungsläufe im Warehouse durchzuführen.

4. Remote Call In: Es werden Daten in Force.com erzeugt, geändert oder gelöscht.

5. UI Update: Über ein User Interface werden Daten online verarbeitet automatisch aktualisiert.

Integrations-Patterns können in zwei Kategorien unterteilt werden – die Daten- und die Prozessintegration.

4.3.1 DatenintegrationDieses Pattern beschreibt und unterstützt die Anforderung Daten in zwei Systemen auf gleichem Stand und auf gleicher Datenintegrität zu halten. Das gilt insbesondere für die Aktualität und Richtigkeit der Informatio-nen in beiden Systemen. Es ist die einfachere Art der Integration, indem ein einfacher, sicherer und konsisten-ter Datenaustausch stattfindet. Diese Art der Synchronisation der Datenbestände findet beispielsweise im Master Data Management Anwendung.

Diese Art der Integration hilft mehrere beteiligte Transaktionen zu steuern, die in unterschiedlichen Systemen ablaufen. Im Falle einer solchen Integration spielt die Synchronisation mittels Trigger-Funktionalität über Pro-zess- und Systemgrenzen eine zentrale Rolle. Diese Form der Prozesskommunikation und -kontrolle fordert ein Orchestrationsverfahren, das alle beteiligten Abläufe abstimmt und zentral steuert. Sobald viele Systeme beteiligt sind und es keine zentrale Instanz gibt, wird ein erhöhter Aufwand benötigt, um alle Komponenten zu choreographieren. Man spricht hier von einem Choreograph. In dieser Konfiguration ist es zwingend erfor-derlich alle möglichen Applikationsszenarien abzubilden und Regeln zu hinterlegen, die Ausnahmensituatio-nen beschreiben. Dieses Verfahren kommt immer nur dann in Frage, wenn keine zentrale Kontrolle möglich ist.

Choreographie ist vergleichbar mit Orchestrierung - nur werden bestimmte Abläufe mit verschieden beteilig-ten Systemen automatisiert, indem Trigger und Events korreliert werden. Solche Abläufe mit mehr als einem beteiligten System erfordern ein eindeutiges Applikationsdesign mit klar definiertem Exception Handling. Sol-che Anforderungen entstehen, wenn Systeme unterschiedliche Laufzeiten der Message Verarbeitung haben, oder sie nicht im Batch laufen dürfen und im online-Betrieb zur Ausführung kommen.

Master Slave Ansätze können ebenfalls eine Rolle spielen, um lang laufende Transaktionen mit großen Daten-mengen zu steuern, um die Antwortzeiten der Message Queues nicht zu beeinträchtigen. Hintergrundverar-beitung wird getrennt von Message-Verarbeitung. Hier liefert salesforce.com definierte Integrations-Patterns, die solche Situationen der Verarbeitung in den Griff bekommen.

4.3.2 Prozessintegration (BPM in SAP und salesforce.com)

Seite 21 / 23

update

In diesen Fällen werden Integrationsdesign, Ausnahmebehandlung und Fehlerbehebung komplexer. Im Auto-mat werden sowohl die Fehlersituation als auch deren Auflösung beschrieben. Hier ist die PI Architektur im Vorteil, da sie regelbasiert steuert.

Was kann aber nun helfen den richtigen Integrationsweg zu definieren? Um das mit einfachen Worten zu beschreiben: Der prozessorientierte Ansatz ist genau dann sinnvoll, wenn mehrere Systeme funktional in Verbindung miteinander stehen - sprich eine oder mehrere Anwendungen werden in den Kontext einer exter-nen Anwendung konzeptionell integriert. Im Falle der SAP Landschaft ist dies immer dann der Fall, wenn be-teiligte Transaktionen Informationen austauschen und die Verarbeitung online, synchron, oder asynchron geschieht. Dazu kommen die Fehlerbehandlung beim Rollback der Anwendung und das Zurücksetzen der Transaktionen.

Im Design der Applikationsszenarien und dem Zusammenspiel mit der SaaS Cloud sind solche Überlegungen sowie Automations- und Steuerungsverfahren notwendig, damit die Verfügbarkeit der beteiligten Business Transaktionen gewährleistet bleibt.

Dazu im Gegensatz steht die einfachere Datenintegration, die Informationen für die Anwendungen bereit-stellt - angefangen beim Insert oder Update einer Tabelle, oder einer komplexen Datenmanipulation, die re-ferentielle Integrität der Daten sicherstellen muss.

Hierbei spielt Timing eine entscheidende Rolle, d.h. blockieren oder nicht blockieren von Verarbeitungsschrit-ten. Im Sprachgebrauch redet man von synchroner oder asynchroner Verarbeitung.

Synchrone Verarbeitung in diesem Kontext beschreibt eine nahezu real-time-Verarbeitung. Das bedeutet An-frage- und Antwortoperation stehen in direkter Verbindung und der Prozess wartet auf die Antwort des Re-mote Systems. Dies ist eine Art von Blockade, die nur dann aufgehoben wird, wenn der Prozess sein Ergebnis/seine Antwort erhalten hat.

Im Falle des Kunden ergeben sich nun konkrete Überlegungen und Anforderungen an das Design und den Betrieb der SaaS Anwendung. Dies soll in folgendem Beispiel aufgezeigt werden.

Zweites Beispiel - Asynchrone Verarbeitung: Die Ausgangslage ist eine Anwendung, welche in salesforce.com Leads verfolgt und bearbeitet, Pipeline-Management betreibt und Vertriebsaktivitäten listet. Aus einem Lead wird ein Kunde, der einen Auftrag erstellt und dieser Auftrag wird anschließend im ERP ausgeführt. Der Kunde muss mit den Daten aus salesforce.com angelegt werden, wo er als Lead mit einer Opportunity gelistet ist. Dies stellt eine einfache und sehr realistische Situation dar, wie zwei Systeme miteinander in Verbindung tre-ten, um einen einfachen Business Prozess zu unterstützen.

Technisch läuft hier Folgendes ab: In salesforce wird ein Event erzeugt, der einen Prozess im remote-System startet, also im SAP ERP. Der Event liefert die Information an den remote-Prozess ohne auf die Beendigung des SAP Prozesses zu warten. Das Pattern ist eine Prozesskommunikation, die nach dem Prinzip „Fire and Forget“ funktioniert, und asynchron abläuft. Wäre sie synchron und würde der Prozess auf den remote-Prozess war-

Seite 22 / 23

update

ten, könnte es zu einer Blockade der Message Queue kommen – vorausgesetzt die Transaktion im remo-te-System braucht zu lange, um sie erfolgreich zu beenden. Bei der asynchronen Verarbeitung nutzen dann andere Transaktionen die Queue für ihre Nachrichtenverarbeitung.

Bei asynchroner Verarbeitung sendet der remote-Prozess einen Trigger/Event, sobald die Transaktion erfolg-reich beendet wurde.

In salesforce.com läuft eine sogenannte Workflow-Driven Outbound Messaging-Verarbeitung ab. Dies kann ohne technischen Aufwand in salesforce.com abgebildet werden. Dieses Verfahren ist die Lösung, die optimal für dieses Szenario einsetzbar ist. Der remote-Prozess im SAP ERP nutzt dieses Verfahren für Insert, Update oder Delete Operation. salesforce.com sendet SOAP Messages an die remote-Systemkomponente - in diesem Fall outbound und Workflow gesteuert. Diese Message ist unabhängig vom salesforce.com User Interface. Diese Outbound Message wird zu dem Endpunkt gesendet, wo der SAP Prozess diese Nachricht empfängt und ein „Acknowledgement“ zurücksendet. Im Fehlerfall kann die Transaktion ungültig gemacht werden.

In diesem Szenario läuft folgendes ab:

1. Es wird ein DML (Data Manipulation Language) Befehl erzeugt in Form eines Insert, Update, Delete.

2. Eine Regel in SFDC triggert eine Regel auf der Basis definierter Konditionen, die für diese Verarbeitung gelten (zur Erinnerung: BPM ist in SAP regelgesteuert).

3. Die Regel im Workflow erzeugt eine vordefinierte Outbound Message, die dem Listener-Prozess im remo-te-System eine SOAP Message sendet.

4. Der remote-Listener-Prozess erhält die SOAP Message, legt sie in eine lokale Message Queue, und sendet ein positives Acknowledgement an den salesforce.com Prozess.

5. Die Message Queue in SAP sendet die Nachricht an den internen SAP Prozess zur Verarbeitung (ccBPM/PO) und orchestriert bei vielen dieser Nachrichten mit den Endpunkten der MQs.

6. salesforce.com erhält das positive Acknowledgement und beendet die Verarbeitung, aber wartet nicht bis die remote-Verarbeitung beendet ist.

Seite 23 / 23

update

5 Fazit und nächste Schritte

Ziel des Whitepapers ist, dem Leser einen Leitfaden und Best Practices für eine Integration einer Cloud-ba-sierten CRM-Lösung in eine SAP Landschaft aufzuzeigen. Hierzu wurden die verschiedenen Integrationskon-zepte von SAP Netweaver und Saleforce.com dargestellt. Es wurde projektbezogen eine generelle Vorgehens-weise definiert und anschließend an Hand verschiedener Third Party-Produkte unterschiedliche Ansätze einer Integration in die SAP Anwendungen dargestellt.

Die Erfahrungen aus diesem Projekt lassen sich wie folgt zusammenfassen:

1. Es gibt sehr unterschiedliche Wege in das SAP System zu integrieren.

2. Diese kann man sinnvoll bewerten, indem man im ersten Schritt die Business Anforderungen und Szena-rien beschreibt - daraus leiten sich die Integrations-Patterns ab.

3. SAP liefert eine komplexe Prozessintegrationsplattform, die ein Business Prozess Management bereit-stellt.

4. Es wurden die wesentlichen Anforderungen an eine Integrationsplattform beschrieben, die man nutzen sollte, wenn Prozesse aktiv - also direkt - in die Abläufe eines SAP Landscape integriert werden.

5. Es wurde ein mögliches Pattern zur Integration beschrieben, welches aus Sicht der beteiligten Kompone-neten die Integration mittels Message Queues erklärt.

Impressum

Datum: Februar 2015

Autor: Joachim Weide

Kontakt: marketing@avato-consulting.com

www.avato-consulting.com © 2015 avato consulting ag

Weitere Informationen / Community

Im Intranet haben Sie die Möglichkeit mit unseren Experten zu diskutieren. Zudem haben Sie hier die Gelegenheit wei-tere interessante Themen für kommende Whitepaper und Newsletter vorzuschlagen.