Geschäftsprozessintegration mit SAP: Fallstudien zur Steuerung von Wertschöpfungsprozessen entlang der Supply Chain

Geschäftsprozessintegration mit SAP Burkhardt Funk • Jorge Marx Gómez Peter Niemeyer • Frank Teuteberg Geschäftsproz...

Author: Burkhardt Funk | Jorge Marx Gómez | Peter Niemeyer | Frank Teuteberg

112 downloads 1312 Views 8MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Geschäftsprozessintegration mit SAP

Burkhardt Funk • Jorge Marx Gómez Peter Niemeyer • Frank Teuteberg

Geschäftsprozessintegration mit SAP Fallstudien zur Steuerung von Wertschöpfungsprozessen entlang der Supply Chain

1C

Burkhardt Funk Institut für elektronische Geschäftsprozesse Scharnhorststraße 1 21335 Lüneburg Deutschland [email protected]

Peter Niemeyer Institut für elektronische Geschäftsprozesse Scharnhorststraße 1 21335 Lüneburg Deutschland [email protected]

Jorge Marx Gómez Universität Oldenburg Fak. Informatik Abt. Wirtschaftsinformatik Ammerländer Heerstr. 114-118 26129 Oldenburg Deutschland [email protected]

Frank Teuteberg Institut für Informationsmanagement und Unternehmensführung Katharinenstraße 1 49069 Osnabrück Deutschland [email protected]

ISBN 978-3-642-12720-5 e-ISBN 978-3-642-12721-2 DOI 10.1007/978-3-642-12721-2 Springer Heidelberg Dordrecht London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Springer-Verlag Berlin Heidelberg 2010 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandentwurf: WMXDesign GmbH, Heidelberg Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Geleitwort Geschäftsprozessmanagement und -integration sind zentrale Themen in Wissenschaft und Praxis der Wirtschaftsinformatik. Daraus resultiert die Notwendigkeit, Studenten die konzeptionellen Grundlagen zu vermitteln und deren Anwendung anhand konkreter Problemstellungen und Technologien einzuüben. Diesem Ziel verschreibt sich das vorliegende Lehrbuch und füllt so die Lücke zwischen Lehrbüchern, die einerseits die konzeptionellen Grundlagen zum Geschäftsprozessmanagement vermitteln und andererseits ausgewählte Modellierungssprachen und BPM-Technologien im Detail erläutern. Das didaktische Konzept des vorliegenden Buches ermöglicht ein aktives und an praktischen Problemstellungen orientiertes Lernen. Dazu werden in den Kapiteln jeweils Lernziele definiert und abschließend durch Kontrollfragen geprüft. Nach einführenden Kapiteln über die zugrundeliegenden Konzepte (Geschäftsprozess-Management, -Modellierung) und Technologien (SAP Business Workflow, SAP Process Integration) stellt das Buch eine Reihe von Fallstudien vor, die mit der Umweltwirkung von Produkten ein aktuelles Thema adressieren, an dem die Autoren im Rahmen des Kompetenz- und Forschungstransfernetzwerks ERTEMIS (www.ertemis.eu) wissenschaftlich arbeiten. Werden in der ersten Fallstudie noch stark vereinfachende Annahmen getroffen, die Problemstellung sozusagen unter Laborbedingungen untersucht, werden diese Annahmen in den weiteren Fallstudien sukzessive aufgehoben, so dass der Leser schließlich ein Integrationsproblem unter realen Praxisbedingungen bearbeitet. Die Beispielimplementierung der Fallstudien erfolgt auf Basis der SAP Produkte SAP Process Integration und SAP Business Workflow, die vielen deutschen Hochschulen im Rahmen der SAP University Alliance zur Verfügung stehen. Das vorliegende Buch ist von Studierenden der Wirtschaftsinformatik und angrenzender Disziplinen mit Gewinn zu lesen, kann aber auch Praktikern empfohlen werden, die sich in die Implementierung von Integrationsszenarien auf der Basis von SAP-Technologien einarbeiten wollen. Jörg Becker, Münster

Danksagung Ohne die Unterstützung unserer MitarbeiterInnen und Studierenden wäre die Erarbeitung dieses Buches nicht möglich gewesen. Unser besonderer Dank gilt (in alphabetischer Reihenfolge) Frau Anja Grube, Frau Dr. Liane Haak sowie den Herren Michael Heinemann, Benedikt Kleine Stegemann, Mark Lehmann, Jan Schallitz und Benjamin Wagner vom Berg. Herrn Werner Müller vom Springer Verlag danken wir für seine unermüdliche Unterstützung und die zahlreichen Anregungen. Wir wünschen Ihnen – lieber Leser – viel Spaß und zahlreiche neue Erkenntnisse bei der Lektüre und freuen uns auf Rückmeldungen zu Ihren Erfahrungen mit und Anregungen zum vorliegenden Lehrbuch unter der Adresse [email protected]. Die Autoren, im Februar 2010

Inhaltsverzeichnis 1

Einleitung ..................................................................................................... 1 1.1 Zielsetzung und Inhalt ............................................................................. 1 1.2 Didaktisches Konzept .............................................................................. 2 1.3 Voraussetzungen...................................................................................... 5 1.4 Literaturquellen ....................................................................................... 5

2

Geschäftsprozessmanagement und Prozessmodellierung ........................ 7 2.1 Lernziele .................................................................................................. 7 2.2 Einleitung ................................................................................................ 7 2.3 Ziele des Geschäftsprozessmanagements und der Prozessmodellierung . 9 2.4 Hintergrund und Historie der Geschäftsprozessorientierung ................. 10 2.5 Begriffliche Grundlagen ........................................................................ 12 2.6 Phasen des Geschäftsprozessmanagements ........................................... 14 2.6.1 Analysephase ................................................................................. 16 2.6.1.1 Identifikation von Prozessen mit Verbesserungspotenzial .... 18 2.6.1.2 Entwicklung einer Prozessvision ........................................... 19 2.6.2 Detailmodellierung der Ist-Prozesse .............................................. 20 2.6.3 Validierung und (Re-)Engineering ................................................ 21 2.6.4 Implementierung der Soll-Prozesse ............................................... 22 2.6.4.1 Organisatorische Implementierung ........................................ 23 2.6.4.2 IT-Implementierung ............................................................... 24 2.6.5 Verifikation und Abnahme ............................................................ 24 2.6.6 Prozess-Controlling ....................................................................... 24 2.7 Grundsätze der ordnungsgemäßen Prozessmodellierung ...................... 25 2.8 Modellierungssprachen .......................................................................... 28 2.8.1 EPK ............................................................................................... 29 2.8.2 Erweiterte EPK .............................................................................. 31 2.8.3 UML und die objektorientierte Geschäftsprozessmodellierung .... 33 2.8.4 Business Process Modelling Notation ........................................... 36 2.8.5 Business Process Execution Language .......................................... 37 2.9 Geschäftsprozessmodellierung mit WS-BPEL ...................................... 38 2.9.1 Einleitung ...................................................................................... 38 2.9.2 Webservices ................................................................................... 38 2.9.2.1 Dienstabrufe........................................................................... 40 2.9.2.2 Dienstbeschreibung................................................................ 41 2.9.2.3 Dienstverzeichnis................................................................... 43 2.9.3 Basisaktivitäten in WS-BPEL........................................................ 43 2.9.4 Strukturelle Aktivitäten in WS-BPEL ........................................... 44 2.9.5 Fortgeschrittenere Konzepte in WS-BPEL .................................... 44 2.10 Kontrollfragen und weiterführende Aufgaben ................................... 47 2.11 Literatur ............................................................................................. 49

x

Inhaltsverzeichnis

3

Einführung in SAP Business Workflow .................................................. 55 3.1 Lernziele ................................................................................................ 55 3.2 Einleitung .............................................................................................. 55 3.3 Die Aufgabe als zentrales Element im Workflow ................................. 59 3.4 SAP Business Workflow ....................................................................... 60 3.4.1 Anlegen von Workflows................................................................ 63 3.4.2 Workflows zur Laufzeit ................................................................. 66 3.4.2.1 Business Workplace .............................................................. 66 3.4.2.2 Rollen .................................................................................... 68 3.4.3 Workflows und Business Intelligence Integration ......................... 69 3.5 SAP Business Workflows im Internet ................................................... 70 3.5.1 SAP WebFlow ............................................................................... 71 3.5.2 Empfang und Versand von Dokumenten ....................................... 71 3.6 Integration anderer Werkzeuge und Anwendungen .............................. 73 3.6.1 Integration von ARIS .................................................................... 73 3.6.2 Schnittstellen zu Mail-Systemen ................................................... 77 3.6.3 Schnittstellen zu Microsoft Produkten........................................... 79 3.6.4 Microsoft Dynamics CRM ............................................................ 81 3.7 Zusammenfassung und Ausblick ........................................................... 82 3.8 Kontrollfragen und weiterführende Aufgaben....................................... 83 3.9 Literatur ................................................................................................. 84

4

Einführung in SAP Process Integration .................................................. 87 4.1 Lernziele ................................................................................................ 87 4.2 Einleitung .............................................................................................. 87 4.3 Anforderungen an Integrationsplattformen ........................................... 88 4.4 Systemarchitektur SAP PI ..................................................................... 90 4.4.1 System Landscape Directory ......................................................... 90 4.4.2 Integration Server .......................................................................... 91 4.4.3 Integration Directory ..................................................................... 93 4.4.4 Enterprise Services Repository ...................................................... 93 4.4.5 Administration, Configuration und Monitoring............................. 93 4.5 Designobjekte in SAP PI ....................................................................... 94 4.5.1 Service Interfaces .......................................................................... 95 4.5.2 External Definitions und Imported Objects ................................... 96 4.5.3 Operation Mappings ...................................................................... 97 4.5.4 Design von Integrationsprozessen ................................................. 98 4.6 Konfigurationsobjekte in SAP PI ........................................................ 101 4.7 Monitoring ........................................................................................... 103 4.8 Kontrollfragen und weiterführende Aufgaben..................................... 104 4.9 Literatur ............................................................................................... 104

Inhaltsverzeichnis

xi

5

Überblick zu den Fallstudien.................................................................. 105 5.1 Einleitung ............................................................................................ 105 5.2 Fachlicher Hintergrund ........................................................................ 105 5.3 Ablauf und Systeme der Fallstudien .................................................... 108 5.4 Technische Voraussetzungen............................................................... 109 5.5 Literatur ............................................................................................... 110

6

Fallstudie zur service-orientierten Integration ..................................... 113 6.1 Lernziele .............................................................................................. 113 6.2 Einleitung ............................................................................................ 113 6.2.1 Aufgabenstellung ......................................................................... 113 6.2.2 Umsetzung ................................................................................... 114 6.3 Softwareprodukte und -komponenten.................................................. 116 6.4 Design .................................................................................................. 119 6.4.1 Data Types ................................................................................... 120 6.4.2 Message Types ............................................................................ 123 6.4.3 Service Interfaces ........................................................................ 124 6.4.4 Message Mappings ...................................................................... 125 6.4.5 Operation Mapping ...................................................................... 129 6.5 Konfiguration ...................................................................................... 129 6.5.1 Kommunikationskanäle ............................................................... 130 6.5.2 Web Service Description Language ............................................ 132 6.5.3 Konfiguration der Nachrichtenverarbeitung ................................ 135 6.6 Umsetzung in den externen Systemen ................................................. 137 6.6.1 SAP-System des Unternehmens .................................................. 137 6.6.2 Implementierung des Webservice-Clients ................................... 139 6.7 Ablauf und Monitoring ........................................................................ 141 6.8 Kontrollfragen und weiterführende Aufgaben ..................................... 143

7

Fallstudie zur Geschäftsprozessautomatisierung ................................. 145 7.1 Lernziele .............................................................................................. 145 7.2 Einleitung ............................................................................................ 145 7.2.1 Aufgabenstellung ......................................................................... 145 7.2.2 Umsetzung ................................................................................... 146 7.3 Vorbereitungen SAP PI ....................................................................... 148 7.3.1 Software-Komponentenversion ................................................... 149 7.3.2 Namensräume .............................................................................. 150 7.3.3 Verbindungsdaten zum ERP-System ........................................... 150 7.3.4 Release-Übernahme von Designobjekten .................................... 151 7.4 Vorbereitungen SAP ERP .................................................................. 151 7.4.1 Anlegen des Entwicklungspakets ................................................ 152 7.4.2 Datenstrukturen ........................................................................... 153 7.4.3 Funktionsbaustein ........................................................................ 154

xii

Inhaltsverzeichnis

7.5 Design.................................................................................................. 156 7.5.1 Import der externen Interfaces ..................................................... 157 7.5.2 Abstrakte Service Interfaces ........................................................ 158 7.5.3 Operation Mappings .................................................................... 164 7.5.4 Integrationsprozess ...................................................................... 169 7.5.5 Darstellung des Integrationsprozesses als BPEL-Prozess ........... 178 7.6 Konfiguration ...................................................................................... 182 7.6.1 Konfigurationsszenario................................................................ 183 7.6.2 Integrationsprozess ...................................................................... 183 7.6.3 Business-System Hersteller-ERP ................................................ 183 7.6.4 Business-Komponente Kundensystem ........................................ 185 7.6.5 Business-Komponente Lieferantensystem................................... 186 7.6.6 Business-Komponente EMIS ...................................................... 187 7.6.7 Nachrichtenstrecken .................................................................... 187 7.6.8 Ablauf .......................................................................................... 190 7.6.9 Monitoring ................................................................................... 192 7.7 Kontrollfragen und weiterführende Aufgaben..................................... 193 8

Fallstudie zur Benutzerinteraktion........................................................ 195 8.1 Lernziele .............................................................................................. 195 8.2 Einleitung ............................................................................................ 195 8.2.1 Aufgabenstellung......................................................................... 195 8.2.2 Umsetzung ................................................................................... 196 8.3 Vorbereitungen SAP PI ....................................................................... 198 8.3.1 Softwarekomponentenversion ..................................................... 198 8.3.2 Namensräume .............................................................................. 199 8.3.3 Release-Übernahme von Designobjekten .................................... 199 8.3.4 Import des Datentyps Mail .......................................................... 200 8.4 Vorbereitungen im SAP ERP .............................................................. 200 8.4.1 Datenstrukturen ........................................................................... 200 8.4.2 Anlegen des Businessobjektes ..................................................... 202 8.4.3 Funktionsbausteine ...................................................................... 205 8.4.4 Workflow-Implementierung ........................................................ 210 8.5 Design.................................................................................................. 218 8.5.1 Import der externen Interfaces ..................................................... 218 8.5.2 Abstrakte Service Interfaces ........................................................ 219 8.5.3 Operation Mappings .................................................................... 220 8.5.4 Integrationsprozess ...................................................................... 225 8.6 Konfiguration ...................................................................................... 237 8.6.1 Konfigurationsszenario................................................................ 237 8.6.2 Integrationsprozesse .................................................................... 237 8.6.3 Business-System des Unternehmens ........................................... 238 8.6.4 Business-Komponente Kundensystem ........................................ 239 8.6.5 Business-Komponente Lieferantensystem................................... 240

Inhaltsverzeichnis

xiii

8.6.6 Business-Komponente EMIS....................................................... 240 8.6.7 Kommunikationskanal Mail ........................................................ 241 8.6.8 Nachrichtenstrecken .................................................................... 241 8.6.9 Ablauf .......................................................................................... 246 8.7 Kontrollfragen und weiterführende Aufgaben ..................................... 248 9

Ausblick .................................................................................................... 249 9.1 Anregungen zur Erweiterung der Fallstudien ...................................... 249 9.2 Perspektiven der Geschäftsprozessintegration und -automatisierung .. 251 9.2.1 Aktuelle Probleme ....................................................................... 251 9.2.2 Lösungsmöglichkeiten ................................................................. 253 9.3 Umweltwirkung in betrieblichen Informationssystemen ..................... 255 9.3.1 Carbon Footprint.......................................................................... 255 9.3.2 Stand der EMIS- und ERP-Integration ........................................ 256 9.4 Literatur ............................................................................................... 257

Stichwortverzeichnis ......................................................................................... 261

Abkürzungsverzeichnis AAE ABAP API ARIS AVE BAPI BOR BPEL BPM BPMN BPR CRM EAI eEPK EMIS EPK ERP ESB ESR FTP GP GPM GPMO HTTP IE IP IS JDBC JMS LCA LOB MAPI OWL

Advanced Adapter Engine Advanced Business Application Programming Application Programming Interface Architektur integrierter Informationssysteme ARIS Value Engineering Business Application Programming Interface Business Object Repository Business Process Execution Language Business Process Management Business Process Modeling Notation Business Process Reengineering Customer Relationsship Management Enterprise Applikation Integration Erweiterte Ereignisgesteuerte Prozessketten Environmental Management Information System Ereignisgesteuerte Prozessketten Enterprise Resource Planning Enterprise Services Builder Enterprise Services Repository File Transfer Protocol Geschäftsprozess Geschäftsprozessmanagement Geschäftsprozessmodellierung Hypertext Transfer Protocol Integration Engine Integrationsplattform Integration Server Java Database Connectivity Java Message Service Life Cycle Assessment Line of Business Message Application Programming Interface Web Ontology Language

xvi

Inhaltsverzeichnis

PAS RDF RFC RTW SAP PI SLD SOA SOAP SQL UDDI UML URL W3C WAPI WAR WFMC WSDL WSMO WTP XML XSD XSLT

Publicly Available Specification Resource Description Framework Remote Function Call Runtime Workbench SAP Process Integration System Landscape Directory Service Oriented Architecture Simple Object Access Protocol Structured Query Language Universal Description, Discovery and Integration Unified Modeling Language Uniform Resource Locator World Wide Web Consortium Workflow Programming Interface Web Application Archive Workflow Management Coalition Web Service Description Language Web Service Modeling Ontology Eclipse Web Tool Platform Extensible Markup Language XML Schema Definition Extensible Stylesheet Language Transformation

1 Einleitung 1.1 Zielsetzung und Inhalt Mit dem vorliegenden Lehrbuch zur Geschäftsprozessintegration auf Basis von SAP Process Integration (SAP PI) verfolgen wir das Ziel, ein solides Fundament zu den Grundlagen und Facetten der Geschäftsprozessautomatisierung und -integration zu liefern und zum anderen einen praktischen Einblick in SAP-Integrationslösungen in Form von drei aufeinander aufbauenden Fallstudien zu geben. Der Fokus der Fallstudien liegt dabei auf der Geschäftsprozessintegration entlang einer Supply Chain mit dem Anwendungsbeispiel "Carbon Footprint", d.h. der Ermittlung der C02-Emissionen, die einem einzelnen Produkt in seinem Lebenszyklus zugerechnet werden können. Besonderes Augenmerk wird hierbei darauf gelegt, mit weitgehend realistischen betriebswirtschaftlichen Prozessen und Technologien zu arbeiten. Die praktische Arbeit mit den eingesetzten Technologien (SAP Business Workflow sowie insbesondere dem Integrationsserver SAP PI) sind dabei zentrale Bestandteile der Fallstudien. Die drei aufeinander aufbauenden Fallstudien behandeln die automatisierte Erfassung und Verarbeitung von Treibhausgas-Emissionen sowie den Datenaustausch der zur Erfassung benötigten verschiedenen externen Services. Ziel ist die Umsetzung eines vollständigen Geschäftsprozess-Lebenszyklus von der Zieldefinition über die Modellierung bis hin zur Implementierung und Ausführung mit SAP-Integrationslösungen. Somit beinhaltet das gewählte Anwendungsszenario gleichermaßen grundlegende Modellierungskonzepte wie auch moderne Integrationstechnologien. Hierbei werden sowohl verschiedene Mapping-Funktionalitäten, Ansätze zur Geschäftsprozessautomatisierung bzw. -integration als auch verschiedene Adaptoren der SAP PI betrachtet. Das Lehrbuch richtet sich primär an Lehrende und Studierende in den (bisherigen) Diplom- und neuen Masterstudiengängen der Fachrichtungen Wirtschaftsinformatik, Informatik sowie Wirtschaftswissenschaften. Aber auch Praktiker können sich mit dem vorliegenden Buch einen soliden Einblick in die Geschäftsprozessintegration am Beispiel von SAP-Technologien verschaffen. Die Fallstudien des Lehrbuches bieten Studierenden die Möglichkeit, sich eingehend und praxisnah mit wesentlichen Methoden der Prozessmodellierung auseinanderzusetzen und Wissen aus anderen Veranstaltungen im Studium der Wirtschaftsinformatik anzuwenden und zu vertiefen. Darüber hinaus werden wichtige Konzepte der Integration betrieblicher Informationssysteme vermittelt und anhand der SAP PI deren Umsetzung mit Hilfe einer modernen Integrationsplattform demonstriert. Das Buch ist wie folgt aufgebaut: Beginnend mit einer Einführung in das Geschäftsprozessmanagement im zweiten Kapitel, wird in Kapitel 3 ein Überblick

2

Einleitung

über das Konzept der Workflows am Beispiel von SAP-Technologien gegeben. Kapitel 4 führt in das Werkzeug SAP PI ein. In Kapitel 5 werden der fachliche Hintergrund des Anwendungsszenarios der drei Fallstudien und der diesbezügliche Stand von Wissenschaft und Praxis dargestellt. Dann folgt die Beschreibung der beteiligten Akteure (Systeme) und ihrer Rollen im Ablauf des Szenarios. Ziel der ersten Fallstudie in Kapitel 6 ist es, den Leser mit den für die Automatisierung und Integration von Geschäftsprozessen erforderlichen Ansätzen vertraut zu machen und die Umsetzung am Beispiel von SAP PI zu demonstrieren. Die zweite Fallstudie in Kapitel 7 nutzt die entstandenen Schnittstellen und bettet diese in einen Geschäftsprozess ein, der auf der Process Engine der SAP PI implementiert wird. Die Aufgabe dieses Prozesses besteht im Zusammenführen der in unterschiedlichen Systemen vorhandenen Informationen zur Umweltwirkung des angefragten Produktes. Gegenstand der dritten Fallstudie in Kapitel 8 ist die Integration von Anwenderentscheidungen in Geschäftsprozessen im Rahmen von Workflows. Zu diesem Zweck werden SAP Workflows verwendet und gezeigt, wie eine Integration mit SAP PI möglich ist. Kapitel 9 gibt schließlich einen Ausblick auf die Möglichkeiten einer Erweiterung der Fallstudien, auf aktuelle Probleme der semantischen Geschäftsprozessmodellierung und -integration sowie auf zukünftige Arbeiten und Ansätze zur durchgängigen Betrachtung der CO2-Emission eines Produktes und der Prozessintegration entlang einer Wertschöpfungskette. Sämtliche für das Verständnis der behandelten Fallstudien notwendigen Vorkenntnisse werden in den Kapiteln 2 bis 5 vermittelt. Dem Leser wird empfohlen, die einzelnen Kapitel nacheinander durchzuarbeiten. Leser, die bereits über umfangreiche Kenntnisse im Bereich des Geschäftsprozessmanagements und des Workflow Managements verfügen, können auch direkt mit dem Einstieg in Kapitel 4 beginnen. Die Fallstudien bauen so aufeinander auf, dass eine sukzessive Bearbeitung erforderlich ist.

1.2 Didaktisches Konzept Durch kapitelbezogene Lernziele, Kontrollfragen im jeweiligen Kapitel sowie rekapitulierende Fragen, in den Satzspiegel integrierte komplementäre Praxisfallstudien und Einblicke in die Praxis, Zusammenfassungen der wesentlichen Inhalte eines Kapitels, die Angabe von Online-Ressourcen sowie ein leserfreundliches Layout und Hervorhebungen soll das Buch zur intensiven Eigenarbeit anleiten. Die in die jeweiligen Kapitel integrierten (Praxis-)Fallstudien und Kontrollfragen unterstützen den Selbstlerneffekt. Wir hoffen, dass durch dieses didaktische Konzept und die Praxisnähe der „Lernspaß“ erhöht wird.

Didaktisches Konzept

3

Musterlösungen zu ausgewählten Kontrollfragen, ergänzendes Begleitmaterial sowie sämtliche Abbildungen und ausgewählte Präsentationsfolien im Powerpoint-Format, Multiple-Choice-Fragen sowie weiterführende Internet-Links werden im Online-Service zu diesem Lehrbuch unter http://www.sap-bpi.de zur Verfügung gestellt. Dieser Online-Service stellt sowohl für Lehrende als auch für Studierende gleichermaßen hilfreiche Materialien zur Verfügung. Die Kapitel des Buches sind weitestgehend in sich geschlossene Lerneinheiten, die jeweils Gegenstand einer Vorlesungseinheit von 2 bis 4 akademischen Stunden sein können. Eine flexible Einbindung des gesamten Lehrbuches oder ausgewählter Kapitel in bestehende Syllabi ist somit an vielen Stellen möglich. Das Buch kann in Schulungen sowie in Lehrveranstaltungen im Bereich des Geschäftsprozessmanagements sowie der Prozess- und Anwendungsintegration (Enterprise Application Integration) zum Einsatz kommen, in denen die Teilnehmer Schritt für Schritt die Fallstudien am Rechner ausführen. In den Kapiteln 2 bis 4 bestehen die primären Lernziele im Verstehen komplexer Prozesse sowie im Verstehen von Abstraktionsmethoden und Modellierungstechniken. Die Lernziele bewegen sich gemäß der Taxonomie kognitiver Lernziele von Benjamin Bloom (Bloom 1956) in erster Linie auf den Komplexitätsgraden Wissen und Verstehen. Die Taxonomie von Bloom umfasst insgesamt die Komplexitätsgrade Wissen, Verstehen, Anwenden, Analyse, Synthese und Evaluation. Lernziele des zweiten Teils des Lehrbuchs (der Fallstudien) sind hingegen die Erkenntnis der allgemeinen Probleme einer Prozessintegration sowie die Anwendung unterschiedlicher Integrationsmethoden. Die Lernziele bewegen sich hierbei somit in erster Linie auf den Komplexitätsgraden Anwenden und Analyse. Der Charakter der in diesem Lehrbuch zum Einsatz kommenden Fallstudien ist in Abb. 1.1 in Form eines morphologischen Kastens zusammengefasst. Merkmal

Ausprägung 1

Ausprägung 2

Ausprägung 3

Ausprägung 4

Ausprägung 5

Typ

Einzelfallstudie kritisch 6 einzigartig enthüllend

Mehrfachfallstudie

holistische Fallstudie

eingebettete Fallstudie

-

Theoriebeziehung

Theorieentwicklung als Teil der Fallstudie

vorhandene Theorie als Basis der Fallstudie

Generalisierung von Fallstudie auf Theorie

-

-

Lernziel

Verstehen

Anwenden

Analysieren

Synthetisieren

Evaluieren

Inhalt

Falldarstellung mit Offenlassen der Problemlösung

Fragen/Antworten zur Erschließung des Problems

umfangreiches Material zur Entnahme nötiger Informationen

-

-

Natur des Problems

individuell

isoliert

organisatorisch

Kombination aus links genannten

-

Datenherkunft

real

halbfiktiv

fiktiv

-

-

Gestaltung

deskriptiv

illustrierend

erklärend

erforschend

vergleichend

Umsetzung

Frontalunterricht

Selbstlerneinheit

beides

-

-

Komplexität

< 5 Seiten

5-10 Seiten

10-20 Seiten

20-40 Seiten

> 40 Seiten

Ergebnisüberprüfung

Präsentation

schriftliche Ausarbeitung

Prüfung

Kombination aus links genannten

-

Abb. 1.1: Klassifikation der eingesetzten Fallstudien (Funk et al. 2008)

4

Einleitung

Die Fallstudien eignen sich gut für die Bearbeitung im Rahmen einer Blockveranstaltung über vier bis 5 Tage mit jeweils 6 bis 8 akademischen Stunden. In Tabelle 1.1 ist exemplarisch ein Zeitplan gegeben, der sich bei der Durchführung von Kursen zur Geschäftsprozessintegration mit SAP PI an den Universitäten der Autoren dieses Lehrbuches (Lüneburg, Osnabrück sowie Oldenburg) bewährt hat. Für die Bearbeitung der Fallstudien am Rechner empfiehlt sich eine Gruppengröße von maximal 20 Teilnehmern und zwei Lehrenden (Übungsleitern), welche durch die Reihen gehen und Fragen der Kursteilnehmer beantworten und bei möglichen Problemen Hilfestellung leisten. Zur Auflockerung der Blockveranstaltung sollte ein Praxisvortrag eines Anwenders der SAP-Integrationslösungen oder eines SAPBeraters in Erwägung gezogen werden. Tabelle 1.1: Exemplarischer Zeitplan Tag 1 der Blockveranstaltung Erwartungen der Kursteilnehmer und Lehrenden, etwaige Vorkenntnisse der Kapitel 1 bis 4 Kursteilnehmer, Lern- und Lehrziele im Rahmen eines Einführungsgedes Lehrbuches sprächs eruieren Unternehmensporträt der SAP AG, Produktspektrum der SAP AG Einführung in Grundlagen des Geschäftsprozessmanagements Anmeldung am System und Vertrautmachen mit den Benutzeroberflächen, der Menüführung, Hilfe sowie grundsätzlichen Bedienung der zum Einsatz kommenden Systeme Tag 2 der Blockveranstaltung Motivation und Vorstellung des Anwendungsszenarios der Fallstudien Fallstudie 1 im Vermittlung von konzeptionellen Grundlagen, die für die Durchführung der Lehrbuch Fallstudien erforderlich sind Eigenständige Durchführung von Fallstudie 1 am Rechner durch die Teilnehmer Besprechung der Lösung und Kontrollfragen zu Fallstudie 1 Tag 3 der Blockveranstaltung Praxisvortrag Fallstudie 2 im Vermittlung von konzeptionellen Grundlagen, die für die Durchführung der Lehrbuch Fallstudien erforderlich sind Eigenständige Durchführung von Fallstudie 2 am Rechner durch die Teilnehmer Besprechung der Lösung und Kontrollfragen zu Fallstudie 2 Tag 4 der Blockveranstaltung Vermittlung von konzeptionellen Grundlagen, die für die Durchführung der Fallstudie 3 im Fallstudien erforderlich sind Lehrbuch Eigenständige Durchführung von Fallstudie 3 am Rechner durch die Teilnehmer Besprechung der Lösung und Kontrollfragen zu Fallstudie 3 Tag 5 der Blockveranstaltung (halber Tag) Test im Hinblick auf die Erreichung der Lern- und Lehrziele Abschluss- und Feedbackgespräch Evaluation der Lehrveranstaltung

Literaturquellen

5

1.3 Voraussetzungen Die Fallstudien des Lehrbuches stellen verschiedene Anforderungen an Studierende und Lehrende sowie an die technische Infrastruktur, die im Folgenden kurz skizziert werden: Das Lehrbuch richtet sich primär an Studierende eines Wirtschaftsinformatik-, Informatik- oder BWL-Hauptstudiums. Neben grundlegenden Kenntnissen betriebswirtschaftlicher Funktionen und Prozesse ist eine Affinität zur technischen Umsetzung hilfreich. Darüber hinaus sollten die Teilnehmer über erste SAP-Erfahrungen verfügen, d.h. insbesondere mit der Navigation in SAPSystemen vertraut sein. Kenntnisse von SAP PI oder SAP Workflow werden nicht vorausgesetzt. Zusätzlich müssen ein SAP Backend System (mit Entwicklungsberechtigung) und ein SAP PI System verfügbar sein. Da die Grundkonfiguration zwischen SAP Backend System und SAP PI System nicht Bestandteil der Fallstudie ist, wird empfohlen, beide Systeme von einem der beiden SAP UCC (Hochschulkompetenzzentren) in Magdeburg oder München betreiben zu lassen, welche die erforderliche recht umfangreiche Konfiguration und Wartung der Systeme übernehmen können. Weitere notwendige technische Voraussetzungen sowie Vorbereitungsmaßnahmen durch die Lehrenden werden an den entsprechenden Stellen in den Fallstudien erläutert. Die Lehrenden sollten Erfahrungen in der Prozessmodellierung und der Prozessintegration mitbringen. Kenntnisse der Integrationsplattform SAP PI und des SAP Business Workflow sind hilfreich, aber nicht Voraussetzung.

1.4 Literaturquellen Bloom B (1956) Taxonomy of Educational Objectives, Handbook I: The Cognitive Domain. David McKay, New York Funk B, Niemeyer P, Rautenstrauch C, Scheruhn HJ, Weidner S (2008) Modellierung und Implementierung eines Order2Cash Prozesses in verteilten Systemen. In: Bichler M, Hess T, Krcmar H, Lechner U, Matthes F, Picot A, Speitkamp B, Wolf P (Hrsg) Proceedings der Multikonferenz Wirtschaftsinformatik (MKWI), München, 26.02.-28.02. 2008. GITO Verlag, Berlin, S 425-431

2 Geschäftsprozessmanagement und Prozessmodellierung 2.1 Lernziele Nach der Lektüre von Kapitel 2 können Sie die folgenden Fragen beantworten: x x x x x x

Was versteht man unter Geschäftsprozessen und Prozessorientierung? Was sind die Ziele des Geschäftsprozessmanagements und der Prozessorientierung in Organisationen? Wie lassen sich (kritische) Geschäftsprozesse identifizieren, analysieren und kontinuierlich überwachen? Wie lassen sich Geschäftsprozesse beschreiben und dokumentieren? Welche Notationen zur Modellierung von Geschäftsprozessen stehen zur Verfügung und über welche Modellierungselemente (Objekte) verfügen diese? Wie können Webservices sowie die WS-BPEL zur Automatisierung und Integration von Prozessen beitragen?

2.2 Einleitung Seit Anfang der 90er Jahre hat sich Geschäftprozessmanagement (GPM) als fester Bestandteil der Anwendungssystem- und Organisationsgestaltung in der Praxis etabliert (Gaitanides et al. 1994). Auch in der Wissenschaft ist Geschäftsprozessmanagement ein weit verbreitetes Forschungsfeld, das sich großer Beliebtheit erfreut (vgl. stellvertretend für viele Ehrig et al. 2007, Funk et al. 2008, Heinrich et al. 2008, Hepp, Roman 2007, Mendling, Nüttgens, 2006, Teuteberg et al. 2009, Thomas, Fellmann 2009). Der interessierte Leser kann zudem auf eine Vielzahl an (Lehr-)Büchern zum Thema Geschäftsprozessmanagement zurückgreifen (vgl. stellvertretend für viele Allweyer 2005, Becker et al. 2009, Hammer, Champy 1995, Gadatsch 2005, Rosenkranz 2002 oder Staud 2006). Kapitel 2 gibt eine Einführung in das Geschäftsprozessmanagement (GPMLebenszyklus) und die Geschäftsprozessmodellierung. Es werden die Ziele erläutert, die mit dem Geschäftsprozessmanagement und der Prozessorientierung in Unternehmen verfolgt werden, sowie in der gegebenen Kürze der Hintergrund und die historische Entwicklung des Geschäftsprozessmanagements aufgezeigt. Die unterschiedlichen Methoden, die für die Modellierung von Geschäftsprozessen zur Verfügung stehen, und ausgewählte Notationen (EPK, eEPK, UML, BPMN) werden vorgestellt. Möglichkeiten der Prozessintegration auf der Basis von Webservices und der WS-BPEL werden ebenfalls thematisiert.

8

Geschäftsprozessmanagement und Prozessmodellierung

Blickpunkt Praxis Einführende Fallstudie: Wie Geschäftsprozessmanagement Stuart Wright dabei hilft Geschäftswissen zu sichern Branchensituation Die Öl- und Gasindustrie steht weltweit vor dem Problem, dass es einen Mangel an qualifiziertem Personal zur Ölförderung gibt. Daneben stellen die nachlassende Nachfrage und die Erschöpfung der vorhandenen Quellen weitere Herausforderungen dar. Dies hat in den letzten Jahren dazu geführt, dass vermehrt auch schwer zugängliche Quellen erschlossen werden. Hierzu ist ein spezielles Wissen notwendig. Neu eingestellte Mitarbeiter müssen schnell in diese wissensintensive Branche eingearbeitet werden; dies wird aber durch eine hohe Mitarbeiterfluktuation erschwert. Die Herausforderung Bei der Ausführungsplanung in der Öl- und Gasförderung sind Geschäftsprozesse nötig, die hochgradig standardisiert sind, um die getätigten Investitionen zu maximieren. Bei der Projektdurchführung kommt es zu einer häufigen Personalrotation, da die Arbeiten offshore durchgeführt werden und oftmals Mitarbeiter von anderen Firmen abgeworben werden. Folglich werden die Arbeiten von verschiedenen Teams durchgeführt, die unabhängig voneinander zum gemeinsamen Ziel führen müssen. Hierfür ist eine gute Dokumentation der bereits erfolgten Arbeitsschritte notwendig. Die Lösung Das Unternehmen Stuart Wright (http://www.stuartwright.com.sg/) hat hierfür die Software Enterprise Process Center (EPC) von Interfacing verwendet, in der die Arbeitsmethoden, die Aufgaben und die Informationsflüsse modelliert wurden. Der gesamte Prozess wurde als Prozesskarte mit Inputs, Outputs, beschreibenden Dokumenten und den jeweils verantwortlichen Personen dargestellt. Hierdurch kann dieser Prozess wiederholt durchgeführt werden, unabhängig davon, wer welche Arbeitsschritte durchführt. Vorteile Durch diese Standarisierung der Arbeitsabläufe wurde es möglich, das Wissen der Mitarbeiter zu sichern. Das hat das Problem der Personalfluktuation für Stuart Wright entschärft, da geringere Trainingskosten anfallen. Ebenso ist die Zusammenarbeit zwischen verschiedenen Arbeitsgruppen bzw. den Projektbeteiligten leichter, da alle auf die gleiche Dokumentation der modellierten Prozessaktivitäten zurückgreifen können. Quelle: Interfacing (2008): BPM helps Stuart Wright Preserve Company Knowledge, Case Story, April 2008; http://interfacing.com/uploads/File/case%20story%20stuart%20wright.pdf

Ziele des Geschäftsprozessmanagements und der Prozessmodellierung

9

2.3 Ziele des Geschäftsprozessmanagements und der Prozessmodellierung Einige der zentralen Fragestellungen im Bereich des Geschäftsprozessmanagements sind: „Wer (Akteure) macht was (Aufgaben), wann (zeitliche Abfolge), wie (Qualität), womit (Ressourcen) und zu welchem Zweck (Unternehmensziele)?“ In den nachfolgenden Abschnitten wird diesen Fragestellungen weiter nachgegangen. Zu den primären Zielen des Geschäftsprozessmanagements zählen (Rosenkranz 2006, S. 16 f.): x x x x

x

x x x x

das Identifizieren von Geschäftsprozessen, das Planen, Gestalten und Modellieren der Prozesse, das Dokumentieren betrieblicher Prozessabläufe, das Abbilden von Prozessen mit fest definierten Rollen, Rechten und benötigten Informationsobjekten (z.B. Dokumenten, Dateien) bzw. Ressourcen zu deren Ausführung, das Festlegen von Schnittstellen zwischen einzelnen Prozessen, damit diese in Hierarchiestufen mit unterschiedlichem Detaillierungsgrad zu Wertschöpfungsketten abgebildet werden können, das Durchführen einer prozessorientierten Kostenkalkulation (Prozesskostenrechnung), das Überwachen der Prozesse, das interne sowie externe Prozess-Benchmarking sowie das kontinuierliche Verbessern von Geschäftsprozessen (kontinuierliches Verbesserungsmanagement).

Nach Gartner Inc. (www.gartner.com), ein Unternehmen, das Marktforschungsergebnisse und Analysen im Bereich der Informationstechnologie anbietet, nimmt innerhalb des Geschäftsprozessmanagements die Modellierung der identifizierten Geschäftsprozesse einen sehr hohen Stellenwert ein. Ca. 40 % der gesamten Zeit von Projekten im Bereich des GPM werden in den Unternehmen allein für die Konstruktion von Prozessmodellen (Geschäftsprozessmodellierung) verwendet (zitiert nach Mendling 2008, S. 1). Gartner Inc. hat daher die Geschäftsprozessmodellierung im Jahr 2008 als eine der wichtigsten strategischen Unternehmensaufgaben identifiziert (Melenovsky 2005). Zu den primären Zielen der Geschäftsprozessmodellierung gehören (Rosenkranz 2006, S. 16 f., Staud 2006, S. 17 f.): x die Dokumentation der Geschäftsprozesse des Unternehmens, x die Vorbereitung einer Geschäftsprozessverbesserung bzw. -restrukturierung, um bspw. im Rahmen einer Ist-Analyse von Geschäftsprozessen Kenntnis über die eigenen betrieblichen Abläufe zu erlangen, neue Organisationsstrukturen und Unternehmensabläufe einzuführen bzw. umzugestalten oder um bspw. einzelne Aufgaben bzw. Prozesse auszulagern (d.h. ein Outsourcing von Prozessen zu betreiben),

10


x die Vorbereitung der Automatisierung bzw. IT-Unterstützung (Workflows) der betrieblichen Abläufe, x die Festlegung von Prozesskennzahlen zum Benchmarking der Prozessleistung, x die Definition von Service Level Agreements wie bspw. bei OutsourcingAktivitäten, x ein Internes und externes Benchmarking zwischen Unternehmensteilen, Geschäftspartnern und Konkurrenten, x das Aufzeigen von Best Practices in Form von Referenzmodellen, x das Compliance Management, d.h. das Abgleichen der Geschäftsprozesse mit den geltenden Regelungen des Unternehmens und regulatorischen Anforderungen des Gesetzgebers, x das Erfüllen von Auflagen von Geschäftspartnern sowie x das Erlangen von Zertifizierungen. Weitere Zielsetzungen der Geschäftsprozessmodellierung sind: x das Einarbeiten von Mitarbeitern in die betrieblichen Abläufe, x das Vermeiden von Wissensverlust (zum Beispiel aufgrund starker Mitarbeiterfluktuation; vgl. hierzu auch die einführende Praxisfallstudie) sowie x die Unterstützung des Qualitätsmanagements.

2.4 Hintergrund und Historie der Geschäftsprozessorientierung Adam Smith, ein amerikanischer Ökonom und Philosoph, hat bereits mit seinem 1776 veröffentlichten Buch "An Inquiry into the Nature and Causes of the Wealth of Nations" gezeigt, welche Chancen der Übergang zur maschinellen Herstellung in Großbetrieben bietet, und wie dieses sich auf die Produktivität von Arbeitskräften positiv auswirken kann (Smith 1776). Smith begründete damit den Grundsatz der Arbeitsteilung, d.h. der Fragmentierung von Aufgaben in Teilaufgaben und der Spezialisierung von Arbeit bzw. Arbeitskräften. Die individuellen Aufgaben der einzelnen Arbeitskräfte und die Koordination zwischen diesen Teilaufgaben sind dabei Gegenstand der Analyse. Primäres Ziel ist die Verbesserung von betrieblichen Arbeitsabläufen. Frederick W. Taylor hat diese Grundidee der Arbeitsteilung später weiterentwickelt (Taylor 1911, S. 61). Nach ihm entstand der Begriff des Taylorismus. Die Effizienz dieses Konzepts wurde von Henry Ford demonstriert, indem er ab 1913 Montagebänder einsetzte, die Werkstücke von einem Arbeiter zum nächsten transportiert haben. Er "erfand" quasi die Fließbandarbeit zur Massenfertigung und präsentierte der Öffentlichkeit in seinen Fabriken stolz Produktionszyklen von nur 81 Stunden “from the mine to the finished machine” (Ford 1926, S.105).

Hintergrund und Historie der Geschäftsprozessorientierung

11

Lange beschäftigte sich die Wissenschaft ausschließlich mit der Gestaltung von Aufbauorganisationen. Dies führte in der Praxis zunehmend zu einer Entfremdung vom Kunden sowie zu mangelnder Flexibilität und Stärke am Markt und den damit einhergehenden Wettbewerbsnachteilen. Fritz Nordsieck war 1932 einer der ersten, der zwischen Aufbau- und Prozessorganisation unterschieden hat (Nordsieck 1932, Nordsieck 1934). Im folgenden Zitat weist Nordsieck auf die Notwendigkeit einer Prozessorientierung in Unternehmen hin: „Der Betrieb ist in Wirklichkeit ein fortwährender Prozess, eine ununterbrochene Leistungskette. [...] anzustreben ist in jedem Fall eine klare Prozessgliederung.“ (Nordsiek 1932). Nordsieck hat verschiedene Typen von Workflow-Diagrammen beschrieben, z.B. Diagramme für die Arbeitsteilung, Diagramme für die Aktivitätenabfolge oder Diagramme für die Aufgabenzuweisung (Nordsiek 1932). In seinen Arbeiten identifiziert Nordsieck die Abfolge der Arbeitsschritte und die zeitlichen Beziehungen zwischen Aufgaben als den zentralen Gegenstand der Prozessanalyse (Nordsiek 1934, vgl. zur historischen Entwicklung des GPM auch Mendling 2008, S. 2 ff.). Zu Beginn der 90er Jahre hatten Michael Hammer und James Champy den Ansatz des Business Reengineering (BR) formuliert (vgl. Hammer, Champy 1993 sowie Hammer, Champy 1995) wonach Geschäftsprozesse vergleichsweise einfach neu strukturiert werden können, um eine messbare Verbesserung von Leistungsgrößen wie Kosten, Qualität, Service und Zeit zu erzielen. Der Ansatz des Business Reengineering wurde zum Teil im Hinblick darauf kritisiert, dass er von einer „grünen Wiese“ in den Unternehmen ausginge und daher für gewachsene Organisationen nicht oder nur mit großem Ressourceneinsatz in Form von Zeit, Kosten, Personal, etc. direkt umsetzbar sei. Seit Mitte der 90er Jahre profitieren die Anwender von Workflow-Systemen mit offenen (Kommunikations-)Standards, die zur weiteren Verbesserung der Interoperabilität und Integrationsfähigkeit der Workflow-Systeme mit anderen Anwendungssystemen beitrugen (Georgakopoulos et al. 1995). Für Verbesserungen im Bereich der Workflow-Systeme ist die 1993 gegründete Workflow Management Coalition (WfMC) von besonderer Wichtigkeit (Hollingsworth 2004). Ein historischer Überblick über Workflow-Systeme findet sich in (Zur Muehlen 2004, S. 93 f., vgl. hierzu auch Mendling 2008, S. 3 ff.). Ansätze und Notationen (z.B. Unified Modeling Language und Ereignisgestützte Prozessketten) zur Geschäftsprozessmodellierung wurden insbesondere durch Grady Booch, Ivar Jacobson und James E. Rumbaugh (Booch et al. 1999) sowie durch August-Wilhelm Scheer (Scheer 1992) vorangetrieben. Seit der Entwicklung der eXtensible Markup Language (XML) und der Webservices-Technologie sind Anwendungsszenarios einer unternehmensübergreifenden Geschäftsprozessintegration sehr viel leichter umsetzbar. Aktuelle Standardisierungsbemühungen beziehen sich hauptsächlich auf Fragen der Interoperabilität von Anwendungssystemen (siehe hierzu stellvertretend für viele Mendling et al. 2004, Mendling 2008). Das Interesse der Industrie, die Integration interorganisationaler Prozesse zu fördern, führte zu einer schnelleren Durchsetzung von spezifizierten Standards für die Webservice-Komposition. Beispiele für Stan-

12


dards sind die Business Process Execution Language for Web Services (WSBPEL) (Curbera et al. 2002, Andrews et al. 2003, Alves et al. 2007, Mendling 2008), die Web Service Choreography Description Language (WS-CDL) (Kavantzas et al. 2005) sowie ebXML für inter-organisationale Prozesse (für einen Überblick hierzu siehe Hofreiter et al. 2006). In der betrieblichen Praxis haben sich davon nur wenige Standards durchgesetzt. Die Integration von Orchestrierungs- und Choreographiesprachen ist zurzeit eines der wichtigsten Forschungsthemen in diesem Bereich. Orchestrierung definiert dabei, welche Funktionen in welcher Reihenfolge ausgeführt werden (interne Sicht auf Geschäftsprozesse). Choreographie definiert wiederum die Interaktion zwischen Geschäftsprozessen (externe Sicht auf Geschäftsprozesse). Choreographie beschreibt somit den Nachrichtenaustausch und das Zusammenspiel mehrerer beteiligter Parteien.

2.5 Begriffliche Grundlagen Die zentralen Begriffe in diesem Kapitel 2: Geschäftsprozess, Geschäftsprozessmanagement (GPM), Geschäftsprozessmodellierung (GPMO) sowie Business Process Reengineering (BPR) werden nachfolgend kurz definiert. Geschäftsprozess Der Begriff Geschäftsprozess wird in der Literatur häufig diskutiert (vgl. stellvertretend für viele z.B.: (Keller und Teufel 1997, S. 153 ff., Staud 2006, S. 7 ff.). Eine Definition von (Hammer und Champy 1995, S. 52) lautet: "Wir definieren einen Unternehmensprozess als Bündel von Aktivitäten, für das ein oder mehrere unterschiedliche Inputs benötigt werden, und das für den Kunden ein Ergebnis von Wert erzeugt." Staud definiert den Begriff Geschäftsprozess wie folgt (Staud 2006, S. 9): "Ein Geschäftsprozess besteht aus einer zusammenhängenden abgeschlossenen Folge von Tätigkeiten (Aktivitäten), die zur Erfüllung einer betrieblichen Aufgabe notwendig sind. Die Tätigkeiten werden von Aufgabenträgern in organisatorischen Einheiten mit ihrer Aufbau- und Ablauforganisation unter Nutzung der benötigten Produktionsfaktoren geleistet." Scheer schreibt: "Geschäftsprozesse werden aus einer zusammengehörenden Abfolge von Unternehmensverrichtungen zum Zwecke der Leistungserstellung gebildet" (Scheer 1998, S. 3). Nach (Becker, Schütte 2004, S. 107) ist ein Prozess "die inhaltlich abgeschlossene, zeitliche und sachlogische Folge von Aktivitäten, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objekts notwendig sind." In der DIN-Norm 19222 wird der Begriff wie folgt definiert: “eine Gesamtheit von aufeinander einwirkenden Vorgängen in einem System, durch die Materie, Energie oder auch Information umgeformt, transportiert oder auch gespeichert

Begriffliche Grundlagen

13

wird”. Zahlreiche weitere Definitionen von Geschäftsprozessen finden sich auch in (Rump 1999). Typische Beispiele für Geschäftsprozesse sind die Kreditvergabe in einer Bank oder die Auftragsabwicklung in einem Produktionsbetrieb (Becker, Kahn 2008, S. 6 f.). Gemein ist den oben aufgeführten Definitionen im weiteren Sinne folgendes (Staud 2006, S. 7 ff.): x Mit Geschäftsprozessen werden ein Ziel oder auch mehrere Ziele verfolgt, die sich aus den Unternehmenszielen (bzw. der Unternehmensstrategie) ableiten, x Ein Geschäftsprozess lässt sich in Teilaufgaben zerlegen, x Die Teilaufgaben werden von Aufgabenträgern wahrgenommen, die wiederum verschiedenen Organisationseinheiten angehören, x Für die Erfüllung der Geschäftsprozesse sind Unternehmensressourcen notwendig (z.B. Personal, Material, Finanzen), x Ein Geschäftsprozess (z.B. Auftragsabwicklung) tangiert oft mehrere Abteilungen bzw. Funktionsbereiche (z.B. Beschaffung, Produktion oder Vertrieb) und liegt somit oftmals "quer" zur klassischen Aufbauorganisation, x Geschäftsprozesse benutzen in der Regel Informationsträger (z.B. eine Auftragsbestätigung) zu ihrer Realisierung. Geschäftsprozessmanagement (GPM) GPM (Bucher, Winter 2009, S. 6) ist ein ganzheitliches Managementkonzept, welches die Analyse und Überwachung sowie die Konstruktion und Anwendung von konzeptionellen Modellen der Geschäftsabläufe von Unternehmen und Verwaltungen umfasst. GPM beschäftigt sich insbesondere mit dem Identifizieren, Planen, Gestalten, Modellieren, Dokumentieren, Überwachen, Steuern sowie dem kontinuierlichen Verbessern von Geschäftsprozessen. GPM dient dabei der Anwendungssystem- und Organisationsgestaltung aus der Perspektive der betrieblichen Abläufe. Die genannten Aufgaben des GPM sind i.d.R. dauerhaft und kontinuierlich wahrgenommene Aufgaben. Charakteristisch für das GPM sind das Denken in sog. Regelkreisen und die Integration von Ziel-, Planungs-, Steuerungsund Kontrollsystemen für das interne und externe Benchmarking von Geschäftsprozessen. Geschäftsprozessmodellierung (GPMO) GPMO umfasst sämtliche Aktivitäten, die mit der Konstruktion von Geschäftsprozessmodellen im Rahmen des Geschäftsprozessmanagements verbunden sind. Die GPMO setzt dabei Informationsmodelle ein, welche als Wissensträger und Kommunikationsmedium den prozessorientierten Gestaltungsprozess unterstützen sollen. Die eingesetzten Informationsmodelle repräsentieren dabei die betriebswirtschaftlich relevanten Sachverhalte für Zwecke der Anwendungssystem- und Organisationsgestaltung (Becker, Schütte 2004, S. 67).

14


Zum Begriff des (Prozess-)Modells gibt es in der Literatur keine einheitliche Definition (vgl. stellvertretend für viele Schütte 1998, S. 40-62, vom Brocke 2003, S. 9-25, Frank 2000). Es lassen sich jedoch drei grundlegende Merkmale von (Prozess-)Modellen unterscheiden (Stachowiak 1973, S. 136, Kosiol 1961, S. 321, Ahlemann 2006, S. 47 ff.): 1. Abbildungsmerkmal: Modelle repräsentieren über eine Abbildungsrelation ein reales System (Realweltausschnitt). 2. Verkürzungsmerkmal: Modelle abstrahieren von Details des realen Systems und verkürzen somit den Realweltausschnitt. 3. Pragmatisches Merkmal: Mit der Bildung von Modellen werden pragmatische Ziele verfolgt; Modelle werden durch ein modellierendes Subjekt zu einem bestimmten Zweck konstruiert. Schütte definiert ein Modell als "das Ergebnis einer Konstruktion eines Modellierers, der für Modellnutzer eine Repräsentation eines Originals zu einer Zeit als relevant mit Hilfe einer Sprache deklariert" (Schütte 1998, S. 59). Hinter diesem Modellverständnis steht die Erkenntnis, dass Modelle nicht nur eine direkte Abbildung eines realen Systems sind, sondern nur über den Umweg eines Modellierers expliziert werden können und somit vielmehr Ergebnis einer problembezogenen Strukturierungsleistung sind, welche einen bestimmten Zweck verfolgt. Vorkenntnisse, Erfahrungen und die Intention des Modellierers haben somit maßgeblichen Einfluss auf das Ergebnis der Modellierung (im Sinne einer Modellierung als subjektiver Akt) (Schütte 1998, S. 51, vom Brocke 2003, S. 15 ff.). Zudem wird in dieser Definition explizit die Verwendung einer Modellierungssprache gefordert; natürlichsprachliche, zweckbezogene Aussagen über Organisationssysteme wären demzufolge noch nicht als Modell zu verstehen. Business Process Reengineering (BPR) Business Process Reengineering (Staud 2006, S. 18 f.) bezeichnet einen Ansatz zur radikalen Neugestaltung von Geschäftsprozessen auf der Basis einer ausgeprägten Kundenorientierung. Der Begriff (Re-)Engineering verdeutlicht, dass es sich primär um einen ingenieurwissenschaftlichen Ansatz handelt, in dem die Verwendung von Methoden und Modellen eine zentrale Rolle spielt (Konstruktionslehre). Sofern ein hoher Veränderungsgrad bei analysierten Geschäftsprozessen notwendig ist, sind Ansätze des Change Managements bei der Neugestaltung der Geschäftsaprozesse von Bedeutung.

2.6 Phasen des Geschäftsprozessmanagements Das Geschäftsprozessmanagement mit dem Ziel einer Verbesserung im Sinne einer kontinuierlichen Prozessverbesserung ist kein einmaliges Projekt, sondern eine

Phasen des Geschäftsprozessmanagements

15

dauerhafte, kontinuierliche Aufgabe. Eine Möglichkeit der kontinuierlichen Durchführung des Geschäftsprozessmanagements im Unternehmen stellt die Orientierung am Geschäftsprozessmanagement-Kreislauf dar. Das GPM ist grundsätzlich hierbei an keine bestimmte Vorgehensweise geknüpft. Dennoch haben sich in der betrieblichen Praxis mehrere Ansätze zur Umsetzung etabliert. Grundsätzlich orientiert sich das GPM an klassischen Vorgehensmodellen von Organisationsprojekten mit den idealtypischen Phasen: 1. 2. 3. 4. 5.

Vorbereitung Voruntersuchung Hauptuntersuchung (Ist-Erhebung - Ist-Analyse - Soll-Konzeption) Umsetzung sowie Evaluierung

Der Plan-Do-Act-Check-Zyklus (Deming 1982, S. 88) ist daher Basis für viele der in der Literatur vorgestellten GPM-Zyklusmodelle. Im Wesentlichen werden hierbei Managementaktivitäten, die sich auf Geschäftsprozesse beziehen, als Phasen eines sog. Lebenszyklus angeordnet (van der Aalst, van Hee 2002). Im Folgenden orientieren wir uns hauptsächlich an dem in (Schmidt et al. 2009, S. 53) vorgeschlagenen Modell, da es verschiedene Lebenszyklusmodelle für das Geschäftsprozessmanagement in einem Modell konsolidiert, die u.a. in (Galler, Scheer 1995, Neumann et al. 2003) vorgestellt werden. Ähnlich wie der allgemeine Entwicklungsprozess von Informationssystemen weist dieser Lebenszyklus eine Aktivitätenanalyse sowie die Modellierung und die Implementierung als zentrale Elemente des GPM auf. Unternehmensstrategie

Unternehmensvision Analyse

Betrieb und Monitoring Projektmanagement

Verifikation und Abnahme

Aufbau des Prozesscontrollings

Geschäftsprozess

Change Management

ITImplementierung

IT-Vision

Modellierung

Validierung

Re-Engineering

Organisatorische Implementierung

IT-Strategie

IT-Governance

Abb. 2.1: Geschäftsprozessmanagement-Lebenszyklus als kontinuierlicher Verbesserungsprozess (in enger Anlehnung an: Schmidt et al. 2009, S. 53)

16


Der Lebenszyklus umfasst im Einzelnen die folgenden Managementaktivitäten: Analyse, Modellierung, Validierung, (Re-)Engineering, IT- und organisatorische Implementierung, Verifikation sowie Betrieb und Monitoring. Abb. 2.1 veranschaulicht die idealtypische Abfolge dieser Aktivitäten. Das GPM ist in seinen Grundzügen ein kontinuierlicher Verbesserungsprozess. Das Managementobjekt, das kontinuierlich verbessert werden soll, sind dabei die Geschäftsprozesse. Rückkopplungen von den einzelnen Phasen in frühere Phasen sind dabei im Einzelfall nötig (symbolisiert durch die Pfeile im inneren Kreislauf). Begleitende Aktivitäten sind das Prozess-Controlling, das Change Management sowie das Projektmanagement. Die Rahmenbedingungen werden durch die Unternehmensvision, die Unternehmensstrategie, IT-Vision sowie die IT-Governance gesetzt (vgl. Abb. 2.1). Organisationen können grundsätzlich unterschiedliche Reifegrade in der Unterstützung der einzelnen Phasen und ihrer – möglichst reibungslosen – Übergänge erreichen. Ein Reifegradmodell (sog. Maturity Model) hilft diese unterschiedlichen Reifegrade zu definieren, um beurteilen zu können, inwieweit ein Reifeobjekt (z.B. Institution, Prozesse) die für jeden Reifegrad allgemeingültig definierten Qualitätskriterien bzw. Anforderungen erfüllt (Knackstedt et al. 2009). Die Erfüllung dieser Anforderungen wird anhand von spezifizierten Kriterien und Fragenkatalogen sowie Checklisten gemessen. Das Kriterium Reifegrad zeigt dementsprechend an, aus wie vielen unterschiedlichen Reifegradebenen das entsprechende Reifegradmodell besteht. Typischerweise werden vier oder fünf Reifegradstufen verwendet. Spezifische Reifegradmodelle für das Geschäftsprozessmanagement werden bspw. in (Rosemann et al. 2006) besprochen. Eine Vielzahl an Reifegradmodellen für unterschiedliche Prozesse findet sich bspw. im Cobit-Rahmenwerk (vgl. Johannsen, Goeken 2007), welches sich auch in der Unternehmenspraxis zunehmender Beliebtheit erfreut. Die nachfolgenden Abschnitte beschreiben die jeweilige Intention und die enthaltenen Aufgabenbereiche des in Abb. 2.1 vorgestellten Geschäftsprozessmanagement-Lebenszykus (vgl. hierzu auch Eicker et al. 2007, S. 24 ff.).

2.6.1 Analysephase Ziel dieser Phase ist es, die im Unternehmen vorhandenen Geschäftsprozesse auf Schwachstellen und Verbesserungspotenziale, ihre Wertorientierung sowie auf ihren Beitrag zur Steigerung der Wertschöpfung und zur Erreichung der strategischen Unternehmensziele hin zu untersuchen (Allweyer 2005, S. 223). Es geht in dieser Phase somit primär darum, Geschäftsprozesse mit Verbesserungspotenzial zu identifizieren und zu analysieren. Dabei können sowohl existierende Prozesse identifiziert bzw. dokumentiert als auch Prozesse neu geplant und strukturiert bzw. eingeführt werden.


17

Zur Identifizierung der Geschäftsprozesse bietet sich deren Prüfung hinsichtlich ihrer Zielerreichung an (bspw. auf Basis von Kosten, Durchlaufzeit, Warendurchsatz, Qualität sowie Nutzen der einzelnen Prozessaktivitäten, aber auch auf der Basis von möglichen Medien-, Organisations- oder Systembrüchen zwischen einzelnen Prozessaktivitäten). Des Weiteren bietet sich zur Analyse von Prozessen auch eine Simulation der Prozesse oder eine Prozesskostenrechnung an (Eicker et al. 2007, S. 26 f.). Medien- und Systembrüche haben bspw. einen hohen Einfluss auf die Durchlaufzeit einzelner Prozesse und können dadurch die Prozesskosten erhöhen (Allweyer 2005, S. 229). Ein primäres Ziel ist "in möglichst kurzer Zeit zu möglichst geringen Kosten einen möglichst hohen Nutzen für den Kunden in möglichst hoher Qualität zu erbringen“ (Allweyer 2005, S. 229). Bei der Realisierung dieses Zieles kann es durchaus zu Zielkonflikten zwischen einzelnen Teilzielen wie Durchlaufzeitreduzierung, Kostenreduzierung, Nutzenmaximierung oder Qualitätsverbesserung kommen. Eine hohe Qualität von Prozessen kann jedoch auch helfen, langfristig Kosten zu reduzieren, indem bspw. Material- und Energieverbräuche reduziert werden, Ausfallzeiten minimiert werden oder Prozessfehler, die zu hohen Nachbesserungs- und Reparaturkosten führen, vermieden werden. Die dokumentierten Prozesse, d.h. der dokumentierte Ist-Zustand der identifizierten Prozesse, können nun analysiert werden. Hierzu werden die erhobenen Kennzahlen und im Rahmen von Expertengesprächen erhaltene Informationen (z.B. Organigramme, DLZ-Analysen, Prozesskosten, skizzierte Problemfelder) nach verschiedenen Gesichtspunkten mit der Zielsetzung Schwachstellen bzw. Ansatzpunkte für Verbesserungen zu identifizieren, ausgewertet. Notwendige Voraussetzung für eine Geschäftsprozessanalyse ist eine vollständige Dokumentation der jeweiligen Prozesse. Aus diesem Grund ist neben der eigentlichen Dokumentation auch die Durchführung einer Ist-Erhebung bei den Mitarbeitern (direkt am Prozess beteiligte Mitarbeiter, Prozessverantwortliche, Fachexperten, Manager) mittels Interviews und Workshops hilfreich. Allweyer hat Vor- und Nachteile der Ist-Analyse (vgl. Tab. 2.1) von Prozessen gegenübergestellt (Allweyer 2005, 224 ff.). Tabelle 2.1: Vor- und Nachteile der Ist-Analyse von Prozessen (Allweyer 2005, 224 ff., Eicker et al. 2007, S. 26 f.) Vorteile der Ist-Analyse

Nachteile der Ist-Analyse

Verständnis für Prozessabläufe

Der Aufwand für die Ist-Erhebung und Modellierung ist vergleichsweise hoch

Aufdeckung von versteckten Problemen und deren Berücksichtigung bei der SollProzessmodellierung Möglichkeit der Aufdeckung von Verbesserungspotenzial durch einen besseren Vergleich der Ist- mit den Soll-Prozessen

Der Blick für Veränderungspotenziale kann durch die intensive Beschäftigung mit den IstZuständen eingeschränkt werden

18


Trotz der genannten Nachteile ist die Phase der Ist-Analyse von großer Bedeutung, um zunächst einen Gesamtüberblick über alle bestehenden Prozessabläufe eines Unternehmens zu gewinnen und auf diese Weise Schwachstellen und Verbesserungspotenziale zu erkennen (Allweyer 2005, S. 226). 2.6.1.1 Identifikation von Prozessen mit Verbesserungspotenzial Diese Phase des Geschäftsprozessmanagements hat das Ziel, genau diejenigen Geschäftsprozesse zu identifizieren, die „die größten Probleme“ in einem Unternehmen bereiten. Folgende zentrale Fragen sind Gegenstand der Prozessidentifikation (Schmelzer, Sesselmann 2007, S. 123 ff.): x Auf welche Kundengruppen bzw. Marktsegmente will sich das Unternehmen in Zukunft konzentrieren? x Was sind die Kundenanforderungen, -bedürfnisse und -erwartungen? x Welche Produkte/Leistungen erwarten die Kunden heute und in Zukunft? x Wie zufrieden sind die Kunden mit den heute angebotenen Produkten/Leistungen? x Wo liegen Wettbewerbsvorteile? x Welche Kernkompetenzen spielen heute und in der Zukunft eine entscheidende Rolle? x Welche Wettbewerbsstrategie soll verfolgt werden? Erste Ansatzpunkte für eine Prozessidentifikation können z.B. sein (Schmelzer, Sesselmann 2007, S. 124): x x x x x x x x

Stärken und Schwächen einzelner Prozessaktivitäten, Qualitätsziele, Kundenerwartungen, Identifikation von Mehrfacharbeiten Häufige Stellen-/Abteilungswechsel im Ablauf Liege-/Wartezeiten Gesamtdurchlaufzeit sowie Medien- und Systembrüche (Mehrfacheingaben von Daten).

Bei der Identifizierung von Geschäftsprozessen kann grundsätzlich top-down oder bottom-up vorgegangen werden (vgl. Speck, Schnetgöke 2003, S. 195 ff., Schmelzer, Sesselmann 2007, S. 121 ff.). Top-Down-Ansatz Der Top-down-Ansatz (Schmelzer, Sesselmann 2007, S. 121 ff.) geht von der Unternehmensstrategie aus, d.h. die in der Unternehmensstrategie definierten Geschäftsfelder, Kundengruppen sowie Kundenanforderungen bilden zusammen mit der Wettbewerbsstrategie und den Kernkompetenzen des Unternehmens den Aus-


19

gang für die Prozessidentifizierung. Es wird abgeleitet, welche Geschäftsprozesse zur Erreichung der Unternehmensziele benötigt werden, und wie diese abzugrenzen sind. Beim Top-down-Ansatz werden daher zunächst die primären Geschäftsprozesse bzw. Kernprozesse und ihre Teilprozesse identifiziert. Anschließend folgt die Festlegung der sekundären Geschäftsprozesse, die sich an den Leistungsanforderungen der primären Geschäftsprozesse orientieren. Die weitere Aufteilung in Prozessschritte, Arbeitsschritte und Aktivitäten ist späteren operativen Planungsschritten vorbehalten. Das Ergebnis des Top-down-Vorgehens ist schließlich ein Sollkonzept der Geschäftsprozesse. Bottom-up-Ansatz Der Bottom-up-Ansatz (Schmelzer, Sesselmann 2007, S. 122) geht dagegen von den jeweiligen Aktivitäten auf der untersten Prozessebene sowie der bestehenden Funktionsorganisation aus. Einzelne Prozessaktivitäten werden hierbei nach ablauf-, informations- oder auch kostenrechnungstechnischen Gesichtspunkten zu Teil- und Geschäftsprozessen in höheren Prozessebenen gebündelt. Es wird zunächst kein gezielter Bezug zur Unternehmensstrategie und zu den Kunden hergestellt. Das Vorgehen beim Bottom-up-Ansatz führt primär dazu die Ist-Situation im Unternehmen abzubilden. In der Praxis hat sich eher der Top-down-Ansatz bei der Identifizierung von Geschäftsprozessen bewährt, da dessen Ergebnisse i.d.R. strategiekonformer und überschneidungsfreier sind. Zudem lassen sich diejenigen Geschäftsprozesse, die eine wichtige Verbindung zu den Kunden und zur Unternehmensstrategie haben aber auch Aktivitäten ohne direkten Kundennutzen und Wertorientierung besser aufdecken. Die Gefahr ist zudem geringer, auf dem Bestehenden zu beharren oder sich sogar im Detail zu verlieren. Als Ausgangsdaten für die Identifizierung von Geschäftsprozessen werden insbesondere Informationen zu Zielmärkten und Kundengruppen, Kundenanforderungen, -bedürfnissen und -erwartungen, zur Wettbewerbsstrategie, den Kernkompetenzen, kritischen Erfolgsfaktoren, Stärken und Schwächen des Unternehmens, Unternehmenszielen sowie zu den Zielmärkten benötigt. 2.6.1.2 Entwicklung einer Prozessvision Das Vorgehen in dieser Phase folgt häufig dem Leitsatz: ”Alles was der Kunde nicht honoriert, ist Verschwendung”. Bei der Entwicklung einer Prozessvision ist daher folgendes zu berücksichtigen (Schmelzer, Sesselmann 2007, S. 91 f. und S. 462 ff.): x Der Leitgedanke einer Prozessvereinfachung (”keep it simple”) ist hilfreich und sollte Beachtung finden. x Transport- und Liegezeiten sowie die Kapazitätsauslastung bieten Ansätze zur Neugestaltung.

20


x Der Einsatz von Simulationsinstrumenten zur Entwicklung einer Prozessvision ist hilfreich, da z.B. statische Warteschlangenuntersuchungen u.U. dazu führen, dass Engpässe nur lokal abgebaut werden und in einem anderen Prozessabschnitt zu neuen Engpasssituationen führen. x Es sollte eine Durchsicht der Modellierungsergebnisse auf wertschöpfende Tätigkeiten hin erfolgen. Dabei sind semantische Auffälligkeiten zu beachten: z.B. können Formulierungen wie Eingabe, Konvertierung und Kontrolle auf mögliche Medienbrüche oder nicht wertschöpfende Tätigkeiten hinweisen, die auf deren Sinnhaftigkeit untersucht werden sollten. x Die Neugestaltung sollte bei mengenmäßig häufigen oder personalintensiven Prozesssegmenten ansetzen. x Die Möglichkeit der Funktionsintegration durch den Einsatz von Informationstechnik sollte untersucht werden. x Es sollte auch untersucht werden, welche Tätigkeiten von anderen besser oder kostendeckender durchgeführt werden können; sind beispielsweise bestimmte Tätigkeiten erste Outsourcing- oder Verlagerungskandidaten? x Elemente der Qualitätskontrolle sollten in den Prozess integriert werden. x Es sollte ein Vergleich mit Referenzprozessen (Best Practices) vorgenommen werden.

2.6.2 Detailmodellierung der Ist-Prozesse Gegenstand dieser Phase (Eicker et al. 2007, S. 24 ff.) ist das Zusammenfassen der Geschäftsprozesse eines Unternehmens zu einem Ist-Modell mit dem Ziel, verschiedene Schnittstellen zwischen den einzelnen Prozessen zu identifizieren sowie einen besseren Einblick in deren Komplexität zu erhalten (Allweyer 2005, S. 129). Die innerbetrieblichen Abläufe in einem Unternehmen werden dabei fachspezifisch dargestellt. Ein Ist-Modell kann dabei auf verschiedene Art und Weisen dokumentiert werden (Allweyer 2005, S. 130, Eicker et al. 2007, S. 25 ff.): x x x x

Tabellarische Darstellung, Textuelle Beschreibung, Grafische Prozessmodelle ohne Verwendung einer bestimmten Notation, grafische Modelle auf Basis einer bestimmten Notation.

Welche Modellierungsform und Dokumentation letztendlich ausgewählt wird, hängt von dem zu verfolgenden Zweck und der jeweiligen Zielsetzung ab (Allweyer 2005, S. 130).


21

2.6.3 Validierung und (Re-)Engineering Um vorliegende Geschäftsprozesse zu verbessern oder neue Geschäftsprozesse zu gestalten (Business Process (Re-)engineering bzw. Prozessrestrukturierung), lassen sich folgende prinzipielle Vorgehensweisen (vgl. Abb. 2.2) berücksichtigen (Jarz 2003, S. 11 ff., Abts, Mülder 2010, S. 254): x Änderung der Reihenfolge: Eine Reihenfolgeänderung kann zu Effizienzsteigerungen des Prozesses führen, falls vorher durch eine bestehende Abteilungsstruktur Einschränkungen bestanden haben. x Vermeidung von Schleifen und Rücksprüngen: Aktivitäten sollten nicht wiederholt werden müssen, wenn erst in einem späteren Schritt ein Problem festgestellt wird. x Einfügen eines Vorgangs: Zur Verbesserung der Effizienz des gesamten Geschäftsprozess kann im Einzelfall das Einfügen eines weiteren Vorgangs beitragen. x Weglassen von Vorgängen: Nicht wertschöpfende Tätigkeiten wie Doppelarbeiten oder Mehrfacherfassungen usw. sollten entfallen. x Überlappung: Ein Vorgang wird bereits gestartet, bevor der vorhergehende Vorgang beendet ist. Zielsetzung hierbei ist die Durchlaufzeitminimierung. x Zusammenfassen von Vorgängen: Der Vorteil des Zusammenfassens von Vorgängen ist, dass weniger Schnittstellen vorhanden sind und somit auch Medienbrüche vermieden werden können. x Parallelisierung: Hierbei werden zwei Vorgänge gleichzeitig ausgeführt, um den Geschäftsprozess zu beschleunigen. Es kann aber nicht beliebig parallel gearbeitet werden, z.B. wenn ein Mitarbeiter auf die Ergebnisse eines anderen Mitarbeiters angewiesen ist. x Standardisierung: Hierbei werden durch generelle Regeln die Geschäftsprozesse beschleunigt, da dokumentiert ist, wie jeweils vorgegangen werden soll. Des Weiteren sind die Ressourcenzuweisungen eindeutig geregelt. Zu beachten ist, dass durch "Überstandardisierung" auch ein Flexibilitätsverlust entstehen kann. x Komplexitätsreduzierung: Heute führt vor allem die Variantenvielfalt zu steigender Komplexität. Es ist jedoch möglich Komplexität durch mehr Personal oder EDV-Einsatz in den Griff zu bekommen. x Automatisierung: Vorgänge lassen sich durch EDV-Einsatz automatisieren. Dies kann eine weitere Fehlerreduzierung und Zeitersparnis bewirken. x Abbau von Beständen: Hohe Bestände verdecken häufig Probleme. Oft wird mit hohen Sicherheitsbeständen, hohen Ausschussfaktoren, großen Losen geplant, um Risiken möglichst gering zu halten.

22


Ist-Ablauf

A

Beschleunigung

A

Zusammenlegung

A+B

Ergänzung

A

B1

Neue Reihenfolge

B

A

C

Verbesserte Vorgangsschritte

A

B+

C+

Wegfall von Vorgangsschritt

A

C

Automatisieren A

B B

C C

B

Parallelisieren

B2

C

C

B A

Auslagerung

C

C

A

C B extern

Abb. 2.2: Möglichkeiten der Prozessrestrukturierung (Abts, Mülder 2010, S. 254, Schmelzer, Sesselmann 2007, S. 87, Jarz 2003, S. 11 ff.)

Praxisbeispiel Dell Computer ("Business Process Reengineering") Ein Beispiel für das Reengineering von Geschäftsprozessen lieferte Dell Computer, ein US-amerikanischer Hersteller von Computer-Hardware: Funktionen, die vorher Groß- und Einzelhandel durchführten, wurden seit 1996 durch Ausbau des Direktvertriebs der Computer-Hardware über das Internet ersetzt. Im Jahr 2000 betrugen die Tagesumsätze über den InternetVerkauf bereits 5 Millionen US-Dollar. Quelle: http://de.wikipedia.org/wiki/Dell

2.6.4 Implementierung der Soll-Prozesse Im Bereich der Prozessimplementierung sollten entsprechende organisatorische Maßnahmen zur Anwendung kommen, um die in der voran gegangenen Phase entworfenen Prozesse in geeigneter Weise umsetzen zu können (Eicker et al. 2007, S. 17 ff.). Hierbei kann bspw. das Change Management zum Einsatz kommen, welches u.a. die Vorbereitung und erfolgreiche Umsetzung von Veränderun


23

gen in Geschäftsprozessen umfasst. Voraussetzung für ein erfolgreiches Change Management ist die Motivation der an den Veränderungsprozessen beteiligten Mitarbeiter (Allweyer 2005, 92 f.). Die Implementierung neuer Informationssysteme in die bestehende System- und Prozesslandschaft sowie deren Anpassung an die strategischen Unternehmensziele und vorhandenen Prozesse stellen dabei häufig eine besondere Herausforderung dar. Nach der vorher erfolgten Analyse der Ist-Modelle und der Schwachstellen, folgt in dieser Phase die Modellierung der Sollprozesse. Mit einer Sollprozesserstellung sollten dabei folgende sowohl innen- als auch außengerichtete Erwartungen verknüpft sein: Kosteneinsparungen, Arbeitsablaufstraffungen, Bearbeitungszeitverkürzungen, Verbesserung der Prozessqualität, Stärkung der Kundenbeziehungen oder auch eine Vergrößerung der Marktanteile (Speck, Schnetgöke 2003, S. 191). Das Ergebnis des Sollprozess-Entwurfs „ist die Entwicklung neuer, verbesserter Geschäftsprozesse“, wobei sich die Gliederung der Prozesse „nicht an den Ist-Prozessen, sondern an den tatsächlich benötigten Leistungen orientieren soll“ (Allweyer 2005, S. 261 f.). Als Ausgangsbasis der Sollprozesserstellung dienen neben der Analyse der Ist-Modelle auch die strategischen Unternehmensziele. Die Sollprozessmodellierung der Kernprozesse baut auf den Ergebnissen des strategischen Prozessmanagements auf, da dort bereits die zu erbringenden Leistungen festgelegt wurden. Die benötigten Supportprozesse sowie die Teilaktivitäten auf den unterschiedlichen Prozessebenen werden jeweils aus den zu erbringenden Leistungen abgeleitet (Allweyer 2005, S. 263). 2.6.4.1 Organisatorische Implementierung In dieser Phase werden hauptsächlich die organisatorische Komponente und der Einfluss der (Ablauf-)Organisation auf die Geschäftsprozesse untersucht. Hierbei werden Schwachstellen identifiziert, die die Bereiche der Entscheidungsträger und Prozessverantwortlichen betreffen. Es kann in dieser Phase analysiert werden, ob eventuell zu viele Hierarchieebenen existieren, die die Eigenverantwortlichkeit der Mitarbeiter einschränken oder sogar kontraproduktiv auf deren Motivation wirken und so Prozessaktivitäten verlängern oder deren Qualität mindern (Eicker et al. 2007, S. 28 ff). Die Untersuchung der Ist-Modelle auf Schwachstellen im Bereich der Ablauforganisation kann zu einer Verschlankung der Prozesslandschaft führen, indem überflüssige Prozessaktivitäten eliminiert werden (Eicker et al. 2007, S. 28 ff.). Weiterhin lassen sich möglicherweise Potenziale zur Reduzierung von Durchlaufzeiten identifizieren, d. h. es wird analysiert, ob Prozesse auch parallel ablaufen können (anstatt nacheinander) oder Durchlaufzeiten mithilfe eingesetzter Anwendungssysteme verringert werden können. Weiterhin kann in dieser Phase untersucht werden, ob die Auslastung der Mitarbeiter angemessen ist, und ob ggf. die Einführung von Anreizsystemen dazu beiträgt, die Motivation der Mitarbeiter noch weiter zu erhöhen (Schwegmann, Laske 2003, S. 179).

24


2.6.4.2 IT-Implementierung In dieser Phase wird das Ist-Modell dahingehend analysiert, ob ggf. Problemfelder in der IuK-Unterstützung der Bereiche der Aufbau- und Ablauforganisation des Unternehmens bestehen (Schwegmann, Laske 2003, S. 177, Eicker et al. 2007, S. 28). Hierzu gehören z.B. das Fehlen von notwendigen Funktionalitäten in den vorhandenen Anwendungssystemen oder eine unzureichende, redundante Datenhaltung innerhalb verschiedener Anwendungssystem-Landschaften. Diese kann zu erhöhtem Aufwand bei der Dateneingabe, zu Medienbrüchen, zu einer Erhöhung der zur Verfügung stehenden Schnittstellen oder sogar zu inkonsistenten, fehlerhaften Datenbeständen und mangelhafter Datenqualität führen. Weitere Problembereiche sind bspw. eine mangelnde Bedienbarkeit oder die Verwendung inkompatibler Schnittstellen zwischen den eingesetzten Informations- und Kommunikationssystemen (Schwegmann, Laske 2003, S. 177 f.). Zur Unterstützung der Geschäftsprozesse werden häufig Enterprise-ResourcePlanning (ERP)-Systeme eingesetzt, die „alle wesentlichen betrieblichen Bereiche umfassen“ (Allweyer 2005, S. 306 f.). Die Verbreitung von ERP-Systemen in den Unternehmen ist vergleichsweise hoch, da diese Systeme eine Vielzahl der durch die Durchführung der Geschäftsprozesse erforderlichen Funktionalitäten abdecken (Allweyer 2005, S. 312).

2.6.5 Verifikation und Abnahme Eine Möglichkeit, die erstellten Prozessmodelle in dieser Phase zu analysieren, ist die Methode des Benchmarking (Schwegmann, Laske 2003, S. 183, Eicker et al. 2007, S. 34 ff.). Hierbei werden Kennzahlen der zu analysierenden Prozesse ermittelt und mit bereits erhobenen Kennzahlen anderer erfolgreicher Prozesse (Best Practices) verglichen. Hierdurch lassen sich Abweichungen leichter erkennen und durch die Abstützung auf Best Practices oder Referenzprozesse besser beheben (Schwegmann, Laske 2003, S. 183). Durch Simulationen kann in dieser Phase bspw. untersucht werden, ob die erstellten Prozesse die vorher festgelegten Kriterien erfüllen, um in die bestehende Prozesslandschaft des Unternehmens übertragen werden zu können oder ob eine umfassende Überarbeitung der SollProzessmodelle notwendig ist, d.h. vorherige Phasen des GPM-Lebenszyklus neu durchlaufen werden müssen.

2.6.6 Prozess-Controlling Sobald die Implementierung der Prozesse abgeschlossen ist, kann deren kontinuierliches Controlling (Monitoring) beginnen (Eicker et al. 2007, S. 36 f.). Ziel

Grundsätze der ordnungsgemäßen Prozessmodellierung

25

hierbei ist es, Aussagen darüber zu treffen, wie erfolgreich die Umsetzung der Prozessmodelle verlaufen ist und ob bzw. inwiefern die zu erfüllenden Zielkriterien und Sollwerte erreicht werden konnten. Ist dies nicht der Fall, so ist zu ermitteln, aus welchen Gründen die Prozesse die Erwartungen und Sollwerte verfehlt haben. Die Ermittlung der Prozesskennzahlen kann sowohl manuell erfolgen als auch durch informationstechnische Systeme unterstützt werden (Allweyer 2005, S. 387 f.). Eine Möglichkeit der Auswertung stellen Business-Intelligence-Systeme dar, die in der Lage sind, umfangreiche Datenmengen in einem Data Warehouse zu integrieren und diese dann entsprechend zu analysieren und auszuwerten. Das Geschäftsprozessmanagement ist, wie bereits angesprochen, ein kontinuierlicher Verbesserungsprozess. Beispielhaft für ein mögliches Konzept zur Umsetzung eines ständigen Verbesserungsmanagements sei an dieser Stelle das japanische Managementkonzept Kaizen genannt. Bei Kaizen ist der Prozessgedanke in allen Ebenen des Unternehmens verankert. Grundgedanke und Ziel dieses Managementkonzepts sind kleine und schnell umzusetzende Veränderungen (d.h. keine Prozessinnovationen oder komplexere Restrukturierungsmaßnahmen). Mitarbeiter werden dazu ermuntert und geschult, Verbesserungsvorschläge einzubringen. Das Kaizen Konzept verhilft u.a. zu einer unternehmensweiten Auseinandersetzung mit Prozessverbesserungen und fördert zudem die Anerkennung der durch die Mitarbeiter eingebrachten Verbesserungsvorschläge (Allweyer 2005, S. 407 ff.).

2.7 Grundsätze der ordnungsgemäßen Prozessmodellierung Aspekte der Modellkonstruktion Nach vom Brocke sind folgende vier Aspekte bei der Konstruktion von (Prozess-) Modellen zu berücksichtigen (vom Brocke 2003, S. 52 ff.): 1. Modellbezogener Aspekt: Im Rahmen dieses Aspekts steht die verwendete Notation zur Darstellung sowie die Abgrenzung der Anwendungsdomäne im Vordergrund. 2. Methodenbezogener Aspekt: Im Rahmen dieses Aspekts steht die Auswahl geeigneter Problemlösungs- und Darstellungsmethoden im Vordergrund. 3. Organisationsbezogener Aspekt: Im Rahmen dieses Aspekts steht die Definition der an der Modellkonstruktion beteiligten Akteure sowie Vorgehensweisen (Phasen) im Vordergrund. 4. Technologiebezogener Aspekt: Im Rahmen dieses Aspekts steht die Auswahl von technischen Werkzeugen zur Konstruktion der (Prozess-)Modelle sowie die verwendeten Standards im Vordergrund. Abb. 2.3 stellt die zu berücksichtigenden Aspekte bei der Konstruktion von Prozessmodellen und ihre Beziehungen zueinander dar.

26

Geschäftsprozessmanagement und Prozessmodellierung Referenzmodellierung

Technologieorientierung

Methodenorientierung

Sprache

Namenskonvention

Layout

Modellorientierung

Notation

Organisationsorientierung

MetaModell

ProjektManagement Metriken

Standards

Akteure

Phasen

Werkzeuge «unterstützt»

Modellierer

Modellnutzer

Abb. 2.3: Aspekte der Modellkonstruktion (vom Brocke (2003), S. 52 ff.)

Methodik der Prozessmodellierung Eine Methodik zur Geschäftsprozessmodellierung umfasst eine Modellierungssprache, eine Modellierungstechnik sowie idealtypischerweise ein SoftwareWerkzeug, das die softwaretechnische Umsetzung unterstützt, und ein Vorgehensmodell, das Empfehlungen und Richtlinien zur Anwendung der Modellierungsmethodik gibt. In der Literatur wird zwischen Methode und Methodik differenziert. Die Methodik beschreibt eine planmäßige und wiederholbare Art und Weise des Vorgehens zur Erlangung wissenschaftlicher oder praktischer Ergebnisse. Der Begriff Methodologie wird zwar oftmals als Synonym zu dem Begriff Methodik verwendet, wird jedoch auch als Bezeichnung für die Theorie wissenschaftlicher Methoden (Methodenlehre) verwendet (Petrasch, Meimberg 2006, S. 41). Abb. 2.4 illustriert die Bestandteile einer Methodik im Sinne einer systematischen Vorgehensweise) zur Geschäftsprozessmodellierung, welche verschiedene Techniken, eine Modellierungssprache sowie ein Vorgehensmodell zur strukturierten Anwendung der einzelnen Techniken in einem strukturierten Prozess umfasst. Den einzelnen Aktivitäten des Vorgehensmodells werden im Rahmen einer Methodik i.d.R. eine oder mehrere Rollen (d.h. Verantwortliche) zugeordnet. Zur Qualitätssicherung werden häufig im Rahmen einer Methodik auch Metriken bzw. Kennzahlen oder sogar Reifegradmodelle zur Verfügung gestellt, die die Qualität eines im Rahmen der Methodik entwickelten Prozessmodells messen.

Grundsätze der ordnungsgemäßen Prozessmodellierung

27

Abb. 2.4: Bestandteile und Konzept einer Methodik zur Geschäftsprozessmodellierung (In Anlehnung an Sturm, Shehory 2003, S. 61)

Grundsätze ordnungsgemäßer Prozessmodellierung Für die Geschäftsprozessmodellierung wurden von verschiedenen Autoren Kriterien zur Beurteilung der Güte von Prozessmodellen sowie Empfehlungen für eine ordnungsgemäße Modellerstellung formuliert. Die Grundsätze ordnungsgemäßer Modellierung (GoM) (Becker et al. 1995, Schütte 1998, S. 111 ff.) umfassen sechs Prinzipien. Die ersten drei Prinzipien definieren notwendige Voraussetzungen für die Qualität von Prozessmodellen (Korrektheit, Relevanz und Wirtschaftlichkeit), die anderen drei Prinizipien optionale Kriterien (Klarheit, Vergleichbarkeit und systematischen Aufbau). Die Grundsätze ordnungsmäßiger Modellierung (GoM) von Schütte (Becker et al. 1995, Schütte 1998, S. 111 ff.) berücksichtigen hierbei sowohl statische als auch dynamische Aspekte von Modellen. Schütte hat diesbezüglich einen dreidimensionalen Würfel mit den Dimensionen Anwendungsgebiet, Abstraktionsgrad sowie Grundsätze einer ordnungsmäßigen Modellerstellung entwickelt. In Tabelle 2.2 werden die Grundsätze erläutert (Schütte 1998, S. 119 ff., Schlagheck 2000, S. 58 ff., Ahlemann 2006, S. 82 ff., vom Brocke, Buddendick 2004, S. 22 ff.):

28


Tabelle 2.2: Qualitätskriterien ordnungsmäßiger Modellierung (Schütte 1998, S. 119 ff., Schlagheck 2000, S. 58 ff.) Grundsatz

Erläuterung

Konstruktionsadäquanz

Die Konstruktionsadäquanz eines Modells ist ein Ausdruck für die Modellqualität aus Sicht der Modellbenutzer. Ein Modell besitzt für Modellnutzer insbesondere dann eine hohe Qualität, wenn das Modell einen Problembereich im Hinblick auf die Zielsetzung angemessen abbildet.

Sprachadäquanz

Die Sprachadäquanz eines Modells ist ein Ausdruck für eine zweckadäquate und syntaktisch richtige Darstellung durch die gewählte Modellierungssprache. Die Zweckmäßigkeit der eingesetzten Sprache lässt sich anhand der Verständlichkeit, des Formalisierungsgrads und der verfügbaren Darstellungstechniken (Sprachumfang) messen.

Systematischer Aufbau

Mit dem Qualitätskriterium des systematischen Aufbaus von Modellen ist die Forderung nach einer Systematisierung der Teilmodelle in verschiedenen Abstraktionsebenen und Sichten verknüpft, so dass dadurch die Komplexität des Problembereichs bzw. die Modellkomplexität reduziert werden kann. Bei der Modellierung sozio-technischer Systeme wird i.d.R. zumindest zwischen einer Struktur- und Verhaltenssicht differenziert.

Vergleichbarkeit

Die Vergleichbarkeit eines Modells ist dadurch bestimmt, inwieweit es sich zu anderen Modellen derselben Problemdomäne in Beziehung setzen lässt, so dass die Inhalte von jeweils 2 Modellen auf Deckungsgleichheit untersucht werden können. Dies setzt voraus, dass in unterschiedlichen Sprachen abgebildete Modelle einen ähnlichen Sprachumfang aufweisen und sich die Modellierungssprachen (mit Hilfe von Meta-Modellen) ineinander überführen lassen.

Klarheit

Die Klarheit eines Modells ist durch Kriterien wie Übersichtlichkeit, Lesbarkeit und Strukturiertheit bestimmt und ein Maß für die Anschaulichkeit (Transparenz) eines Modells.

Wirtschaftlichkeit Die Wirtschaftlichkeit eines Modells bestimmt als Nebenbedingung alle anderen Qualitätskriterien. Modellierungsentscheidungen sind daher im Hinblick auf deren ökonomische Auswirkungen sowohl auf die Entwicklung als auch auf die Nutzung von Modellen zu treffen.

2.8 Modellierungssprachen Zur Prozessmodellierung können unterschiedliche formale oder semiformale Modellierungssprachen verwendet werden, die zumeist auf einer grafischen Notation basieren. Populäre Beispiele und in der Praxis weit verbreitete Modellierungssprachen sind die Unified Modeling Language (UML), 1996 von Grady Booch, Ivar Jacobson und James Rumbaugh vorgeschlagen und unter der Leitung der OMG (Object Management Group) laufend überarbeitet, Ereignisgesteuerte Prozessketten (EPK), 1992 von einer Arbeitsgruppe unter der Leitung von August-Wilhelm

Modellierungssprachen

29

Scheer (Keller, Nüttgens, Scheer 1992) entwickelt sowie Petrinetze (Petri 1962). (Gadatsch 2005) unterscheidet zwischen skriptbasierten und diagrammbasierten Methoden zur Geschäftsprozessmodellierung (vgl. Abb. 2.5). Skriptbasierte Sprachen ermöglichen eine formale Beschreibung von Prozessmodellen mit einer an Programmiersprachen angelehnten Notation (Gadatsch 2005, S. 67). Diagrammbasierte Methoden

Datenflussorientiert

Kontrollflussorientiert

IDEF-Diagramme

Petri-Netze

Erweiterte EPK

Datenflussdiagramme (SSA)

Struktogramme

Aufgabenkettendiagramm (PROMET)

Flussdiagramme (SADT)

Swimlanediagramme

Folgestruktur und Folgeplan

GPM-Diagramme

Objektorientiert

Activity Diagram (UML)

Vorgangsereignisschema (SOM)

Use Case Diagram (UML)

StatechartDiagramm

Interaktionsdiagramm (SOM)

ActivitychartDiagramm

Objektorientierte EPK

Abb. 2.5: Diagrammbasierte Methoden zur Geschäftsprozessmodellierung (Quelle: Gadatsch 2005, S. 67)

Die diagrammbasierten Methoden lassen sich in objektorientierte, datenflussorientierte und kontrollflussorientierte Methoden einteilen. Bekanntester Vertreter der kontrollflussorientierten Methoden sind die Ereignisgesteuerten Prozessketten (EPKs). Objektorientierte Methoden auf Basis der UML finden zunehmend Eingang in die Geschäftsprozessmodellierung. Eine weitere Methode zur Geschäftsprozessmodellierung ist die Business Process Modeling Notation (BPMN) (OMG 2008). Bei der maschinell lesbaren Spezifikation von Geschäftsprozessen kommen in den letzten Jahren zunehmend auch XML-basierte Sprachen zum Einsatz. Die wichtigsten sind die Business Process Modeling Language (BPML), die Business Process Execution Language (BPEL) sowie die XML Process Definition Language (XPDL) der Workflow Management Coalition (WfMC).

2.8.1 EPK Zur Beschreibung und Analyse von Geschäftsprozessen wird häufig die von Scheer entwickelte Methodik und Notation der EPKs eingesetzt, die auch ein zentraler Bestandteil des SAP-Konzepts zur Organisations- und Prozessmodellierung sowie der SAP-Referenzmodelle sind. Die Methodik wurde im Rahmen der Archi-

30


tektur Integrierter Informationssysteme (ARIS) entwickelt und ist dementsprechend auch wesentliches Element des ARIS-Konzepts. Die Methodik und Notation der Ereignisgesteuerten Prozesskette (EPK) wurde 1992 zur (Re-)Dokumentation und semiformalen Beschreibung von Geschäftsprozessen an der Universität des Saarlandes unter Leitung von Scheer in Zusammenarbeit mit der SAP AG entwickelt (Keller, Nüttgens, Scheer 1992). Die Methodik ist zentraler Bestandteil einer Vielzahl von Referenzmodellen und Grundlage verschiedener modellgetriebener Ansätze für ein werkzeuggestütztes Geschäftsprozessmanagement. Sie ist aufgrund ihrer anschaulichen Repräsentation und der durchgängigen Werkzeugunterstützung in der Praxis vergleichsweise weit verbreitet. Ereignisgesteuerten Prozessketten stellen die zeitlich-logischen Abhängigkeiten von Ereignissen und Funktionen dar. Funktionen werden dabei von Ereignissen ausgelöst, die wiederum definieren, dass ein Zustand eingetreten ist (z.B. Kundenauftrag eingetroffen). In einer EPK wechseln sich die Modellierungselemente Funktionen mit Ereignissen ab, wobei eine EPK jedoch immer mit einem Ereignis beginnt und endet. Die zentralen Konstrukte zur Modellierung eines Kontrollflusses mit Hilfe von ereignisgesteuerten Prozessketten sind (Jarz 2003, S. 23 ff.): x Ereignisse: Zustandsübergänge und Bedingungen mit einem Zeit-, Daten-, Bearbeitungs-, Benutzer- oder Nachrichtenbezug. Ein mögliches Startereignis einer EPK ist »Auftrag ist eingetroffen« und die dadurch angestoßene Aktivität könnte »Auftrag prüfen« sein. Die EPK könnte mit dem Ereignis »Auftrag ist ausgeführt« enden. Das Symbol für ein Ereignis ist sechseckig. Bei Ereignissen wird das zu kennzeichnende Objekt mit einem Verb im Partizip Perfekt verbunden (z. B. Kundenauftrag (ist) angelegt). Ereignisse besitzen genau einen eingehenden und einen ausgehenden Pfeil. Eine Ausnahme von dieser Regel bilden Anfangsereignisse (hier geht keine gerichtete Kante ein) sowie Endereignisse (hier geht kein Pfeil hinaus). Sollten mehrere Ereignisse zu einer Funktion führen, dann müssen Konnektoren (bspw. UND) vorgeschaltet werden. Da ein Ereignis über keine Entscheidungsgewalt verfügt und Ereignisse im Unterschied zu den "aktiven" Funktionen einen passiven Charakter haben, darf ein Ereignis nicht über einen OR- oder einen XOR-Konnektor zu zwei Funktionen gesplittet werden. x Funktionen: Aufgaben bzw. Tätigkeiten zur Unterstützung eines oder mehrerer Unternehmensziele. Funktionen gehen mit einem Zeit- und Ressourcenverbrauch einher. Ressourcen (bspw. Produktionsfaktoren, Informationssysteme, Anwender) können den jeweiligen Funktionen zugeordnet werden. Funktionen (z.B. „Auftrag prüfen“) werden durch Rechtecke mit abgerundeten Kanten symbolisiert. Zur Bezeichnung der Funktionen wird i.d.R. das jeweilige Objekt der Bearbeitung und ein Verb im Infinitiv verwendet (z. B. Kundenauftrag anlegen).


31

Verknüpfungsoperatoren (Konnektoren): Dienen der Verknüpfung von Ereignissen und Funktionen und zum Aufspalten und Vereinigen des Kontrollflusses. Sie sind somit die grafische Abbildung komplexer Geschäftsregeln. Als Konnektoren stehen AND-, OR- bzw. XOR-Operatoren zur Verfügung. Konnektoren werden jeweils in einem kleinen Kreis mit dem entsprechenden Symbol dargestellt werden. x Kontrollflusskanten: Gerichtete Pfeile zwischen Ereignissen, Funktionen und Verknüpfungsoperatoren. Der Kontrollfluss einer EPK ist ein gerichteter und zusammenhängender Graph, dessen Knoten Ereignisse, Funktionen und Verknüpfungsoperatoren darstellen. x Prozesswegweiser: Hinweise auf andere Prozesse, welche durch ein Rechteck symbolisiert werden, hinter dem sich ein Sechseck verbirgt.

2.8.2 Erweiterte EPK Erweiterte ereignisorientierte Prozessketten (eEPK) stellen zusätzliche Prozesselemente zur Modellierung bereit. Hierzu zählen Organisationseinheiten, die eine bestimmte Funktion ausführen, Input- und Outputeinheiten wie bspw. Dokumente, Dateien, Datenbanken oder auch Anwendungssysteme, die für die Ausführung einer Funktion benötigt werden, aus denen Informationen geladen oder in die Informationen gespeichert werden können. Im Rahmen der eEPK ist es somit zusätzlich möglich Datenflüsse, Organisationseinheiten oder Anwendungssysteme mit abzubilden. Zur erweiterten Ereignisgesteuerten Prozesskette (eEPK) gehören die folgenden weiteren Konstrukte (Gadatsch 2005, S. 137, S. 160-162; Jarz 2003, S. 25): x Organisationseinheiten: Sie stellen Rollen oder Personen dar, die für den Prozess verantwortlich sind. Beispiele für Organisationseinheiten sind „Kunde“ oder „Produktionsabteilung“. Organisationseinheiten werden durch eine Ellipse, die vor dem linken Rand eine senkrechte Linie enthält, symbolisiert. Organisationseinheiten, die in der Organisationssicht näher beschrieben werden (Organigramm), dienen zur Beschreibung der Gliederungsstruktur eines Unternehmens. x Informationsobjekte: Dokumente oder sonstige Datenspeicher (z.B. „Kundendatenbank“), die durch ein Rechteck symbolisiert werden. Informationsobjekte, welche in der Datensicht näher beschrieben werden (Entity-RelationshipModell), dienen zur Abbildung von Gegenständen der realen Welt. x Anwendungssysteme: Anwendungssysteme, welche in der Funktionssicht näher beschrieben werden (Anwendungstyp -Diagramm), dienen zur Unterstützung einzelner Geschäftsprozesse. x Prozesswegweiser: Prozesswegweiser dienen zur Verknüpfung von Teilprozessen.

32


Tabelle 2.3 zeigt die Notation des eEPK-Prozesskettendiagramms. Tabelle 2.3: eEPK-Symbole (Gadatsch 2005, S. 137, S. 160-162; Jarz 2003, S. 25) Symbol

Benennung

Bedeutung

Typ

Ereignis

Beschreibung eines eingetretenen Zustandes

Ereignisknoten

Funktion

Beschreibung der Transformation von einem Inputzustand zu einem anderen Outputzustand

Aktivitätsknoten

Logische Operatoren: „exklusives oder“ „oder“ „und“

Logische VerknüpfungsBedingungsknoten operatoren beschreiben die Verknüpfung von Ereignissen und Funktionen

Parallelisierung

Verzweigung in parallele Vorgänge

Verzweigungsknoten

Zusammenführung

Zusammenführen von parallelen Vorgängen

Verzweigungsknoten

Organisationseinheit

Beschreibung der Organisationsstruktur

Organisationsknoten

Informationsobjekt

Abbildung von Gegenstän- Aktivitätsknoten den der realen Welt

Anwendungssystem

Anwendungssysteme zur Prozessunterstützung (z.B. SAP R/3)

Aktivitätsknoten

Kontrollfluss

Zeitlich-logischer Zusammenhang von Ereignissen und Funktionen

Kontrollflusskante

Informationsfluss

Informationsfluss zu Funk- Datenflusskante tionen

Sachleistungsfluss

Räumlich-logischer ZuSachflusskante sammenhang von Sachleistungen

Zuordnung

Zuordnung von Ressourcen Zuordnungsbe/ Organisationseinheiten ziehungskante

Prozesswegweiser

Horizontale Prozessverknüpfung

Übergangsknoten


33

Abb. 2.6 verdeutlicht die Anwendung von EPK und eEPK an einem Beispiel. Strategisches Prozessmodell (Wertschöpfungskettendiagramm) Angebotsbearbeitung

Auftrag eingegangen

Auftragsbearbeitung

Schlankes Prozessmodell (EPK)

Faktura

Produktion

Anfragedaten

Versand

Auftrag eingegangen

Materialdaten Vertrieb Prüfung, ob ausführbar

Prüfung, ob ausführbar Kunde (extern)

SAP R/3 XOR

Auftrag ist ausführbar

XOR

Auftrag ist nicht ausführbar

Detailliertes Prozessmodell (eEPK)

Auftrag ist ausführbar

Auftrag ist nicht ausführbar

Abb. 2.6: Anwendungsbeispiel EPK und eEPK (Quelle: Gadatsch 2005, S. 144)

2.8.3 UML und die objektorientierte Geschäftsprozessmodellierung Eine weitere Notation zur Konstruktion von Geschäftsprozessmodellen ist die Unified Modeling Language (UML), die eine sehr starke Verbreitung gefunden hat und ein Quasi-Standard für die Modellierung objektorientierter Informationssysteme geworden ist. Auf eine detaillierte Einführung in UML und deren Entstehungsgeschichte wird an dieser Stelle verzichtet und stattdessen auf die umfangreiche Literatur zur UML verwiesen (vgl. stellvertretend für viele Oestereich 2001, Hitz et al. 2005). UML wurde von Grady Booch, James Rumbaugh und Ivar Jacobson entwickelt (Booch et al. 1999). UML ist eine Zusammenstellung mehrerer Darstellungstechniken nach dem objektorientierten Paradigma zur Informationsmodellierung. Derzeit ist die Version 2.1 aktuell, welche durch die Object Management Group (OMG) als neue Version angenommen wurde. UML 2.1 stellt 6 Diagrammtypen für die Modellierung von statischen Aspekten (Strukturdiagramme) und 7 Diagrammtypen für die Modellierung von dynamischen Aspekten (Verhaltensdiagramme) zur Verfügung. Für die Geschäftsprozessmodellierung sind die Sequenzdiagramme sowie die Aktivitäts- und Zustandsdiagramm der

34


UML von Bedeutung. Tab. 2.4 zeigt die für Aktivitäts- und Zustandsdiagramme in UML verwendete Notation. Tabelle 2.4: Symbole im UML-Aktivitäts- und Zustandsdiagramm (Jarz 2003, S. 32) Symbol

Benennung

Bedeutung

Startzustand

Markiert den Beginn eines Aktivitätsdiagramms und besitzt keine eingehenden Kontrollflüsse

Endzustand

Markiert das Ende eines Aktivitätsdiagramms und besitzt keine ausgehenden Kontrollflüsse

Aktionszustand

Kleinster Teil eines Ablaufs. Die darin ablaufende Aktivität ergibt eine Aktion, die eine Zustandsänderung des Systems bewirkt oder einen Wert zurückliefert

Subaktivitätszustand Verfeinerung durch Subaktivitäten. Zusammenfassung von mehreren Abläufen in einen Subaktivitätszustand. Kontrollfluss (Transition)

Zeitlich-logischer Zusammenhang von Aktionszuständen. Stellt meist ein Ereignis dar, das aus einem Aktionszustand hervorgeht

Objektfluss

Objekte werden als Eingabe oder Ausgabe einer oder mehrerer Aktivitäten angesprochen

Gabelung

Zeigt den Beginn eines parallelen Ablaufs (Nebenläufigkeit) durch den Synchronisationsbalken an

Vereinigung

Zeigt das Ende eines parallelen Ablaufs (Nebenläufigkeit) durch den Synchronisationsbalken an

Verzweigung

Zeigt den Beginn von einem oder mehreren alternativen Abläufen an

Zusammenführung

Zeigt das Ende von einem oder mehreren alternativen Abläufen an

Empfang eines Ereignisses

Zeigt den Empfang eines Ereignisses im Zuge einer Transition an

Senden eines Ereignisses

Zeigt das Senden eines Ereignisses im Zuge einer Transition an

Klasse / Objekt

Abbildung von Gegenständen der realen Welt bzw. deren Abstraktion auch in Form von Datenbeständen

Schwimmbahn (Ver- Zeigt den Bereich der Verantwortlichkeit einer antwortlichkeitsOrganisationeinheit an. Innerhalb der bereich) Schwimmbahn finden die Abläufe statt.

Der Parallelisierungsknoten teilt einen Ablauf in mehrere nebenläufige Abläufe auf. Hierbei gibt es genau einen eingehenden und beliebig viele ausgehende Kan-


35

ten. Der sog. Synchronisierungsknoten führt mehrere nebenläufige Aktivitäten zusammen, d.h. synchronisiert diese. Hierbei gibt es beliebig viele eingehende Kanten aber nur genau eine ausgehende Kante. Ein Zustand ist ein Ausdruck (z.B. Stereotyp, Eigenschaftswert oder freie Formulierung), der die möglichen Inhalte oder Reaktionsmöglichkeiten eines Modellelements auf Ereignisse spezifiziert. Eine Aktion ist eine (benutzerdefinierte) Aktivität zum lesenden bzw. schreibenden Zugriff auf Modellelemente (Objekte) sowie zum Aufruf anderen Verhaltens. Aktivitäts- und Zustandsdiagramme werden zur Darstellung des dynamischen Aspekts von Systemen verwendet, sind somit auch für Geschäftsprozessmodellierungen gut geeignet (Jarz 2003, S. 32 ff.). Ein Aktivitätsdiagramm ist ein Flussdiagramm, welches den Kontrollfluss von Aktivität zu Aktivität darstellt (Jarz 2003, S. 31). Mit Hilfe von Parallelisierungsknoten können im Aktivitätsdiagramm auch parallel ablaufende Vorgänge dargestellt werden. Die Zustandsübergänge werden auch als Kontrollflüsse bezeichnet. Zustandsübergänge stellen in der Regel auch Ereignisse dar. Abb. 2.7 zeigt ein Beispiel eines Aktivitäts- und Zustandsdiagramms in UMLNotation. Verantwortlichkeitsbereich (Schwimmbahn)

Kunde

Startzustand

Vertrieb

Lager

Angebot prüfen [abgelehnt] [else]

Artikel bestellen

Aktionszustand / Aktivität

Sequentielle Verzweigung

Zustandsübergang (Kontrollfluss, Transition)

Auftrag bearbeiten Gabelung (fork)

Artikel zusammenstellen

Objektfluss

a: Auftrag [in Arbeit]

Lieferung erhalten

Rechnung bezahlen

Kunden abrechnen

r: Rechnung [unbezahlt]

Auftrag versenden

Vereinigung (join)

a: Auftrag [in Arbeit]

Objekt Zustand

Auftrag schließen r: Rechnung [bezahlt]

Endzustand

Abb. 2.7: Beispiel eines Aktivitäts- und Zustandsdiagramms in UML-Notation (Quelle: Jarz 2003, S. 33)

36


2.8.4 Business Process Modelling Notation Die Business Process Modeling Notation (BPMN, engl. Modellierungsnotation für Geschäftsprozesse) ist eine weitere Modellierungsnotation zur grafischen Spezifikation von Geschäftsprozessen und Workflows. Tabelle 2.5: Elemente der BPMN-Notation (vgl. zur BPMN-Notation z.B. Allweyer 2008) Element Flow Objects : Knoten in einem Geschäftsprozessdiagramm Activities: Aktivitäten in einem Geschäftsprozessdiagramm Events: Ereignisse in einem Geschäftsprozessdiagramm

Connecting Objects: Verbindende Kanten in einem Geschäftsprozessdiagramm

Gateway: Entscheidungspunkte in einem Geschäftsprozessdiagramm Swimlanes: Bereiche zur Abgrenzung einzelner Akteure oder Systeme in einem Geschäftsprozessdiagramm

Artifacts: Objekte wie Data Objects (z.B. Dokumente), Groups (Zusammenfassungen von Objekten) und Annotations (Kommentare) in einem Geschäftsprozessdiagramm

Beispiel


37

Die BPMN wurde 2002 durch Stephen A. White, einem IBM-Mitarbeiter, entwickelt und im Juni 2005 durch die Object Management Group (OMG) zur weiteren Entwicklung übernommen. Seit 2006 ist BPMN ein offizieller Standard der OMG. Zu den grafischen Elementen der BPMN gehören die in Tabelle 2.5 aufgeführten Elemente (vgl. zur BPMN Allweyer 2008). Maschinell lesbare Prozessbeschreibungen der BPMN können zum Beispiel in der Business Process Execution Language (BPEL) oder in der XML Process Definition Language (XPDL), beides XML-basierte Sprachen für die Beschreibung von Prozessen, dargestellt werden. BPMN, BPEL und XPDL ergänzen sich wechselseitig, da BPEL und XPDL über eine maschinell lesbare Ausführungssemantik verfügen und das Speichern von grafischen BPMN-Diagrammen in einem maschinell lesbaren Format unterstützen.

2.8.5 Business Process Execution Language Die Business Process Execution Language (BPEL) ist eine XML-basierte Sprache zur Geschäftsprozessmodellierung, welche im Jahr 2002 von IBM, BEA Systems und Microsoft eingeführt wurde. BPEL wird zur Beschreibung von so genannten Webservice-Orchestrierungen und Webservice-Choreographien verwendet, welche ebenfalls in Form von Webservices bereitgestellt werden. WebserviceOrchestrierung definiert dabei, welche Funktionen in welcher Reihenfolge ausgeführt werden (interne Sicht auf Geschäftsprozesse). Webservice-Choreographie definiert wiederum die Interaktion zwischen Webservices (externe Sicht auf Geschäftsprozesse). Webservice-Choreographie beschreibt somit den Nachrichtenaustausch und das Zusammenspiel mehrerer beteiligter Parteien. Eine direkte Interaktion mit Anwendern wird jedoch von BPEL nicht unterstützt. BPEL-Prozesse kommunizieren ausschließlich mit anderen Webservices, die somit als Schnittstelle zu den Anwendern fungieren. BPEL selbst stellt eine BasisSpezifikation dar, auf der verschiedene andere Notationen aufgebaut werden können. Weitere "Dialekte" sind BPELJ und WS-BPEL4People. Mit BPELJ wird das Ziel verfolgt, dass einzelne Aktivitäten Java-Code enthalten können, um die Ausführung von Prozessen zu beschleunigen. Dies macht die Prozesse selbst jedoch wieder abhängig von der Programmiersprache Java. IBM hat zusammen mit SAP und anderen Unternehmen die Modellierungssprache BPEL4People entwickelt, welche als Erweiterung von BPEL auch eine direkte Interaktion von Anwendern unterstützen soll. Der Standard BPEL ermöglicht selbst keine graphische Darstellung der modellierten Prozesse. Hierfür wird häufig auf die Business Process Modeling Notation (BPMN) zurückgegriffen, welche eine Beschreibung für die Abbildung von BPMN nach BPEL enthält. Allerdings entsprechen die Möglichkeiten von BPMN nicht exakt den Möglichkeiten der BPEL. So können mit BPMN Prozesse modelliert werden, die sich mit Hilfe von BPEL nicht direkt umsetzen lassen.

38


2.9 Geschäftsprozessmodellierung mit WS-BPEL

2.9.1 Einleitung Unter Webservices versteht man lose gekoppelte verteilte Dienste, die über Internet-basierte Protokolle sowie XML-Nachrichten in einer sog. Service-orientierten Architektur veröffentlicht, lokalisiert und dynamisch aufgerufen werden können (Hansen, Neumann 2005, S. 804). WS-BPEL ist Teil der sogenannten Webservice-Spezifikationen und definiert eine Grammatik für die Beschreibung des Verhaltens eines Geschäftsprozesses basierend auf Interaktionen zwischen dem Prozess und seinen Partnern (Webservices). Die Interaktion mit den an einem Prozess beteiligten Partnern geschieht durch die Webservice-Schnittstellen mit Hilfe der WSDL-Spezifikation. Aktuell ist WS-BPEL Release 2.0 als Standard, bei dessen Entwicklung Hersteller wie SAP und Siebel mitgewirkt haben, verfügbar. Bis zur Version 1.1 wurde der BPEL-Standard noch mit BPEL4WS (Business Process Execution Language for Webservices) bezeichnet. Das OASIS WS-BPEL Komitee beschloss am 14. September 2004, die Spezifikation WS-BPEL 2.0 zu nennen, um in Einklang mit den anderen WS-*Spezifikationen und Standards wie WSDL, WS-Security etc. zu sein. In WS-BPEL lassen sich für Prozesse die gewünschte Koordination der Service-Interaktionen zwischen den Partnern definieren. WS-BPEL bietet darüber hinaus Mechanismen für den Umgang mit Verarbeitungsfehlern und Ausnahmen („exceptions“) an. Ein Prozess ist letztendlich eine aufeinander abgestimmte Menge von Webservice-Interaktionen. Sog. BPEL-Engines (wie z.B. Oracle BPEL Process Manager – vormals Collaxa BPEL Orchestration Server, SAP PI, IBM WebSphere Process Server oder Microsoft BizTalk Server) erlauben das Ausführen der BPELProzessinstanzen.

2.9.2 Webservices Ein Webservice ist eine Software-Anwendung, die mit einem Uniform Resource Identifier (URI) eindeutig identifizierbar ist und deren Schnittstelle mit Hilfe der XML definiert, beschrieben und gefunden werden kann. Ein Webservice unterstützt die direkte Interaktion mit anderen Webservices unter Verwendung XMLbasierter Nachrichten durch den Austausch über internetbasierte Protokolle (Hansen, Neumann 2005, S. 803).

Geschäftsprozessmodellierung mit WS-BPEL

39

Webservices sind dabei nicht gleichzusetzen mit herkömmlichen WebAnwendungen, sie können jedoch von diesen genutzt werden. Zu den (Kern-) Spezifikationen für Webservices zählen (Hansen, Neumann 2005, S. 804): x BPEL4WS: Business Process Execution Language for Web Services bzw. WSBPEL x BPML: Business Process Modeling Language x UDDI: Universal Description, Discovery and Integration x WSDL: Web Service Description Language x SOAP: Simple Object Access Protocol x HTTP: Hyptertext Transfer Protocol x SMTP: Simple Mail Transfer Protocol Auf Basis der Kernspezifikationen UDDI, WSDL und SOAP kann eine Serviceorientierte Architektur entwickelt werden, die Dienstnachfrager (Konsumenten), Dienstanbieter sowie ein Verzeichnisdienst umfassen (vgl. Abb. 2.8).

Abb. 2.8: Funktionsweise von Webservices (Quelle: Hansen, Neumann 2005, S. 804)

Der Anbieter eines Webservices veröffentlicht in einem sog. UDDI-Verzeichnis die Beschreibung seiner Dienste. Der Dienstnachfrager (Konsument) kann nun dieses Verzeichnis durchsuchen und einen gewünschten Dienst auswählen. Nach einem Austausch weiterer Protokolldetails, findet die dynamische Anbindung des Konsumenten an den Webservice des Anbieters statt. Der Konsument kann nun auf einzelne Methoden des nachgefragten Webservices zurückgreifen. Die Grundlage für das oben skizzierte Anwendungsszenario bilden drei XMLbasierte Standards, die in den nachfolgenden Abschnitten noch näher erläutert werden:

40


x UDDI: Verzeichnisdienst zur Registrierung von Webservices. Dieser Dienst ermöglicht das dynamische Auffinden von Webservices durch die potentiellen Konsumenten. Allerdings hat sich UDDI bisher (noch) nicht global durchgesetzt und wird allenfalls in kleineren Firmen-Intranets verwendet. x WSDL: Dient zur Beschreibung der von dem jeweiligen Webservice bereitgestellten Methoden und deren Parametern. x SOAP: Protokoll zur Kommunikation und zum strukturierten Nachrichtenaustausch zwischen Webservices. Hier wird der eigentliche Aufruf eines Webservices gestartet. 2.9.2.1 Dienstabrufe SOAP ist ein Netzwerkprotokoll, mit dessen Hilfe Daten zwischen Webservices ausgetauscht und sog. Remote Procedure Calls durchgeführt werden können (Hansen, Neumann, 2005, S. 805). SOAP stützt sich auf andere Standards. Hierzu gehören XML zur Repräsentation der Daten sowie Internet-Protokolle der Transportund Anwendungsschicht im TCP/IP-Referenzmodell zur Übertragung der Nachrichten (die Verwendung von SOAP erfolgt i.d.R. über HTTP und TCP). Eine minimale SOAP-Nachricht besteht aus einem sog. „Envelope“ genannten Element (vgl. Abb. 2.9).

Abb. 2.9: Struktur einer SOAP-Nachricht (vgl. Hansen, Neumann 2005, S. 805)

Dieses Element referenziert mittels eines Namensraum-Attributs auf http://www.w3.org/2003/05/soap-envelope. Optional kann ein Header-Element verwendet werden, in dem Meta-Informationen wie beispielsweise zum Routing, zur Verschlüsselung oder zur Transaktionsidentifizierung untergebracht werden können. Im Body-Element sind die eigentlichen Nutzdaten wie z.B. Informationen zum Datenaustausch oder Anweisungen für einen entfernten Prozeduraufruf untergebracht. Die im Body-Element untergebrachten Daten sind vom Empfänger entsprechend zu interpretieren.


41

2.9.2.2 Dienstbeschreibung Die Web Service Description Language (WSDL) ist eine plattform-, programmiersprachen- und protokollunabhängige XML-basierte Beschreibungssprache für Webservices. Mit Hilfe von WSDL lassen sich die angebotenen Funktionen, Daten, Datentypen und Austauschprotokolle eines Webservice beschreiben (vgl. Abb. 2.10). Hierbei werden im Wesentlichen die Operationen definiert, die von außen zugänglich sind, sowie die jeweiligen Parameter und Rückgabewerte dieser Operationen. Ein WSDL-Dokument beinhaltet im XML-Format Angaben zur Schnittstelle, zum Zugangsprotokoll sowie Details zum Deployment und alle notwendigen Informationen zum Zugriff auf den Webservice. In einem WSDLDokument sind jedoch keine Quality-of-Service-Informationen oder Ontologien zur semantischen Einordnung des Webservices enthalten. Webservices werden durch die in Tab. 2.6 aufgeführten sechs XML-Hauptelemente definiert. Tabelle 2.6: WSDL-Elemente Element Datentypen (types)

Kurzbeschreibung Datentypen, die zum Austausch der Nachrichten (messages) verwendet werden Nachrichten (messa- Abstrakte Definitionen der übertragenen Daten ges) Schnittstellentypen (portType)

Bindung (binding) Ports (port) Endpoint Services (service)

One-way: Der Service bekommt eine Input-Message vom Client. Request-response: Der Service bekommt einen Request (Input-Message) vom Client und sendet eine Antwort (Output-Message) Solicit-response: Der Service sendet eine Message und erwartet eine Antwort vom Client Notification: Der Server sendet eine Output-Message Bestimmt das Protokoll und Datenformat für die Nachrichten, die durch einen bestimmten Port-Typ gegeben sind Spezifiziert eine Adresse für eine Kommunikationsschnittstelle (üblicherweise ein URI); in WSDL 2.0 wurde die Bezeichnung zu Endpoint geändert Zusammenfassung einer Menge von verwandten Ports

Abb. 2.10 zeigt exemplarisch die Struktur eines WSDL-Dokuments.

42


Abb. 2.10: Beispiel für die Struktur eines WSDL-Dokuments (Quelle: Hansen, Neumann 2005, S. 812)


43

2.9.2.3 Dienstverzeichnis Universal Description, Discovery and Integration (UDDI) bezeichnet einen standardisierten Verzeichnisdienst für Webservices. Der Verzeichnisdienst UDDI enthält die Namen von Unternehmen, ihre Daten und ihre Services. Dabei kann man in UDDI zwischen drei Arten von Informationen unterscheiden: Den "White Pages", einer Art Telefonbuch, den "Yellow Pages", einer Art elektronischer Entsprechung der Gelben Seiten sowie den "Green Pages", einer Art Schnittstellenbeschreibung. White Pages (Basisinformationen) geben ähnlich wie ein Telefonbuch (daher der englische Begriff „White Pages“) Auskunft über die Identität des Serviceanbieters. Hierzu gehören Informationen über das Geschäftsfeld oder allgemeine Kontaktdaten eines Ansprechpartners. Yellow Pages (Service-Kategorisierung) ermöglichen ähnlich wie ein „Branchenverzeichnis“, den „Gelben Seiten“ (englisch „Yellow Pages“), eine Klassifikation verschiedener Dienste hinsichtlich ihres Zweckes. Dies hilft leichter, die passenden Services zu finden. Green Pages enthalten die Schnittstellenbeschreibungen eines Webservices, um die Passfähigkeit von Webserviceanbieter und Webservicenutzer zu überprüfen. Die Beschreibungen werden im sogenannten tModel gespeichert, welches die Zusammenhänge zwischen Unternehmen, deren Diensten sowie Schnittstellen darstellt. Ende 2005 kündigten allerdings die größten der bisherigen Unterstützer von UDDI wie z.B. IBM, Microsoft und SAP an, den Verzeichnisdienst UDDI nicht weiter zu entwickeln und abzuschalten.

2.9.3 Basisaktivitäten in WS-BPEL Elementare Aktivitäten (Basic Activities) in WS-BPEL sind die grundlegenden (atomaren) Aktivitäten, welche nicht aus anderen Aktivitäten aufgebaut sind. Tabelle 2.7 fasst die elementaren Basisaktivitäten zusammen.

44


Tabelle 2.7: Basisaktivitäten in BPEL Basisaktivität

Erläuterung

assign

Zuweisen von Werten an Variablen

invoke

Synchroner (request/response) oder asynchroner Aufruf eines einzelnen Webservices

receive/reply

Anbieten einer synchronen oder asynchronen Webservice-Schnittstelle

throw

Explizites Signalisieren eines Fehlers, welcher durch Fehlerbehandlungen aufgefangen werden kann

terminate

Verarbeitung einer Aktivität soll abgebrochen werden

wait

Ein Prozess soll eine Zeitspanne warten

empty

Ausführen einer leeren Aktivität, z. B. um programmtechnisch in einer Fehlerbehandlung Fehler zu unterdrücken

2.9.4 Strukturelle Aktivitäten in WS-BPEL Strukturelle Aktivitäten (Structured Activities) beinhalten wiederum andere Aktivitäten und lassen so eine rekursive Komposition von komplexeren Prozessen zu. Tabelle 2.8 fasst die strukturellen Aktivitäten zusammen. Tabelle 2.8: Strukturelle Aktivitäten in BPEL Strukturelle Aktivität sequence

Erläuterung In einer Sequence werden zusammengefasste Aktivitäten nacheinander (sequentiell) abgearbeitet

while switch

Aktivitäten werden solange ausgeführt bis eine bool'sche Bedingung erfüllt ist Bedingte Ausführung von Aktivitäten (Fallunterscheidung)

for each

In einer Schleife kann bspw. ein Array von Elementen durchlaufen werden

flow

Aktivitäten können parallel oder in beliebiger Reihenfolge ausgeführt werden

pick

Ähnlich der Fallunterscheidung bei der Steueranweisung switsch; pick ist eine blockierende Operation, die auf externe Ereignisse wartet (z.B. Eintreten einer oder mehrerer Nachrichten (Messages), einen bestimmten Zeitpunkt oder den Ablauf einer Zeitspanne)

2.9.5 Fortgeschrittenere Konzepte in WS-BPEL BPEL ermöglicht eine blockstrukturierte Spezifikation von Prozessen, d. h. bei der Definition von lokalen Umgebungen (sog. Scopes) können lokale Variablen definiert und Aktivitäten gebündelt, d.h. zu einer transaktionalen Einheit zusammen


45

gefasst werden. Mit den Scopes können darüber hinaus Fehlerbehandlung (Fault Handler), Kompensationsbehandlung (Compensation Handler) und Ereignisbehandlung (Event Handler) realisiert werden. Durch einen Compensation Handler können lang-andauernde Transaktionen realisiert werden, indem fehlgeschlagene oder vorangegangene Aktivitäten (z.B. Stornierung eines Auftrags) wieder rückgängig gemacht werden (entspricht einem Rollback bei Datenbanken). Abb. 2.11 zeigt beispielhaft die Definition eines Geschäftsprozesses in BPEL.

Abb. 2.11: Beispiel für die Definition eines BPEL-Prozesses (Hansen, Neumann 2005, S. 824)

46


Für einen Aufruf wurden partnerLink, verschiedene Ein- und Ausgabevariablen, die entsprechende WSDL-Schnittstelle (Attribut portType) und die aufzurufenden Operationen entsprechend angegeben (vgl. Hansen, Neumann 2005, S. 824). Der spezifizierte „fault handler“ definiert alternative Ausführungspfade, wenn ein Fehler innerhalb des „scope“ ausgelöst wird. Es werden jene Aktivitäten spezifiziert, die nacheinander ausgeführt werden, wenn Fehler auftreten. Mittels sequence wurde ein spezieller Kontrollfluss spezifiziert.

Blickpunkt Praxis Abschließende Fallstudie: Wie Deutz mit SAP XI über 100 Geschäftsprozesse, die SAP- und Nicht-SAP-Lösungen umfassen, integriert abwickelt Branchensituation Die Deutz AG (www.deutz.de) ist einer der weltweit führenden Motorenhersteller für Diesel- und Gasmotoren. Deutz wurde 1864 gegründet und beschäftigt weltweit rund 4930 Mitarbeiter. Das Unternehmen erzielte 2008 einen Umsatz von 1,459 Milliarden Euro. Die von Deutz gefertigten Motorbaureihen werden in einer sehr hohen Variantenanzahl angeboten. Die Fertigungsund Montageprozesse sind daher auch entsprechend komplex und nur durch reibungslos funktionierende IT-Systeme steuerbar. Die Herausforderung Deutz entschied sich für eine weitere Prozessintegration bereits Mitte 2002 die SAP Exchange Infrastructure (XI), als Komponente der Integrationsplattform SAP NetWeaver, zusammen mit SAP R/3 in der Branchenausprägung Discrete Industries einzusetzen. Hintergrund dieser Entscheidung war die schwierige Kommunikation zwischen den Nicht-SAP-Systemen (Montageleitrechner, Lagerverwaltungs- und Logistiksystemen), den bestehenden SAPSystemen, Eigenentwicklungen sowie einem System eines externen Dienstleisters für die Materialversorgung und einem weiterem System für die Ersatzteilversorgung im Logistikzentrum. Die besondere Herausforderung bestand darin, SAP R/3 mit dem Montageleitrechner, dem Lagerverwaltungssystem, dem EDI-Subsystem und den Anwendungssystemen der externen Dienstleister zu verknüpfen. Die Lösung „Mit SAP R/3 und SAP XI wollen wir uns für zukünftige Anforderungen, wie Webservices, rüsten“, erklärt Bernd Wieching, SAP-XI-Verantwortlicher bei Deutz. „Gleichzeitig galt es, bestehende Prozesse zu harmonisieren und bisherige Investitionen zu sichern.“ Vorteile Rund 1.800 Deutz-Mitarbeiter aus den Bereichen Entwicklung, Vertrieb, Beschaffung, Logistik, Produktion, After Sales und Administration arbeiten mit

Kontrollfragen und weiterführende Aufgaben

47

den neuen SAP-Systemen. Hinzu kommen ca. 400 weitere Anwender von externen Vertriebspartnern. Mehr als 100 verschiedene Prozesse mit über 25.000 Nachrichten (Events) werden über SAP XI integriert und harmonisiert abgewickelt. Durch die Offenheit der Lösung SAP XI war es möglich, Geschäftsprozesse innerhalb und über die Unternehmensgrenzen hinaus zwischen SAPSystemen und Nicht-SAP-Systemen integriert abzuwickeln. Quelle: SAP AG: Deutz AG í Eine harmonische Systemfamilie dank SAP NetWeaver; www.sap.com/germany/media/50071160.pdf; Abruf: 12.02.2010.

2.10 Kontrollfragen und weiterführende Aufgaben Tabelle 2.9: Kontrollfragen Nr.

Frage

Antwort in Abschnitt

1

Welche Ziele werden mit dem Geschäftsprozessmanagement verfolgt?

2.3

2

Welche (historischen) Gründe führten zur stärkeren Prozessorientierung in Unternehmen?

2.4

3

Was ist ein Geschäftsprozess? Erläutern Sie den Begriff und geben Sie ein Beispiel.

2.5

4

Welche Phasen umfasst das Geschäftsprozessmanagement?

2.6

5

Wie kann IT die einzelnen Phasen des Geschäftsprozessmanagements unterstützen und deren Qualität fördern?

2.6

6

Nennen und erläutern Sie die Grundsätze der ordnungsgemäßen Prozessmodellierung.

2.7

7

Welche Notationen zur Modellierung von Geschäftsprozessen stehen zur Verfügung? Wie unterscheiden sich diese?

2.8

8

Ein produzierendes Unternehmen bittet Sie, eine Geschäftsprozessanalyse für den Prozess Materialbestellung durchzuführen. In welchen Schritten gehen Sie bei Ihrer Prozessanalyse vor?

2.5, 2.6, 2.7, 2.8

9

Nennen und erläutern Sie die Möglichkeiten zur Prozessverbesserung.

2.6.3

10

Modellieren Sie den Prozess Kundenauftragsbearbeitung als erweiterte EPK.

2.8

11

Welche Nutzeffekte versprechen sich Unternehmen von dem Einsatz von Webservices zur Prozessintegration?

2.9

12

Welche fortgeschritteneren Konzepte stehen in WS-BPEL zur Verfügung? Gehen Sie insbesondere auf Möglichkeiten der Fehlerbehandlung ein.

2.9

48


Diskussionsfragen Stimmen Sie der folgenden Aussage zu? Warum bzw. warum nicht? Begründen Sie Ihre Antwort. Effizientes und effektives Geschäftsprozessmanagement ist nur unter Einsatz moderner Informations- und Kommunikationstechnologien möglich. Diskutieren Sie, ob Prozessintegration auf der Basis von Webservices nur ein kurzfristiges Modethema ist oder ob sie sich langfristig in der Wissenschaft sowie der Unternehmenspraxis etablieren wird.

Blickpunkt Internet-Ressourcen Weiterführende Informationen zu den Themen Geschäftsprozessmodellierung und Geschäftsprozessmanagement finden Sie auf den folgenden Internet-Seiten: ABPMP – The Association of Business Process Management Professionals (www.abpmp.org), Business Process Management Initiative (www.bpmi.org) sowie den Internet-Seiten der einschlägigen Softwarehersteller im Bereich des Geschäftsprozessmanagements wie z.B. IBM, Oracle, SAP, IDS-Scheer oder die BOC-Gruppe.

Internet-Recherche 1.

2.

3.

Rufen Sie die Enzyklopädie der Wirtschaftsinformatik unter www.enzyklopaedie-der-wirtschaftsinformatik.de auf und suchen Sie nach den Begriffen Geschäftsprozessmodellierung, Prozessmanagement, EPK sowie Grundsätze ordnungsgemäßer Modellierung. Rufen Sie die Internet-Seiten von Microsoft, IBM, Oracle, SAP, IDSScheer sowie der BOC-Gruppe auf und recherchieren Sie, welche Produkte diese Unternehmen zum Geschäftsprozessmanagement in ihrem jeweiligen Produktportfolio enthalten. Erstellen Sie einen vergleichenden tabellarischen Bericht mit verschiedenen Vergleichskriterien (z.B. unterstützte Modellierungsnotationen, Schnittstellen zu anderen Anwendungssystemen, Möglichkeiten einer automatisierten Geschäftsprozessanalyse (Simulation, Prozesskostenrechnung), etc.). Rufen Sie die Internet-Seite des W3C (World Wide Web Consortium) unter www.w3.org auf und recherchieren Sie, welche Aufgaben das W3C bei der Standardisierung im Bereich Webservices übernimmt. An welchen aktuellen Problemstellungen im Bereich Webservices wird derzeit gearbeitet?

Literatur

49

2.11 Literatur Abts D, Mülder W (Hrsg) (2010) Masterkurs Wirtschaftsinformatik. Vieweg + Teubner, Wiesbaden Ahlemann F (2006) Unternehmensweites Projektcontrolling: Ein Referenzmodell für Softwareund Organisationssysteme. In: Hoppe U, Rieger B, Teuteberg F, Witte T (Hrsg) Schriften des Instituts für Informationsmanagement und Unternehmensführung (IMU), Bd 1. Eul, Lohmar, Köln Allweyer T (2005) Geschäftsprozessmanagement. Strategie, Entwurf, Implementierung, Controlling. W3L, Herdecke Allweyer T (2008) BPMN Business Process Modeling Notation. Einführung in den Standard für die Geschäftsprozessmodellierung. Books on Demand, Norderstedt Alves A, Arkin A, Askary S, Barreto C, Bloch B, Curbera F, Ford M, Goland Y, Guizar A, Kartha N, Liu CK, Khalaf R, Koenig D, Marin M, Mehta V, Thatte S, van der Rijn D, Yendluri P, Yiu A (2007) Web services business process execution language version 2.0. Committee specification, 31 January 2007, http://docs.oasis-open.org/wsbpel/2.0/CS01/wsbpel-v2.0CS01.pdf. Abruf 09.02.2010. Andrews T, Curbera F, Dholakia H, Goland Y, Klein J, Leymann F, Liu K, Roller D, Smith D, Thatte S, Trickovic I, Weerawarana S (2003) Business Process Execution Language for Web Services, Version 1.1. Specification, BEA Systems, IBM Corp., Microsoft Corp., SAP AG, Siebel Systems Becker J, Schütte R (2004) Handelsinformationssysteme, 2. Aufl. Verlag Moderne Industrie, Frankfurt am Main Becker J, Kahn D (2008) Der Prozess im Fokus. In: Becker J, Kugeler M, Rosemann M (Hrsg) Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 6. Aufl. Springer, Berlin et al, S 3-16 Becker J, Rosemann M, Schütte R (1995) Grundsätze ordnungsmäßiger Modellierung. Wirtschaftsinformatik 5:435-445 Becker J, Kugeler M, Rosemann M (Hrsg) (2008) Prozessmanagement – Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 6. überarbeitete und erweiterte Aufl. Springer, Berlin Becker J, Mathas C, Winkelmann A (2009) Geschäftsprozessmanagement. Springer, Berlin Booch G, Rumbaugh J, Jacobson I (1999) The Unified Modeling Language User Guide. Journal of Database Management 4:51-52 Booch G, Rumbaugh J, Jacobson I (2002) Das UML-Benutzerhandbuch. Addison-Wesley, München et al Bucher T, Winter R (2009) Geschäftsprozessmanagement – Einsatz, Weiterentwicklung und Anpassungsmöglichkeiten aus Methodiksicht. HMD – Praxis der Wirtschaftsinformatik 266:516 Curbera F, Goland Y, Klein J, Leymann F, Roller D, Thatte S, Weerawarana S (2002) Business Process Execution Language for Web Services, Version 1.0. Specification, BEA Systems, IBM Corp., Microsoft Corp. http://msdn.microsoft.com/enus/library/ee251592(BTS.10).aspx#bpelv1-0final__toc16076413. Abruf 09.02.2010 Deming WE (1982) Out of the Crisis. Massachusetts Institute of Technology, Cambridge Dostal W, Jeckle M, Melzer I, Zengler B (2005) Service-orientierte Architekturen mit Web Services – Konzepte, Standards, Praxis, 1. Aufl. Spektrum, München Ehrig M, Koschmider A, Oberweis A (2007) Measuring Similarity between Semantic Business Process Models. In: Roddick JF, Hinze A (Hrsg) Proceedings of the Fourth Asia-Pacific Conference on Conceptual Modelling (APCCM 2007), Ballarat, Australia, January 30February 2, 2007, S 71-80 Eicker S, Nagel A, Schuler P M (2007) Flexibilität im Geschäftsprozessmanagement-Kreislauf. ICB-Research Report No. 21, Duisburg, Essen.

50


Ferstl OK, Sinz EJ (1995) Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen. Wirtschaftsinformatik 3:209-220 Ford H (1926) Today and Tomorrow. Doubleday, Page and Company, Garden City Frank U (1994) Multiperspektivische Unternehmensmodellierung. Theoretischer Hintergrund und Entwurf einer objektorientierten Entwicklungsumgebung. Oldenbourg, München, Wien Frank U (2000) Modelle als Evaluationsobjekt: Einführung und Grundlegung. In: Häntschel I, Heinrich LJ (Hrsg) Evaluation und Evaluationsforschung in der Wirtschaftsinformatik. Oldenbourg, München, S 339-352 Freund J, Rücker B, Henninger T (2010) Praxishandbuch BPMN. Hanser, München Funk B, Niemeyer P, Rautenstrauch C, Scheruhn H, Weidner S (2008) Modelling and implementation of an order-to-cash process in distributed systems. In: GITMA 2008 Conference Proceedings, S 72-75 Gadatsch A (2002) Management von Geschäftsprozessen: Methoden und Werkzeuge für die ITPraxis. Eine Einführung für Studenten und Praktiker, 2. überarbeitete und erweiterte Aufl. Vieweg, Braunschweig et al Gadatsch A (2005) Grundkurs Geschäftsprozess-Management, 4. Aufl. Vieweg, Wiesbaden Gaitanides M (1983) Prozessorganisation. Entwicklung, Ansätze und Programme prozessorientierter Organisationsgestaltung. Vahlen, München Gaitanides M, Scholz R, Vrohlings A (1994) Prozeßmanagement – Grundlagen und Zielsetzungen. In: Gaitanides M, Scholz R, Vrohlings A, Raster M (Hrsg) Prozeßmanagement. Konzepte, Umsetzungen und Erfahrungen des Reengineering. Hanser, München, Wien Galler J, Scheer AW (1995) Workflow-Projekte: Vom Geschäftsprozeßmodell zur unternehmensspezifischen Workflow-Anwendung. Information Management 1:20-27 Georgakopoulos D, Hornick M, Sheth A (1995) An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Journal of Distributed and Parallel Databases 2:119-153 Hammer M, Champy J (1993) Reengineering the Corporation – A Manifesto for Business Revolution. Harper Collins, New York Hammer M, Champy J (1995) Business Reengineering – Die Radikalkur für das Unternehmen. Campus, Frankfurt/Main Hansen H, Neumann G (2005) Wirtschaftsinformatik 2 – Informationstechnik, 9. Aufl. UTB, Stuttgart Heinrich B, Bewernik MA, Henneberger M, Krammer A, Lautenbacher F (2008) SEMPA – Ein Ansatz des Semantischen Prozessmanagements zur Planung von Prozessmodellen. Wirtschaftsinformatik 6:445-460 Hepp M, Roman D (2007) An Ontology Framework for Semantic Business Process Management. In: Oberweis A, Weinhardt C, Gimpel H, Koschmider A, Pankratius V, Schmizler B (Hrsg) eOrganisation: Service-, Prozess, Market-Engineering, 8. Internationale Tagung Wirtschaftsinformatik, Bd 1. Universitätsverlag Karlsruhe, Karlsruhe, S 423-440 Hitz M, Kappel G, Kapsammer E, Retschitzegger W (2005) UML @ Work: Objektorientierte Modellierung mit UML 2, 3. aktualisierte und überarbeitete Aufl. dpunkt.verlag, Heidelberg Hofreiter B, Huemer C, Kim JH (2006) Choreography of ebxml business collaborations. Information Systems and E-Business Management 4:221-243 Hollingsworth D (2004) The Workflow Reference Model: 10 Years On. In: Fischer L (Hrsg) Workflow Handbook 2004. Future Strategies, Lighthouse Point, S 295-312 Jarz EM (2003) Skriptum Geschäftsprozesse. Kufstein. Johannsen W, Goeken M (2007) Referenzmodelle für IT-Governance. Strategische Effektivität und Effizienz mit COBIT, ITIL & Co. dpunkt.-Verlag, Heidelberg Kavantzas N, Burdett D, Ritzinger G, Fletcher T, Lafon Y, Barreto C (2005) Web Services Choreography Description Language Version 1.0. W3C Candidate Recommendation 9 November 2005, World Wide Web Consortium. http://www.w3.org/TR/ws-cdl-10/. Abruf 09.02.2010. Keller G, Teufel T (1997) SAP R/3 prozessorientiert anwenden. Iteratives Prozess-Prototyping zur Bildung von Wertschöpfungsketten. Addison-Wesley, Bonn et al

Literatur

51

Keller G, Nüttgens M, Scheer AW (1992) Semantische Prozeßmodellierung auf der Grundlage Ereignisgesteuerter Prozeßketten (EPK). Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 89, Saarbrücken. http://www.iwi.uni-sb.de/Download/iwihefte/heft89.pdf. Abruf 30.08.2008 Knackstedt R, Pöppelbuß J, Becker J (2009) Vorgehensmodell zur Entwicklung von Reifegradmodellen. Wirtschaftsinformatik 1:535-544 Kosiol E (1961) Modellanalyse als Grundlage unternehmerischer Entscheidungen. ZfbF 13:318334 Kosiol E (1962) Organisation der Unternehmung. Gabler, Wiesbaden Krallmann H, Frank H, Gronau N (2002) Systemanalyse im Unternehmen, 4. Aufl. Oldenbourg, München Melzer I et al (2008) Service-orientierte Architekturen mit Web Services, 3. Aufl. Spektrum, Heidelberg Mendling J (2007) Detection and Prediction of Errors in EPC Business Process Models. Dissertationsschrift, Wirtschaftsuniversität Wien Mendling J (2008) Metrics for Process Models: Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness, LNBIP 6. Springer, Berlin Mendling J, Hafner M (2005) From Inter-organizational Workflows to Process Execution: Generating BPEL from WS-CDL. In: Meersman R, Tari Z, Herrero P (Hrsg) OTMWS 2005. LNCS Bd 3762. Springer, Heidelberg, S 506-515 Mendling J, Nüttgens M (2006) EPC Markup Language (EPML) – An XML-Based Interchange Format for Event-Driven Process Chains (EPC). ISeB 3:245-263. http://wi.wuwien.ac.at/home/mendling/publications/TR05-EPML.pdf. Abruf 30.08.2008 Mendling J, Nüttgens M, Neumann G (2004) A Comparison of XML Interchange Formats for Business Process Modelling. In: Feltz F, Oberweis A, Otjacques B (Hrsg) Proceedings of EMISA 2004 – Information Systems in E-Business and E-Government. LNI Bd 56. Köllen, Bonn, S 129-140 Mendling J, zur Muehlen M, Price A (2005) Standards for Workflow Definition and Execution. In: Dumas M, ter Hofstede A, van der Aalst WMP (Hrsg) Process Aware Information Systems: Bridging People and Software Through Process Technology. Wiley, Chichester, S 281316 Mielke C (2002) UML-Modellierung und Anwendungsgenerierung. Spektrum, Heidelberg, Berlin Melenovsky MJ (2005) Business Process Management’s Success Hinges on Business-Led Initiatives. Gartner Note G00129411. http://www.modus21.com/resources/gartner_bpm.pdf. Abruf 09.02.2010 Neumann S, Probst C, Wernsmann C (2003) Kontinuierliches Prozessmanagement. In: Becker J, Kugeler M, Rosemann M (Hrsg) Prozessmanagement – Ein Leitfaden zur prozessorientierten Organisationsgestaltung. Springer, Berlin et al, S 309-335 Nordsieck F (1932) Die schaubildliche Erfassung und Untersuchung der Betriebsorganisation. Poeschel, Stuttgart Nordsieck F (1934) Grundlagen der Organisationslehre. Poeschel, Stuttgart Nüttgens M, Rump FJ (2002) Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK). In: Desel J, Weske M (Hrsg) Promise 2002: Prozessorientierte Methoden und Werkzeuge für die Entwicklung von Informationssystemen. Proceedings des GI-Workshops und Fachgruppentreffens, Potsdam, LNI Bd 21, S 64-77 Nüttgens M, Rump, FJ (Hrsg) (2004) EPK 2004 – Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten. Proceedings des GI-Workshops und Arbeitskreistreffens, Luxemburg. Bonn: Gesellschaft für Informatik Object Management Group (OMG) (2008) Business Process Management Initiative (BPMI): Business Process Modeling Notation (BPMN) Information. http://www.bpmn.org/. Abruf 12.02.2010

52


Oestereich B (2001) Objektorientierte Softwareentwicklung: Analyse und Design mit der Unified Modeling Language, 5., völlig überarbeitete Aufl. Oldenbourg, München, Wien Österle H (1995) Entwurfstechniken. Springer, Berlin et al Österle H, Gutzwiller T (1992) Konzepte angewandter Analyse- und Design-Methoden, Bd I: Ein Referenz-Metamodell für die Analyse und das System-Design. AIT, Hallbergmoos Papazoglou MP (2007) Web Services: Principles and Technology. Prentice Hall, Essex Petrasch R, Meimberg O (2006) Model Driven Architecture: Eine praxisorientierte Einführung in die MDA. dpunkt.verlag, Heidelberg Petri CA (1962) Kommunikation mit Automaten. Schriften des Rheinisch-Westfälischen Institutes für Instrumentelle Mathematik an der Universität Bonn, Heft 2. Rheinisch-Westfälisches Institut für Instrumentelle Mathematik, Bonn Rosenkranz F (2002) Geschäftsprozesse. Modell- und computergestützte Planung. Springer, Berlin et al Rosemann M, de Bruin T, Power B (2006) A Model to Measure Business Process Management Maturity and Improve Performance. In: Jeston J, Nelis J (Hrsg) Business Process Management: Practical Guidelines to Successful Implementations. Butterworth-Heinemann, Oxford, Burlington, S 299-315 Rosemann M, Schwegmann A, Delfmann P (2008) Vorbereitung der Prozessmodellierung. In: Becker J, Kugeler M, Rosemann M (Hrsg) Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 6. Aufl. Springer, Berlin et al, S 45-103 Rump FJ (1999) Geschäftsprozeßmanagement auf der Basis ereignisgesteuerter Prozeßketten: Formalisierung, Analyse und Ausführung von EPKs. Teubner, Stuttgart et al Scheer AW (1992) Architektur Integrierter Informationssysteme. Grundlagen der Unternehmensmodellierung, 2. Aufl. Springer, Berlin et al Scheer AW (1996) ARIS-House of Business Engineering: Von der Geschäftsprozessmodellierung zur Workflow-gesteuerten Anwendung; vom Business Process Reengineering zum Continuous Process Improvement. Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 133. Universität des Saarlandes, Saarbrücken Scheer AW (1998) ARIS – Modellierungsmethoden, Metamodelle, Anwendungen, 3. Aufl. Springer, Berlin et al Scheer AW (2002) ARIS – Vom Geschäftsprozess zum Anwendungssystem, 4. Aufl. Springer, Berlin Scheer AW, Nüttgens M, Zimmermann V (1997) Objektorientierte Ereignisgesteuerte Prozeßkette (oEPK) – Methode und Anwendung. Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 141. Universität des Saarlandes, Saarbrücken Schlagheck B (2000) Objektorientierte Referenzmodelle für das Prozess- und Projektcontrolling: Grundlagen – Konstruktion – Anwendungsmöglichkeiten. DUV, Wiesbaden Schmelzer HJ, Sesselmann W (2007) Geschäftsprozessmanagement in der Praxis, 6. Aufl. Hanser, München, Wien Schmidt W, Fleischmann A, Gilbert O (2009) Subjektorientiertes Geschäftsprozessmanagment. HMD – Praxis der Wirtschaftsinformatik 266:52-62 Schütte R (1998) Grundsätze ordnungsmäßiger Referenzmodellierung: Konstruktion konfigurations- und anpassungsorientierter Modelle. Gabler, Wiesbaden Schwegmann A, Laske M (2003) Istmodellierung und Istanalyse. In: Becker J, Kugeler M, Rosemann M (Hrsg) Prozessmanagement – Ein Leitfaden zur prozessorientierten Organisationsgestaltung. Springer, Berlin et al, S 159-190 Smith A (1776) An inquiry into the nature and causes of the wealth of nations. London Speck M, Schnetgöke N (2003) Sollmodellierung und Prozessoptimierung. In: Becker J, Kugeler M, Rosemann M (Hrsg) Prozessmanagement – Ein Leitfaden zur prozessorientierten Organisationsgestaltung. Springer, Berlin et al, 2003, S 191-226 Stachowiak H (1973) Allgemeine Modelltheorie. Springer, Wien

Literatur

53

Staud JL (2006) Geschäftsprozessanalyse: Ereignisgesteuerte Prozessketten und objektorientierte Geschäftsprozessmodellierung für Betriebswirtschaftliche Standardsoftware, 3. Aufl. Springer, Berlin Sturm A, Shehory O (2003) A Framework for Evaluating Agent-Oriented Methodologies. In: Giorgini P, Henderson-Sellers B, Winikoff M (Hrsg) Agent-Oriented Information Systems, 5th International Bi-Conference Workshop, AOIS 2003, July 14, 2003, Melbourne (Australia), and October 13, 2003, Chicago, IL (USA), LNCS Bd 3030. Springer, Berlin et al., S 94109 Taylor FW (1911) The Principles of Scientific Management. Harper and Brothers, New York, London Teuteberg F, Kluth M, Ahlemann F, Smolnik S (2009) Semantic Benchmarking of Process Models – An Ontology-Based Approach. In: Proceedings of the 30th International Conference on Information Systems (ICIS), December 15-18, 2009, Phoenix, Arizona, USA Thomas O, Fellmann M (2009) Semantic Process Modeling – Design and Implementation of an Ontology-Based Representation of Business Processes. In: Business & Information Systems Engineering 6. – Dt. Übersetzung in: Wirtschaftsinformatik 6:506-518, u. d. T.: Semantische Prozessmodellierung – Konzeption und informationstechnische Unterstützung einer ontologiebasierten Repräsentation von Geschäftsprozessen van der Aalst WMP, van Hee K (2002) Workflow Management: Models, Methods, and Systems. MIT Press, Cambridge vom Brocke J (2003) Referenzmodellierung – Gestaltung und Verteilung von Konstruktionsprozessen. Logos, Berlin vom Brocke J, Buddendick C (2004) Konstruktionstechniken für die Referenzmodellierung. Systematisierung, Sprachgestaltung und Werkzeugunterstützung. In: Becker J, Delfmann P (Hrsg) Referenzmodellierung: Grundlagen, Techniken und domänenbezogene Anwendungen. Physica, Heidelberg, S 19-49 Zur Muehlen M (2004) Workflow-based Process Controlling. Foundation, Design, and Implementation of Workflow-driven Process Information Systems. Advances in Information Systems and Management Science, Bd 6. Logos, Berlin

3 Einführung in SAP Business Workflow 3.1 Lernziele Nach der Lektüre von Kapitel 3 können Sie die folgenden Fragen beantworten: x Was ist Workflow Management und konkret unter SAP Business Workflow zu verstehen? x Wie erfolgt die Workflow Definition und welche Werkzeuge kommen zum Einsatz? x Welche Rolle spielt der Business Workplace und wodurch unterstützt er Workflows zur Laufzeit? x Wie erfolgt das Workflow Management über das Internet? x Kann SAP Business Workflow in andere Anwendungen integriert werden? Wie könnte diese Integration im Fall von ARIS aussehen? Wie ist dies im Falle von Microsoft Sharepoint ausgestaltet? x Warum erfordert ein Workflow Management System eine Schnittstelle zu Mail-Systemen?

3.2 Einleitung Viele Unternehmen entscheiden sich nicht zuletzt für die Einführung einer SAPStandardsoftware, weil sie sich hiervon eine signifikante Verbesserung ihrer Geschäftsprozesse versprechen. Das Workflow Management von SAP spielt hierbei eine zentrale Rolle, da es eine Unterstützung bietet, automatische Prozesse sicher, schnell und transparent zu gestalten und durchzuführen. Dabei werden nicht nur unternehmensinterne Geschäftsprozesse durch das Workflow Management unterstützt, sondern auch unternehmensübergreifende Prozesse und somit die Kooperation von Lieferanten, Partnern und Kunden. Der folgende Blickpunkt in die Praxis verdeutlicht die Bedeutung des Workflow Managements noch einmal:

Blickpunkt Praxis Einführende Fallstudie: Wie gelingt es der Müller Unternehmensgruppe die Stammdatenpflege mit Hilfe von Workflows des SAP MaterialCockpits zu optimieren? Branchensituation Die Unternehmensgruppe Theo Müller ist das größte private MolkereiUnternehmen in Deutschland und in zahlreichen weiteren europäischen

56

Einführung in SAP Business Workflow

Ländern sowie in Israel vertreten. Über 4.500 Mitarbeiter erwirtschafteten 2008 einen Umsatz von rund 2,3 Mrd. Euro. Damit zählt die Unternehmensgruppe zu den Top 10 der Molkereiunternehmen in Europa. In Großbritannien ist sie bereits seit 1995 Marktführer im Joghurt-Segment mit dem Joghurt mit der Ecke (Müller Corner). Zur Gruppe gehören Tochterunternehmen mit eigenständigen, starken Marken: Müller, Weihenstephan, Sachsenmilch und Käserei Loose. Handelsmarken und BasisMilchprodukte wie Butter, H-Milch, Laktosepulver und Molkeprotein ergänzen das Portfolio. Neben den Milch verarbeitenden Tochterunternehmen gehören zur Müller-Gruppe das Verpackungsunternehmen Optipack GmbH, das firmeneigene Logistikunternehmen Culina, die Fahrzeugtechnik Aretsried GmbH und Müller Naturfarm, eines der größten Frucht verarbeitenden Unternehmen in Deutschland. Die Herausforderung Bei Müller als internationales, auf Wachstum ausgerichtetes Unternehmen stehen eine vielfältige Produktpalette und die Ausrichtung auf die jeweiligen Märkte im Fokus. Mit der stetigen Einführung neuer landesspezifischer Produkte ist auch ein hoher Aufwand der Materialpflege im SAP-System verbunden. Jeden Monat werden bei Müller über 400 neue Materialien in SAP angelegt und gepflegt. Hierbei sind pro Material die individuellen Ausprägungen für mehrere Werke zu berücksichtigen. Als Anforderungen werden die Verkürzung der Durchlaufzeiten, die Reduzierung manueller Fehler, die Verringerung des Koordinationsaufwandes und die Automatisierung der Arbeitsschritte definiert. Die Lösung Das Unternehmen Müller hat hierfür gemeinsam mit der realtime AG (SAP Beratungs- und Softwarehaus) eine Lösung entwickelt, die zu einer erheblichen Effizienzsteigerung im Unternehmen führte. Die Konzeption umfasste ein SAP-Materialpflegetool zur automatischen Stammdatenbefüllung durch vordefinierte Produktgruppen, flexible SAP Workflows zur Koordination der Pflege- und Kontrollschritte für die jeweilige Produktgruppe bzw. Organisationseinheit und eine anwenderfreundliche all-in-one Oberfläche für alle relevanten SAP-Transaktionen (Workflow-Cockpit). Dadurch war es möglich, Fehler und Durchlaufzeiten durch automatisierte Materialpflege zu reduzieren. Beispielsweise wurde zur Automatisierung der Befüllung des Materialstamms ein Template entwickelt, das typische Feldinhalte einer Produktgruppe wie bspw. Butter zuordnet. Bei der Neuanlage eines Materials bestimmt man über die Produktgruppe die vordefinierten Feldinhalte zur Befüllung und legt die verschiedenen Organisationsebenen (Werke, Verkaufsorganisationen) fest. Per Knopfdruck wird dann das Material erstellt und die Felder automatisch pro Organisationsebene befüllt. Nach der Verbuchung wird für alle angelegten Organisationsebenen der Start des jeweiligen SAP Workflows angeboten, um fehlende Informationen bei den

Einleitung

jeweiligen Abteilungen abzufragen. Außerdem war es möglich, die Effizienz der Prozesse mit SAP Workflow zu steigern. Auf Grundlage der neu strukturierten und optimierten Arbeitsprozesse wurde ein durchgängiger Workflow für jede Kombination Materialart bzw. Organisationsebene konzipiert und realisiert. Zusätzlich zu den Materialstammdaten steuert der Workflow auch weitere Aktivitäten für eine komplette Materialanlage. Dazu gehören z.B. die Pflege der Planungsrezepte und die Endkontrolle inklusive Materialfreigabe. Innerhalb des Workflows erhält der jeweilige Sachbearbeiter seine Aufgabe per SAP-Mail. Mit einem Klick wird direkt die entsprechende Transaktion gestartet. Materialnummer, Organisationsebene etc. sind bereits im Workflow vordefiniert, so dass nur noch die zu pflegenden Felder angezeigt werden. Manuelle Fehler werden dadurch reduziert, das Unternehmen erhält die maximale Flexibilität und kurze Reaktionszeiten bei Änderungen. Die Workflows sind so konzipiert, dass alle relevanten Parameter editierbar sind und die Änderungen direkt in Echtzeit im Produktivsystem vorgenommen werden können, z. B. Materialarten und Organisationsebenen (Vertrieb und Werke), die Auswahl der einzelnen Arbeitsschritte und Sachbearbeiter sowie die Durchführung von Transaktionen und Benachrichtigungen per EMail. Vorteile Im SAP Workflow-Cockpit werden nun alle relevanten Transaktionen zu den Materialpflege-Arbeitsschritten zentral zusammengefasst. Hier stehen Auswertungen, die Pflege und Kontrolle der zugehörigen Tabellen, das Starten des Materialpflegetools und der Workflows zur Verfügung. Durch die anwenderfreundliche all-in-one Oberfläche muss sich der User nun weder Transaktionen merken noch durch die Menüs klicken. Neben Standardauswertungen stehen auch individuelle Transaktionen zur Verfügung, z.B. die Kontrolle des Workflow-Fortschritts bzw. von Terminüberschreitungen, die Pflege der Vertreter, die Statusänderung eines Arbeitsschritts oder die Anzeige der Workitems pro Material. Durch die Einführung der Lösung konnten sich für Müller letztlich folgende Vorteile realisieren lassen: x Verkürzung der Gesamtworkflowdauer um 40 % x Material in einem Schritt für beliebige Organisationsebenen und verschiedene Organisationssichten anlegen x Komfortables und individuelles Customizing x Userfreundliches Handling x Reduzierung manueller Fehler Darüber hinaus konnte der Pflegeaufwand für Stammdaten deutlich vereinfacht werden und es kann erheblich schneller und flexibler auf Änderungswünsche reagiert werden. Quellen: http://www.realtime-ag.de/downloads/success-story-realtime-mueller.pdf

57

58


Gerade in Zeiten einer globalisierten Welt, in der zunehmend immer mehr Geschäftsbereiche outgesourct werden, ermöglicht ein effizientes Workflow Management, Geschäftsprozesse reibungslos und zusätzlich kosteneffizient zu gestalten. In diesem Zusammenhang ist es insbesondere notwendig, Einheiten zu integrieren, die nicht direkt an das SAP-System angeschlossen sind. Auf die hierfür im Workflow Management von SAP vorgesehenen Komponenten wird weiter unten eingegangen. Bevor aber das Workflow Management von SAP im Detail vorgestellt wird, ist zunächst der Begriff Workflow eindeutig zu definieren. Hierzu sei auf die in Kap.2.3 erfolgten Definitionen für Prozess und den auf betriebswirtschaftliche Aspekte fokussierten Geschäftsprozess verwiesen. In der Weiterführung der Definition des Geschäftsprozesses werden Workflows von der Workflow Management Coalition (WFMC) als komplette oder teilweise automatisierbare Geschäftsprozesse definiert, welche Informationen, Dokumente oder Aufgaben von einem Aufgabenträger zum anderen unter der Berücksichtigung bestimmter, zuvor definierter Regeln weitergeben (WFMC1999). Ein Workflow Management System ist danach ein System, welches die Ausführung von Workflows unter Einsatz von Software definieren, kreieren und managen kann. Es besteht aus einer oder mehrerer Workflow Engines, die die Workflow Definitionen interpretieren, mit den Workflow Nutzer interagieren und die notwendigen IT Werkzeuge und Applikationen aktivieren (WFMC1999). Im Rahmen dieses Kapitels wird erläutert, wie das Workflow Management durch SAP Workflow unterstützt und realisiert wird. Zunächst werden jedoch die Grundzüge des Workflow Managements, beginnend mit der Rolle der Aufgabe innerhalb der SAP-Systeme dargestellt, denn Geschäftsprozesse und ihre Modellierung spielen bis zur SAP NetWeaver Architektur (Marx Gómez, Rautenstrauch, Cissek 2008) nach wie vor die zentrale Rolle (Abb. 3.1). Bei SAP NetWeaver werden zunächst drei wesentliche Ebenen unterschieden: die Ebene des Users, die des Prozessexperten und -analysten sowie die des Entwicklers bzw. die des Programmierers. Auf allen Ebenen werden Prozesskomponenten oder Modelle in unterschiedlicher Form benötigt (Krimmel, Orb 2010 und Goebel, Ritthaler 2005). Eingebettete Prozesse mit entsprechend definierten Workflows bieten die Möglichkeit, Geschäftsprozesse zu automatisieren, zu überwachen sowie adäquate Informationen für deren Ausführung bereitzustellen. Dadurch ist es möglich, die richtigen Informationen zur richtigen Zeit den richtigen Personen entsprechend ihren Aufgaben bereitzustellen. Da Aufgaben eine zentrale Rolle für Workflows darstellen, werden sie und ihre Bedeutung im Folgenden zunächst kurz vorgestellt.

Die Aufgabe als zentrales Element im Workflow

59

Abb. 3.1: Rollen und Tools in SAP NetWeaver (in Anlehnung an SAP 2006a)

3.3 Die Aufgabe als zentrales Element im Workflow Eine Reihe von Aufgaben ist im Rahmen der Prozesse eines SAP-Systems zu bewältigen. Für die automatisierbaren Aufgaben wurde daher das Business Task Management entwickelt, das die Automatisierung, Ausführung und Überwachung von Aufgaben umfasst (SAP 2006a). Dazu zählt auch die Koordination und Ausführung von Aufgaben auf Basis automatisierter Prozessflüsse und Events im System sowie die Verfolgung des Aufgabenfortschritts. Die Aufgaben umfassen dabei Business Transaktionen, Alarmfunktionen, Formulare, Dokumente und auch Aspekte des Wissensmanagements. Abb. 3.2 veranschaulicht den grundlegenden Zusammenhang zwischen den Aufgaben innerhalb eines Prozesses und den damit verbundenen Workflows. Ziel ist es, aus den fachlichen Anforderungen konkrete Aufgaben in den Prozessen zu identifizieren. Diese müssen durch eine bestimmte Funktionalität des SAP-Systems abgebildet werden und dem Rollenkonzept der Benutzerverwaltung entsprechen, d.h. jedem Benutzer werden gemäß seiner Rolle im SAP-System bestimmte Funktionen als Aufgaben zugeordnet. Diese stehen dann im Rahmen des

60


spezifischen Workflows für bestimmte sogenannte Workitems. Workitems sind somit eine kleinere Einheit des Workflows (ein Teil davon) und repräsentieren eine Aufgabe oder eine Teilaufgabe. Alle Workitems zusammen werden in der universellen Worklist verwaltet. Darüber hinaus sind wiederkehrende, automatisierbare Aufgaben wiederum Bestandteil einer Workflow Definition (vgl. Abschnitt 3.4.1), die einen bestimmten Workflow auslösen. Zudem repräsentiert diese Aufgabe auf der Ausführungsebene des Systems einen Dienst oder eine Methode, die z.B. bestimmte Datenbankzugriffe regeln. Die Aufgabe ist also das zentrale Element im Workflow.

Abb. 3.2: Zusammenhang von Aufgaben und Workflows im SAP-System (in Anlehnung an SAP 2006a)

3.4 SAP Business Workflow Das im SAP ERP-System integrierte Workflow Management System wird als SAP Business Workflow bezeichnet. Mit SAP Business Workflow können Geschäftsprozesse innerhalb des SAP-Systems definiert, optimiert und automatisiert werden. Dafür nutzt SAP Business Workflow die bestehenden Transaktionen des SAP ERP-Systems und integriert diese entsprechend der dazugehörigen Prozessdefinitionen. Für den Einsatz von SAP Business Workflow bieten sich vor allem solche Arbeitsabläufe an, die immer wieder durchlaufen werden oder eine Vielzahl von Mitarbeitern involvieren. Da SAP Business Workflow integrierter Be-

SAP Business Workflow

61

standteil der ERP-Installation ist, erfordert es zudem keine zusätzlichen Lizenzen oder Installationen. Seit der Einführung des SAP R/3 Enterprise Releases 4.70 und des Web Application Servers gibt es darüber hinaus mit SAP WebFlow die Möglichkeit, unternehmensübergreifende Prozesse über das Internet zu integrieren und externe Partner an der Prozessintegration zu beteiligen. Über die Jahre hat sich der Einsatz des Business Workflows im SAP ERP-System stark verändert, was auf unterschiedliche Einflüsse zurückzuführen ist (Abb. 3.3).

Abb. 3.3: Entwicklung des SAP Workflow vom Business Workflow zum Workflow in SAP NetWeaver (in Anlehnung an SAP 2006a)

Es wird ersichtlich, dass sich der Business Workflow, wie er in den SAPSystemen der 90er Jahre vorherrschte, schrittweise zu dem Konzept weiterentwickelt hat, das heute im Rahmen des NetWeaver Frameworks wiederzufinden ist. Mit der Einführung des Enterprise Portal 5.0 (EP 5.0) kam die Universal Worklist hinzu, welche zur Verwaltung der Workitems dient und als zentraler Zugriffspunkt für Aufgaben, Alarme und Benachrichtigungen dient. Im Jahr 2003 kamen dann Funktionen des Business Process Managements (BPM) hinzu und in SAP NetWeaver 2004 schließlich die Erweiterung um Collaboration Task und Guided Procedures (vgl. Abb. 3.4). Mit der Erweiterung folgten dann das Workitem Calling und die Web Dynpros für ABAP (Advanced Business Application Programming, SAP eigene Programmiersprache). In der heutigen Fassung von SAP NetWeaver 7.0 findet sich eine vollständig integrierte Lösung für das Business Process Management, das auch den Workflow berücksichtigt (siehe auch Abb. 3.11). Neben der Prozesssicht auf Basis des Business Process Management (BPM) kamen immer mehr kollaborative Aufgabenstellungen und mit der SAP NetWeaver 2004s Architektur auch die Guided Procedures als weiteres Element zur Steuerung von Aufgaben hinzu (Abb. 3.4):

Abb. 3.4: Guided Procedures (in Anlehnung an SAP 2007a)

Guided Procedures sind dabei im Gegensatz zu Workflows eher als Anleitungen zu verstehen, also eine schrittweise Vorgehensweise, wie und in welcher Reihen-

62


folge etwas aus- bzw. durchzuführen ist (siehe in Abb. 3.4 am Beispiel die auszuführenden Schritte nach der Initialisierung der Guided Procedure). Sie werden für unklare und kurzfristige Vorgänge verwendet und sind nicht automatisierte Prozesse wie Workflows. SAP Business Workflow und Guided Procedures können daher im Wesentlichen wie folgt unterschieden werden (Tabelle 3.1). Tabelle 3.1: Unterschiede zwischen Business Workflow und Guided Procedures (in Anlehnung an SAP 2006b) SAP Business Workflows werden genutzt, wenn

Guided Procedures werden genutzt, wenn

die Vorgänge innerhalb von SAP liegen

die Vorgänge nicht SAP inhärent sind oder eine heterogene Mischung von Systemen vorliegt

die Vorgänge tief in das SAP-System integriert sind

es sich um eine SAP-Lösung außerhalb des ABAP Stacks handelt

detaillierte und kritische Kriterien zur Prüfung erforderlich sind

wenig oder keine Prüfungskriterien gefordert sind (eher Anleitungen)

die Vorgänge längerfristig und klar definiert sind

die Vorgänge kurzfristig und unklar definiert sind

kurz- bzw. mittelfristig nur wenig Änderungen zu erwarten sind

kurz- bzw. mittelfristig viele Änderungen zu erwarten sind

ĺ Entwicklung und Wartung liegen beim Workflow Entwickler

ĺ Entwicklung und Wartung liegen beim Business Experten

Ausgeführt wird der Workflow aus Sicht des Benutzers im Business Workplace. Hier wird ihm das Workitem angezeigt, das ausgeführt werden soll. Um dies zu ermöglichen, ist es notwendig, dass der Workflow vorher im Workflow Builder durch eine Workflow-Definition definiert wurde (Dart et al. 2009). Diese Beschreibung beinhaltet die einzelnen Schritte, die der Workflow zur Laufzeit ausführen wird. Diese Schritte (Steps) steuern den Workflow entweder direkt oder enthalten eine Referenz auf die jeweilige auszuführende Aufgabe, welche sich auf eine Methode eines Objekttyps im Business Object Repository (BOR) bezieht. Diese kann zur Laufzeit entweder automatisch (Hintergrundaufgabe) oder von einem Benutzer (Dialogaufgabe) ausgeführt werden. Die Abb. 3.5 zeigt den Zusammenhang der einzelnen Elemente des SAP Workflows im Überblick. Im Business Workplace gibt es demnach zwei alternative Möglichkeiten, einen Workflow-Schritt ausführen zu lassen: die automatische Ausführung im Hintergrund und die manuelle durch das Aufrufen eines Workitem. Während ersteres im Hintergrund abläuft, führt die zweite Möglichkeit einen Dialogschritt aus, der eine Dialogaufgabe startet. Letztlich rufen beide entsprechende Methoden auf Businessobjekten auf, die wiederum Transaktionen im SAP-System aufrufen. Alternativ zum Business Workplace kann ein Dialogschritt einem Benutzer auch aufgrund seiner Rolle in der Organisation zugeordnet sein.


63

Bei der Definition und der Ausführung eines Workflows lassen sich demnach drei Hauptfunktionsbereiche differenzieren: das Anlegen von Workflows (siehe Abschnitt 3.4.1), Workflows zur Laufzeit (siehe Abschnitt 3.4.2) und das Reporting von Workflows (siehe Abschnitt 3.4.3), die im Rahmen dieses Kapitels näher erläutert werden. Zur Umsetzung dieser Workflowfunktionen bietet SAP eine Reihe von Werkzeugen an, welche die Verwaltung und Nutzung von Workflows ermöglichen, die im Folgenden anhand des Workflow-Lebenszyklus (Definition, Laufzeit und Reporting von Workflows) vorgestellt werden. Business Workplace

Workflow

Aufgaben

Workflow wird durch Ereignis gestartet Workitem Workitem Workitem

Dialogschritt

(Business) Objekttyp

Dialogaufgabe

Hintergrundschritt

enthält

Methoden

Schritt steuert Workflow Automatische Ausführung im Hintergrund

Business Object Repository

Hintergrundaufgabe

rufen auf

Dialogschritt Bearbeiterzuordnung

Organisationsmanagement

- Transaktionen und Funktionen des R/3 - eigene Programme - externe Anwendungen Desktop-Anwendungen

Abb. 3.5: SAP Workflow Elemente im Zusammenhang (in Anlehnung an Brahm 2003)

3.4.1 Anlegen von Workflows Bevor ein Workflow ausgeführt werden kann, muss er zuerst im System durch eine Workflow Definition angelegt (definiert) werden. Dies kann in graphischer Form in einer Modellierungsumgebung interaktiv erfolgen, z. B. in einem Workflow Builder. Dazu werden die Abläufe als in einer SAP-eigenen Notation modelliert, visualisiert und letztlich implementiert. Damit der Workflow zur Laufzeit ausgeführt werden kann, wird die Workflow Definition erzeugt. Damit werden sowohl Kontroll- als auch Datenfluss zwischen den einzelnen Schritten des Prozesses aktiv gesteuert (Wenzel 2001) (Tabelle 3.2).

64


Tabelle 3.2: SAP Step Types und zugehörige Symbole (in Anlehnung an SAP 2004) Symbol

Step Type

Laufzeit Funktion

Prozesskontrolle

Die Funktionen Cancel work item oder Set work item to obsolete werden auf andere Workitems oder auf bestehende Workflows angewandt.

Ad hoc Anker

In der Definition werden Workflows gespeichert, die diesen Schritt ersetzen. Während der Laufzeit kann ein autorisierter Benutzer einen der gespeicherten Workflows auswählen. Der Ad Hoc Anker wird dann durch einen Schritt dieses Workflows ersetzt.

Aktivität

Ausführung eines Sub-Workflows oder einer Aufgabe.

Bedingung

Einer von zwei in der Workflow-Definition festgelegten Ästen wird verarbeitet. Die Entscheidung erfolgt regelbasiert.

Benutzerentscheidung

Der Prozessfluss des aktuellen Workflows wird durch eine Benutzerentscheidung bestimmt.

Vorlage-Dokument

Ein Dokument wird aus einer Vorlage erzeugt.

Container Operation Elementare arithmetische Operationen oder Wertzuweisungen werden auf individuelle Elemente des Workflow-Containers angewendet. Erzeugung eines Ereignisses

Ein Ereignis wird erzeugt.

Formular

Die Daten eines Container-Dokuments, das auf eine Struktur verweist, können als Formular angezeigt, verarbeitet oder freigegeben werden.

E-Mailversand

Eingegebener Text wird als E-Mail versandt.

Mehrfach-Bedingung Einer von verschiedenen in der Workflow-Definition festgelegten Ästen wird ausgeführt. Hierfür wird der Wert eines Container-Elements vom System geprüft. Verzweigung

Der folgende Prozess verzweigt sich, d.h.es können beliebig viele Äste bis zum erfolgreichen Beenden oder eine Bedingung für das Beenden definiert werden.

Undefinierter Schritt Keine Funktion während der Laufzeit. Schleife (UNTIL)

Eine Folge von zu wiederholenden Schritten, bis die definierte Abschlussbedingung eintritt.

Schleife (WHILE)

Eine Folge von zu wiederholenden Schritten bis die definierte Vergleichsregel erfüllt wird. Das System erhält die Schleife, falls die Vergleichsregel nicht erfüllt wird.

Warten auf Ereignis

Das System wartet auf ein bestimmtes Ereignis. Das Workitem kann nur bei Eintritt dieses Ereignisses abgeschlossen werden. Das Ereignis kann auch durch das Auftreten eines XML-Dokuments ausgelöst werden.

Web-Aktivität

Der Inhalt von Container-Elementen wird unverändert oder als XML-Dokument an eine URL gesendet und wartet auf eine Antwort. Dies ermöglicht eine Kommunikation mit einem durch eine Web-Aktivität ausgelösten Prozess.


65

Die Workflow Definition ist die technische Implementierung der Geschäftsprozesse und wird auch als Workflow Design bezeichnet. Dabei wird der Workflow aus den Schritten (Steps), die ihn steuern, und aus den von ihm auszuführenden Aufgaben zusammengesetzt (Gatling 2010) Es existieren verschiedene Typen für die einzelnen Schritte (Step Types), die unterschiedliche Funktionen für die Ausführung des Workflows haben. So kann z. B. eine bestimmte Aktivität folgen oder eine Bedingung abgefragt werden, die dann den weiteren Verlauf bestimmt (Dart et al. 2009) Unter Aufgaben werden dabei wie vorher definiert elementare betriebswirtschaftliche Tätigkeiten verstanden, die sich wiederum auf die Methode eines Objekttyps beziehen. Für jede Aufgabe werden weitere potentielle Bearbeiter definiert. Unterschieden wird dabei in automatisch ausführbare Methoden (Hintergrundaufgaben) oder in solche, die durch einen Benutzer ausgeführt werden (Dialogaufgaben) (Abb. 3.6).

Abb. 3.6: SAP Workflow Definition und Laufzeit (in Anlehnung an (SAP 2006b))

Jeder definierte Schritt steht dabei für ein Workitem. Diese Workitems repräsentieren zur Laufzeit einen bestimmten Dialogschritt des Workflows, der wieder-um einer bestimmten Dialogaufgabe oder Aktion im System zugeordnet ist. Sie sind also eine Ausprägung des Workflows zur Laufzeit. Workitems werden dem Benutzer im Business Workplace zur Ausführung angezeigt und rufen bestimmte ihnen zugeordnete Methoden auf Businessobjekten auf. Zusätzlich können weitere Angaben zu den Bearbeitern und zur Überwachung der Termine hinterlegt werden, die dann später zur Laufzeit vom WorkitemManager ausgewertet werden. Der Start eines Workflows erfolgt zur Laufzeit entweder manuell oder wird vom System ausgeführt. Das System kann allerdings nur Workflows starten, deren Workflow Definition mindestens ein auslösendes

66


Ereignis enthalten. Nur wenn dieses eintritt, wird der entsprechende Workflow automatisch gestartet. Eine Reihe von Definitionswerkzeugen unterstützt diese Aufgaben: x Business Workflow Explorer: Der Business Workflow Explorer ermöglicht einen Überblick über alle existierenden Aufgaben. x Workflow Wizard Explorer: Zur Definition von Workflows gibt es zahlreiche Workflow Wizards, mit denen spezielle Teile eines Workflows erstellt werden können. Der Workflow Wizard Explorer gibt einen Überblick über die existierenden Workflow Wizards und kann sowohl aus dem Workflow Builder gestartet werden als auch als separates Tool genutzt werden. x Workflow Builder: Im Workflow Builder können Workflows angezeigt und Veränderungen vorgenommen werden. Dadurch können z. B. Anpassungen wie Bearbeiterzuordnungen oder Änderungen in Terminüberwachungen direkt an den von SAP ausgelieferten Originalen vorgenommen werden. x Business Object Builder: Um die Funktionen des SAP-Systems mit dem Workflow zu verknüpfen, werden Business Objekte eingesetzt, die im Business Object Builder definiert und analysiert werden können. Diese Business Objekte werden dem Workflow in Form wiederverwendbarer Aufgaben zur Verfügung gestellt. Mit dem Business Object Builder können Business Objekte auch um Ereignisse erweitert werden, die im Standard nicht enthalten sind und die dann zur automatischen Auslösung eines Workflows verwendet werden können (SAP 2008). Wird im nächsten Schritt nun die Workflow Definition aktiviert, wird automatisch eine Laufzeitversion (Workflow Runtime) generiert, die dann beim Start des Workflows manuell oder automatisch jeweils in der gültigen Laufzeitversion für die Ausführung benutzt wird. Änderungen an der Workflow Definition und darauf basierende neue Laufzeitversionen bewirken keine Änderungen an den bereits ausgeführten Workflows.

3.4.2 Workflows zur Laufzeit Zentrales Element während der Laufzeit eines Workflows ist der Business Workplace. Der Endanwender erhält Informationen zu seinen auszuführenden Tätigkeiten im Business Workplace (Brahm, Pargmann 2003). Dort hat der Nutzer einen zentralen Überblick über alle durchzuführenden Tätigkeiten, zu deren Ausführung er berechtigt ist, und kann von dort direkt mit der Ausführung beginnen. 3.4.2.1 Business Workplace Der Business Workplace stellt eine Arbeitsumgebung dar, um Geschäfts- und Kommunikationsprozesse im Unternehmen zu erledigen. Die Benutzer erhalten


67

dort ihre von den SAP Business Workflows zugeordneten Workitems und bearbeiten Dokumente, die ihnen von Personen oder anderen Anwendungen gesendet wurden. Zur Verwaltung seiner Dokumente und Arbeitsvorgänge steht jedem Benutzer eine Ablage zur Verfügung. Darüber hinaus können Informationen aus seinem Arbeitsumfeld hier zur Verfügung gestellt werden, z. B. über internes Mailing. Zudem wird durch den Workplace die Integration von Microsoft Outlook ermöglicht, und eine webfähige Variante ist ebenfalls verfügbar. Der Business Workplace ist somit eine notwendige Voraussetzung für die Teilnahme SAP Business Workflow. Da er auch für das Senden in und aus anderen SAP Anwendungen zuständig ist, wird in vielen Anwendungen ein direkter Verweis in den Business Workplace angeboten. Der Business Workplace besteht im Wesentlichen aus drei Bereichen (Abb. 3.7):

Abb. 3.7: Business Workplace Aufteilung (in Anlehnung an Brahm, Pargmann 2003)

Im Übersichtsbaum werden im Eingang die Workflows nach Aufgaben, Inhalt, Inhaltsart und Ordnungsbegriff gruppiert. Zudem werden im Workflow-Eingang alle Dialog- und Terminüberschreitung-Workitems, denen der Benutzer als Empfänger zugeordnet ist, verwaltet. Dazu zählen auch überfällige Einträge, Terminmeldungen und fehlerhafte Einträge. Im Ausgang stehen die Auskünfte zu gestarteten Workflows sowie selbst ausgeführte und weitergeleitete Workitems zur Verfügung. Darüber hinaus wird eine Wiedervorlage angeboten. In der Worklist stehen abhängig davon, in welchem Bereich der Übersichtsliste der Benutzer sich befindet, verschiedene Funktionen zur Verfügung. Es ist eine Liste aller Workitems, die einem Benutzer zu einem Zeitpunkt zugeordnet sind. Der Benutzer ist jeweils einer der Empfänger jedes angezeigten Workitem. In der Workitem-Vorschau, im unteren Bereich des Business Workplace, wird ein in der Worklist markiertes Workitem in einer Vorschaufunktion angezeigt. Diese Anzeige ist kundenindividuell zu konfigurieren. Zusätzlich kann aus der Vorschau heraus auf Objekte und Anlagen des Workitem direkt zugegriffen werden. Durch die verkürzte Sicht auf das Workflow-Protokoll kann auf bisherige Schritte (also einzelne Workitems), deren Bearbeiter und bisher angesprochene Informationsobjekte zugegriffen werden.

68


Der Business Workplace ist somit die wesentliche Schnittstelle zwischen dem Benutzer und dem Workflow-System. Die Zuordnung des Benutzers zu definierten Rollen ist dabei ein wesentliches Merkmal während der Laufzeit der Workflows. 3.4.2.2 Rollen Neben der direkten Zuordnung zu Stellen oder Organisationseinheiten werden Benutzern im SAP-System bestimmte Funktionen über Rollen zugeordnet. Dazu liefert das System ein Rollenkonzept, das den jeweiligen Tätigkeiten im SAP-System entspricht. Für SAP Business Workflow wurden ebenfalls entsprechende Rollen definiert, die Workflow Rollen. Diese resultieren aus einem unterstellten Handlungsablauf bei der Arbeit mit dem SAP Business Workflow und repräsentieren unterschiedliche Aufgabenfelder zur Definitions- und Laufzeit eines Workflows, wodurch sich ein Vorgehensmodell für die Entwicklung bis hin zur Pflege der Workflows ableiten lässt (Brahm, Pargmann 2003). Folgende Rollen sind definiert: x Der Prozessberater identifiziert innerhalb des Betriebs diejenigen Geschäftsprozesse, die mit der Workflow-Technologie abgebildet werden sollen. x Der Workflow-Entwickler implementiert diese Prozesse dann mit Hilfe der Definitionswerkzeuge des SAP Business Workflow. x Der Systemadministrator betreut die Workflows zur Laufzeit und ist für die technische Auswertung zuständig. x Der Prozesscontroller betreut die Workflows aus betriebswirtschaftlicher Perspektive und nimmt entsprechende Auswertungen vor. x Der Sachbearbeiter für Workflows stellt den Endbenutzer im WorkflowKontext dar, der in seinem Workflow-Eingang die ihm zugeteilten Aufgaben bearbeitet. Für jede Rolle wird zusätzlich ein rollenspezifisches Vorgehensmodell beschrieben, so dass sich das gesamte rollenbasierte Vorgehensmodell erst aus der Summe von Überblicksmodell und den Einzelmodellen ergibt. Die Workflow-Rollen sollen die konkreten Anwender des SAP Business Workflow ansprechen, da diese meist nur einen Teil der vorhandenen Information benötigen. Die Sicht aus der Perspektive der Rolle stellt somit eine anwendungsbezogene und damit auch eingeschränkte Sicht auf die Referenzdokumentation dar. Diese richtet sich wiederum nur an den Personenkreis, der einen vollständigen und detaillierten Überblick über die vorhandenen Funktionen benötigt. Abb. 3.8 stellt alle wesentlichen Elemente der SAP Workflow Engine noch einmal abschließend im Gesamtzusammenhang dar (Kosog 2007).


Rollen

Work Items Person

Aufgabe Organisationsstruktur Rollenauflösungsregel

Aufgabe Objekte

Organisationselement

Agent

Position

Workplace

Ausführen Frühester Start Spätester Start Spätestes Ende

Gruppe

Attribute Methoden

Weiterleiten Notiz hinzuf. Ersetzen

Objekte SchlüsselStruktur

69

Ereignisse ABAP

Veröffentlichung & flexible Kopplung

CallTransaktion Include

Trigger

Event

ABAP OO

Funktions Modul Workitem

Workflow

Abb. 3.8: SAP Workflow Engine (in Anlehnung an Kosog 2007)

3.4.3 Workflows und Business Intelligence Integration Mit Einführung des Release 6.10 des Web Application Servers (WAS) ist das vorherige Workflow Information System (WIS) obsolet geworden, da nun direkt Berichte auf Basis von Business Intelligence (BI) erstellt werden können (Marx Gómez et al. 2006). Dabei können jedoch auch Probleme entstehen, weil Workflow Projekte mit BI Anforderungen nicht die Standard Workflow Datenextraktion nutzen können. Hierfür war es bisher notwendig, eine eigene Datenextraktionslogik für den Workflow zu implementieren. Die Abb. 3.9 verdeutlicht den Zusammenhang zwischen den Queries basierend auf InfoCubes im Business Intelligence und den Workitems eines Workflows: Mittlerweile ist es möglich, technische Daten des Workitem in BI als InfoCube darzustellen. Damit sind Fragestellungen, wie z. B. „Wie viele Workflows vom Typ X wurden ausgeführt?“ oder „Wie lange war die durchschnittliche Durchführungsdauer für einen bestimmten Workflowschritt?“ zu beantworten. Diese betriebswirtschaftliche Auswertung von Workflows dient dabei insbesondere zu Informations- und Optimierungszwecken. Zur Beantwortung können zum Beispiel Workload-Analysen zur Ermittlung der Arbeitsbelastung einzelner Mitarbeiter, Planstellen, Stellen oder Organisationseinheiten oder die Workitem-Analysen die-

70


nen. Letztere ermöglichen es, statistische Auswertungen zu Workitems durchzuführen (Dart et al. 2009).

Abb. 3.9: Business Warehouse Integration für SAP Workflow (in Anlehnung an SAP 2007a)

Die zu analysierenden Workitems können dabei zeitlich, in Bezug auf ihren Typ und ihre Aufgabe eingeschränkt werden. Die Ergebnisse der durchgeführten Analysen gibt der Prozesscontroller z. B. an das Management weiter, um Vorschläge zur Optimierung zu unterbreiten, welche dann wiederum zu Änderungen am Workflow durch den Prozessberater und Workflow-Entwickler führen können.

3.5 SAP Business Workflows im Internet Neben SAP Business Workflow findet man in der Literatur auch noch SAP WebFlow. Diese Bezeichnung wurde zu Zeiten des Internet Booms etabliert, um die Internetfähigkeit von SAP Business Workflow hervorzuheben. Heutzutage sind fast alle Funktionen in SAP auch internetfähig, und eine Differenzierung ist nicht mehr notwendig. Daher wird aktuell nur noch die Bezeichnung SAP Business Workflow genutzt (SAP 2009a). Der Begriff SAP WebFlow wird meist nur noch dann genutzt, wenn es allein um die Nutzung von Workflows im Internet geht. In den folgenden Abschnitten werden genau diese Funktionen von SAP Workflows im Internet vorgestellt.

SAP Business Workflows im Internet

71

3.5.1 SAP WebFlow SAP WebFlow bezeichnet die Funktionen, durch die der SAP Business Workflow über das Internet ausgeführt werden kann. Der WebFlow ermöglicht damit die Ausführung eines Workflows über Unternehmensgrenzen hinweg. Dadurch ist es möglich x aus einem Business Workflow heraus XML-Dokumente an andere Systeme zu versenden x aus dem eigenen SAP-System einen Business Workflow auf einem anderen SAP-System zu starten x auf die Ergebnisse eines auf einem anderen System ausgeführten Business Workflows zu reagieren x einen Business Workflow zu starten, wenn ein geeignetes XML-Dokument empfangen wird Der WebFlow ist demnach sowohl in der Lage, auf eingehende XML-Dokumente zu reagieren, als auch selbst XML-Dokumente zu versenden. Der WebFlow unterstützt dazu das Übertragungsprotokoll Wf-XML. Diese XML-Daten können auch ohne Umschlag versendet werden. Wenn ein XML-Dokument im SAPSystem eintrifft, kann ein WebFlow gestartet werden. Das XML-Dokument wird an den WebFlow übergeben, der die erhaltenen Daten weiterverarbeitet. Der WebFlow schickt eine eigenständige Rückmeldung an den Absender des XMLDokuments. Dazu wird der neue Schritttyp Web-Aktivität verwendet. Mit diesem Schritttyp werden die XML-Dokumente versendet, wobei das verwendete Übertragungsprotokoll definiert und festgelegt, ob der WebFlow auf eine Antwort des Empfängersystems warten soll oder nicht.

3.5.2 Empfang und Versand von Dokumenten Als Voraussetzung für den Empfang und Versand dieser XML-Dokumente ist es notwendig, für das SAP-System einen Web-Server und einen Internet Transaction Server (ITS) zu installieren. Versandt werden können selbsterstellte XMLDokumente oder durch den WebFlow aus den Daten generierte Dokumente, die Wf-XML-Dokumente. Der Versand kann dann mit dem Übertragungsprotokoll HTTP (W3C 2009) oder HTTPS (Softed 2010) erfolgen und ist immer dann abgeschlossen, wenn das aufzurufende System mit einer http-Nachricht geantwortet hat. Die folgende Abb. 3.10 zeigt schematisch den Ablauf dieser Web-Aktivität:

72


Abb. 3.10: Ablauf einer Web-Aktivität

Damit durch ein ankommendes Wf-XML-Dokument ein Business Workflow auf einem SAP-System gestartet werden kann, muss ein Service aktiviert sein, der das ankommende Wf-XML-Dokument verarbeitet und die darin enthaltenen Daten in die Importparameter des zu startenden Business Workflows schreibt. Durch diesen Vorgang wird der Business Workflow dann gestartet und ausgeführt. Grundsätzlich sind folgende Szenarien beim Versand und Empfangen möglich: x Versand eines XML-Dokuments an ein anderes System: Ein selbsterstelltes XML-Dokument von SAP-System A wird an System B versandt, d.h. die WebAktivität versendet das XML-Dokument an den angegebenen Empfänger. Enthält die http-Antwort von B ein XML-Dokument, kann dieses im Workflow-Container gespeichert werden, und der Business Workflow wird auf System A fortgesetzt. x Versand eines Wf-XML-Dokuments an ein anderes System: Hierbei wird das zu versendende XML-Dokument durch den WebFlow selbst erstellt, an System B als Wf-XML-Dokument versandt und die http-Antwort wird vom WebFlow ausgewertet. Anschließend wird der Business Workflow auf System A fortgesetzt. x Versand eines Wf-XML-Dokuments an ein anderes System mit Rückmeldung: Bis zur eingehenden http-Antwort verläuft dieses Szenario analog zu dem Szenario ohne Rückmeldung, dann wartet jedoch die Web-Aktivität auf ein WfXML-Antwortdokument. Die darin enthaltenen Daten schreibt die WebAktivität in den Workflow-Container, und der Business Workflow wird dann auf dem System A fortgesetzt. x Versand eines Wf-XML-Dokuments an ein anderes SAP-System und Start eines Business Workflows: Eine weitere Möglichkeit ist es, durch den WebFlow auf System B einen Business Workflow zu starten. Dazu muss aus den Daten zunächst ein Wf-XML-Dokument erstellt werden. Die notwendige URL, an die das Wf-XML-Dokument geschickt wird, kann dafür durch einen Wizard gene-

Integration anderer Werkzeuge und Anwendungen

73

riert werden. Damit sichergestellt ist, dass der zu startende Business Workflow auf System B alle notwendigen Daten erhält, muss die Schnittstelle des aufzurufenden Business Workflows vollständig bekannt sein. Die http-Antwort wird anschließend vom WebFlow ausgewertet und der Business Workflow auf System A fortgesetzt. x Versand eines Wf-XML-Dokuments an ein anderes SAP-System und Start eines Business Workflows mit Rückmeldung: Dieses Szenario verläuft bis zur eingehenden http-Antwort analog zum vorher beschriebenen Szenario ohne Rückmeldung. Wenn der Business Workflow auf dem System B beendet ist, werden die Daten der Exportparameter der Schnittstelle als Wf-XMLAntwortdokument wieder an den aufrufenden Business Workflow des Systems A zurückgesandt. Die Web-Aktivität schreibt diese Daten dann in den Workflow-Container und setzt den Business Workflow auf System A fort. x Start eines Business Workflows durch ein ankommendes Wf-XML-Dokument ohne Antwort: Bei einem ankommenden Wf-XML-Dokument startet der WebFlow den genannten Business Workflow und schreibt die darin enthaltenen Daten in die passenden Importparameter der Schnittstelle. Der WebFlow sendet eine http-Antwort zurück. x Start eines Business Workflows durch ein ankommendes Wf-XML-Dokument mit Antwort: Dieses Szenario verläuft analog zu dem vorherigen Szenario ohne Antwort. Nach Beendigung des Business Workflows erstellt der WebFlow ein Wf-XML-Antwortdokument, das die Daten der Exportparameter der Schnittstelle enthält und an das aufrufende System zurücksendet.

3.6 Integration anderer Werkzeuge und Anwendungen Nach der Vorstellung der wesentlichen Prinzipien, Funktionen und Werkzeuge zur Definition und zur Ausführung von Workflows mit Hilfe von SAP Business Workflows werden im folgenden Abschnitt die Bedeutung der Integration und der Schnittstellen zu anderen Werkzeugen und Anwendungen betrachtet.

3.6.1 Integration von ARIS Die ARIS Plattform der IDS Scheer AG stellt integrierte Softwareprodukte zur Verfügung, die Unternehmen bei der kontinuierlichen Verbesserung ihrer Geschäftsprozesse unterstützen. Dabei werden alle Phasen eines BPM-Projektes abgedeckt, von der Strategiedefinition über das Prozessdesign und die Überführung der Modelle in die IT bis zum Controlling der ausgeführten Prozesse. ARIS ist in drei Plattformen für Strategie, Design und Implementierung strukturiert mit je-

74


weils verschiedenen Einzelprodukten vom ARIS Business Architect über den ARIS Business Designer bis zum ARIS BI (Business Intelligence) Modeler. ARIS selbst verfügt über keine eigene Ausführungsebene, sondern bietet Schnittstellen zu ERP-Anbietern wie SAP bzw. Middleware für Microsoft oder Oracle. Unter dem Stichwort „Modellieren statt Programmieren“ ist es Ziel, modellierte Geschäftsprozesse mit möglichst wenig Aufwand in SAP zu übertragen. Hierfür existieren eine Reihe von der IDS Scheer AG und SAP teilweise gemeinsam entwickelte Werkzeuge. So bietet die IDS Scheer AG z. B. speziell für SAP adaptierte Produkte wie den ARIS Business Architect for SAP NetWeaver. Weitere ausgewählte Werkzeuge und Vorgehensweisen für das integrierte BPM von SAP mit ARIS werden im Folgenden vorgestellt.

SAP NetWeaver

Prozessmodellierung mit ARIS for SAP NetWeaver Geschäftsprozesse bilden die Grundlage für Workflows. Aus diesem Grund gibt es eine Reihe von Abhängigkeiten, die bereits bei der Prozessmodellierung hinsichtlich ihrer späteren Automatisierung in Form von Workflows beachtet werden müssen. ARIS for NetWeaver ist eine gemeinsam entwickelte Anwendung der IDS Scheer AG und SAP. Es bietet die Möglichkeit, die Unternehmensprozesse aus fachlicher Sicht zu analysieren und auf dieser Basis entsprechende betriebswirtschaftliche Anforderungen an SAP zu formulieren. Dazu enthält ARIS for SAP NetWeaver eine durchgängige Beschreibung der Prozessarchitektur von Businessmodellen bis zur Implementierung der Prozesse über den SAP Solution Manager, SAP PI (SAP Process Integration) und SAP Business Workflow (Krimmel, Orb 2010) (Abb. 3.11).

Abb. 3.11: Prozessmodellierung mit ARIS für SAP NetWeaver (in Anlehnung an SAP2006b)


75

Dabei lässt sich eine dreistufige Vorgehensweise unterteilen: Auf der obersten Ebene, dem „Process Architecture Model“, werden zunächst die Architektur der Geschäftsprozesse rein betriebswirtschaftlich und ohne Bezug auf die Software ausgearbeitet. Ziel ist es, Soll-Prozesse für das Unternehmen zu definieren. Es existiert eine Vielzahl von Modellierungsfunktionen (z. B. EPK-Modellierung), die gut für die Abbildung von Business Szenarios, Geschäftsprozessen und Prozessschritten geeignet und auf einander abgestimmt sind. Weiterhin können auch vordefinierte Business Szenarios und Geschäftsprozesse als Vorlage genutzt und auf das Unternehmen angepasst werden. ARIS for SAP NetWeaver ermöglicht dabei, die Prozessinformationen zentral in einem mehrsprachigen Repository zu verwalten. Auf der zweiten Ebene (Process Configuration Model) werden die einzelnen Prozesse konfiguriert und die einzelnen Prozessschritte definiert. Das im ersten Schritt erstellte Business Modell wird in ein Modell zur Prozesskonfiguration überführt. Hier werden auch die für die Umsetzung erforderlichen Maßnahmen für das Customizing von SAP sowie die Definition der im Rahmen des Monitoring zu überwachenden Werte identifiziert. Die entwickelten Prozessmodelle lassen sich automatisch mit dem SAP Solution Manager synchronisieren, um sie dann in der Unternehmensprozessarchitektur von SAP umzusetzen. Für die Übernahme von in ARIS modellierten Prozessen gibt es im SAP Solution Manager direkt integrierte Funktionen (Abb. 3.12).

Abb. 3.12: Synchronisation zwischen ARIS Business Architekt for SAP und SAP Solution Manager (IDS Scheer 2010)

76


Auf der dritten Ebene, dem „Process Execution Model“, werden die modellierten Prozessflüsse konkret zur Ausführung in SAP PI und anderen Applikationen genutzt. Die Entwicklungsumgebung von SAP PI nutzt dabei den BPEL-Standard (Business Process Execution Language), um die in ARIS abstrahierte Prozesslogik auf die Laufzeitumgebung von SAP PI zu übertragen. Hier werden dann Schnittstellen zu SAP und Non-SAP-Applikationen in einer übergreifenden Prozesslogik orchestriert. SAP Solution Manager Der SAP Solution Manager ist das von SAP bereitgestellte Produkt, das bei der Implementierung und dem globalen Roll-Out von SAP-Anwendungen unterstützt, und eine weiteres Beispiel dafür, wie Workflows zum Einsatz kommen. Dabei werden auch der Betrieb und die Instandhaltung sowie das Änderungsmanagement berücksichtigt. Für den Bereich BPM verfügt der Solution Manager über ein integriertes „Business Process Repository“ mit entsprechenden Referenzprozessbeschreibungen sowie konfigurationsrelevanten Inhalten und Dokumentationen. Im Rahmen des Projektmanagements stehen Funktionen zur Konfiguration und zum Testen der zu implementierenden Prozesse bereit. Die Definition der Geschäftsprozesse erfolgt über eine grafische Benutzeroberfläche, und Projektdokumentationen können in allen gängigen Formaten (PPT, XLS, DOC) gespeichert werden. Auch die durchgängige Konfiguration von Geschäftsprozessen über mehrere verteilte SAP-Systeme wird unterstützt (Volerming, Scholz 2005). ARIS Value Engineering (AVE) ARIS Value Engineering (kurz AVE) ist ein relativ neuer von der IDS Scheer AG entwickelter Ansatz für die Durchführung von SAP-Implementierungen, beziehungsweise für die Optimierung einer bestehenden SAP-Implementierung. AVE ist ein ganzheitlicher, modellbasierter Ansatz, der alle Schlüsselaspekte einer Implementierung (Prozesse, Systeme, Daten, Organisation) berücksichtigt. Im Mittelpunkt stehen die SAP-Referenzprozesse. AVE ist hierbei nicht nur ein Rahmenkonzept, sondern es wird der komplette BPM-Kreislauf mit den Phasen Strategie, Design, Implementierung und Controlling durchlaufen (Brabänder, Erbach 2007) (Abb. 3.13). Für jede Arbeitsphase gibt es standardisierte Arbeitspakete, die aufeinander aufbauen und die bekannten Werkzeuge wie die ARIS-Plattform, den SAP Solution Manager und SAP NetWeaver Process Integration verwenden. Die Schritte der einzelnen Phasen sind in Abb. 3.13 schematisch dargestellt. Für jede einzelne Phase sind die benötigten Inhalte, die Darstellungsform und die zu verwendenden Werkzeuge vorgegeben. Damit wird eine einheitliche und prozessorientierte Vorgehensweise gesichert.


77

Abb. 3.13: Vorgehensweise für AVE für SAP (in Anlehnung an Seidler 2006)

3.6.2 Schnittstellen zu Mail-Systemen Für die effektive Benachrichtigung innerhalb des BPM in SAP ist die Integration von Mailsystemen in die Geschäftsprozesse in vielen Fällen von hoher Bedeutung. Dies ist der Tatsache geschuldet, dass beispielsweise ein Großteil der Anwender nicht, beziehungsweise nicht ständig, den Workplace von SAP verwenden, über den Benachrichtigungen innerhalb eines Geschäftsprozesses zugestellt werden könnten. Die Mehrheit der Anbieter nutzt jedoch durchgehend ihr E-Mail-System, so dass Benachrichtigungen hierüber sehr schnell zur Kenntnis genommen werden. Dabei ist es irrelevant, welches Mailsystem zum Einsatz kommt. Für die Einbindung von E-Mails in den Workflow existieren zwei Voraussetzungen. Zum einen sind in den Workflows die Benachrichtigung über E-Mail bei bestimmten Schritten zu berücksichtigen und zum anderen müssen diese Nachrichten über Schnittstellen zu den jeweiligen Mailsystemen (z. B. Microsoft Exchange/ Outlook, Lotus Notes) zugestellt werden.

78


Für die Anbindung der Mailsysteme sind die verschiedenen Schnittstellen von SAP unabhängig von den Workflow-Komponenten nutzbar. Die Möglichkeiten sind hier release-abhängig beziehungsweise unterschiedlich bezüglich der genutzten Komponenten. Wichtige Tools sind zweifelsohne der SAP Exchange Connector und das Internet-Mail-Gateway. MAPI-fähige Mailapplikationen können über das SAP MAPI SPI (SAP Message Application Programming Interface Service Provider Interface) angebunden werden. Die Unterstützung der SAP MAPISchnittstelle ist jedoch auslaufend. Für die Anbindung von Lotus Notes bietet SAP eine SAP-WAPI (Workflow Programming Interface) basierte Lösung, die mit der MAPI-Schnittstelle vergleichbar ist. Eine Neuentwicklung ist das Framework für Extended Notifications for SAP Business Workflow (Abb. 3.14): SAP Business Workflow

SAP GUI oder Portal UWL

Workitems sammeln

Erweiterte Nachrichten

Endanwender

Workitems ausführen

E-Mails senden

E-Mail E-Mail Client

Abb. 3.14: Extended Notifications for SAP Business Workflow (in Anlehnung an SAP2007b)

Dieses bietet eine Reihe von hilfreichen Funktionen zur Mail-Benachrichtigung innerhalb von Workflows: x Benachrichtigung des Benutzers über Workitems, die nicht voranschreiten x Direkte Versendung von Workitems an Groupware-Produkte wie Microsoft Outlook und Lotus Notes mit direkter Rückmeldemöglichkeit an BackendTransaktionen x Einstellung individueller Mailbenachrichtigungen x Aggregierte Benachrichtigungsmails mit mehreren Workitems Wie die vorgestellten Beispiele zeigen, wird der Integration von Mailprodukten von SAP eine hohe Aufmerksamkeit geschenkt. Ziel ist es, auch Benutzer in die Geschäftsprozesse einzubinden, die wenig oder auch gar nicht mit SAP arbeiten.


79

3.6.3 Schnittstellen zu Microsoft Produkten Die Integrationstiefe von SAP in Microsoft-Produkte ist trotz mittlerweile jahrzehntelanger Koexistenz immer noch sehr unterschiedlich bezüglich der Funktionen und abhängig vom jeweiligen Microsoft-Produkt. Eine starke gegenseitige Integration von SAP und Microsoft ist jedoch aus verschiedenen Gründen von enormer Bedeutung und hat ein hohes Potential zur Verbesserung der Abbildung der Geschäftsprozesse ohne Brüche. So setzt in der heutigen Ist-Situation ein Großteil der Unternehmen nicht nur in der Infrastruktur Microsoft Produkte ein, sondern auch im Bereich der Kommunikation und Informationsbereitstellung. Innerhalb des Unternehmens wiederum nutzt ein Großteil der Anwender diese Produkte. In der Microsoft-Terminologie werden diese Anwender „Information Worker“ genannt. In der Regel nutzt jedoch nur ein kleiner Teil dieser „Information Worker“ SAP. Um alle Anwender in die Geschäftsprozesse in SAP einzubinden, birgt die Integration der Microsoft-Produkte daher ein hohes Potential. Neben dem oben schon erwähnten Microsoft Exchange Server und den Office Produkten wie Microsoft Word und Microsoft Excel nehmen dabei Microsoft Sharepoint, Microsoft Dynamics CRM und der Microsoft BizTalk Server Schlüsselpositionen ein (Abb. 3.15).

Abb. 3.15: Übliche Verteilung zwischen SAP Power Usern und Information Workern in Unternehmen (Dopp 2009)

Microsoft BizTalk Server Der BizTalk Server von Microsoft unterstützt die Integration von Geschäftsprozessen innerhalb der (heterogen) IT-Landschaft eines Unternehmens. Einsatz findet der BizTalk Server in folgenden Aufgabenbereichen: x Business Process Management (BPM) x Service Orientierte Architekturen (SOA) x Enterprise Application Integration (EAI)

80


Der Microsoft BizTalk Server bietet auf verschiedenen Ebenen Instrumente für die Integration von SAP-Geschäftsprozessen an. Ein wesentliches Instrument ist die im LOB (line-of-business) Adapter-Pack enthaltene SAP-Schnittstelle, die auf WCF (Windows Communication Foundation) basiert. Die Adapter-Schnittstelle bietet zwei wesentliche Funktionen: x Einen Schema-Generator zur Erzeugung von XSD-Schemata für XMLSchnittstellen zum Aufruf von BAPI´s, RFC´s und Idocs. Die Übertragung der Daten erfolgt über das Simple Object Access Protokoll (SOAP). x Ein Konfigurationsset zur Erstellung von Schnittstellen für den SAP Connector für Microsoft.NET und zur Erstellung von Routing-Nachrichten. Das LOB SDK (Software Development Kit) verfügt über eine Integration von Microsoft Visual Studio und ermöglicht es Entwicklern, angepasste Schnittstellen über die im BizTalk Server verfügbaren Adapter hinaus zu entwickeln. Microsoft Sharepoint Der Microsoft Office Sharepoint Server ist eine integrierte Suite, die umfassende Content Management- und Suchfunktionen bietet und damit zur Beschleunigung von Geschäftsprozessen über Bereichs- und Unternehmensgrenzen hinweg beiträgt. Die Oberfläche von Sharepoint wird dem Anwender über den Internet Explorer zur Verfügung gestellt und der Anwender kann direkt über die HTMLWerkzeuge von Sharepoint neue Seiten erstellen. Sharepoint kann eine zentrale Rolle bei der Einbindung von SAPNichtanwendern in die SAP-Geschäftsprozesse einnehmen. Dabei bleibt in der Regel die Workflow-Logik innerhalb des SAP-Systems, und Sharepoint dient zur Bereitstellung von Informationen und Genehmigungsschritten, beispielsweise in Form von Formularen. Ergänzende Workflow Schritte können jedoch auch auf Basis der Windows Workflow Foundation oder den Sharepoint-Workflows innerhalb von Sharepoint erstellt werden (Dopp2009). Für die Bereitstellung und Bearbeitung von Workflows gibt es innerhalb von Sharepoint verschiedene Möglichkeiten. So können Workflows über das Workflow-Cockpit auf der Webseite des Benutzers bearbeitet werden. Eine Massenbearbeitung (z. B. von Urlaubsanträgen) ist über die sogenannte WorkflowPowerbox möglich. Hier können Workflowentscheidungen für mehrere Prozessinstanzen in einem einzelnen Schritt getroffen werden. Für die Programmierung von Schnittstellen zwischen SAP und Sharepoint bietet sich das WCF LOB (line of business) SDK (Software Development Kit) von Microsoft an, das auch beim BizTalk Server Verwendung findet. Ein komfortables und auf speziell diese Anforderungen zugeschnittenes Entwicklungswerkzeug stellt beispielsweise der Service Studio-Designer der Sitrion Services GmbH dar, der sich in die Microsoft Visual Studio Umgebung integriert (Dopp2009). Die Architektur ist in folgender Abb. 3.16 dargestellt:


81

Abb. 3.16: Sitrion Service Studio Designer (Dopp 2009)

Hier sind Möglichkeiten gegeben, bestehende SAP BAPIs, aber auch SAP Enterprise Services und SAP Business Intelligence Schnittstellen, in den Service zu integrieren und die Schnittstelle dieser Backend-Funktionalitäten für die Nutzer eines Dienstes in Sharepoint aufzubereiten.

3.6.4 Microsoft Dynamics CRM Microsoft Dynamics CRM (ursprünglich Microsoft CRM genannt) ist die CRMLösung, die von Microsoft selbst entwickelt und 2004 auf den Markt gebracht wurde. Microsoft ist eine integrative auf die Geschäftsprozesse von Unternehmen unterschiedlicher Branchen anpassbare CRM-Lösung, deren Schwerpunkte in den Bereichen Vertrieb, Marketing und Service liegen. Auch in diesem Bereich gibt es zahlreiche Einsatzmöglichkeiten für die Automatisierung von Geschäftsprozessen in Form von Workflows, daher wird in diesem Abschnitt die Integration dieser Lösung mit SAP näher betrachtet. Microsoft Dynamics CRM bietet selbst keine Standard-Schnittstelle zu SAP. Allerdings sind hier Möglichkeiten der Anbindung über proprietäre Schnittstellen

82


oder den Microsoft BizTalk Server als Middleware gegeben. Eine Anbindung ist in jedem Fall sinnvoll, um Daten und Nachrichten zwischen den beiden Systemen auszutauschen, zum Beispiel, um innerhalb des Lieferprozesses einen Lieferstatus von SAP an CRM weiterzugeben und dort eine Benachrichtigung des Kunden anzustoßen. Auch die Möglichkeit des Zugriffs aus CRM gezielt auf bestimmte Datensätze in SAP ist in vielen Fällen sinnvoll. SAP bietet hierfür einen parametrisierten GUI-Aufruf. Generell ist es bei Schnittstellen zwischen CRM und ERP-Systemen sinnvoll, die Komplexität möglichst schon in der Konzeption zu reduzieren. Auf Datenebene ist es beispielsweise hilfreich, die „Datenhoheit“ über die verschiedenen Segmente festzulegen. Definiert man das CRM-System als Master für Adressdaten und das ERP-System als Master für Belegdaten, so können verbunden mit entsprechenden Eingaberestriktionen unidirektionale statt bidirektionale Schnittstellen für den Datenaustausch konzipiert werden.

3.7 Zusammenfassung und Ausblick Das Workflow Management von SAP in Form des SAP Business Workflow ist ein wichtiger Bestandteil der SAP-Lösungen bis hin zu der Umsetzung in der aktuellen SAP NetWeaver 7.1 Architektur. Es stellt nicht nur die Grundfunktionen zum Anlegen, Ausführen und Reporten des Workflows bereit, sondern verfügt über zahlreiche Schnittstellen zu anderen Funktionen und stellt eine Integration zu Anwendungssysteme anderer Hersteller bereit, so dass diese in den Workflow einbezogen werden können (z. B. Mail Integration). In diesem Kapitel wurden die grundlegenden Funktionen erläutert und die wichtigsten Werkzeuge des SAP Business Workflow vorgestellt. Zudem wurde sowohl die funktionale als auch die technische Integration zu Herstellern anderer Anwendungssysteme vorgestellt. SAP hat im Rahmen ihrer SAP NetWeaver Architektur das Business Process Management und SAP Workflow vollständig integriert. Neuere Tendenzen gehen nun in Richtung einer Verknüpfung von Business Intelligence und dem Business Process Management (Hagemann Snabe et al. 2009). Die Überarbeitung der Prozesse (Business Process Reengineering) spielt dabei ebenso eine große Rolle wie auch die kontinuierliche Verbesserung (Continuous Improvement) der Prozesslandschaft. Hierzu wurde ein neuer Architekturansatz entwickelt, in dem die SAP Business Suite 7.0 auch die serviceorientierte Architektur (SOA) unterstützt (Hagemann Snabe et al. 2009).



Frage


1

Welche Rolle spielen die Aufgabe und das Workitem innerhalb des Workflows?

3.1

2

Wie ist der Zusammenhang zwischen dem Organisationsplan eines Unternehmens und der universellen Worklist eines Users?

3.1

3

Welche Unterschiede gibt es zwischen dem SAP Business Workflow und den Guided Procedures?

3.2

4

Welchen Zusammenhang gibt es zwischen den Business Objects und den Workitems?

3.2

5

Was geschieht, wenn ein Workflow kein auslösendes Ereignis enthält?

3.2.1

6

Welche Rollen werden im Rollenkonzept des SAP Business Workflows differenziert?

3.2.2.2

7

Durch welche Integration ist es möglich, ein Reporting von Workflows durchzuführen?

3.2.3

8

Wie ist der Ablauf einer Web-Aktivität im SAP WebFlow definiert?

3.2.2

9

Welche Rolle spielt SAP NetWeaver bei der Prozessmodellierung mit ARIS für das SAP-System?

3.4.1.1

10

Wieso ist eine Mailintegration in Workflow Management Systeme sinnvoll und welche Funktion übernimmt sie?

3.4.2

Diskussionsfragen Diskutieren Sie warum Workflow Management Systeme trotz einer umfangreichen Prozessintegration heutiger ERP-Systeme notwendig sind, und worin die Unterschiede liegen. Stimmen Sie der folgenden Aussage zu? Gut definierte Workflows ersetzen die kontinuierliche Verbesserung der Geschäftsprozesse. Begründen Sie Ihre Antwort.

Blickpunkt Internet-Ressourcen Weiterführende Informationen zu den aktuellen SAP Workflow Produkten finden Sie auf den Internet-Seiten von SAP, insbesondere im SAP Community Network, dem SAP Developer Network (SDN): unter www.sdn.sap.com.

83

84


Internet-Recherche 1.

2.

3.

Rufen Sie die Internet-Seiten von SAP auf und recherchieren Sie, welche Produkte zum Workflow Management in der aktuellen Version von SAP NetWeaver eingesetzt werden. Erstellen Sie eine Übersicht, in der Sie die neuen Ansätze den alten Versionen gegenüberstellen und Vorund Nachteile bewerten. Recherchieren Sie auf den Internet-Seiten der IDS Scheer AG nach dem ARIS Business Architekt for SAP und zeigen Sie die Vorteile dieser Lösung für die Prozessmodellierung im Gegensatz zum SAP Solution Manager auf. Gehen Sie auf die Internet-Seiten von Microsoft und recherchieren Sie die Integrationsmöglichkeiten von Microsoft Dynamics NAV mit dem SAP Business Workflow System. Stellen Sie die Unterschiede und Gemeinsamkeiten tabellarisch gegenüber.

3.9 Literatur Brabänder E, Erbach F (2007) AVE for SAP – Eine Vorgehensweise für das Geschäftsprozessmanagement mit SAP. Springer, Berlin, Heidelberg Brahm M, Pargmann H (2003) Workflow Management mit SAP WebFlow. Das Handbuch für die Praxis. Springer, Berlin, Heidelberg Dart J, Dick E, Gatling G, Hilss O, Kapoor S, Kempf S, Keohan S, Kosog Th, Médaille P, Pokraka M, Rickayzen A, Sabnani S, Sedlmayr J, Sohn T (2009) Practical Workflow for SAP. 2. Aufl. SAP Press, Bonn Dopp M (2009) SAP-Self-Services in SharePoint – Selbst ist der Mitarbeiter. In: SHAREPoint Magazin, Sonderheft 2009, S 2-7 Gatling G (2010) Workflow-Management mit SAP. 2. Aufl. SAP Press, Bonn Goebel A, Ritthaler D (2005) SAP Enterprise Portal – Technologie und Programmierung. Nachdruck 2005. SAP Press, Bonn Hagemann Snabe J, Rosenberg A, Møller C, Scavillo M (2009) Business Process Management – the SAP Roadmap. SAP Press, Bonn IDS Scheer AG (2010) Umsetzung und Optimierung von geschäftsprozessbasierten SAPLösungen. http://www.idsscheer.com/de/Software/ARIS_Software/ARIS_for_SAP_NetWeaver/7782.html. Abruf 12.02.2010 Kosog T (2007) Workitems, UWL and Web Dynpro for ABAP. http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/20f4843e-314f-2a10-2a888c4afa20dda6&overridelayout=true. Abruf 11.02.2010 Krimmel M, Orb J (2010) SAP NetWeaver Process Integration. 2. Aufl. SAP Press, Bonn Marx Gómez J, Rautenstrauch C, Cissek P, Grahler B (2006) Einführung in SAP Business Information Warehouse. Springer, Berlin, Heidelberg Marx Gómez J, Rautenstrauch C, Cissek P (2008) Einführung in Business Intelligence mit SAP NetWeaver 7.0. Springer, Berlin, Heidelberg SAP AG (2004) SAP Step Types and their Symbols. http://help.sap.com/saphelp_nw04/Helpdata/EN/c5/e4b74f453d11d189430000e829fbbd/fram eset.htm. Abruf 11.02.2010

Literatur

85

SAP AG (2006a) Understanding Business Process. Tools Available in SAP NetWeaver. http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/60ea26d5-214f-2a10-f78f904396c1be69&overridelayout=true. Abruf 11.02.2010 SAP AG (2006b) Using Forms in Workflows and Guided Procedures. http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/1098f36e-304f-2a10-709296a74210aa8d&overridelayout=true. Abruf 11.02.2010 SAP AG (2007a) Revisiting SAP Business Workflow – SAP NetWeaver Product Management. https://www.sdn.sap.com/irj/scn/index;jsessionid=(J2EE3414700)ID1019675450DB1025115 2055200603467End?rid=/library/uuid/60cd3e04-204f-2a10-ba86852f2a84f8c8&overridelayout=true. Abruf 11.02.2010 SAP AG (2007b) Workflow extended notifications. http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/f01448bb-324f-2a10-fe96cb36c26a3089&overridelayout=true. Abruf 11.02.2010 SAP AG (2009b) Workflow FAQ – General Questions. https://wiki.sdn.sap.com/wiki/display/HOME/1.+General+Questions. Abruf 11.02.2010 Seidler S (2006) From Business Process to SAP Configuration. Deployment of ARIS for SAP NetWeaver and SAP Solution Manager in Projects. ARIS Expert Paper, IDS Scheer AG. http://www.ids-scheer.com/set/5944/ARIS_Expert_Paper__NetWeaver_Deployment_Seidler_2006-09_en.pdf. Abruf 11.02.2010 Softed Systems (2010) Wie funktioniert HTTPS? http://www.softed.de/fachthema/https.aspx. Abruf 11.02.2010 Volmering T, Scholz T (2005) Business Process Management mit SAP NetWeaver und ARIS – Eine gemeinsame Sprache für Business und IT. Springer, Berlin, Heidelberg W3C (2006) Hypertext Transfer Protocol Specifications. http://www.w3.org/Protocols/. Abruf 11.02.2010 Wenzel P (2001) Vertrieb und Workflow mit SAP R/3, 1. Aufl. Vieweg, Braunschweig, Wiesbaden Workflow Management Coalition (1999) Terminology and Glossary, 3. Aufl, Document Number WFMC-TC-1011. Workflow Management Coalition, Winchester. http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf. Abruf 11.02.2010

4 Einführung in SAP Process Integration 4.1 Lernziele Nach der Lektüre von Kapitel 4 können Sie die folgenden Fragen beantworten: x Welche Anforderungen werden an eine Integrationsplattform gestellt und wie werden sie am Beispiel der SAP PI erfüllt? x Über welche Design-Artefakte werden in der SAP PI Schnittstellen bzw. Mappings beschrieben? x Welche Beschreibungen eines Integrationsprozesses werden zur Design-Zeit, welche zur Konfigurationszeit erfasst? x Welche Aufgaben übernimmt das System Landscape Directory in der SAP PI? x Welche Konfigurationsobjekte werden in der SAP PI verwendet?

4.2 Einleitung Integrationsplattformen werden wie in Kapitel 2 dargestellt zur technischen Implementierung, Steuerung und Überwachung sowohl innerbetrieblicher als auch unternehmensübergreifender Geschäftsprozesse eingesetzt. In den Fallstudien dieses Buches wird die Integrationsplattform SAP NetWeaver Process Integration (SAP PI) verwendet. SAP NetWeaver Process Integration ist eine offene Integrations- und Anwendungsplattform und bietet Werkzeuge für die Umsetzung einer serviceorientierten Architektur für Geschäftsanwendungen (Enterprise SOA) an. Weitere Informationen zur SAP PI finden Sie im Abschnitt „Literatur“ dieses Kapitels. Da es sich bei der SAP PI um eine Weiterentwicklung der SAP Exchange Infrastructure XI handelt, ist die Trennlinie zwischen XI und PI nicht immer klar zu ziehen und je nach zeitlichem Bezug und Release werden die Begriffe synonym verwendet. Nach einer kurzen Darstellung der allgemeinen Anforderungen an Integrationsplattformen, werden die wichtigsten Funktionen und Entwicklungsobjekte von SAP PI im Überblick gezeigt. Der konkrete Umgang mit SAP PI wird in den sich anschließenden Fallstudien im Detail erläutert.

88

Einführung in SAP Process Integration

4.3 Anforderungen an Integrationsplattformen Bei der Integration von Anwendungssystemen wird häufig zwischen zwei Integrations-Architekturen unterschieden (Abb. 4.1). Während bei der Punkt-zu-PunktIntegration die zu integrierenden Systeme direkt miteinander kommunizieren, werden in der Hub- & Spoke-Architektur die Nachrichten über eine zentrale Integrationsplattform ausgetauscht. Die Hub- & Spoke-Architektur wird häufig bei komplexen Systemlandschaften bevorzugt, weil (i) die Anzahl der Schnittstellen im Vergleich zur Punkt-zu-Punkt-Integration deutlich geringer ist, und (ii) das Integrationswissen aus den zu integrierenden Systemen separiert werden kann.

Hub & Spoke

Punkt-zu-Punkt

Anw

Anw

Anw

Anw Hub

Anw

Anw

Anw

Anw

Anw Anw

Anw = zu integrierende IT-Anwendungen

Abb. 4.1: Integrationsarchitekturen

Die Kernaufgabe einer Integrationsplattform (IP) besteht darin, eingehende Nachrichten, die von unterschiedlichen Systemen an die IP geschickt werden, an geeignete Empfänger weiterzuleiten. Da den Sendern solcher Nachrichten die späteren Empfänger in der Regel nicht bekannt sind (die Separation des Integrationswissens aus den Anwendungen ist ein wesentliches Ziel der sog. Hub- & SpokeArchitekturen), besteht die erste Herausforderung an die IP darin, ein Regelwerk abzubilden, mit dem entsprechende Nachrichtenstrecken konfiguriert werden können. Da die beteiligten Systeme auf unterschiedliche Schnittstellentechnologien (z.B. SOAP oder Java Message Service) und -formate (z. B. Odette) aufsetzen, besteht eine weitere Herausforderung darin, innerhalb eines Geschäftsprozesses Nachrichten zwischen unterschiedlichen technischen Formaten zu konvertieren. Schließlich beschreiben die kommunizierenden Systeme aufgrund fehlender Standards die gleichen Sachverhalte häufig mit abweichenden Wertebereichen (Datenkonflikte) und in unterschiedlichen Strukturen (Schemakonflikte). Eine Integrationsplattform muss daher Funktionen zur Verfügung stellen, mit denen entsprechende Darstellungen transformiert werden können.

Anforderungen an Integrationsplattformen

89

Das folgende Beispiel enthält zwei Darstellungen einer CO2-Emission. Ein Datenkonflikt liegt bei den unterschiedlichen Wertebereichen der Einheiten, ein Schemakonflikt bei der unterschiedlichen Darstellung der Emissionsart vor: Darstellung A Darstellung B Typ: CO2-Emission Kategorie: Emission Menge: 1,234 Material: CO2 Einheit: kg Menge 1.234 Einheit: 10 Bei der Abbildung unternehmensübergreifender Prozesse treten häufig Konstellationen auf, in denen der genaue Nachrichtenfluss erst zur Laufzeit des Prozesses festgelegt werden kann. In der dritten Fallstudie dieses Buches werden etwa Emissionsdaten zu Produkten von Lieferanten abgerufen. Nur wenn eine solche Anfrage erfolglos ist, weil etwa der Lieferant die Informationen nicht liefern kann, muss eine Folgeverarbeitung angestoßen werden. Um solche komplexen Integrationsprozesse abbilden zu können, muss die IP in der Lage sein, einfache Kontrollstrukturen (Selektionen, Iterationen) abzubilden. Wie zuvor erwähnt haben in Hub- & Spoke-Architekturen die am Geschäftsprozess beteiligten Systeme in der Regel keinerlei Kenntnisse der weiteren Systeme. Vor diesem Hintergrund kann die Überwachung des Nachrichtenflusses ausschließlich von der IP als zentraler Instanz wahrgenommen werden. Eine IP muss somit Funktionen zum Monitoring der Nachrichtenflüsse und Prozesse vorhalten. Tabelle 4.1 stellt eine Übersicht über die genannten Anforderungen an Integrationsplattformen und die zur Lösung erforderlichen Elemente und Konzepte dar. Tabelle 4.1: Anforderungen an Integrationsplattformen Probleme und Anforderungen

Elemente und Konzepte

Schema- und Datenkonflikte

Mapper übersetzen zwischen unterschiedlichen Strukturen und Vokabularen

Ortstransparenz

Routing ermöglicht transparente Speicherung und Nutzung der Systemlandschaft

Verschiedene technische Formate

Adapter Engine vermittelt zwischen verschiedenen technischen Schnittstellen (z.B. JDBC) und Nachrichtenprotokollen (z.B. SOAP)

Trennung von Belangen und Wiederverwendbarkeit

Trennung in Artefakte des Entwurfs und der Konfiguration

Wartbarkeit

Versionierung ermöglicht Weiterentwicklung

Prozessorientiernug

Process Engine bildet Abläufe und komplexe Kontrollstrukturen ab

90


4.4 Systemarchitektur SAP PI Die Implementierungsphasen von Integrationsprozessen auf der SAP PI sind in Tabelle 4.2 dargestellt: zunächst müssen alle beteiligten internen Systeme und Softwarekomponenten gepflegt werden. Im nächsten Schritt sind alle statischen Beschreibungen des Integrationsszenarios im ESR zu hinterlegen. Anschließend können die abzubildenden Nachrichtenstrecken konfiguriert werden. Anschließend werden die Integrationsprozesse ausgeführt und überwacht. Tabelle 4.2: Implementierungsphasen in der SAP PI Zeitpunkt

PI-Komponente

Aufgaben

Pflege der Systemlandschaft

System Landscape Directory

Erfassung der beteiligten Systeme und Softwarekomponenten

Designzeit

Enterprise Services Repository

Erfassung von Schnittstellen, Mappings und Prozessdefinitionen

Konfigurationszeit

Integration Directory

Erfassung von Routing-Regeln und externen Kommunikationspartnern

Laufzeit

Integration Engine / Runtime Envi- Empfangen und Weiterleiten von ronment Nachrichten; Monitoring

Für jede dieser Implementierungsphasen stellt die SAP PI passende Werkzeuge zur Verfügung, die in die Bereiche System Landscape Directory (SLD), Enterprise Services Repository (ESR), Integration Directory (ID) und Configuration and Monitoring gegliedert sind und im Folgenden vorgestellt werden (Abb. 4.2).

4.4.1 System Landscape Directory Im System Landscape Directory (SLD) werden alle Informationen über die interne (und teilweise externe) Systemlandschaft erfasst und zentral zur Verfügung gestellt. Hierzu gehören neben den beteiligten Systemen und deren Beziehungen untereinander auch die installierten Softwareprodukte. Bei den Systemen wird zwischen technischen Systemen und Business-Systemen unterschieden. Bei einem SAP-System wird die SAP-Installation als technisches System und die jeweiligen Mandanten (logische Systeme) als Business-Systeme erfasst. Allerdings können im SLD auch beliebige nicht-SAP-Systeme abgebildet werden. Neben den internen Systemen können im SLD auch Softwareprodukte erfasst werden. Dabei können zu jedem Softwareprodukt unterschiedliche Komponenten angelegt werden, die wiederum verschiedene Versionen umfassen können. Jede Softwarekomponente wird technischen Systemen zugeordnet und dort für die Business-Systeme aktiviert, auf denen sie installiert ist.

Systemarchitektur SAP PI

91

Central Monitoring SAP Systems

Enterprise Services Repository (ESR)

Integration Directory (ID)

Integration Server (IS)

3rd Party Systems 3rd Party Middleware Component

System Landscape Directory (SLD) Design

Configuration

Runtime

Abb. 4.2: Komponenten der SAP PI (in Anlehnung an SAP AG 2009)

Die im SLD hinterlegten Softwarekomponentenversionen spielen auch beim Design von Integrationsszenarien eine wesentliche Rolle. Alle hierzu erforderlichen Metadaten (Datentypen, Interfaces, Mappings etc.) müssen jeweils einer im SLD hinterlegten Softwarekomponentenversion zugeordnet werden. Die Versionierung von Softwarekomponenten übernimmt somit neben der Verwendung von Namensräumen in der SAP PI Entwicklung eine strukturierende Rolle.

4.4.2 Integration Server Der Integration Server (IS) stellt die zentrale Komponente für den Ablauf der Nachrichtenverarbeitung dar, indem dieser alle Nachrichten der angeschlossenen Anwendungssysteme empfängt und weiterleitet. Gemäß den Konfigurationsdaten für jedes Integrationsszenario führt der Integration Server die Empfängerbestimmung, das Mapping und das Routing der Nachrichten aus. Darüber hinaus umfasst der IS die Laufzeitumgebung zur Automatisierung und Ausführung von Geschäftsprozessen. Der IS ist zu diesem Zweck mit der Integration Engine (IE), der Business Process Engine (BPE) und der Advanced Adapter Engine (AAE) in Teilkomponenten unterteilt, die im Folgenden beschrieben werden.

92


Integration Engine Die wichtigste Aufgabe der Integration Engine besteht in der Verarbeitung von XML-Nachrichten. Die Verarbeitung einer eingehenden Nachricht beginnt nach der Validierung des XML-Formats mit dem sog. logischen Routing. Hierbei werden der Empfänger und ein geeignetes Empfänger-Interface bestimmt. Das Format der eingehenden Nachricht und das Empfänger-Interface legen, sofern notwendig, das anschließende Mapping fest. Das technische Routing schließt die Verarbeitung mit der Bestimmung des technischen Zielsystems ab und versendet die transformierte Nachricht an dieses. Business Process Engine Während sich die IE auf den Austausch von Nachrichten beschränkt, erweitert die BPE die Funktionalität des Integration Servers um eine zustandsbehaftete Nachrichtenverarbeitung. Über Integrationsprozesse können semantische Zusammenhänge zwischen Nachrichten und eine entsprechende Steuerung der Verarbeitung abgebildet werden. So kann etwa nach dem Empfang einer Nachricht auf weitere gewartet werden, bevor die Bearbeitung fortgesetzt wird. Zur formalen Beschreibung von Geschäftsprozessen wird die Business Process Excecution Language (BPEL) verwendet. Im Gegensatz zu SAP Business Workflow kommuniziert die BPE mit Anwendungen in Backend-Systemen ausschließlich über Nachrichten und somit unter Vermittlung des Integration Servers. Die BPE hat keinen Zugriff auf Prozesse innerhalb der Anwendungen oder auf das Benutzer- oder Organisationsmanagement. Daher gilt: x Die BPE steuert keine Prozesse innerhalb von Anwendungen. Allerdings können Anwendungen über Nachrichten in systemübergreifende Prozesse eingebunden werden. x Die BPE steuert keine komplexen Benutzerinteraktionen. Diese können nur in den Backend-Systemen umgesetzt und genutzt werden. Advanced Adapter Engine Während die Integration Engine mit angebundenen Anwendungssystemen direkt über das PI-Nachrichtenformat (SOAP with Attachements) kommunizieren kann, kommt die Advanced Adapter Engine (AAE) zum Einsatz, wenn externe Systeme über andere Nachrichtenformate oder Technologien angesprochen werden sollen. Mit der Auslieferung der SAP PI verfügt die AAE standardmäßig über technische Adapter wie beispielsweise FTP (File Transfer Protocol), JMS (Java Message Service) oder JDBC (Java Database Connectivity). Darüber hinaus werden branchenspezifische Nachrichtenformate wie CIDX (chemische Industrie) oder RNIF (Halbleiterindustrie) unterstützt. Da die AAE auf JCA (Java Connector Architecture) basiert, können Erweiterungen entsprechend entwickelt werden.

Systemarchitektur SAP PI

93

4.4.3 Integration Directory Im Bereich Integration Directory wird mit dem Integration Builder das zentrale Werkzeug für die Konfiguration von Nachrichtenstrecken und komplexen Integrationsprozessen zur Verfügung gestellt. Hier wird erfasst, welche Systeme, Prozesse oder externe Partner als Sender bzw. Empfänger von Nachrichten auftreten können und über welche Kommunikationskanäle diese zu erreichen sind (z.B. Mail, FTP, SOAP). Darüber hinaus kann mittels komfortabler Assistentenprogramme (Wizards) das Regelwerk festgelegt werden, auf Basis derer der Integration Server wie zuvor erwähnt zu eingehenden Nachrichten den (oder die) passenden Empfänger, die passenden Schnittstellen, die anzuwendenden Transformationsregeln sowie den passenden Kommunikationskanal ermittelt.

4.4.4 Enterprise Services Repository Das zentrales Werkzeug im Bereich des Enterprise Services Repository ist der Enterprise Services Builder (ESB), über den alle von der SAP PI verarbeiteten Schnittstellen und Transformationsregeln erfasst werden können. Hierzu gehören Service Interfaces, Message-Typen und Datentypen zur Beschreibung der Schnittstellen, sowie Operation- und Message Mappings zur Beschreibung der zur Überwindung von Struktur- oder Datenkonflikten zwischen Schnittstellen erforderlichen Transformationen. Darüber hinaus können im ESB BPEL-Prozesse zur Abbildung komplexer Integrationsprozesse erfasst werden. Die im ESB erstellten Objekte haben dabei zunächst keinerlei Bezug zu konkreten Sendern oder Empfängern von Nachrichten, sondern enthalten die in diesem Sinne statischen Beschreibung der Integrationsprozesse und Schnittstellen. Optional kann im Enterprise Services Repository zusätzlich eine Service Registry eingebunden werden, welche Registrierung und Lokalisierung von Services, sowie den Serviceaufrufe nach UDDI 3.0 unterstützt. Da diese Komponente nicht in allen SAP PI Installationen zur Verfügung steht, wird sie in den Fallstudien dieses Buches nicht eingesetzt.

4.4.5 Administration, Configuration und Monitoring Der Link zur Administration in Abb. 4.2 bietet einerseits Systeminformationen (z.B. Hardware, Betriebssystem und Java-Versionen) und andererseits Anwendungsinformationen (z.B. Verzeichnisstrukturen und Lizenzen). Für die Arbeit mit der SAP PI ist ferner die Sperr- und Cache-Administration in diesem Abschnitt von Bedeutung. Tritt beispielsweise bei der Arbeit im ESB ein Systemabsturz des

94


Clients auf, so kann es zu Sperrungen kommen, die nicht im ESB aufgelöst werden können, sondern an dieser Stelle gelöscht werden müssen. Unter der Überschrift „Configuration and Monitoring“ werden weitere Administrator-Funktionen zur technischen Konfiguration der SAP PI angeboten. Daneben enthält der Bereich Runtime Workbench eine Reihe von Werkzeugen zur Überwachung der beteiligten Systemkomponenten (Komponenten Monitoring) und zur Überwachen der abgebildeten Integrationsprozesse (Message Monitoring). Somit ist die Runtime Workbench der zentrale Ausgangspunkt für Fehleranalysen jeglicher Art.

4.5 Designobjekte in SAP PI Zur Designzeit werden über den Enterprise Services Builder (ESB) die Schnittstellen zu allen am Integrationsprozess beteiligten Systemen, die Transformationsregeln zur Überwindung von Daten- und Strukturkonflikten, sowie die Verarbeitungslogik im Fall komplexer Geschäftsvorfälle erfasst und im Enterprise Services Repository abgelegt. Alle Designobjekte werden jeweils einer konkreten Softwarekomponentenversion zugeordnet. Die Arbeit im ESB beginnt daher immer mit dem Import einer zuvor im SLD angelegten Softwarekomponentenversion, der dann im ESR ein oder mehrere Namensräume zugewiesen werden können. Innerhalb dieser Namensräume erfolgt dann die Erfassung der Designobjekte.

Ausgangsschnittstelle

Inbound-Interface

Softwarekomponente 1

Integration Repository

Outbound-Interface

Business System A

Business System B

Eingangsschnittstelle

Softwarekomponente 2

Struktur- und Werte-Mapping

Abb. 4.3: Design einer Nachrichtenstrecke in der SAP PI (Quelle: SAP AG)

Die Kernaufgabe der SAP PI besteht darin eingehende Nachrichten in ein geeignetes Format zu übersetzen und an den richtigen Empfänger weiterzuleiten. Wie in Abb. 4.3 dargestellt, erfordert jede solche Nachrichtenstrecke Schnittstellenbeschreibungen für eingehenden und ausgehenden Nachrichten, sowie eine Trans-

Designobjekte in SAP PI

95

formationsregel zwischen Senderformat und Empfängerformat. Die Schnittstellenbeschreibungen werden in der SAP PI als Service Interfaces, die Transformationsregeln als Operation Mappings erfasst.

4.5.1 Service Interfaces Bei der Erfassung eines Service Interfaces ist über den Typ zu spezifizieren, ob es für eingehende oder ausgehende Nachrichten verwendet wird. Service Interfaces über die Nachrichten aus externen Systemen verschickt werden, erhalten den Typ Outbound Interface, solche über die Nachrichten aus der SAP PI empfangen werden den Typ Inbound Interface. Neben diesen beiden Typen sieht die SAP PI auch sogenannte abstrakte Interfaces vor. Abstrakte Interfaces werden im Rahmen von Integrationsszenarien verwendet, da hier der Schnittstellentyp häufig erst zur Laufzeit feststeht. Bei der Typisierung von Service Interfaces ist grundsätzlich die Perspektive der an die SAP PI angebundenen Systeme einzunehmen: Eine Nachricht, die von einem solchen System an die SAP PI geschickt wird, erreicht die SAP PI demnach über ein Outbound Interface (Abb. 4.3). Diese Typisierung führt gerade am Anfang häufig zu Irritationen, da sie ja auch bedeutet, dass aus Perspektive der SAP PI eingehende Nachrichten grundsätzlich über Outbound Interfaces empfangen werden. Über den Modus eines Service Interfaces wird gesteuert, ob das sendende System auf eine Antwort wartet (synchrone Schnittstelle) oder sich die Kommunikation auf das Senden der Nachricht beschränkt (asynchrone Schnittstelle). Neben Typ und Modus enthalten Service Interfaces eine technische Beschreibung der zugehörigen Datenstruktur. Während bei asynchronen Interfaces nur die Struktur der gesendeten Nachricht (Request) anzugeben ist, muss bei synchronen Interfaces zusätzlich die Struktur für die Antwort (Response) spezifiziert werden. Darüber hinaus kann zu jedem Service Interface ein Format für etwaige Fehlermeldungen angegeben werden. Da solche Strukturbeschreibungen häufig in unterschiedlichen Service Interfaces vorkommen, werden sie in der SAP PI als eigene Designobjekte, sogenannte Data Types erfasst. Dabei erfolgt die Zuordnung der Datentypen zu Service Interfaces nicht direkt, sondern über Message Types, die eine semantische Beschreibung der Datenstruktur und einen Verweis auf den zugehörigen Data Type enthalten (Abb. 4.4).

96

Einführung in SAP Process Integration Service Interface: CO2e_Impact_Inbound Modus: asynchron Kategorie: Input

Service Interface: GHG_Impact_Outbound Modus: asynchron Kategorie: Output

Messagetyp Output: GHG_Impact Datentyp: GHG_Impact

Messagetyp Input: CO2e_Impact Operationmapping:

C02_Impact CO2_Unit CH4_Impact

Datentyp: CO2e_Impact CO2e_Impact

Messagemapping: GHG_ImpactTo CO2e_Impact

CO2e_Unit

CH4_Unit N2O_Impact N2O_Unit HFC_Impact ...

Abb. 4.4: Designelemente in der SAP PI

In dem auf Abb. 4.4 skizzierten Beispiel sollen die Emissionsdaten zu einem Produkt über die SAP PI versendet werden. Während der Sender die Daten für jedes der sieben Treibhausgase getrennt ausweist, verarbeitet der Empfänger nur sogenannte CO2-Äquivalente (CO2e), bei denen die Umweltwirkung aller Treibhausgase über international anerkannte Faktoren in die Wirkung von CO2 umgerechnet wird. Zum Design dieser Nachrichtenstrecke müssen zunächst die beiden Schnittstellen als Service Interfaces erfasst werden. Da keine direkte Antwort erwartet wird, sind hierzu je ein Outbound- und ein Inbound-Interface vom Modus asynchron anzulegen. Zu jedem der beiden Interfaces sind dann je ein Data Type mit der technischen Beschreibung der Datenstruktur und je ein Message Type mit Referenz auf den Data Type anzulegen.

4.5.2 External Definitions und Imported Objects Design-Objekte wie Data Types oder Service Interfaces können im Enterprise Services Repository entweder direkt über einen entsprechenden Editor angelegt werden oder aber wie im Folgenden beschrieben extern definiert bzw. importiert werden. So können bereits in (aus Sicht der SAP PI) externen Systemen oder Werkzeugen implementierte Funktionen mit geringem Aufwand übernommen werden.


97

Unter External Definitions wird in diesem Zusammenhang die vollständig, syntaktische Beschreibung von Nachrichten verstanden. Hierfür wurden in der Praxis eine Reihe von Sprachen (z.B. die Interface Definition Language insb. für CORBA) entwickelt, die geeignet sind, Schnittstellen und Nachrichtenformate zu beschreiben. SAP PI bietet die Übernahme von Definitionen im WSDL-, XSD(XML Schema Definition) und DTD-Format an (Document Type Definition). Diese Definitionen (bzw. deren Interpretation durch SAP PI) beschränken sich auf die Schnittstellenbeschreibung, ohne auf eine konkrete Implementierung zu verweisen. Eine Ausnahme bildet die WSDL, die es ermöglicht neben der Nachrichtendefinition auch Service Operations bzw. den Ort eines Webservices anzugeben. Die SAP PI extrahiert beim Anlegen einer externen Definition anhand eines WSDL-Dokumentes ausschließlich die Message Types, die dann im nächsten Schritt bei der Definition von Service Interfaces analog manuell angelegter Message Types referenziert werden können. Ein Beispiel: Im Rahmen der Fallstudien wird der Webservice eines Lieferanten in SAP PI eingebunden. Das beschreibende WSDL-Dokument definiert verschiedene Request- und Response-Nachrichten, deren externe Definition verwendet wird. Der im WSDL-Dokument angegebene Ort des Webservices wird nicht weiter verwendet und kann von dem später in der Konfiguration anzugebenden Ort des Webservices abweichen. Im Gegensatz zu externen Definitionen bieten die sog. Imported Objects nicht nur die Möglichkeit, Schnittstellendefinitionen zu importieren, sondern RFCfähige Funktionsbausteine aus externen SAP-Systemen anzubinden. Der Unterschied zwischen externen Definitionen und importierten Objekten liegt also darin, dass erstere ausschließlich die Schnittstelle beschreiben, während letztere bereits die Bindung an eine konkrete Implementierung in einem externen SAP-System vornehmen.

4.5.3 Operation Mappings Zur Transformation eines Schnittstellenformates auf ein anderes stehen im ESR sogenannte Operation Mappings zur Verfügung. Die Transformation wird durch ein Operation Mapping beschrieben, das neben Quell- und Ziel Interface einen Verweis auf ein (oder mehrere) sogenannte Message Mappings enthält. In den Message Mappings ist die eigentliche Konvertierungslogik hinterlegt. Hierzu stehen verschiedene Varianten zur Verfügung: x Einfache Transformationsregeln können in einem grafischen Mapping Editor erfasst werden. Per Drag & Drop können Feldinhalte der Quellstruktur denen der Zielstruktur zugeordnet werden. Dies kann direkt oder unter Anwendung einfacher Feldoperationen (arithmetische Grundfunktionen wie Rundung, Maximum, Wurzel u.a.) erfolgen.

98


x Zur Abbildung komplexerer oder performancekritischer Transformationen können auch externe Mappings (ABAP-Programme, JAVA-Mappings, XSLTMappings) importiert werden. x Es existieren weitere Lookups, die es ermöglichen Mapping-Funktionen aus anderen Anwendungssystemen zu verwenden. So kann bspw. über JDBCLookups die Übersetzung bzw. Umschlüsselung zwischen Systemen anhand von externen Datenbanken erfolgen. Das Message Mapping zu dem oben beschriebenen Emissionsbeispiel, in dem die Wirkungen unterschiedlicher Treibhausgase in die Wirkung von CO2 anhand eines Materials umzurechnen ist, kann problemlos über den Mapping Editor des ESR erfasst werden (vgl. Abb. 4.5). Die Aggregation der Treibhausgase verschiedener Materialien wird in den Fallstudien mit Hilfe einer Java-Klasse demonstriert.

Abb. 4.5: Mapping Editor im Enterprise Services Builder

4.5.4 Design von Integrationsprozessen Neben Schnittstellen und Mappings gehören auch Integrationsprozesse zu den Objekten, die zur Design-Zeit im Enterprise Services Repository erfasst werden.


99

Analog zur Abbildung einfacher Nachrichtenstrecken, werden zur Design-Zeit keinerlei Angaben über die am Prozess beteiligten Sender bzw. Empfänger von Nachrichten gemacht. Vielmehr kann jeder im ESR hinterlegte Integrationsprozess im Rahmen der späteren Konfiguration als Sender bzw. Empfänger in Nachrichtenstrecken verwendet werden. Zur Design-Zeit wird also die reine Ablauflogik der Prozesse erfasst. Hierzu steht im ESR ein grafischer Prozess-Editor zur Verfügung, der zur Definition der Prozesse eine Reihe von Konstruktionselementen, sogenannte Step Types, zur Verfügung stellt und als Ergebnis einen BPELProzess erzeugt. Die SAP PI unterstützt dabei zusätzlich zum BPEL 2.0 Standard eine eingeschränkte Art von Benutzerinteraktionen, die in der BPEL4People 1.0 Spezifikation vorgesehen sind. Ein einfacher Integrationsprozess, der eine vorgegebene Anzahl von Nachrichten sammelt, um diese anschließend als Liste weiter zu versenden, ist in Abb. 4.6 dargestellt.

Abb. 4.6: Integrationsprozess zum Sammeln von Nachrichten (Papenfuss 2008)

Im Folgenden wird ein kurzer Überblick über die in SAP PI unterstützten Step Types gegeben, die zur Implementierung von Integrationsprozessen zur Verfügung stehen. Eine gewisse Ähnlichkeit zu den Basis Aktivitäten bei der Abbildung von Workflow Definitionen im Workflow Builder (vgl. Kap. 3) ist kaum zu übersehen. In der Tat bildet SAP PI die Integrationsprozesse zur Laufzeit als WorkflowInstanzen ab, die in der gewohnten Workflowumgebung laufen. Folgende Step Types stehen zur Abbildung von Integrationsprozessen zur Verfügung: Receive Step Dieser Schritt kann als Startereignis einen Prozess instanziieren, aber auch innerhalb eines Prozesses auftreten. Da zur Laufzeit zu jedem Prozess viele Prozessinstanzen zur gleichen Zeit existieren können, ist zu beschreiben, wie vom Prozess empfangene Nachrichten der passenden Prozessinstanz zugeordnet werden. Hierzu können Receive Steps sogenannte Korrelationen zugeordnet werden. Die Zuordnung kann anhand eines dedizierten Attributs im Sinne einer Session-ID oder eines Attributs des eigentlichen Nachrichteninhaltes erfolgen.

100


Send Step Über diesen Schritt können Nachrichten gesendet werden. Hierbei kann es sich um eine Antwort (Response) zu einer vorher empfangenen synchronen Nachricht handeln, oder um eine neue Nachricht, die asynchron verschickt wird. Grundsätzlich schickt die Process Engine die Nachricht an ein internes Interface in der SAP PI, also nicht direkt an externe Systeme oder Webservices. Receiver Determination Step Dieser Schritt ermöglicht es, das synchrone Senden einer Nachricht an mehrere Empfänger zu kontrollieren, indem zur Laufzeit alle Empfänger einer Nachricht schon vor dem Send Step ermittelt werden. Das Senden erfolgt dann häufig innerhalb einer Schleife, so dass der Prozess auf die Antwort jedes Empfängers separat reagieren kann. Transformation Step Über diesen Schritt können Operation Mappings auf Nachrichten angewendet werden. Häufig wird dieser Schritt auch zur technischen Überführung von n einzelnen Nachrichten in eine Tabelle von Nachrichten (und umgekehrt) eingesetzt. User Decision Über diesen Schritt können einfache Benutzerentscheidungen in den Prozess integriert werden. Hierzu werden verschiedene Entscheidungsoptionen definiert, zwischen der ein zur Konfigurationszeit ermittelter Anwendern wählen kann. Als Anwender kommen dabei ausschließlich die am SAP PI System registrierten Anwender in Frage. Eine Benutzerentscheidung, die wie in den Fallstudien dargestellt in externen Systemen stattfindet, ist dort zu implementieren und wird aus Sicht der SAP PI wie jedes andere System im Rahmen der üblichen Nachrichtenkommunikation adressiert. Switch Zur bedingten Ausführung von Prozesszweigen steht der Switch zur Verfügung, über den verschiedene Prozesszweige mit zugehöriger Ausführungsbedingung hinterlegt werden können. Zur Laufzeit wird nur der Zweig prozessiert, dessen Bedingung als erste erfüllt ist. Block Als Modularisierungseinheiten innerhalb der Prozessdefinitionen stehen Blocks zur Verfügung. Blöcke können beliebig tief ineinander geschachtelt werden. Blöcke sind einerseits die Einheit, in der über sogenannte Container-Elemente lokale Variablen deklariert werden können. Darüber hinaus stehen für Blöcke Mechanismen zur Fehler- und Ausnahme-Bearbeitung zur Verfügung. So kann etwa zu jedem Block ein Prozesszweig definiert werden, der im Falle einer SystemAusnahme automatisch prozessiert wird (Exception Handler). Container Operation In Container Operationen können die innerhalb eines Blockes als Container Element definierten lokalen Variablen verändert werden. Hierzu stehen ein Operator

Konfigurationsobjekte in SAP PI

101

zur Erweiterung tabellenartiger Variablen zur Verfügung (Append) sowie ein Zuweisungsoperator (Assign) zur Verfügung. Letzterer ermöglicht den Zugriff auf einzelne Attribute komplexer Data Types mit Hilfe von XPath. Control Der Control Step kann verwendet werden, um die Verarbeitung des gesamten Integrationsprozesses zu stoppen. Alternativ ist es möglich, über diese Aktivität eine Ausnahme auszulösen, die dann von dem nächstgelegenen Exception Handler bearbeitet wird. Fork Über den Fork Step können mehrere Prozesszweige parallel gestartet werden. Zur Terminierung der Prozesse stehen mehrere Verfahren zur Verfügung, u.a. kann eine globale Abbruchbedingung für alle parallelisierten Zweige hinterlegt werden. Loop Wiederholte Ausführungen von Prozesszweigen können über die Loop-Aktivität umgesetzt werden. Über eine Abbruchbedingung wird gesteuert, wie oft der zugehörige Prozesszweig durchlaufen wird. Iterationen, mit denen ein Verarbeitungsblock für jede Zeile einer im Context definierten Tabelle ausgeführt werden soll, können auch ohne Loop-Anweisung umgesetzt werden. Hierzu kann bei der Definition eines Blockes eine tabellenartige Variable spezifiziert und die Ausführung parallel für alle Zeilen (Modus ParForEach) oder auch nacheinander für jede Zeile (Modus ForEach) erzwungen werden. Wait Der Wait Step hält den Prozess für ein angegebenes Zeitintervall oder bis zu einem bestimmten Zeitpunkt an. Soll bspw. der Status eines externen Systems durch regelmäßige Versendung einer Nachricht aus der SAP PI an das externe System überprüft werden, ist es sinnvoll, die entsprechende Schleife vor dem Versand einer neuen Nachricht warten zu lassen, um so eine unnötige Belastung beider Systeme zu vermeiden.

4.6 Konfigurationsobjekte in SAP PI Während die einzelnen Objekte zur Designzeit einer Softwarekomponente zugeordnet werden, erfolgt zur Konfigurationszeit die Gruppierung der Objekte über ein Konfigurationsszenario. Zur Konfiguration einer Nachrichtenstrecke müssen Regeln hinterlegt werden, mit denen aus dem Sender-Interface und dem Kommunikationskanal des Senders der Absender, das Empfängerinterface, das Empfängersystem, das Outbound-Interface und der Kommunikationskanal ermittelt werden. Als Empfänger kommen dabei neben den im SLD gepflegten BusinessSystemen auch externe Systeme (Business-Service) und Integrationsprozesse in Frage.

102


Die Konfiguration beginnt mit der Definition eines solchen Konfigurationsszenarios, dem dann alle beteiligten Sender und Empfänger als Kommunikationskomponenten zugeordnet werden. Als Sender/Empfänger kommen neben den im SLD beschriebenen Business Systemen auch externe Systeme (Business Komponenten) und die im ESR erfassten Integrationsprozesse in Frage. Im nächsten Schritt ist zu jeder solchen Businesskomponente anzugeben, über welche Adapter sie als Sender bzw. Empfänger von Nachrichten auftreten kann. Die zugehörigen technischen Beschreibungen werden der Businesskomponente als Kommunikationskanal zugeordnet. Zur Erfassung der eingangs beschriebenen Regeln steht ein Assistentenprogramm zur Verfügung, das nach Eingabe von Quell- und Ziel-Daten (jeweils Kommunikationskomponente, Kommunikationskanal und Enterprise Service) und der anzuwendenden Operation Mappings die folgenden Konfigurationsobjekte erzeugt: x Die Sendervereinbarung (Sender Agreement) legt zu vorgegebenen Sender und Enterprise Service fest, über welchen Kommunikationskanal entsprechende Nachrichten in die SAP PI gelangen dürfen. Bei eingehenden Nachrichten deren Sender nicht unmittelbar erkennbar ist, kann die SAP PI aus den Sendervereinbarungen das sendende System ableiten. x Die Empfängervereinbarung (Receiver Agreement) legt entsprechend fest, über welchen Kommunikationskanal Nachrichten an einen Empfänger verteilt werden. x Die Empfängerermittlung (Receiver Determination) legt den Empfänger fest, an den eingehende Nachrichten gesendet werden sollen. Hierbei kann die Wahl des Empfängers in Abhängigkeit vom Inhalt der Nachricht ermittelt werden. Zudem können beliebig viele Empfänger angegeben werden. x Die Interface-Ermittlung (Interface Determination) bestimmt, in welchem Format die eingehende Nachricht an den Empfänger weitergeleitet wird und welche Mappings zur Transformation zu verwenden sind. Hierbei können zu einer eingehenden Nachricht durchaus mehrere Nachrichten (mit unterschiedlichen Message-Typen) versendet werden. Konfigurationsobjekte sind globale Objekte, die grundsätzlich in unterschiedlichen Konfigurationsszenarien verwendet werden können. Anders als Softwarekomponentenversionen im ESR haben Konfigurationsszenarien keine eigenen Namensräume. Das manuelle Löschen von Konfigurationsobjekten birgt daher große Risiken.

Monitoring

103

4.7 Monitoring Für die Überwachung der SAP PI zur Laufzeit stehen verschiedene Möglichkeiten zur Verfügung. Es können die Funktionen einzelner Systemkomponenten, Geschäftsprozessinstanzen und der Nachrichtenfluss geprüft und analysiert werden. In Fehlerfällen sind insb. die Möglichkeiten zum Monitoring des Nachrichtenflusses von Bedeutung. Entweder wird dazu über sog. TCP/IP-Monitore die Kommunikation auf dem Netzwerk überwacht oder aber die Nachrichten werden innerhalb der beteiligten Systeme – also den angebundenen externen Systemen bzw. der SAP PI – analysiert. Die SAP PI ermöglicht über die Runtime Workbench (RTW), dem WebFrontend der SAP PI, im Message-Monitoring die Auswahl von eingegangenen und versendeten Nachrichten nach verschiedenen Kriterien wie Datum, Sender, Empfänger, Interfaces und Namespaces. Liegt ein Fehler vor, kann der Nachrichteninhalt und deren SAP PI interne Verarbeitung angezeigt werden. Neben der RTW kann die Nachrichtenanalyse über die Transaktion SXI_MONITOR auch in der SAP GUI der beteiligten Systeme untersucht werden.

104



Frage


1

Erläutern Sie die Anforderungen, die an eine Integrationsplattform gestellt werden. Wie werden diese Anforderungen in SAP PI umgesetzt?

4.2

2

Erläutern sie die Unterschiede zwischen dem Enterprise Services Repository und dem Integration Directory?

4.3

3

Erläutern Sie an welchen Stellen sich in der SAP PI die Anbindung von SAP-Systemen von der von nicht-SAP-Systeme unterscheidet?

4.3.1

4

Welche Design-Artefakte sind zur Abbildung einer Nachrichtenstrecke in der SAP PI unbedingt erforderlich?

4.4

5

Welche Konfigurations-Artefakte sind zur Abbildung einer Nachrichtenstrecke in der SAP PI unbedingt erforderlich?

4.5

6

Welche Möglichkeiten bietet die SAP PI zur Abbildung von Mappings?

4.4.3

7

Grenzen Sie die Aufgaben von Integration Server und Business Process Engine in der SAP PI gegeneinander ab.

4.2

8

Was wird in der SAP PI unter Step Types verstanden? Welche Step Types werden unterstützt?

4.4

9

Vergleichen Sie die Step Types der SAP PI mit den in Kapitel 3 vorgestellten Activity Types im SAP Workflow.

4.4

4.9 Literatur Banner M, Klein H, Riesner C (2009) Praxisleitfaden SAP NetWeaver PI – Administration. SAP Press, Bonn Krimmel M, Orb J (2009) SAP NetWeaver Process Integration. SAP Press, Bonn Nicolescu V, Funk B, Niemeyer P, Heiler M, Wittges H, Morandell T, Visintin F, Kleine Stegemann B, Kienegger H (2009) Praxishandbuch SAP NetWeaver PI – Entwicklung. SAP Press, Bonn Papenfuss D (2008) Integration verteilter Systeme mit Hilfe der SAP Exchange Infrastructure anhand einer Fallstudie zum Order2Cash-Prozess. Thesis Universität Lüneburg Raju S, Wallacher C (2008) B2B Integration Using SAP NetWeaver PI. SAP Press, Bonn SAP AG (2009) SAP NetWeaver 7.1 PI: Design, Configuration and Runtime. http://help.sap.com/saphelp_nwpi71/helpdata/EN/84/e8763c997fda50e10000000a11405a/fra meset.htm. Abruf 16.02.2010

5 Überblick zu den Fallstudien 5.1 Einleitung Die in den vorhergehenden Kapiteln beschriebenen Konzepte und Technologien werden im Rahmen der folgenden drei Fallstudien angewendet und anhand von Beispielen erläutert und vertieft. Fachlicher Hintergrund der Fallstudien ist die mit Hilfe betrieblicher Informationssysteme automatisierte Ermittlung und Kommunikation der Umweltwirkung von Produkten eines Unternehmens (im Folgenden kurz das „Unternehmen“ genannt). Kunden des Unternehmens sollen über eine Webservice-Schnittstelle in die Lage versetzt werden, die Umweltwirkung von Produkten, die sie von dem Unternehmen bezogen haben, abzufragen. Die drei Fallstudien sind in dieses Szenario eingebettet und bauen aufeinander auf. Ziel der ersten Fallstudie ist es, den Leser mit den für die Automatisierung von Geschäftsprozessen erforderlichen Ansätzen zur Integration vertraut zu machen und die Umsetzung mit SAP PI zu demonstrieren. Die zweite Fallstudie nutzt die entstandenen Schnittstellen und bettet diese in einen Geschäftsprozess ein, der auf der Process Engine der SAP PI implementiert wird. Die Aufgabe dieses Prozesses besteht im Zusammenführen der in unterschiedlichen Systemen vorhandenen Informationen zur Umweltwirkung des angefragten Produktes. Gegenstand der dritten Fallstudie ist die Integration von Anwenderentscheidungen in Geschäftsprozessen im Rahmen von Workflows. Zu diesem Zweck wird SAP Business Workflow verwendet und gezeigt, wie eine Integration mit SAP PI möglich ist. Im Folgenden werden zunächst der fachliche Hintergrund des Szenarios und der diesbezügliche Stand von Wissenschaft und Praxis dargestellt. Anschließend folgt die Beschreibung der beteiligten Akteure (und Systeme) und ihrer Rollen im Ablauf des Szenarios. Im letzten Abschnitt des Kapitels werden die technischen Voraussetzungen und Besonderheiten der Fallstudie erläutert.

5.2 Fachlicher Hintergrund Die mit der fortschreitenden Industrialisierung und dem veränderten Konsumverhalten einhergehende Umweltbelastung ist seit Jahrzehnten Gegenstand der öffentlichen Diskussion. Dies hat insbesondere in den Industrieländern zu einem erhöhten Umweltbewusstsein bei Verbrauchern und in der Folge auch bei Unternehmen geführt. Vor diesem Hintergrund wurden in der Wissenschaft Methoden zur Ermittlung und Bewertung der Umweltwirkung von Unternehmen, Produktionsprozessen und einzelnen Produkten entwickelt. Unter dem Stichwort „Ökobilanzie

106

Überblick zu den Fallstudien

rung“ werden wie in der englischen Bezeichnung Life Cycle Assessment (Guinée 2002) erkennbar sämtliche Umweltwirkungen entlang des gesamten Lebenszyklusses eines Produktes – also von der Rohstoffentnahme, über die Produktion, die Verwendung bis hin zur Entsorgung – ermittelt. Ziele der Ökobilanzierung sind vielschichtig und umfassen u.a. die Identifikation von Optimierungspotenzialen in der Produktion, beispielsweise durch Einsatz von Stoffstromanalysen (Möller 2000), die Verbraucherinformation, die informatorische Absicherung nachhaltig ökologischen Handelns von Unternehmen (z.B. Sustainable Supply Chain – Seuring und Müller 2008) sowie eine Entscheidungsgrundlage für die Regulierung von Unternehmen (z.B. Emissionszertifikate). In den ISO-Normen 14040 und 14044 wird das Vorgehen zur Erstellung von Ökobilanzen in der Praxis erläutert. Im ersten Schritt werden die Ziele dargestellt und der Untersuchungsrahmen, also die Systemgrenzen, festgelegt. Mit der Sachbilanz (Life Cycle Inventory) werden anschließend die Stoffströme untersucht. Dies umfasst einerseits den Ressourcenverbrauch, beispielsweise Rohstoffentnahmen und Energieverbrauch, und andererseits die gewünschten und ungewünschten Emissionen während der Herstellungs- aber auch der Nutzungsphase. Die Sachbilanz beschreibt detailliert die stoffliche Perspektive auf den Produktlebenszyklus, ohne bereits eine Wertung im Hinblick auf die Umweltwirkung vorzunehmen. Auf Basis der Sachbilanz erfolgt die Abschätzung der Umweltwirkung von Produkten, indem die einzelnen darin vorkommenden Stoffe in Beziehung zu möglichen Umweltschäden gesetzt werden. Für die Beschreibung der Umweltwirkung gibt es zwei Ansätze: x Unter Einsatz quantitativer Modelle (Guinée 2002) werden aus der Sachbilanz die sogenannten Midpoint Categories, beispielsweise Treibhauspotenzial oder Ozonschichtverringerung, abgeschätzt. Der Begriff Midpoint Level weist darauf hin, dass diese Methoden nicht das Ende der Wirkungsketten der Umweltschäden (etwa die Auswirkungen auf die menschliche Gesundheit) in Betracht ziehen. x Schadensorientierte Methoden (Goedkoop und Spriensma 2001) modellieren die Ursache-Wirkungs-Kette bis zu den folgenden Endpunkten: (i) menschliche Gesundheit, gemessen in DALY (Disability Adjusted Life Years), (ii) Qualität des Ökosystems, gemessen in dem Anteil ausgestorbener Arten, und (iii) verbleibende Menge natürlicher Ressourcen und ihre Abbaubarkeit. Ergebnisse der schadensorientierten Methoden können leichter interpretiert werden, weisen jedoch auch einen höheren Grad an Unsicherheit auf, da die modellierten Wirkungszusammenhänge nicht abschließend erforscht sind. Um diese Unsicherheiten in der Ermittlung von Umweltwirkungen entlang der Wertschöpfungskette möglichst gering zu halten, haben Funk, Möller und Niemeyer (2009) vorgeschlagen, den Informationsfluss auf die Midpoint Categories zu beschränken. Zu diesem Zweck wurde eine Referenzarchitektur vorgeschlagen, die sich auf die Ermittlung der Umweltwirkung einer Wertschöpfungsstufe kon-

Fachlicher Hintergrund

107

zentriert. Im Rahmen der Fallstudien wird eine im Hinblick auf die Schnittstellen und Funktionalität reduzierte Version dieser Architektur (Abb. 5.1) verwendet.

Abb. 5.1: Referenzarchitektur nach Funk, Möller und Niemeyer (2009)

Für die folgenden Fallstudien wurde aus den Midpoint Categories diejenige ausgewählt, die die öffentliche Diskussion aufgrund des Klimawandels heute bestimmt: das Treibhauspotenzial. In diesem Zusammenhang wird häufig der Begriff des Carbon Footprints verwendet. Er steht stellvertretend für eine Reihe von Konzepten zur Messung des Treibhauspotenzials, wird jedoch meist als ein zusammenfassendes Maß für alle emittierten Treibhausgase verstanden. Unterschiedliche Treibhausgase wie Methan oder Distickstoffoxid werden zu diesem Zweck in CO2-Äquivalente umgerechnet und addiert (British Standards Institution 2009). Die Integration der Umweltwirkung in operative betriebliche Informationssysteme – also ERP-Systeme – ist seit den 1990er Jahren Gegenstand der wissenschaftlichen Diskussion (Funk, Möller und Niemeyer 2007). Dabei werden vor allem Ansätze zur Integration von Stoffstrommanagementsystemen und Systemen zur Produktionsplanung und -steuerung (PPS) (Isenmann und Rautenstrauch 2007) untersucht. Mit den Fallstudien soll ein Instrumentarium für eine technische Lösung zur produktorientierten Bereitstellung sowohl der im Kyoto-Protokoll definierten sechs Treibhausgase als auch des Carbon Footprints skizziert werden.

108


5.3 Ablauf und Systeme der Fallstudien In den drei Fallstudien wird jeweils dasselbe Szenario behandelt: Ein Kunde des Unternehmens fragt bei diesem über einen Webservice den Carbon Footprint einzelner Produkte nach. In allen Fallstudien wird dieser Webservice durch die Integrationsplattform SAP PI bereitgestellt. Die einzelnen Fallstudien unterscheiden sich im Ablauf, in der Komplexität und der Zahl der beteiligten Systeme. In der ersten Fallstudie (service-orientierte Integration) wird davon ausgegangen, dass die Informationen zu den Treibhausgasen der Produkte bereits in dem vom Unternehmen eingesetzten SAP-System vorliegen. Die SAP PI leitet die über den Webservice eingehende Anfrage des Kunden mit einer Referenz auf das gekaufte Produkt an das unternehemensinterne SAP-System weiter und erhält in der synchronen Antwort die Angabe über die unterschiedlichen Treibhausgasemissionen des Produktes zurück. Anschließend rechnet SAP PI mit Hilfe eines Mappings die Werte in CO2-Äquivalente um und fasst sie zum Carbon Footprint zusammen. Technisch werden die verschiedenen Design-Artefakte der SAP PI und deren Erstellung beispielhaft erläutert. Die Konfiguration zeigt die Anbindung des SAPSystems detailliert und skizziert die Generierung des Webservice-Clients auf Basis der in der SAP PI erzeugten WSDL-Beschreibung. Die zweite Fallstudie (Geschäftsprozessautomatisierung) umfasst neben den drei zuvor genannten Systemen (SAP-System und SAP PI des Unternehmens sowie das Kundensystem) zum einen ein betriebliches Umweltinformationssystem zur Stoffstromanalyse (englisch: Environmental Management Information System und im Folgenden als EMIS bezeichnet), das innerhalb des Unternehmens betrieben wird, und zum anderen ein System des Lieferanten. Dieser bietet wie das Unternehmen selbst einen Webservice an, über den Informationen zu den Treibhausgasen von Vorprodukten bezogen werden können. Auf der Grundlage der vom Kunden eingehenden Webservice-Anfrage werden zunächst im SAP-System des Unternehmens die Beschaffungspositionen (Vorprodukte) und die im Unternehmen durchgeführten Fertigungsprozesse durch die SAP PI ermittelt. Anschließend kann das Unternehmen den Beitrag der eigenen Fertigungsprozesse zur Umweltwirkung über das EMIS bestimmen, die Umweltwirkung der Vorprodukte, die von Lieferanten bezogen wurden, über den Webservice ermitteln und letztendlich in aggregierter Form an den Kunden weitergeben. Technisch können die DesignArtefakte der ersten Fallstudie weitgehend verwendet werden. Weitere DesignArtefakte, beispielsweise zur Anbindung der hinzugekommenen Systeme, werden erstellt und demonstrieren, wie externe Webservices an die SAP PI angebunden werden können und welche weiteren Möglichkeiten zur Anbindung von SAPSystemen bestehen (Programmiermodell: inside-out). Das Zusammentragen der Daten aus den verschiedenen Systemen erfolgt über einen BPEL-Prozess, dessen Erstellung und Konfiguration den wesentlichen Teil der zweiten Fallstudie ausmacht.

Technische Voraussetzungen

109

In der Praxis ist derzeit und sicherlich auch auf längere Sicht keine voll automatische Bestimmung von Umweltwirkungen entlang der Supply Chain möglich. Stattdessen sind manuelle Eingriffe durch Experten erforderlich. Diesem Thema widmet sich die dritte Fallstudie (Anwenderentscheidungen in Workflows). Falls weder der Lieferant noch das EMIS in der Lage sind, Auskunft über die Treibhausgase der Vorprodukte bzw. der Fertigungsprozesse zu geben, wird in dem angeschlossenen SAP-Systems ein Workflow instanziiert. Durch das damit verbundene Work-Item erhält ein Experte den Auftrag, die Umweltwirkungen mit Hilfe anderer, hier nicht näher benannter Informationsquellen zu ermitteln oder zumindest abzuschätzen und anschließend manuell zu pflegen. In der Praxis können diese Informationsquellen LCA-Datenbanken wie ecoinvent (Frischknecht et al. 2005) oder Input-Output-Analysen (Leontief 1970) sein. Die Anfrage des Kunden an den Webservice kann somit synchron Informationen zum Carbon Footprint liefern, sofern alle Daten verfügbar sind bzw. automatisch aus den angeschlossenen Systemen ermittelt werden können. Andernfalls wird der Kunde über die Notwendigkeit zur manuellen Nachbearbeitung informiert und erhält später entweder auf die erneute Anfrage über den Webservice oder per Email die gewünschten Informationen. Technisch werden fortgeschrittene Möglichkeiten zur Nutzung der Process-Engine und die damit verbundenen BPEL-Konzepte erläutert. Ferner wird die Umsetzung der in Kap. 3 dargestellten SAP Workflows gezeigt.

5.4 Technische Voraussetzungen Die Bearbeitung der Fallstudien setzt ein SAP-System mit Entwicklungsberechtigung voraus. Für öffentliche Bildungseinrichtungen bieten im Rahmen der SAP University Alliance die University Competence Center (kurz SAP UCC) ein entsprechendes Angebot. Die Webservices sind in Java implementiert und setzen ausschließlich Free Software („Open Source“) ein. SAP-System Für die Entwicklung der Fallstudien wurde ein beim SAP UCC München gehostetes SAP-System (ECC 6.0) verwendet. Als Integrationsplattform kommt die SAP NetWeaver Process Infrastructure im Release 7.1 zum Einsatz. Die für die Integration erforderliche Konfiguration der beiden zuvor genannten Systeme ist nicht Gegenstand der Fallstudien. Dazu sind zunächst das technische SAPSystem (physische Installation) und das Business-System (Mandant) im System Landscape Directory zu definieren und anschließend anzubinden. Evtl. sind darüber hinaus noch die Integration Engine (z.B. Definition und Aktivierung der Queues) zu konfigurieren und adapterspezifische Anpassungen vorzunehmen. Eine detaillierte Anleitung zur Konfiguration ist in Nicolescu et al. (2009) zu finden. Inhaltlich und technisch bauen die drei Fallstudien aufeinander auf. Zur technischen Abgrenzung der Fallstudien und zur Reduzierung des Arbeitsaufwandes bei

110


ihrer Implementierung wird das Versionierungskonzept der SAP PI verwendet. Jede Fallstudie entspricht einer Version der zu entwickelnden Softwarekomponente. Unveränderte Design-Objekte müssen dabei nicht erneut definiert werden, sondern können jeweils aus der vorhergehenden Version übernommen werden. Webservices in Java In den Fallstudien bietet das Unternehmen auf der einen Seite seinen Kunden einen Webservice an und nutzt auf der anderen Seite als Konsument zwei Webservices. Der erste simuliert die von den Lieferanten bereitgestellte Schnittstelle, die zur Ermittlung der Treibhausgase der Vorprodukte dient und somit die vergleichbare Funktionalität auf Seiten der Lieferanten bietet, die den Kunden des Unternehmens zur Verfügung gestellt wird. Der zweite Webservice simuliert das im Unternehmen verwendete EMIS, das die Treibhausgase der internen Produktionsprozesse darstellt. Die beiden zuvor genannten Webservices sind unter einer Webapplikation mit dem Namen EnvironmentalServices zusammengefasst und wurden mit Java 1.6 unter Verwendung von Apache Axis 1.4 und der Eclipse Web ToolPlattform 2.0 implementiert. Die Quellcodes sowie die WAR-Datei (Web Application Archive) können von der Begleitwebsite des Buches heruntergeladen werden. Die WAR-Datei folgt der Java-Servlet-Spezifikation und sollte in einer Vielzahl von Servlet-Engines lauffähig sein (getestet wurde dies mit einem Apache Tomcat 5.5.23). Sie können entweder die Webservices auf einer von Ihnen betriebenen Servlet-Engine bereitstellen oder den unter http://rzserv2.unilueneburg.de:8080/EnvironmentalServices bereitgestellten öffentlichen Webservice verwenden. In beiden Alternativen ist sicherzustellen, dass der Webservice netzwerkseitig aus Sicht der SAP PI erreichbar ist.

5.5 Literatur British Standards Institution (2009) PAS 2050 – Assessing the life cycle greenhouse gas emissions of goods and services.. http://www.bsigroup.com/Standards-and-Publications/How-wecan-help-you/Professional-Standards-Service/PAS-2050. Abruf 11.02.2010 Frischknecht R, Jungbluth N, Althaus HJ, Doka G, Dones R, Heck T, Hellweg S, Hischier R, Nemecek T, Rebitzer G, Spielmann M (2005) The ecoinvent Database: Overview and Methodological Framework. International Journal of Life Cycle Assessment 1:3-9 Funk B, Möller A, Niemeyer P (2007) Integration of Risk-Oriented Environmental Management Information Systems and Resource Planing Systems. In: Hryniewicz O, Studzinski J, Romaniuk M (Hrsg) Proceedings of the EnviroInfo 2007: Environmental Informatics and Systems Research. Shaker Verlag, Aachen, S 545-552 Funk B, Möller A, Niemeyer P (2009) Integration of Environmental Management Information Systems and ERP systems using Integration Platforms. In: Athanasiadis IN, Mitkas PA, Rizzoli AE, Marx Gómez J (Hrsg) Information Technologies in Environmental Engineering. Springer, Berlin, Heidelberg, S 53-63 Goedkoop M, Spriensma R (2001) The Eco-indicator 99 – A damage oriented method for LCIA. http://www.pre.nl/download/EI99_methodology_v3.pdf. Abruf 11.02.2010

Literatur

111

Guinée JB (Hrsg) (2002) Handbook on Life Cycle Assessment. Operational Guide to the ISO Standards. Kluwer, Dordrecht Isenmann R, Rautenstrauch C (2007) Horizontale und vertikale Integration Betrieblicher Umweltinformationssysteme in Betriebswirtschaftlichen Anwendungsszenarien. uwf 2:75-81 Leontief W (1970) Environmental Repercussions and the Economic Structure: An Input-Output Approach. The Review of Economics and Statistics 3:262-271 Möller A (2000) Grundlagen stoffstrombasierter betrieblicher Umweltinformationssysteme. Projekt-Verlag, Bochum Nicolescu V, Funk B, Niemeyer P, Heiler M, Wittges H, Morandell T, Visintin F, Kleine Stegemann B, Kienegger H (2009) Praxishandbuch SAP NetWeaver PI – Entwicklung. SAP Press, Bonn Seuring S, Müller M (2008) From a literature review to a conceptual framework for sustainable supply chain management. Journal of Cleaner Production 15:1699-1710

6 Fallstudie zur service-orientierten Integration 6.1 Lernziele Nach Bearbeitung des Kapitels sind Sie in der Lage, die SAP PI als MessageBroker einzusetzen und können die folgenden Fragen beantworten: x Wie lassen sich externe SAP-Systeme an die SAP PI anbinden? x Welche Funktion haben Namensräume, Software Components und deren Versionierung in SAP PI? x Welche Funktion übernehmen Design-Artefakte wie Data Types, Message Types und Message Mappings und in welchem Zusammenhang stehen sie? x Welche Funktion haben Communication Channels und wie lassen sie sich anlegen? Welche Elemente umfassen sie? x Wie können entwickelte Dienste in SAP PI als Webservice von außen aufgerufen werden? x Wie kann die Nachrichtenkommunikation mit und die Nachrichtenverarbeitung innerhalb der SAP PI überwacht werden?

6.2 Einleitung Die anhaltende Diskussion zum Klimawandel führt zu einer Veränderung des Kundenverhaltens bzgl. ihrer Kaufentscheidungen. Dabei rücken neben rein preislichen Kriterien neue klimarelevante Kriterien bei der Kaufentscheidung in den Fokus. Verschiedene Initiativen zum sog. Product Carbon Footprint und CO2-Labelling haben eine Diskussion über produktspezifischen Klimaschutz und Treibhausbilanzen von Produkten weiter vorangeführt. Unternehmen stehen vor der Aufgabe sich diesen Trends anzupassen und das Informationsbedürfnis ihrer Kunden durch die Bereitstellung entsprechender produktbezogener Daten zu stillen.

6.2.1 Aufgabenstellung Fachliche Zielsetzung der ersten Fallstudie ist es, Kunden eines Unternehmens die Möglichkeit zu bieten, den Carbon Footprint von Produkten abzufragen, die bei dem Unternehmen erworben wurden. Aus Gründen der Vereinfachung wird in dieser Fallstudie davon ausgegangen, dass alle für die Ermittlung des Carbon Footprints benötigten Daten in den Systemen des Unternehmens vorhanden sind

114

Fallstudie zur service-orientierten Integration

und nicht unter Zuhilfenahme externer Systeme bestimmt werden müssen. Es soll ein höchstmöglicher Automatisierungsgrad erreicht und manuelle Bearbeitungsschritte beim Unternehmen vermieden werden.

6.2.2 Umsetzung Die erste Fallstudie erläutert die für die Verwendung von SAP PI und Webserivces erforderlichen technischen Grundlagen. Die Designobjekte dieses Kapitels werden in der zweiten und dritten Fallstudie wiederverwendet und stellen so ein Grundgerüst für die Kommunikation der beteiligten Systeme dar. Systemlandschaft Die eingesetzte SAP PI ermöglicht den Datenaustausch zwischen SAP- und Fremd-Systemen und ist Teil der Systemlandschaft des Unternehmens. Die Produktdaten stammen aus einem SAP ERP-System, welches zur Systemlandschaft des Unternehmens gehört und nach dem Outside-In-Modell an die SAP PI angebunden wird. Typisch für das Outside-In-Modell ist die Definition der Schnittstelle, über die ein externes System mit der SAP PI kommuniziert, innerhalb der SAP PI. Das Modell legt fest, in welchem System eine Schnittstelle syntaktisch definiert und in welches diese Definition importiert wird. Aus Sicht des externen Systems ist die SAP PI „outside“, so dass die Richtung „outside-in“ impliziert, dass die Schnittstelle in der SAP PI definiert, in das angebundene System importiert und dort anschließend implementiert wird. Der Kunde erhält über einen Webservice Zugriff auf die gewünschten Daten zur Umweltwirkung des gekauften Produktes. Der Webservice wird von der SAP PI zur Verfügung gestellt (Provider) und muss als Client (Consumer) in der Systemlandschaft des Kunden implementiert werden. Webservices ermöglichen einen standardisierten Austausch von XML Nachrichten zwischen Softwaresystemen. Eines der Softwaresysteme fungiert dabei als Server oder sog. Provider (in diesem Fall die SAP PI), das andere als Client (System des Kunden). Webservices werden häufig wie in Kap. 2 beschrieben auf Basis von SOAP realisiert. Der Webservice kommuniziert mit der SAP PI über SOAP-Messages, die über das HTTP-Protokoll versandt werden. Dafür wird innerhalb der SAP PI eine WSDLDatei erzeugt, aus der anschließend ein Webservice-Client generiert werden kann. Abb. 6.1 zeigt die beteiligten Systeme dieser Fallstudie. Es wird angenommen, dass sowohl das PI- als auch das ERP-System vom Unternehmen betrieben werden.

Einleitung

Unternehmen

Kunde

«executable» SAP PI

«executable» Webservice Client

115

«executable» SAP ERP

Abb. 6.1: Systemlandschaft der ersten Fallstudie

Ablauf der Fallstudie Der Kunde startet durch eine Anfrage eine Geschäftsprozessinstanz, indem er die Daten eines Verkaufsbelegs an das Unternehmen sendet. Die Anfrage umfasst die folgenden Daten: x x x x x

PartnerID (String, identifiziert Kunden eindeutig) DocumentID (String, identifiziert Verkaufsbeleg) DocumentItem (String, identifiziert eine einzelne Position des Lieferscheins) Material (String, eindeutiger Identifikator eines Materials) Quantity (numerischer Wert, Menge des entsprechenden Materials)

Die SAP PI leitet die Anfrage mit den oben beschriebenen Daten direkt an das SAP ERP-System weiter. Alle zur Ermittlung des Carbon Footprints benötigten Daten werden im ERP-System gehalten und können daher auf Basis der Anfragedaten ermittelt werden. Um auf das Anlegen von Verkaufsbelegen und dem Pflegen der Emissionsdaten im ERP-System verzichten zu können, wird ein ABAPFunktionsbaustein im ERP-System implementiert, der die Emissionsdaten liefert. Diese Emissionsdaten umfassen zum einen die eigentlichen Emissionen und zum anderen die Maßeinheiten der verschiedenen Emissionen (aus Gründen der Vereinfachung sind alle Emissionswerte in einer einheitlichen Maßeinheit angegeben). Die Daten werden dann, ergänzt durch die Anfragedaten, zurück an die SAP PI gesendet. Innerhalb der SAP PI werden die Emissionswerte gewichtet und zum Carbon Footprint zusammengefasst. Anschließend wird der berechnete Carbon Footprint an den Kunden zurückgeliefert. Diese Nachricht umfasst wiederum die Anfragedaten, sowie den Carbon Footprint als Wert und die Maßeinheit. Ziel der Fallstudie Die erste Fallstudie bietet eine Einführung in Basistechnologien der SAP PI. Die Einführung umfasst das Anlegen von Designobjekten, z.B. Data Types, Message Types und Message Mappings. Dabei wird ein komplexes Message Mapping

116


durchgeführt, mit dem beispielhaft der Carbon Footprint berechnet wird. Ferner wird die Anbindung von SAP ERP-Systemen und die Bereitstellung von Webservices mit Hilfe der SAP PI beschrieben.

6.3 Softwareprodukte und -komponenten Bevor Sie mit der Abbildung der Fallstudie in SAP PI beginnen können, müssen Sie einige Vorbereitungen treffen. Zunächst werden Sie im System Landscape Directory ein neues Softwareprodukt anlegen. Das System Landscape Directory bildet die interne Systemlandschaft des Herstellers ab. Dazu gehören zum einen die beteiligten Systeme und ihre Beziehungen zueinander und zum anderen eine Liste der in der Systemlandschaft verfügbaren Softwareprodukte. Ein Softwareprodukt wird zunächst unabhängig von einem System erstellt. Es kann aus verschiedenen Softwarekomponenten bestehen, die zur Kapselung von Funktionen des Softwareprodukts verwendet werden. Sowohl für Softwareprodukte als auch für Softwarekomponenten können unterschiedliche Versionen erstellt werden. Abb. 6.2 stellt den Zusammenhang zwischen Softwareprodukt und Softwarekomponente dar. «product» SAP ERP

«product version» SAP ERP 2005

«Software Component» SAP Basis

«Software Component» SAP HR

«Software Component Versio... SAP Basis 6.0

«Software Component Version» SAP Basis 7.0

«Software Component Version» SAP HR 4.0

Abb. 6.2: Zusammenhang zwischen Softwareprodukt, -komponente und -komponentenversion

Legen Sie im System Landscape Directory ein neues Softwareprodukt sowie die erste Version einer Softwarekomponente an. Im Laufe der beiden weiteren Fall-

Softwareprodukte und -komponenten

117

studien werden Sie die Softwarekomponente weiterentwickeln und entsprechend neue Versionen anlegen. Rufen Sie die Startseite der SAP PI in einem beliebigen Browser auf (ist die URL der SAP PI Startseite nicht bekannt, kann diese auch aus der SAP GUI gestartet werden, Transaktionscode: SXMB_IFR). Durch einen Klick auf System Landscape Directory gelangen Sie nach Eingabe Ihres Benutzernamens und Ihres Passworts in das System Landscape Directory. Legen Sie zunächst ein neues Softwareprodukt an, indem Sie unter Software Catalog auf Product und anschließend auf New klicken. Wählen Sie im ersten Dialogfenster die Aktion Create a new product and version aus und klicken Sie auf Next. Geben Sie im folgenden Dialogfenster in den entsprechenden Feldern die folgenden Daten ein und bestätigen Sie ihre Eingabe durch Klick auf Next. x Product Name: BPM_SAP x Product Vendor: www.springer.de x Product Version: 1 Geben Sie im Dialogfenster Software Unit als Unit Name BPM_SAP ein und gehen Sie zum nächsten Dialogschritt über. Im folgenden Dialogfenster können Sie direkt eine Softwarekomponente für das soeben angelegte Softwareprodukt erstellen. Legen Sie die Softwarekomponente für die erste Fallstudie mit den folgenden Daten an und bestätigen Sie das Anlegen des Softwareprodukts mit der ersten Softwarekomponente durch Klick auf Finish. x x x x

Vendor: www.springer.de Name: BPM_SAP Version: 1 Production State: released

Nachdem Sie das Softwareprodukt mit der Softwarekomponente für die erste Fallstudie angelegt haben, müssen Sie erst das Produkt und die zugehörige Komponente auf dem in der Fallstudie verwendeten SAP ERP-System und dann das Softwareprodukt zunächst auf dem technischen System und anschließend auf dem Business-System installieren. Im SLD der SAP PI wird zwischen technischen Systemen und BusinessSystemen unterschieden. Im Falle von SAP-Systemen handelt es sich bei den technischen Systemen um eine SAP-Installation. Als Business-Systeme werden in diesem Zusammenhang die Mandanten (logische Systeme) einer SAP-Installation bezeichnet. Wechseln Sie auf die Startseite des SLD und klicken Sie im Bereich Landscape auf Technical Systems. Sie finden dort eine Liste aller im SLD definierten technischen Systeme. Suchen Sie aus der Liste die SAP-Installation aus, die das im Rahmen dieser Fallstudie verwendete ERP-System zur Verfügung stellt und öffnen Sie dieses durch einen Klick auf den Namen. Dadurch werden Ihnen technische Informationen zum entsprechenden System angezeigt. Wählen Sie in den

118


ABAP System Details den Reiter Installed Software (Abb. 6.1) aus um sich alle auf dem technischen System installierten Softwareprodukte anzeigen zu lassen.

Abb. 6.3: Liste aller Softwareprodukte eines technischen Systems

Sie können nun ein neues Softwareprodukt auf dem technischen System durch Klick auf Add New Product installieren. Wählen Sie aus der linken Liste Ihr Softwareprodukt BPM_SAP 1 of www.springer.de aus, aktivieren Sie die Checkbox vor der einzigen Softwarekomponentenversion des Produkts in der rechten Liste und klicken Sie anschließend auf Save. Durch die Zuordnung des Softwareprodukts BPM_SAP zum technischen System steht nun allen Business-Systemen des technischen Systems das Produkt zur Verfügung. Das Produkt muss nur noch dem Business-System zugewiesen werden, das es tatsächlich nutzen soll. Wechseln Sie dafür auf die Startseite des SLD und klicken Sie im Bereich Landscape auf Business Systems. Dadurch wird Ihnen eine Tabelle aller vorhandenen Business-Systeme mit dem dazugehörigen technischen System ausgegeben. In der Spalte Client wird bei SAP-Systemen beschrieben um welchen Mandanten es sich im technischen System handelt. Öffnen Sie das Business-System, dem das neue Softwareprodukt zugewiesen werden soll, durch einen Klick auf den Namen. Dadurch wird, ähnlich wie bei den technischen Systemen, die Detailansicht des entsprechenden Business Systems geöffnet. Wählen Sie dort wiederum den Reiter Installed Software und aktiveren Sie in der Liste Installed Products die Checkbox vor der Softwareprodukt BPM_SAP 1. Schließen Sie die Installation des Softwareprodukts ebenfalls durch einen Klick auf Save ab. Sie haben nun alle notwendigen Arbeiten im SLD durchgeführt und können dieses schließen. Bevor Sie mit dem Anlegen von Designobjekten anfangen können, müssen Sie einen eigenen Namensraum in der Softwarekomponente BPM_SAP mit der Version 1 erstellen. Sie werden im Laufe der Fallstudie alle Objekte innerhalb dieses Namensraums anlegen. Namensräume werden in SAP PI zur Vermeidung von Namenskonflikten verwendet. SAP PI geht an verschiedenen Stellen davon aus, dass Designobjekte eindeutig durch die Kombination aus Namen und Namensraum zu identifizieren sind (z.B. bei der Proxy-Generierung). Innerhalb einer Softwarekomponente muss mindestens ein Namensraum existieren, um Design-

Design

119

objekte anlegen zu können. In der Regel werden Namensräume in Form von URLs bezeichnet, um eine weltweite Namenskollision von Namensräumen zu vermeiden. Rufen Sie nun die Startseite der SAP PI auf und öffnen Sie das Enterprise Services Repository durch Klick auf Enterprise Services Builder. Nachdem Sie sich mit Ihrem Benutzernamen eingeloggt haben, müssen Sie zunächst die zuvor angelegte Softwarekomponentenversion importieren. Wählen Sie dafür im Reiter Design Objects den Eintrag Local Software-Component Versions und im Kontextmenü den Eintrag New aus. Dadurch wird ein Wizard gestartet, mit dem Sie die soeben angelegte Softwarekomponentenversion in das Enterprise Services Repository importieren können. Wählen Sie dafür die Option Import from SLD aus und klicken Sie auf Display, um sich die Liste der Softwarekomponentenversionen anzeigen zu lassen. Suchen Sie aus der Liste der Softwarekomponentenversionen Ihre Softwarekomponente BPM_SAP in der Version 1 heraus und importieren Sie diese anschließend. Dadurch werden die Felder Name, Vendor und Version im Wizard automatisch ausgefüllt, und Sie können den Wizard durch Klick auf Create schließen. Nun können Sie im Enterprise Services Repository direkt auf die Softwarekomponentenversion zugreifen. Suchen Sie in der linken Liste im Reiter Design Objects die Softwarekomponente BPM_SAP. Nach dem Aufklappen der Softwarekomponente finden Sie die bisher einzige vorhandene Softwarekomponentenversion. Wählen Sie in ihrem Kontextmenü den Eintrag New und in dem sich öffnenden Dialog Namespace im Bereich Work Areas. Geben Sie als Namensraum http://springer.de/bpm/sap ein und schließen Sie den Dialog mit Klick auf Create. Anschließend speichern Sie das Fenster Edit Namespace Definition ab und schließen dieses. Wechseln Sie nun in den Reiter Change Lists und aktivieren Sie über das Kontextmenü die Standard-Änderungsliste der Softwarekomponentenversion BPM_SAP. Diese Softwarekomponente werden sie in anderer Version auch in der zweiten und dritten Fallstudie verwenden. Sie haben nun alle Vorbereitungen getroffen, die für die Durchführung der ersten Fallstudie notwendig sind und können in der folgenden Designphase die erforderlichen Schnittstellen (Interfaces) und Schnittstellen-Transformationen (Operation Mappings) anlegen.

6.4 Design In diesem Abschnitt werden die erforderlichen Designobjekte für die Nachrichtenkommunikation zwischen Kunde und Unternehmen sowie innerhalb des Unternehmens zwischen SAP-System und dem PI-System entwickelt. Abb. 6.4 zeigt die anzulegenden Designobjekte (Operation Mapping, Message Mapping, Service Interface, Message Type und Data Type) und ihre Beziehungen zueinander.

120


Abb. 6.4: Designobjekte des Fallstudienszenarios.

6.4.1 Data Types Beginnen Sie mit dem Anlegen der Data Types, die anschließend in den Message Types verwendet werden, welche wiederum Bestandteil der Service Interfaces sind. Data Types sind die grundlegende Einheit um die Struktur von Nachrichten innerhalb der SAP PI abzubilden. Ein Data Type besteht aus mehreren Feldern, die entweder auf elementaren Data Types oder anderen zuvor frei definierten Data Types basieren. Es können somit geschachtelte Data Types

Design

121

aufgebaut werden. Einzelne Elemente können in unterschiedlicher Häufigkeit auftreten. Starten Sie mit dem Anlegen des Data Types EnvImpactGHGItem in Ihrem Namensraum http://springer.de/bpm/sap. Innerhalb dieses Data Types werden jeweils die mit einem Produkt verbundenen Mengen an Treibhausgase gespeichert, die im Folgenden in die Berechnung des Carbon Footprints eingehen. Wählen Sie im Kontextmenü ihres Namensraums den Eintrag New und wählen Sie anschließend den Objekttypen Data Type aus dem Bereich Interface Objects aus. Geben Sie als Namen EnvImpactGHGItem ein, belassen Sie die Classification auf FreeStyle Data Type und klicken anschließend auf den Button Create. Legen Sie anhand von Abb. 6.5 die zwölf Elemente CO2_Impact, CO2_Unit, CH4_Impact, CH4_Unit, N2O_Impact, N2O_Unit, HFC_Impact, HFC_Unit, PFC_Impact, PFC_Unit, SF6_Impact sowie SF6_Unit an und speichern anschließend den Data Type ab.

Abb. 6.5: Aufbau des Data Types EnvImpactGHGItem

Legen Sie den nächsten Data Types EnvImpactCO2eItem nach demselben Prinzip anhand von Abb. 6.6 an. CO2e ist das in Kapitel 5 erläuterte Kohlendioxidäquivalent. Mit Einführung des Kohlendioxidäquivalents wird der Tatsache Rechnung getragen, dass nicht nur CO2, sondern auch andere Gase wie Lachgas und Methan als Treibhausgase wirken. Um eine Vergleichbarkeit verschiedener Treibhausgase zu ermöglichen, werden diese hinsichtlich ihrer Wirkung auf CO2 umgerechnet und als CO2e ausgegeben. Der Data Type wird verwendet, um den durch das Mapping berechneten Carbon Footprint in einer Nachricht versenden zu können.

122


Abb. 6.6: Aufbau des Data Types EnvImpactCO2eItem

Den Data Type SalesDocItem legen Sie analog zu den anderen beiden Data Types mit den in Tabelle 6.1 dargestellten Daten an. Dieser Data Type umfasst alle Informationen für eine Anfrage des Kunden. Er wird in allen Nachrichten, die während der Fallstudie ausgetauscht werden, verwendet. Tabelle 6.1: Aufbau des Data Types SalesDocItem Name

Category

SalesDocItem

Complexe Type

Type

Occurence

PartnerId

Element

xsd:string

1

DocumentId

Element

xsd:string

1

DocumentItem

Element

xsd:string

1

Material

Element

xsd:string

1

Quantity

Element

xsd:string

1

Das Anlegen des Data Types EnvImpactGHGSalesDocItem erfolgt analog zum Anlegen der anderen Data Types. Der Data Type stellt die Struktur der Antwort des ERP-Systems auf die durch die SAP PI weitergeleitete Kundenanfrage dar. Er setzt sich aus der Anfrage des Kunden und den durch das ERP-System angehängten Emissionen zusammen. Achten Sie darauf, dass dieser Data Type aus den beiden bereits angelegten Data Types EnvImpactGHGItem und SalesDocItem besteht. Bei der Auswahl des Typs können Sie über die Suchhilfe einen Data Types (Abb. 6.7) aus der Softwarekomponente BPM_SAP als Typ auswählen.

Abb. 6.7: Verwendung der Suchhilfe bei der Erstellung eines Data Types

Design

123

Der Data Type EnvImpactCO2eSalesDocItem wird analog zum Data Type EnvImpactGHGSalesDocItem angelegt. Dieser Data Type definiert die Struktur der Antwort des PI-Systems auf die Anfrage des Kunden und enthält die Anfrage des Kunden und den berechneten Carbon Footprint. Die beiden Elemente des Data Types (Tabelle 6.2) basieren auf den zuvor angelegten Data Type EnvImpactCO2eItem und SalesDocItem. Tabelle 6.2: Aufbau des Data Types EnvImpactCO2eSalesDocItem Name

Category

Type

Occurrence

EnvImpactCO2eSalesDocItem

Complex Type

SalesDocItem

Element

SalesDocItem

1

EnvImpactCO2eItem

Element

EnvImpactCO2eItem

1

Damit haben Sie alle benötigten Data Types angelegt und können mit dem Anlegen der Message Types fortfahren, die auf Basis der zuvor angelegten Data Types erstellt werden.

6.4.2 Message Types Wählen Sie zum Anlegen des Message Types EnvImpactCustomerRequest im Kontextmenü Ihres Namensraums den Eintrag New. Wählen Sie anschließend den Objekttyp Message Type aus dem Eintrag Interface Objects aus. Message Types umfassen jeweils einen Data Type, durch den die Struktur der Message beschrieben wird. Ein Message Type wird verwendet, um den Namen einer Message-Instanz anzugeben. Die ist notwendig, um den WSDL-Standard zu erfüllen, dass eine Message-Instanz über ein Element identifizierbar ist. Deshalb reicht es nicht aus, eine Message ausschließlich durch einen Data Type zu beschreiben. Jeder Data Type wird von mindestens einem Message Type referenziert mit Ausnahme von Data Types, die der Definition eines geschachtelten Data Types dienen, die nicht zwingend durch einen Message Type referenziert werden müssen. Geben Sie den Namen des Message Types ein und bestätigen Sie Ihre Eingabe mit Klick auf den Button Create. Wählen Sie anschließend wie in Abb. 6.8 dargestellt im Datenfeld Data Type Used den Data Type SalesDocItem aus. Um den Data Type SalesDocItem aus ihrem Namensraum auszuwählen, können Sie die Eingabehilfe aufrufen. Speichern Sie am Ende der Bearbeitung den Message Types ab.

124


Abb. 6.8: Aufbau des Message Types EnvImpactCustomerRequest

Legen Sie einen weiteren Message Type mit den Namen EnvImpactERPResponse an und wählen als verwendeten Data Type den zuvor angelegten Data Type EnvImpactGHGSalesDocItem aus. Verfahren Sie nach demselben Prinzip für den Message Type EnvImpactCustomerResponse. Wählen Sie hierbei den Data Type EnvImpactCO2eSalesDocItem als verwendeten Data Type aus. Damit haben Sie alle in diesem Szenario benötigten Message Types angelegt und können mit dem Anlegen der Service Interfaces fortfahren.

6.4.3 Service Interfaces Service Interfaces sind Schnittstellen, mit denen über die SAP PI Nachrichten zwischen Anwendungskomponenten ausgetauscht werden können. Ein Service Interface kann die Rolle übernehmen, einen Nachricht an das PISystem (outbound) oder eine Nachricht aus dem PI-System (inbound) zu senden. Mit der im Folgenden erläuterten Proxy-Generierung ermöglichen Service Interfaces die Anbindung von ABAP- und Java-Anwendungen. Es werden zwei Service Interfaces benötigt: Das erste Service Interface EnvImpactCustomer_ Sync_Out bildet die synchrone Kommunikation mit dem Kunden über einen Webservice ab. Es umfasst die Kundenanfrage (EnvImpact CustomerRequest) und die Antwort an den Kunden (EnvImpactERPResponse). Wählen Sie im Kontextmenü Ihres Namensraums den Eintrag New, um ein neues Service Interface anzulegen. Danach können Sie den Objekttyp Service Interface aus dem Bereich Interface Objects auswählen. Geben Sie anschließend den Namen ein und bestätigen Sie Ihre Eingabe mit Klick auf den Button Create. Geben Sie nun als Category des Service Interfaces Outbound und als Mode Synchronous an. Im Bereich Messages können Sie nun Message Types zum Service Interface hinzufügen. Fügen Sie die Message Types EnvImpact CustomerRequest und EnvImpactCustomerResponse aus Ihrem Namensraum anhand von Abb. 6.9 hinzu. Sie können dabei wieder die Eingabehilfe verwenden. Speichern Sie danach das Service Interface ab.

Design

125

Abb. 6.9: Aufbau des Service Interfaces EnvImpactCustomer_Sync_Out

Das zweite anzulegende Service Interface bildet die ebenfalls synchrone Kommunikation zwischen PI- und ERP-System des Unternehmens ab. Legen Sie das zweite Service Interface EnvImpactERP_Sync_In nach demselben Prinzip des ersten an. Wählen Sie diesmal als Category Inbound und als Mode Synchronous aus. Fügen Sie als Request den Message Type EnvImpactCustomerRequest und als Response den Message Type EnvImpactERPResponse aus Ihrem Namensraum hinzu. In dieser Fallstudie wird die Anfrage des Kunden durch die SAP PI an das ERP-System weitergeleitet. Der Message Type EnvImpactCustomerRequest stellt in diesem Service Interface daher die Anfrage an das ERP-System dar.

6.4.4 Message Mappings Zur Transformation der vom ERP-System versendeten Nachricht EnvImpact ERPResponse in das ausgehende Nachrichtenformat EnvImpactCustomer Response wird das Message Mapping EnvImpactERPResponse_To_EnvImpact CustomerResponse verwendet. Mit Hilfe eines Message Mappings wird definiert, wie eine Nachricht von einer XML-Struktur in eine andere transformiert werden kann. Das Erstellen von Message Mappings wird in der SAP PI von einem graphischen Mapping-Editor unterstützt. Aus einem Message Mapping wird Java-Quellcode erstellt, der zur Laufzeit durch den Integration Engine ausgeführt wird. Legen Sie in Ihrem Namensraum über das Kontextmenü mit dem Eintrag New ein neues Message Mapping an, indem Sie den Objekttyp Message Mapping aus dem Eintrag Mapping Objects auswählen. Geben Sie den Namen ein und bestätigen Sie die Eingabe durch Klick auf den Button Create. Wählen Sie zunächst über die

126


Eingabehilfe die Ausgangs-Message EnvImpactERPResponse und als ZielMessage den Message-Typ EnvImpactCustomerResponse jeweils aus Ihren Namensraum aus. Das Mapping erfolgt in zwei Schritten. Zunächst werden Sie die Kopfdaten der beiden Nachrichten mappen. Die Kopfdaten umfassen hierbei die Felder des Data Types SalesDocItem und sind in beiden Nachrichten gleichermaßen vorhanden. Danach können Sie mit Hilfe des Mappings den Carbon Footprint berechnen und in die Felder CO2eImpact und CO2eUnit der Nachricht EnvImpactRequestCO2eResponse mappen. Beginnen Sie nun mit dem Mapping der Kopfdaten. Mappen Sie zunächst die Ausgangs-Message EnvImpactERPResponse auf die Ziel-Message EnvImpactCustomerResponse. Ziehen Sie dafür das Wurzelelement EnvImpactERPResponse aus der Ausgangsmessage per Drag&Drop auf das Wurzelelement EnvImpactCustomerResponse in der Ziel-Message. Verfahren Sie mit den anderen Elementen der Kopfdaten wie in Tabelle 6.3 beschrieben. Tabelle 6.3: Mapping der Kopfdaten Elemente der Ausgangs-Message EnvImpactERPResponse

Elemente der Ziel-Message EnvImpactCustomerResponse

SalesDocItem

SalesDocItem

PartnerId

PartnerId

DocumentId

DocumentId

DocumentItem

DocumentItem

Material

Material

Quantity

Quantity

Für die Berechnung des Carbon Footprint ist ein aufwändiges Mapping notwendig. Wie bereits beschrieben wird nicht nur die CO2-Emission in den Carbon Footprint eingerechnet, sondern auch Emissionen anderer relevanter Gase. Dafür werden die verschiedenen Emissionswerte zunächst gewichtet und anschließend summiert. Der so ermittelte Wert wird in das Feld CO2e_Impact der Ziel-Message gemappt. Um die Komplexität des Mappings nicht weiter zu erhöhen, wird im Folgenden davon ausgegangen, dass alle Emissionswerte in derselben Maßeinheit vorliegen und eine weitere Umrechnung der Emissionswerte aufgrund unterschiedlicher Maßeinheiten entfällt. Deshalb kann das Element CO2e_Unit der Ziel-Message mit dem Element CO2_Unit der Ausgangsmessage 1:1 per Drag&Drop gemappt werden. Fahren Sie mit dem Mapping fort, indem Sie das Feld EnvImpactGHGItem der Ausgangs-Message mit dem Feld EnvImpactCO2eItem der Ziel-Message mappen. Die weiteren MappingAktivitäten dieses Schrittes finden im Mapping-Editor statt. Ziehen Sie zunächst per Drag&Drop die Felder CO2_Impact, CH4_Impact, N2O_Impact, HFC_Impact, PFC_Impact und SF6_Impact der Ausgangs-Message und das Feld CO2e_Impact der Ziel-Message in den Mapping Editor. Zur Gewichtung der verschiedenen Emissionen werden die in Tabelle 6.4 dargestellten Werte verwendet.

Design

127

Tabelle 6.4: Gewichtung der Emissionen Emission

Bezeichnung

Gewicht

CO2

Kohlendioxid

1

CH4

Methan

21

N2O

Distickstoffoxid

310

HFC

Fluorkohlenwasserstoffe

5920

PFC

Perfluorcarbone

7850

SF6

Schwefelhexafluorid

23900

Fügen Sie die Gewichtungen der Emissionen mit der Constant Funktion in den Mapping-Editor ein. Wählen Sie dafür in der Dropdownliste Functions den Eintrag Constants aus und ziehen anschließend die Funktion Constant in den Mapping-Editor. Per Doppelklick auf die Funktion Constant im Mapping-Editor können Sie den Wert der Funktion verändern. Fügen Sie analog die Gewichtungen der sechs verschiedenen Emissionen ein. Nun müssen die einzelnen Emissionen mit den entsprechenden Gewichtungen multipliziert werden. Dafür wird die Funktion multiply verwendet. Wählen Sie in der Dropdownliste Funktionen den Eintrag Arithmetik und anschließend die Funktion multiply. Ziehen Sie die Funktion in den Mapping-Editor und verbinden Sie Sie mit einem Emissionswert und der dazugehörigen Gewichtung. Verwenden Sie das Prinzip für alle sechs Emissionswerte. Abb. 6.10 stellt die Verbindung der Funktion multiply mit einem Emissionswert und der entsprechenden Gewichtung dar.

Abb. 6.10: Verwendung der Mappingfunktion multiply

Der Mapping-Editor umfasst nun die sechs von einander noch unabhängigen gewichteten Werte. Die einzelnen Werte können jetzt addiert werden. Dafür verwenden Sie die Funktion add aus dem Eintrag Arithmetik. Achten Sie darauf, dass mit der Funktion add immer nur zwei Werte addiert werden können. Sie müssen die Funktion add deshalb solange verwenden, bis eine endgültige Summe entstanden ist. Die endgültige Summe kann anschließend dem Feld CO2e_Impact zugeordnet werden. Dafür verbinden Sie den letzten Eintrag der add Funktion mit dem Element CO2e_Impact. Abb. 6.11 stellt das fertige Mapping der Emissionswerte dar.

128


Abb. 6.11: Message Mapping des ersten Fallstudienszenarios

Abschließend soll das eben angelegte Mapping getestet werden. Speichern Sie zunächst das Mapping ab und wechseln Sie in den Reiter Test, geben die in Abb. 6.12 dargestellten Testdaten in die Testinstanz ein und führen den Test durch.

Abb. 6.12: Test des Message Mappings des Fallstudienszenarios

Nach der Ausführung des Tests wird Ihnen das Bearbeitungsprotokoll angezeigt. Das Ergebnis Ihres Tests sollte mit dem in Abb. 6.12 dargestellten Ergebnis über-

Konfiguration

129

einstimmen. Weicht Ihr Ergebnis von dem dargestellten Ergebnis ab, kontrollieren Sie nochmals Ihr Mapping. Das Mapping ist nun fertig und kann geschlossen werden.

6.4.5 Operation Mapping Ein Operation Mapping verbindet zwei Service Interfaces, genauer gesagt zwei Operationen innerhalb der Service Interfaces, mit einander. Zur Laufzeit werden für diesen Zweck Message Mappings verwendet, die beim Anlegen des Operation Mappings ausgewählt oder angelegt werden können. In der Fallstudie soll der Aufruf des Webservices durch den Kunden an das ERPSystem weitergeleitet und die resultierende Antwort zurückgesendet werden. Dafür werden die Operationen EnvImpactCustomer_Sync_Out und EnvImpactERP_ Sync_In aus den jeweils gleichnamigen Service Interfaces verwendet. Wählen Sie in Ihrem Namensraum im Kontextmenü den Eintrag New, als Designobjekt Operation Mapping aus dem Eintrag Mapping Objects und legen Sie ein neues Operation Mapping mit dem Namen EnvImpactCustomer_Sync_ Out_To_EnvImpactERP_Sync_In an. Als Ausgangs-Operation wählen Sie über die Eingabehilfe das Service Interface EnvImpactCustomer_Sync_Out aus ihrem Namensraum aus. Als Ziel-Operation wählen Sie das Service Interface EnvImpactERP_Sync_In. Klicken Sie anschließend auf Read Operations, um die Ausgangs- und Ziel-Messages der Interfaces zu lesen. Im Reiter Request sind die Ausgangs- als auch die Ziel-Message vom selben Message Type, sodass kein Mapping notwendig ist (dies liegt daran, dass das PI-System die Kundenanfrage unverändert an das ERP-System weiterleitet). Im Reiter Response sind unterschiedliche Ausgangs- und Ziel-Messages angegeben, sodass ein Mapping notwendig ist. Geben Sie deshalb als Mapping-Programm ihr zuvor angelegtes Message Mapping EnvImpactERPResponse_To_ EnvImpactCustomerResponse an. Speichern Sie anschließend das Operation Mapping ab. Zum Abschluss der ersten Fallstudie müssen Sie die angelegten Objekte aktivieren. Wechseln Sie dafür in das Register Change Lists, und aktivieren Sie die Standard Change List in der entsprechenden Softwarekomponentenversion über das Kontextmenü mit dem Eintrag Activate. Damit haben Sie die Designphase abgeschlossen und können mit der Konfigurationsphase fortfahren.

6.5 Konfiguration Die Konfiguration bindet die entwickelten Designobjekte in konkreten Kommunikationsszenarien ein. Während die Entwicklung der Designobjekte im ESR statt-

130


findet, wird für die Konfiguration das Integration Directory verwendet. Bevor Sie mit dem Anlegen der Konfigurationsobjekte beginnen, legen Sie ein Konfigurationsszenario an. Konfigurationsszenarien werden verwendet, um Konfigurationsobjekte innerhalb des Integration Builders zu gruppieren. Sie dienen lediglich der Übersichtlichkeit und haben keine funktionellen Aufgaben. Öffnen Sie über die Startseite der SAP PI das Integration Directory durch Klick auf Integration Builder. Zum Anlegen eines neuen Konfigurationsszenarios wählen Sie im Menü Object – New und wählen aus der Liste Administration den Eintrag Configuration Scenario aus. Tragen Sie als Namen BPM_SAP_1 ein und klicken abschließend auf den Button Create.

6.5.1 Kommunikationskanäle Das ERP-System des Unternehmens wurde bereits im System Landscape Directory angelegt und beim Anlegen des Softwareprodukts verwendet. Es soll nun ein neuer Kommunikationskanal angelegt werden, der die Kommunikation zwischen ERP-System und dem Integration Server der PI konfiguriert. In einem Kommunikationskanal werden die Details zur Verarbeitung einer Nachricht festgelegt. Ein Senderkanal wird verwendet um eine Nachricht zum Integration Server zu schicken, ein Empfängerkanal dient der Zustellung von Nachrichten an externe Empfänger. Bei der Einrichtung der Kommunikationskanäle werden die erforderlichen technischen Parameter wie Login-Daten und Ort der angebundenen Systeme konfiguriert. Wählen Sie das Register Objects und navigieren Sie zum anzubindenden ERPSystem über den Pfad Communication Component – Business System. Sie finden dort die im SLD definierten Business-Systeme. Der Name des ERP-Systems ist nach dem Prinzip CLNT aufgebaut. Öffnen Sie das Business-System zur Bearbeitung und legen Sie in der Liste Communication Channels einen neuen Kommunikationskanal an. Geben Sie als Namen CLNT_1_PI_ReceiverChannel ein. Achten Sie darauf, dass der Kommunikationskanal ihrem Konfigurationsszenario hinzugefügt wird und klicken Sie auf den Button Create. Nehmen Sie nun die in Abb. 6.13 dargestellten Einstellungen im Reiter Parameters des neuen Kommunikationskanals vor. Geben Sie außerdem als Target Host as1 ein. Als User Name und User Password verwenden Sie Ihre Zugangsdaten für das ERP-System und tragen im Feld Client die entsprechende Mandanten-Nummer ein. Speichern Sie anschließend den Kommunikationskanal ab.

Konfiguration

131

Abb. 6.13: Anlegen des neuen Empfängerkanals

Das Kundensystem, von dem die Anfrage gestellt wird, ist nicht im SLD eingetragen. Sie müssen daher zunächst eine neue Business-Komponente im Integration Directory anlegen. Wählen Sie dafür im Reiter Objects unter den Pfad Communication Component – Business Component im Kontextmenü den Eintrag New. Tragen Sie als Namen BPM_SAP_CUSTOMER_1 ein und stellen Sie sicher, dass die Business-Komponente zu Ihrem Konfigurationsszenario hinzugefügt wird, bevor Sie den Button Create drücken. Wählen Sie in der neuen Business-Komponente das Register Sender und fügen ein neues Outbound-Interface hinzu. Geben Sie als Outbound Interface EnvImpactCustomer_Sync_Out aus Ihrem Namensraum an. Speichern Sie die Business-Komponente ab. Fügen Sie außerdem in demselben Reiter einen neuen Kommunikationskanal hinzu. Geben Sie als Namen BPM_SAP_CUSTOMER_1_SOAP_SenderChannel ein und stellen Sie sicher, dass der Kommunikationskanal zu Ihrem Konfigurationsszenario hinzugefügt wird. Nehmen Sie für den Kommunikationskanal die folgenden Einstellungen vor und speichern ihn danach ab. x x x x x x

Adapter Type: SOAP (Sender) Transport Protocol: HTTP Message Protocol: SOAP 1.1 Adapter Engine: Central Adapter Engine HTTP Security Level: HTTP Quality of Service: Best Effort

Wie eingangs erwähnt werden die Begriffe Empfänger- und Senderkanal aus Perspektive der angeschlossenen Systeme definiert. Der Senderkanal der Fallstudie, der zum Aufruf des PI-Systems durch den Kunden als Webservice dient, benötigt folglich keine weiteren technischen Details wie Servername oder Logindaten. Diese werden stattdessen wie im Folgenden dargestellt auf Seite des WebserviceClients, also beim Kunden, benötigt.

132


6.5.2 Web Service Description Language Im nächsten Schritt können Sie mit Hilfe der SAP PI eine WSDL-Datei erzeugen, die anschließend zur Generierung eines Webservice-Clients im Kundensystem genutzt wird. WSDL (Web Service Description Language) dient der formalen Beschreibung von Webservices im Sinne einer Schnittstellendefinition. In einer WSDL-Datei werden die für den Webservice verwendeten Data Type und Nachrichten definiert. Darüber hinaus gibt die WSDL-Datei an, aus welchen Operationen der Service besteht und unter welcher URL dieser zu finden ist. Wählen Sie zur Generierung der WSDL-Datei den Menüpunkt Tools – Display WSDL… und starten Sie damit den entsprechenden Assistenten. Überspringen Sie die Einleitung durch Klick auf Continue. Lassen Sie sich im folgenden Dialogfenster die URL des Webservices vorschlagen und gehen Sie zum nächsten Dialogschritt über (achten Sie darauf, dass die Domain in der angegebenen Form aus dem Kundensystem erreichbar ist). Wählen Sie im folgenden Dialogfenster über die Eingabehilfe das Interface EnvImpactCustomer_Sync_Out aus und gehen Sie zum nächsten Dialogschritt. Geben Sie in diesem Dialog die in Abb. 6.14 dargestellten Daten ein. Über die Buttons Back und Continue können Sie den InterfaceNamen und den Interface-Namensraum aus dem vorherigen Dialogfenster kopieren, ohne Daten zu verlieren.

Abb. 6.14: Erzeugung der WSDL-Datei für den Webservice

Kontrollieren Sie im letzten Dialogfenster nochmals alle Eingaben. Sind alle Eingaben korrekt, können Sie durch Klick auf Finish das WSDL-Dokument generieren lassen. Das generierte WSDL-Dokument speichern Sie auf Ihrem lokalen Computer unter dem Namen EnvImpactCustomer_Sync_Out_Fallstudie1.wsdl ab. Schließen Sie anschließend den Assistenten durch Klick auf Close. An dieser Stelle wird kurz auf die soeben generierte WSDL-Datei und ihre Elemente eingegan-

Konfiguration

133

gen. Mit Hilfe von WSDL-Dateien können wie in Kap. 2 erläutert Webservices beschrieben und Clients zum Aufruf des Webservices erstellt werden. Im Folgenden sollen die wesentlichen Elemente von WSDL-Dateien am Beispiel der soeben erstellten WSDL-Datei erläutert werden. Im Abschnitt werden die Data Types definiert, die der Webservice verwendet. Die Definition basiert auf den Spezifikationen des XML-Schemas und kann einfache und komplexe Data Types beschreiben. Das folgende Listing zeigt den entsprechenden Ausschnitt aus der WSDL-Datei EnvImpactRequest_ Sync_Out_Fallstudie1.wsdl. Die Elemente korrespondieren zu den in SAP PI angelegten Data Types. So wird unter anderem das Element EnvImpact RequestRequest auf Basis des Data Types SalesDocItem beschrieben. 23fe5391efb611decd1100144f8d6fda […]

Der Abschnitt beschreibt die Nachrichten, die zwischen Sender und Empfänger ausgetauscht werden. Das folgende Listing enthält zunächst die Definition der Anfrage und anschließend die der Antwort. Dabei wird jeweils angegeben, welches Element aus der Definition der Data Types in der Nachricht verwendet wird.

134


Im Abschnitt werden die Schnittstellen, genauer gesagt die Operationen des Webservices, beschrieben, über die der Webservice mit dem Client kommuniziert. In Beispiel der Fallstudie wird dort das Service Interface beschrieben. Dabei wird angegeben wird, wie die Input- und Output-Messages aussehen müssen.

Der Abschnitt beschreibt, mit welchem Protokoll die Nachrichten übertragen werden. In der oben erzeugten WSDL-Datei wird dabei beschrieben, dass der Webservice das SOAP über das Transportprotokoll http überträgt. […]

Der letzte Abschnitt beschreibt den eigentlichen Service. Dabei wird innerhalb des Abschnittes der Port in Form einer URL beschrieben, über die der Webservice erreichbar ist. Im unten folgenden Listing wird dem Service ein Name zugewiesen. Anschließend erfolgt die Beschreibung der URL.

Diese Daten reichen zur vollständigen syntaktischen Beschreibung eines Webserivces aus und werden in Abschn. 6.6.2 zur Generierung des Webservice-Clients verwendet.

Konfiguration

135

6.5.3 Konfiguration der Nachrichtenverarbeitung Nun wird die Nachrichtenverarbeitung mit Hilfe eines weiteren KonfigurationsAssistenten vorbereitet, alle benötigten Konfigurationsobjekte angelegt und die Nachrichtenstrecke konfiguriert. Wählen Sie im Menü Tools – Configuration Wizard und im Eingangsbildschirm des Assistenten Party Communication, im folgenden Dialogfenster als Sender Internal System und über die Wertehilfe den Adapter Type SOAP aus. Klicken Sie auf Continue um zum nächsten Dialogfenster zu gelangen. Nehmen Sie dort die in Abb. 6.15 dargestellten Einstellungen vor.

Abb. 6.15: Konfiguration der Message-Verarbeitung – Definition des Senders

Für den Message-Empfänger wählen Sie ebenfalls Internal System und als Adapter Type den XI-Adapter. Gehen Sie zum nächsten Dialogfenster über. Der Empfänger der Message ist ein Business System. Wählen Sie über die Wertehilfe das Business-System CLNT und anschließend das Interface EnvImpactRequest_Sync_In aus Ihrem Namensraum aus. Gehen Sie zum nächsten Schritt weiter. Eine neue Sendervereinbarung wird angelegt. In einer Sendervereinbarung wird beschrieben, wie eine Nachricht eines bestimmten Senders verarbeitet wird, damit sie von der Integration Engine bearbeitet werden kann. Kontrollieren Sie, dass als Communication Channel BPM_SAP_CUSTOMER_1_ SOAP_SenderChannel ausgewählt ist und gehen Sie zum nächsten Schritt über.

136


Das Dialogfenster zur Empfänger-Ermittlung können Sie ohne Änderungen überspringen. In der Empfänger-Ermittlung wird festgelegt, an wen eine eingehende Nachricht weitergesendet wird. Der Empfänger kann auf Basis des Inhalts der Nachricht ermittelt werden. Es können auch mehrere Empfänger angegeben werden. Die Nachricht wird dann parallel an die angegebenen Empfänger versendet. Die Interface-Ermittlung sollte bereits alle benötigten Werte enthalten. In der Interface-Ermittlung wird definiert, in welchem Format eine Nachricht an den Empfänger weitergeleitet wird und welche Message Mappings verwendet werden. Kontrollieren Sie, ob als Interface-Mapping EnvImpactRequest_Sync_Out_To_ EnvImpactRequest_Sync_In aus Ihrem Namensraum angegeben ist, und gehen Sie zum nächsten Schritt weiter. Wählen Sie bei der Empfängervereinbarung über die Wertehilfe den Communication Channel CLNT_ 1_PI_ReceiverChannel aus. In der Empfängervereinbarung wird äquivalent zur Sendervereinbarung festgelegt, über welchen Kommunikationskanal eine Nachricht an den Empfänger gesendet wird. Sorgen Sie beim letzten Schritt dafür, dass alle Einstellungen zu Ihrem Konfigurationsszenario hinzugefügt werden und klicken Sie auf Finish. Aktivieren Sie nun die Standard Change List und schließen Sie den Integration Builder. Zusammenfassend lässt sich die soeben erstellte Message-Verarbeitung wie folgt beschreiben. In der Sendervereinbarung wird festgelegt, über welchen Kommunikationskanal (BPM_SAP_CUSTOMER_1_SOAP_SenderChannel) der Sender (BPM_SAP_CUSTOMER_1) mit der SAP PI kommuniziert. Die Empfängerermittlung bestimmt, an wen die eingehende Nachricht des Senders weitergeleitet wird (CLNT). Die Interface-Ermittlung bestimmt, in welchem Format die Nachricht an den Empfänger weitergeleitet wird. Dabei wird die Transformation durch ein Operation Mapping angegeben (EnvImpactRequest_Sync_Out_To_EnvImpactRequest_Sync_In). Die Empfängervereinbarung bestimmt analog zur Sendervereinbarung, über welchen Kanal (CLNT_1_ReceiverChannel) die SAP PI mit dem Empfänger kommuniziert. Dadurch ist die Nachrichtenstrecke für die Kommunikation des Senders mit dem Empfänger für beide Richtungen konfiguriert. Bevor Sie das Szenario ausprobieren können, sind zwei weitere Schritte notwendig. Zum einen muss der ABAP-Proxy im ERP-System angelegt werden und zum anderen muss der Webservice-Client auf Ihrem lokalen Computer implementiert werden.

Umsetzung in den externen Systemen

137

6.6 Umsetzung in den externen Systemen

6.6.1 SAP-System des Unternehmens Beginnen Sie zunächst mit der Erzeugung des ABAP-Proxies im ERP-System des Unternehmens. Dieser Schritt kann als Import einer bestehenden Schnittstellenbeschreibung aus der SAP PI in ein angebundenes SAP-System interpretiert werden. Die Generierung eines ABAP-Proxys erfolgt nach dem Outside-In-Modell. Über die Transaktion SPROXY wird im ERP-System auf Basis der im Enterprise Services Repository hinterlegten Schnittstelle eine ABAP-ProxyKlasse erzeugt. Dabei muss man zwischen Outbound- und Inbound-Proxys unterscheiden. Bei Outbound-Proxys wird über eine EXECUTE-Methode eine Nachricht verschickt. Bei Inbound-Proxys wird eine Klasse generiert, in der die Bearbeitungslogik der eingehenden Nachricht implementiert werden kann. Melden Sie sich am ERP-System an und rufen Sie den Transaktionscode SPROXY auf. Wählen Sie dort in der linken Navigation den Eintrag Enterprise Service Browser aus, mit dem Sie auf das Enterprise Services Repository des PI-Systems zugreifen können und navigieren Sie zur Softwarekomponente BPM_SAP in der Version 1. Gehen Sie dann zum Service Interface EnvImpactERP_Sync_In und wählen Sie im Kontextmenü den Eintrag Create Proxy. Bitte beachten Sie, dass der Benutzer, mit dem Sie den Proxy anlegen wollen, als Entwickler in SAP registriert ist. Dadurch wird ein Wizard zur Erstellung des ABAP-Proxys gestartet. Im ersten Dialog des Wizards haben Sie die Möglichkeit, ein Entwicklungspaket für die Implementierung der Proxy-Objekte auszuwählen bzw. ein neues Entwicklungspaket anzulegen. Im Rahmen dieser Fallstudie reicht es aus, das bereits bestehende Entwicklungspaket $TMP zu verwenden. Aktivieren Sie daher die Checkbox Local Object und geben die folgenden Daten ein, bevor Sie mit Klick auf Continue zum nächsten Dialog gelangen: x Package: $TMP x Prefix: ZBPM Dadurch haben Sie bereits alle notwendigen Eingaben gemacht und können den Wizard durch Klick auf Complete schließen. Anschließend werden die ProxyObjekte automatisch generiert. Speichern Sie alle Änderungen durch Klick auf das Disketten-Icon ab und aktivieren Sie danach alle angelegten Proxy-Objekte über den Menüpfad Proxy – Activate all.

138


Nun können Sie die ABAP-Proxy-Klassenmethode implementieren. Wechseln Sie dafür in die Transaktion SE80 (Object Navigator) und rufen Sie den Repository Browser auf. Suchen Sie anschließend das lokale Entwicklungspaket $TMP indem Sie den Typ Package und als Suchstring $TMP eingeben. Wählen Sie anschließend in dem aufgerufenen Entwicklungspaket die Klassenmethode ENV_IMPACT_ERP_SYNC_IN wie in Abb. 6.16 dargestellt auf.

Abb. 6.16: Auswahl der ABAP-Proxy-Klassenmethode

Wählen Sie im Kontextmenü der Klassenmethode Change – Implementation, um die Klassenmethode zu verändern. Fügen Sie in dem sich öffnenden ABAP-Editor folgendes Listing ein, und speichern Sie die Änderung anschließend ab. METHOD zbpmii_env_impact_erp_sync_in~env_impact_erp_sync_in. * Zuweisung der Daten aus dem Request ( Data Type SalesDocItem ) output íenv_impact_erpresponseísales_doc_item ípartner_id = input íenv_impact_customer_requestípartner_id . output íenv_impact_erpresponseísales_doc_itemídocument_id = input íenv_impact_customer_requestídocument_id . output íenv_impact_erpresponseísales_doc_itemídocument_item = input íenv_impact_customer_requestídocument_item . output íenv_impact_erpresponseísales_doc_item ímaterial = input íenv_impact_customer_request ímaterial . output íenv_impact_erpresponse ísales_doc_item íquantity = input íenv_impact_customer_request íquantity .

Umsetzung in den externen Systemen

139

* Zuweisung von Testdaten ( Data Type EnvImpactGHG) output íenv_impact_erpresponse íenv_impact_ghgíco2_impact = ’ 0.8520 ’ . output íenv_impact_erpresponse íenv_impact_ghgíco2_unit = ’ g ’ . output íenv_impact_erpresponse íenv_impact_ghgích4_impact = ’ 0.0456 ’ . output íenv_impact_erpresponse íenv_impact_ghgích4_unit = ’ g ’ . output íenv_impact_erpresponse íenv_impact_ghgín2o_impact = ’ 0.4155 ’ . output íenv_impact_erpresponse íenv_impact_ghgín2o_unit = ’ g ’ . output íenv_impact_erpresponse íenv_impact_ghgíhfc_impact = ’ 0.0124 ’ . output íenv_impact_erpresponse íenv_impact_ghgíhfc_unit = ’ g ’ . output íenv_impact_erpresponse íenv_impact_ghgípfc_impact = ’ 0.1050 ’ . output íenv_impact_erpresponse íenv_impact_ghgípfc_unit = ’ g ’ . output íenv_impact_erpresponse íenv_impact_ghgísf6_impact = ’ 0.2120 ’ . output íenv_impact_erpresponse íenv_impact_ghgísf6_unit = ’ g ’ . ENDMETHOD.

Die erstellte Klassenmethode liefert bei Aufruf grundsätzlich konstante DummyWerte zurück. Sie können die soeben geänderte Klassenmethode über den Menüeintrag Method – Check – Method auf Syntaxfehler überprüfen. Wenn die Überprüfung fehlerfrei abläuft, erscheint die Meldung No syntax errors found in der Systemleiste. Nun müssen Sie die veränderten Objekte des Proxys aktivieren. Wählen Sie hierfür den Menüpunkt Method – Activate und aktivieren Sie alle Objekte, die ENV_IMPACT im Namen enthalten. Über den Menüeintrag Method – Test/Execute können Sie nun durch die Eingabe von Testdaten die implementierte Methode testen.

6.6.2 Implementierung des Webservice-Clients Den Webservice-Client des Kunden können Sie anhand der bereits erzeugten und lokal gespeicherten WSDL-Datei EnvImpactRequest_Sync_Out_Fallstudie1.wsdl implementieren. Es gibt hierfür eine Vielzahl von WebserviceImplementierungen, die sich bspw. in Programmiersprache, unterstützten Betriebssystemen und Architektur unterscheiden. Sofern Sie bereits über technische Erfahrungen in der Realisierung von Webservices und Webservice-Clients verfügen, können Sie im Folgenden die Ihnen vertraute Webservice-Plattform verwenden. Im Rahmen dieser und der folgenden Fallstudie wird die Eclipse Web Tool Platform (WTP) als Erweiterung von Eclipse in Kombination mit Apache AXIS verwendet. Die Webservices laufen auf einem Apache Tomcat Server. Nachdem Sie die aktuelle Eclipse-Version heruntergeladen haben, können Sie die WTP als Erweiterung installieren. Achten Sie darauf, dass alle Anforderungen für die Installation der verwendeten Version der WTP erfüllt sind. Danach können Sie die aktuelle Version des Apache Tomcat Servers herunterladen und in einem beliebigen Verzeichnis auf Ihrem lokalen Computer installieren. Anschließend

140


müssen Sie den Server als Laufzeitumgebung in den Eclipse-Einstellungen auswählen. Legen Sie nun ein neues Java Projekt an und importieren Sie die zuvor im PISystem erzeugte WSDL-Datei. Im Menü über New – Web Services – Web Service Client können Sie einen neuen Webservice Client erzeugen. Dadurch werden mehrere Java-Klassen erstellt. Bevor Sie den Webservice aus Eclipse heraus aufrufen können, müssen Sie zwei Anpassungen vornehmen. Öffnen Sie die bei der Webservice-Client-Generierung erstellte Java-Klasse EnvImpactRequest_Sync_OutBindingStub.java, und fügen Sie die folgenden Zeilen ergänzt durch Ihre Zugangsdaten hinzu. public EnvImpactCO2ESalesDocItem envImpactRequest_Sync_Out(SalesDocItemenv ImpactRequestRequest) throws java.rmi.RemoteException { [...] _call.setUsername("Ihr Benutzername"); _call.setPassword("Ihr Benutzerkennwort"); [...] }

Alternativ können die Logindaten für das SAP-System auch direkt in der URL zum Aufruf des Webservices in der Form http://username:password@PI-URL eingebaut werden. Für den Aufruf des Webservice aus Eclipse heraus müssen Sie eine weitere Java-Klasse in Ihrem Projekt anlegen. Verwenden Sie dafür das folgende Listing. Durch das Ausführen der Klasse ClientCaseStudy1 in Eclipse können Sie den Webservice aufrufen. package de.springer.bpm.sap; import java.math.BigInteger; import java.rmi.RemoteException ; import javax.xml.rpc.ServiceException; public class ClientCaseStudy1{ public static void main (String[]args){ SalesDocItem item = new SalesDocItem(); item.setPartnerId("100005"); item.setDocumentId("900002"); item.setDocumentItem("20"); item.setMaterial("Pí100"); item.setQuantity(new BigInteger("4")); EnvImpactRequest_Sync_OutServiceLocator locator = new EnvImpactRequest_ Sync_OutServiceLocator(); try { EnvImpactCO2ESalesDocItem impact; impact = locator.getEnvImpactRequest_Sync_OutPort().envImpactRequest_Sync_Out(item); System.out.println("Material : " + impact.getSalesDocItem().getMaterial());

Ablauf und Monitoring

141

System.out.println("Menge : " + impact.getSalesDocItem().getQuantity().toString()); System.out.println("Carbon Footprint : " + impact .getEnvImpactCO2EItem().getCO2E_Impact() + impact .getEnvImpactCO2EItem().getCO2E_Unit()); } catch (RemoteException ex) { ex.printStackTrace(); } catch (ServiceException ex) { ex.printStackTrace(); } } }

Der Webservice-Client instanziiert zunächst ein Sales-Dokument und dann das Stellvertreterobjekt des Webservices locator. Der Aufruf des Webservices erfolgt im Hintergrund und lädt das Ergebnis in das Objekt impact. Sie haben nun sowohl das im SAP-System des Unternehmens erforderliche Programm als auch den Webservice Client des Kunden implementiert und können im nächsten Abschnitt das Szenario ausführen.

6.7 Ablauf und Monitoring Nachdem Sie den Webservice mit Hilfe des Webservice Clients des Kunden aufgerufen haben, können Sie die vom Integration Server verarbeiteten Messages im Monitoring der SAP PI nachvollziehen. Melden Sie sich dafür über den SAP Logon am PI-System mit Ihren Zugangsdaten an, und rufen Sie die Transaktion SXMB_MONI auf. Wählen Sie den Punkt Monitor for processed XML-Messages und führen Sie die Anfrage aus. Es werden nun alle im Selektionszeitraum verarbeiteten Messages angezeigt (Abb. 6.17).

Abb. 6.17: Ansicht der Nachrichten mit der Transaktion SXMB_Moni

Sie können die Nachrichtenverarbeitung auch über das Webinterface der SAP PI nachvollziehen. Rufen Sie hierfür die Startseite der SAP PI in einem WebBrowser auf. Wählen Sie anschließend aus der Kategorie Configuration and

142


Monitoring den Eintrag Runtime Workbench aus. Es öffnet sich ein neues Fenster, in dem Sie den Link Message Monitoring auswählen. Sie können nun als Komponente die Integration Engine und als Quelle Datenbank auswählen. Durch einen Klick auf Anzeigen gelangen Sie zum Selektionsbildschirm und können Ihrer Suchanfrage durch Auswahl eines Zeitraums einschränken. Mit einem Klick auf Start wird Ihre Abfrage ausgeführt und das Ergebnis der Abfrage wird Ihnen angezeigt. Abb. 6.18 zeigt das Message-Monitoring unter Zuhilfenahme des Webinterfaces.

Abb. 6.18: Message-Monitoring mit Hilfe des Webinterfaces


6.8 Kontrollfragen und weiterführende Aufgaben Tabelle 6.5: Kontrollfragen Nr. Frage


1

Welche Funktion hat das System Landscape Directory? Welche Systeme sind dort für die erste Fallstudie anzulegen?

6.3

2

Ist ein Anlegen des Kunden im System Landscape Directory erforderlich? Begründen Sie Ihre Antwort.

6.3

3

Erläutern Sie die Bedeutung von Name Spaces.

6.3

4

Erläutern Sie anhand der Abb. 6.4 den Zusammenhang zwischen Service Interface und Message Type

6.4

5

Über welche Eigenschaften verfügt ein Service Interface?

6.4

6

Welche primitiven Data Types bietet die SAP PI? Inwieweit können komplexe Data Types über die primitiven hinausgehen?

6.4

7

Schauen Sie sich im ESR die Möglichkeiten des Message Mappings an und skizzieren Sie anhand von Beispielen deren Verwendung? Gibt es Mapping-Aufgaben, die mit den verfügbaren Funktionen nicht abbildbar sind?

6.4

8

Warum ist über das Message Mapping hinausgehend noch ein Operation Mapping erforderlich?

6.4

9

Erklären Sie, warum eine Trennung in Entwurf (ESR) und Konfiguration (ID) sinnvoll ist.

6.4, 6.5

10

Welche Arten von Kommunikationskanälen gibt es? Welche Funktion übernehmen diese jeweils?

6.5

11

Erläutern Sie den Zusammenhang der wesentlichen XMLElemente der WSDL-Datei und stellen Sie einen Zusammenhang zu den konkreten Design-Artefakten her.

6.5

12

Warum ist nach dem Anlegen der Kommunikationskanäle noch die Konfiguration der Nachrichtenverarbeitung erforderlich?

6.5

13

Beschreiben Sie am Beispiel der ersten Fallstudie das Outside-InProgrammiermodell? Wo kommt es zum Einsatz?

6.6

14

Recherchieren Sie nach weiteren SOAP-Implementierungen, die die Generierung von Proxies anhand von WSDL unterstützen und setzen Sie den Client damit um.

6.6

15

Untersuchen Sie mit Hilfe der verschiedenen MonitoringMöglichkeiten den Inhalt der Nachrichten? Welche Zusatzinformationen stehen beim Monitoring auf Ebene einzelner Nachrichten zur Verfügung?

6.7

16

Abschließend beschreiben Sie die Ziele und das inhaltliche Vorgehen der ersten Fallstudie.

143

7 Fallstudie zur Geschäftsprozessautomatisierung 7.1 Lernziele Nach Bearbeitung des Kapitels sind Sie in der Lage, die SAP PI als BusinessProcess-Engine für einfache Integrationsprozesse einzusetzen und können die folgenden Fragen beantworten: x Worin unterscheiden sich die Programmieransätze Inside-Out und Outside-In? x Was versteht man unter RFC-Bausteinen, und welche Bedeutung haben RFCBausteine in der Prozessintegration? x Wie lassen sich Integrationsprozesse in SAP PI definieren und wofür werden sie eingesetzt? x Wie lassen sich Kontrollstrukturen (Sequenzen, Selektionen, Iterationen) in Integrationsprozessen abbilden? x Welche Werkzeuge stellt die SAP PI zur Überwachung von Integrationsprozessen zur Verfügung?

7.2 Einleitung Während in der ersten Fallstudie davon ausgegangen wurde, dass dem Unternehmen die Umweltwirkungen zu allen ausgelieferten Produkten bekannt sind, geht die zweite Fallstudie näher auf die Bestimmung dieser Daten ein. Es wird davon ausgegangen, dass ein internes Umweltinformationssystem Auskunft über die Umweltwirkung der eigenen Fertigungsprozesse gibt, während die Lieferanten Informationen über die Umweltwirkungen der Vorketten zur Verfügung stellen.

7.2.1 Aufgabenstellung In der zweiten Fallstudie wird die Aufgabenstellung der ersten Fallstudie erweitert. Wieder sollen Kunden in die Lage versetzt werden, das CO2-Äquivalent eines vom Hersteller bezogenen Produkts abzufragen. Während in der ersten Fallstudie vereinfachend angenommen wurde, dass alle relevanten Emissionen dem Hersteller schon bekannt sind, müssen diese Daten in der zweiten Fallstudie erst ermittelt werden. Hierzu müssen neben den vom Hersteller selbst verursachten Emissionen die der Vorketten berücksichtigt werden.

146

Fallstudie zur Geschäftsprozessautomatisierung

Zur Ermittlung der vom Unternehmen selbst verursachten Emissionen steht in unserem Szenario ein betriebliches Umweltinformationssystem (EMIS – im Buch wird die in der Praxis verbreitete Abkürzung für den englischen Begriff Environmental Information System verwendet) zur Verfügung, das auf Basis von Fertigungsaufträgen (des Herstellers) die induzierten Emissionen ableiten kann. Die Emissionen der Vorketten werden bei den entsprechenden Lieferanten abgefragt. In dieser Fallstudie wird vereinfachend davon ausgegangen, dass jeder Lieferant (etwa durch Einsatz derselben Software) in der Lage ist, die Emissionen zu allen gelieferten Produkten anzugeben. Schließlich wird angenommen, dass das ERP-System des Unternehmens in der Lage ist zu jedem gelieferten Produkt die zugrundeliegenden Fertigungsprozesse und Beschaffungspositionen zu ermitteln. Die Herausforderungen der zweiten Fallstudie liegen in der Anbindung der Lieferantensysteme und des EMIS an die Systemlandschaft des Unternehmens sowie in der Parallelisierung des Nachrichtenflusses. Durch vereinfachende Annahmen wird ein höchstmöglicher Automatisierungsgrad erreicht, manuelle Eingriffe sind nicht erforderlich.

7.2.2 Umsetzung Im Folgenden wird eine Lösungsmöglichkeit für die geschilderten Herausforderungen wiederum unter der Verwendung des Softwarepakets SAP Process Integration (PI) und der Nutzung von Webservices vorgestellt. Systemlandschaft Die aus der ersten Fallstudie bekannte Systemlandschaft wird wie folgt verändert: x Anbindung des EMIS zur Ermittlung der Emissionen des Herstellers x Anbindung von Lieferantensystemen zur Ermittlung der Emissionen aus Vorketten, vereinfachend beschränken wir uns darauf genau ein Lieferantensystem anzuschließen x Im Gegensatz zur ersten Fallstudie wird das ERP-System des Unternehmens nicht nach dem Outside-In-Ansatz, sondern nach dem Inside-Out-Ansatz an die SAP PI angebunden. Dafür wird ein remotefähiger Funktionsbaustein (RFC) im ERP-System entwickelt und in die SAP PI importiert. Dem Inside-Out-Ansatz folgend werden die erforderlichen Schnittstelle in der anzubindenden Anwendung entwickelt und der anschließend in das PISystem importiert. Die Weiterentwicklung der Schnittstelle findet ebenfalls in der Anwendung statt, sodass bei Veränderungen stets ein neuer Import notwendig ist.

Einleitung

147

Die Anbindung des Kundensystems bleibt unverändert: Dem Kunden wird ein Webservice zur Verfügung gestellt, den er in seiner Systemlandschaft implementieren kann. Die Anbindung des Lieferantensystems und des EMIS erfolgt gleichfalls über Webservices die mit der SAP PI über SOAP-Message kommunizieren. In Abb. 7.1 wird die Systemlandschaft der zweiten Fallstudie dargestellt.

Lieferant

Unternehmen

Kunde


«executable» Webservice supplier



«executable» Webservice EMIS

Abb. 7.1: Systemlandschaft der zweiten Fallstudie

Ablauf des Szenarios Wie in der ersten Fallstudie wird der Geschäftsprozess durch die Anfrage des Kunden initialisiert, der die Daten eines Verkaufsbelegs (Kundenummer, Auftragsnummer und Materialnummer) an das Unternehmen sendet. Aufgrund des komplexeren Prozesses und der angestrebten Parallelisierung leitet das PI-System die Anfrage nicht direkt weiter, sondern instantiiert einen Integrationsprozess der die Steuerung des weiteren Ablaufs übernimmt. Ein Integrationsprozess ist ein ausführbarer Prozess zur Verarbeitung von Nachrichten. Innerhalb eines Integrationsprozesses werden einzelne Prozessschritte und steuerungsrelevante Parameter definiert. Integrationsprozesse werden zur Steuerung und Überwachung von unternehmensübergreifenden Geschäftsprozessen eingesetzt. Im Rahmen dieses Integrationsprozesses werden zunächst die Fertigungs- und Beschaffungspositionen abgefragt, die dem vom Kunden angefragten Produkt zugrundeliegen. Nach dem Inside-Out-Ansatz wird diese Funktion im ERP-System (als SAP Funktionsbaustein) entwickelt und dann in das PI-System importiert. Der daraus resultierende Service liefert eine Liste von Beschaffungspositionen und eine Liste von Fertigungspositionen. Im nächsten Schritt wird die Liste mit den Fer-

148


tigungspositionen an das EMIS System übergeben, das die zugehörigen Emissionsdaten zurückliefert. Parallel zur Anfrage an das EMIS wird die Liste mit den Beschaffungspositionen an das Lieferantensystem übergeben, das die zugehörigen Emissionsdaten zurückliefert. Sobald der Integrationsprozess alle angefragten Emissionsdaten erhalten hat, werden diese zunächst aggregiert, und dann – analog zur ersten Fallstudie – in CO2e umgerechnet und an den anfragenden Kunden zurückgeliefert. Der Ablauf des Szenarios der zweiten Fallstudie wird in Abb. 7.2 dargestellt. «executable» Webservice Client

«executable» «executable» «executable» SAP ERP BPM_SAP_3 Supplier

«executable» EMIS

Request CO2e Identify purchase and production data seq primary data seq material

Request emission

seq production Request emission

aggregate emission Calculate CO2e

Abb. 7.2: Ablauf des Szenarios der zweiten Fallstudie

7.3 Vorbereitungen SAP PI Um möglichst viele Objekte aus der ersten Fallstudie übernehmen zu können, bilden wir die zweite Fallstudie als neue Version derselben Softwarekomponente BPM_SAP ab. Hierzu werden zunächst die neue Softwarekomponente im SLD erfasst und anschließend alle unveränderten Designobjekte kopiert.

Vorbereitungen SAP PI

149

7.3.1 Software-Komponentenversion Rufen Sie die Startseite des PI-Systems in einem beliebigen Browser auf und öffnen Sie das System Landscape Directory. Nachdem Sie sich mit Ihrem Benutzernamen eingeloggt haben, öffnen Sie den Software Catalog zur Anzeige der vorhandenen Softwarekomponenten durch Klick auf Software Components. Zum Anlegen einer neuen Softwarekomponentenversion wählen Sie im Software Catalog den Button New. Verwenden Sie diesmal im ersten Dialogfenster die Option Create a new version for an existing software component und klicken Sie auf Next. Wählen Sie im folgenden Dialogfenster im Feld Product Version aus der Dropdownliste Ihr Softwareprodukt BPM_SAP 1 of www.springer.de aus. Dadurch werden die beiden Felder Unit und Vendor automatisch ausgefüllt. Wählen Sie im Feld Name den einzig verfügbaren Eintrag BPM_SAP aus der Dropdownliste aus, geben Sie als Version 2 an und achten Sie darauf, dass der Production State auf released steht bevor Sie die Erstellung der Softwarekomponentenversion durch Klick auf Finish abschließen. Eine Installation auf dem technischen System und anschließend auf dem Business-System ist nicht notwendig, da die neue Softwarekomponentenversion automatisch dem bereits bestehenden Softwareprodukt zugewiesen wurde, welches bereits auf den beiden Systemen installiert ist. Bevor Sie mit der Arbeit in der neuen Softwarekomponentenversion beginnen können, müssen Sie diese wiederum in das Enterprise Services Repository importieren. Rufen Sie dafür die Startseite der SAP PI auf und öffnen Sie das Enterprise Services Repository durch Klick auf Enterprise Services Builder. Nach erfolgreichem Login wählen Sie im Reiter Design Objects im Kontextmenü des Eintrags Local Software Component Versions den Punkt New. Dadurch wird ein Wizard gestartet, mit dem Sie die soeben angelegte Softwarekomponentenversion in das Enterprise Services Repository importieren können. Wählen Sie dafür die Option Import from SLD aus und klicken Sie anschließend auf Display, um sich die Liste der Softwarekomponentenversionen anzeigen zu lassen. Suchen Sie aus der Liste der Softwarekomponentenversionen Ihre Softwarekomponente BPM_SAP in der Version 2 heraus und importieren Sie diese anschließend. Dadurch werden die Felder Name, Vendor und Version im Wizard automatisch ausgefüllt und Sie können den Wizard durch Klick auf Create schließen. Speichern Sie das Fenster Edit Software Component Version, nachdem Sie die Originalsprache auf Deutsch gestellt haben ab. Nun können Sie im Enterprise Services Repository direkt auf die Softwarekomponenten-Version zugreifen. Im Verlauf der zweiten Fallstudie werden verschiedene Designobjekte aus unterschiedlichen externen Systemen in die SAP PI importiert. Aus Gründen der Übersichtlichkeit werden Sie daher für jedes externe System einen eigenen Namensraum anlegen in dem die Objekte des Systems abgelegt werden. Zusätzlich

150


werden Sie wieder einen weiteren Namensraum für die in SAP PI erstellten Designobjekte anlegen.

7.3.2 Namensräume Beginnen Sie zunächst mit dem Namensraum für selbsterstellte Designobjekte. Suchen Sie in der linken Liste im Reiter Design Objects die Softwarekomponente BPM_SAP. Nach dem Aufklappen der Softwarekomponente finden Sie zwei verschiedene Software-Komponentenversionen. Wählen Sie im Kontextmenü der zweiten Software-Komponentenversion den Eintrag New und in dem sich öffnenden Dialog Namespace im Eintrag Work Areas. Geben Sie als Namensraum http://www.springer.de/bpm/sap ein und schließen Sie den Dialog mit Klick auf Create. Dadurch wird das Fenster Edit Namespace Definition geöffnet. Der soeben angelegte Namensraum befindet sich bereits in der Liste der Namensräume. Fügen Sie nun zwei weitere Namensräume hinzu, indem Sie in der Liste zwei neue Zeilen einfügen und die folgenden Bezeichnungen der Namensräume eingeben. x http://services.springer.de/supplier x http://services.springer.de/emis Speichern Sie das Fenster Edit Namespace Definition ab.

7.3.3 Verbindungsdaten zum ERP-System Nun müssen Sie die Verbindungsdaten zum ERP-System in der SoftwareKomponentenversion eintragen. Die Verbindungsdaten werden zum Import von Designobjekten aus dem ERP-System verwendet und haben keinen Einfluss auf die Konfigurationszeit und den Nachrichtenfluss des Szenarios. Öffnen Sie mit einem Doppelklick auf den Namen die Software-Komponentenversion BPM_SAP 2 of www.springer.de. Sie haben die Software-Komponentenversion nun zur Ansicht geöffnet und müssen in den Bearbeitungsmodus wechseln, bevor Sie die folgenden Verbindungsdaten eingeben. x System: x Client: x Message Server: z Speichern Sie anschließend Ihre Eingaben im Fenster Edit Software Component Version ab. Wechseln Sie in den Reiter Change Lists und aktivieren Sie die Standard-Änderungsliste der Software-Komponentenversion.

Vorbereitungen SAP ERP

151

7.3.4 Release-Übernahme von Designobjekten Zur Übernahme von Designobjekten in neue Komponentenversionen steht in der SAP PI eine komfortable Kopierfunktion zur Verfügung. Wählen Sie hierzu im Menü des Enterprise Services Builder Tools – Transfer Design Objects. Überspringen Sie den Startbildschirm des Wizards. Wählen Sie als Source die erste Software-Komponentenversion und als Target die zweite SoftwareKomponentenversion Ihrer Softwarekomponente BPM_SAP und fahren Sie mit der Auswahl der Objekte im nächsten Dialogschritt fort. Wählen Sie in der Dropdownliste Object Set den Eintrag Individual Objects und deaktivieren Sie ggf. die Option Skip Preview. Fügen Sie nun die in Tabelle 7.1 aufgezählten Designobjekte zur Übernahme hinzu. Tabelle 7.1: Objekte für die Releaseübernahme Name

Type

EnvImpactCO2eItem

Data Type

EnvImpactCO2eSalesDocItem

Data Type

EnvImpactGHGItem

Data Type

EnvImpactGHGSalesDocItem

Data Type

SalesDocItem

Data Type

EnvImpactCustomerResponse

Message Type

EnvImpactERPResponse

Message Type

EnvImpactCustomerRequest

Message Type

EnvImpactERPResponse_To_EnvImpactCustomerResponse

Message Mapping

EnvImpactCustomer_Sync_Out

Service Interface

Führen Sie die Übernahme der Designobjekte durch, indem Sie den Wizard abschließen.

7.4 Vorbereitungen SAP ERP In diesem Abschnitt geht es darum die ERP-Schnittstelle zu entwickeln, die zu einer Lieferscheinposition je eine Liste mit zugrundeliegenden Fertigungspositionen bzw. Beschaffungspositionen liefern soll. Nach dem hier verwendeten Inside-OutProgrammiermodell müssen Sie diesen Service zunächst im SAP ERP-System implementieren. SAP stellt hierzu verschiedene Technologien zur Verfügung, von denen Sie die sogenannten „remotefähigen Funktionsbausteine“ (RFC) einsetzen werden. Da die erforderliche Programmierung in der SAP-eigenen Programmiersprache nicht das Kernthema der vorliegenden Fallstudie ist, wird der folgende

152


Implementierungsvorschlag auf eine Dummy-Implementierung beschränkt: Sie werden den Service so ausgestalten, dass zu jeder Anfrage immer dieselben Beschaffungs- und Fertigungspositionen zurückgegeben werden. Funktionsbausteine sind ABAP-Programme, die systemweit zur Verfügung stehen. Als RFC-Bausteine bezeichnet man Funktionsbausteine, die als RFC-fähig (remote function call) gekennzeichnet sind. RFC-Bausteine eignen sich besonders für Aufrufe aus externen Systemen. SAP-Systeme werden grundsätzlich mit einer umfangreichen Entwicklungsumgebung ausgeliefert, der sogenannten ABAP-Workbench, aus der heraus alle Entwicklungsaktivitäten im SAP System durchgeführt und überwacht werden können. Im Rahmen der Implementierung unseres Funktionsbausteins benötigen Sie die folgenden Entwicklungsobjekte: x Entwicklungspaket: Klammer um alle Entwicklungsobjekte; entspricht in etwa den Paketen in JAVA, bildet aber (leider) keinen eigenen Namensraum; x Funktionsbaustein: Modularisierungseinheit in der Programmiersprache ABAP, die sich besonders gut für externe Aufrufe eignet; x Funktionsgruppe: jeder Funktionsbaustein ist einer Funktionsgruppe zugeordnet. In unserem Beispiel wird die Funktionsgruppe als reines Strukturierungsmerkmal verwendet; x Strukturen: technische Datenbeschreibung, entspricht den Datentypen in SAP PI; x Transportaufträge: Objektlisten für Softwaretransporte zwischen SAPSystemen; sie sind für das Projekt nicht relevant, müssen aber – je nach Systemeinstellung – häufig obligatorisch zugeordnet werden;

7.4.1 Anlegen des Entwicklungspakets Beginnen Sie mit dem Anlegen des RFC-Bausteins im ERP-System, welcher während der Designphase in die SAP PI importiert wird. Loggen Sie sich hierfür über den SAP Logon in das SAP ERP-System ein und rufen Sie die Transaktion Object Navigator im Easy Access Menü über den Menüpfad Tools – ABAP Workbench – Overview auf. Wählen Sie den Repository Browser auf und lassen Sie sich wie in Abb. 7.3 dargestellt das Paket Z_BPM_SAP anzeigen.


153

Abb. 7.3: Suche nach dem Paket Z_BPM_SAP im Repository Browser

Da das Paket noch nicht existiert, werden Sie gefragt, ob Sie das Paket nun anlegen wollen. Bestätigen Sie die Frage mit Yes. Geben Sie als Kurzbeschreibung Developementpackage Case Study BPM ein. Belassen Sie die restlichen Einstellungen wie vorgegeben und wählen Sie den Button zum Anlegen des Pakets. Im folgenden Fenster werden Sie aufgefordert, einen Transportauftrag für das soeben angelegte Paket anzugeben. Transportaufträge dienen der Verwaltung von Änderungen im Repository und Customizing eines SAP-Systems. Mit Hilfe der Transportaufträge können die Änderungen zwischen verschiedenen Systemen transportiert werden. Legen Sie über die Funktionstaste F8 einen neuen Transportauftrag an. Geben Sie dem Transportauftrag die Kurzbeschreibung Request Case Study BPM und speichern Sie ihn ab. Sie gelangen dadurch zum vorherigen Fenster zurück, wobei jetzt der soeben angelegte Transportauftrag im Feld Request angegeben ist. Schließen Sie das Fenster durch Klick auf den Button Continue. Sie können nun mit dem Anlegen der Datenstrukturen beginnen.

7.4.2 Datenstrukturen Wählen Sie im Kontextmenü Ihres Paketes Z_BPM_SAP Create – Dictionary Object – Structure um eine neue Struktur anzulegen. Geben Sie als Namen der Struktur ZBPM_STR_PROD_ORD ein und klicken Sie den Button Continue. Als Kurzbeschreibung geben Sie Reference to production order ein. Wechseln Sie anschließend in den Reiter Components und ändern Sie den Eingabemodus durch Klick auf Predefined Type. Geben Sie dann die in Abb. 7.4 dargestellten Daten ein.

154


Abb. 7.4: Anlegen der Struktur ZBPM_STR_PROD_ORD

Speichern Sie die Struktur ab, und fügen Sie sie dabei zu Ihrem Paket hinzu. Fügen Sie eine weitere Struktur ZBPM_STR_PURC_ORD auf Basis von Tabelle 7.2 zu Ihrem Paket hinzu. Als Kurzbeschreibung geben Sie Reference to purchase order ein. Tabelle 7.2: Aufbau der Struktur ZBPM_STR_PURC_ORD Component

Data Type

Lendth

Short Description

VENDOR

CHAR

10

Account Number of Vendor or Creditor

PO_NUMBER

CHAR

10

Purchasing Document Number

MATERIAL

CHAR

18

Material Number

Speichern Sie die Struktur ab, und fügen Sie sie zu Ihrem Paket hinzu. Aktivieren Sie nun die beiden Strukturen über den Menüeintrag Structure – Activate.

7.4.3 Funktionsbaustein Bevor Sie den RFC-Funktionsbaustein anlegen können, müssen Sie zunächst eine Funktionsgruppe Z_BPM_SAP anlegen. Sie können dies über das Kontextmenü Ihres Pakets machen. Geben Sie für die Funktionsgruppe die Kurzbeschreibung Function Group Case Study BPM an. Funktionsbaustein Nun können Sie über das Kontextmenü der Funktionsgruppe einen neuen Funktionsbaustein wie in Abb. 7.5 dargestellt anlegen.


155

Abb. 7.5: Anlegen des Funktionsbausteins Z_BPM_SAP_GET_PREC_DOCS

Achten Sie darauf, dass im Reiter Attributes der Processing Type der Typ RemoteEnabled Module ausgewählt ist. Geben Sie im Reiter Import des neuen Funktionsbausteins die Daten auf Basis von Abb. 7.6 ein.

Abb. 7.6: Einstellungen im Funktionsbaustein Z_BPM_SAP_GET_PREC_DOCS – Reiter Import

Wechseln Sie in den Reiter Tables. Nehmen Sie die Eingaben anhand von Tabelle 7.3 vor. Tabelle 7.3: Einstellungen im Funktionsbaustein Z_BPM_SAP_GET_PREC_DOCS – Reiter Tables Parameter Name

Typ e spec. Associated Type

T_PRODUCTION_ORDERSLIKE

ZBPM_STR_PROD_ORD

T_PURCHASE_ORDERS

ZBPM_STR_PURC_ORD

LIKE

Fügen Sie anschließend im Reiter Source Code das folgende Listing hinter der Definition der lokalen Schnittstelle ein. DATA: l_str_production_order TYPE zbpm_str_prod_ord2, l_str_purchase_order TYPE zbpm_str_purc_ord.

*** Aufbau von Dummy-Fertigungsaufträgen l_str_production_order-order_number = '100023451'. l_str_production_order-order_item_number = '10'. APPEND l_str_production_order TO t_production_orders.

156


l_str_production_order-order_number = '100027652'. l_str_production_order-order_item_number = '120'. APPEND l_str_production_order TO t_production_orders. *** Aufbau von Dummy Beschaffungsaufträgen * Gehäuse zur Pumpe l_str_purchase_order-vendor = '4000001'. l_str_purchase_order-po_number = '213445'. l_str_purchase_order-material = '102-100'. APPEND l_str_purchase_order TO t_purchase_orders. * Laufrad zur Pumpe l_str_purchase_order-vendor = '4000001'. l_str_purchase_order-po_number = '213886'. l_str_purchase_order-material = '102-200'. APPEND l_str_purchase_order TO t_purchase_orders. * Welle zur Pumpe l_str_purchase_order-vendor = '4000001'. l_str_purchase_order-po_number = '213991'. l_str_purchase_order-material = '102-300'. APPEND l_str_purchase_order TO t_purchase_orders. ENDFUNCTION.

Speichern Sie den Funktionsbaustein ab, und überprüfen Sie ihn über den Menüeintrag Function Module – Check – Syntax. Wenn keine Syntaxfehler festgestellt werden konnten, können Sie den Funktionsbaustein über den Menüeintrag Function Module – Activate aktivieren. Sie haben nun alle Vorbereitungen getroffen, die für die Durchführung der zweiten Fallstudie notwendig sind, und können mit der Designphase fortfahren.

7.5 Design Zunächst importieren Sie alle vorliegenden Schnittstellen (ERP Schnittstelle, EMIS-Schnittstelle und Lieferanten-Schnittstelle) in Ihre Softwarekomponentenversion. Um das angekündigte Integrationsszenario umsetzen zu können, fehlen noch verschiedene technische Schnittstellen, sogenannte abstrakte Service Interfaces und zugehörige Operation Mappings. In Abgrenzung zu den schon verwendeten Service Interfaces können abstrakte Service Interfaces sowohl für eingehende als auch für ausgehende Nachrichten verwendet werden und sind ausschließlich im Rahmen von Integrationsprozessen relevant. Neben den technischen Mappings zwischen den abstrakten Service Interfaces werden Sie auch die Aggregation der Emissionsdaten und die Konvertierung in CO2e als Mapping abbilden.

Design

157

7.5.1 Import der externen Interfaces Import der ERP-Schnittstelle Zum Import des RFC-Funktionsbausteins navigieren Sie in Ihrer SoftwareKomponentenversion zum Eintrag Imported Objects. Importierte RFC-Bausteine können keinem eigenen Namensraum zugeordnet werden, sondern befinden sich automatisch im generischen Namensraum urn:sap-com:document:sap:rfs:functions. Deshalb gibt es in jeder SoftwareKomponentenversion ein extra Eintrag Importierte Objekte. Wählen Sie im Kontextmenü Import of SAP-Objectes um den Wizard für den Import von Objekten aus einem SAP-System zu starten. Geben Sie im ersten Schritt des Wizards die folgenden Daten ein. Falls Sie die Felder Application Server und System Number nicht sehen, klicken Sie auf den Pfeil-Button neben dem Systemnamen. x x x x

Application Server: as1 System Number: Systemnummer aus der System-ID Name: Benutzername für das SAP-System Password: Kennwort für das SAP-System

Expandieren Sie im zweiten Schritt den Objekttyp RFC, um die verfügbaren RFCFunktionsbausteine im entsprechenden SAP-System anzeigen zu lassen. Je nach Systemperformance kann die Abfrage einige Minuten in Anspruch nehmen. Wählen Sie aus der Liste der verfügbaren RFC-Funktionsbausteine Ihren Baustein Z_BPM_SAP_GET_PREC_DOCS aus und fahren Sie mit dem nächsten Schritt fort. Im letzten Schritt des Wizards werden nochmals die ausgewählten Objekte dargestellt. Führen Sie den Import durch einen Klick auf Finish aus. Nach erfolgreichem Import können Sie den Wizard schließen. Import der EMIS-Schnittstelle Den Webservice des EMIS können Sie anhand des Listings im Anhang erstellen oder direkt als WSDL-Datei von der Webseite des Buchs runterladen. Speichern Sie die WSDL-Datei auf Ihrem lokalen Computer. Wechseln Sie in den Namensraum http://services.springer.de/emis und wählen Sie im Kontextmenü den Eintrag New. Wählen Sie aus der Objektkategorie Interface Objects den Eintrag External Definition, geben Sie als Namen EMIS ein, und legen Sie die neue externe Definition an. Wählen Sie als Category den Dokumenttyp wsdl aus und importieren Sie die WSDL-Datei von Ihrem lokalen Computer. Speichern Sie anschließend die neue externe Definition ab. Import der Lieferanten-Schnittstelle Auch die WSDL-Datei des Lieferantensystems können Sie sich von der Webseite dieses Buchs herunterladen oder anhand des Listings im Anhang

158


erstellen. Legen Sie eine neue externe Definition in dem Namensraum http://services.springer.de/supplier mit dem Namen Supplier an. Importieren Sie anschließend die WSDL-Datei des Lieferantensystems und speichern Sie die externe Definition ab.

7.5.2 Abstrakte Service Interfaces Aufgrund des gestiegenen Kommunikationsaufwands müssen Sie eine Reihe zusätzlicher Service Interfaces erstellen. Eine Übersicht hierzu ist in Tabelle 7.4 dargestellt. Tabelle 7.4: Übersicht über abstrakte Service Interfaces der zweiten Fallstudie Service Interface

Namespace

EnvImpactCustomer_Sync_Abstract

http://www.springer.de/bpm/sap

EnvImpactCustomerRequest_Async_Abstract


EnvImpactIntegrationProcessResponse_Async_Abstract


EnvImpactCustomerResponse_Async_Abstract


Z_BPM_SAP_GET_PREC_DOCS_Sync_Abstract


Z_BPM_SAP_GET_PREC_DOCS_REQUEST_ Async_Abstract


Z_BPM_SAP_GET_PREC_ORD_RESPONSE_ Async_Abstract


ProdEnvImpactSupplier_Sync_Abstract

http://services.springer.de/supplier

ProdEnvImpactSupplierRequest_Async_Abstract


ProdEnvImpactSupplierResponse_Async_Abstract


ProdOrdEnvImpactEMIS_Sync_Abstract

http://services.springer.de/emis

ProdOrdEnvImpactEMISRequest_Async_Abstract


ProdOrdEnvImpactEMISResponse_Async_Abstract


Beginnen Sie zunächst mit den Message Interfaces des Namensraums http://www.springer.de/bpm/sap. EnvImpactCustomer_Sync_Abstract Das Service Interface EnvImpactCustomer_Sync_Abstract wird für die synchrone Kommunikation mit dem Kunden verwendet. Wählen Sie im Kontextmenü des Namensraums http://www.springer.de/bpm/sap den Eintrag New. Anschließend können Sie in der Objektkategorie Interface Objects den Eintrag Service Interface auswählen, um ein neues Interface anzulegen. Geben Sie den Namen des Interfaces ein und klicken Sie auf Create. Konfigurieren Sie anschließend das Service Interface anhand von Abb. 7.7.

Design

159

Abb. 7.7: Konfiguration des Service Interfaces EnvImpactCustomer_Sync_Abstract

Die synchrone Kommunikation zwischen zwei Systemen haben Sie bereits im ersten Kapitel der Fallstudie kennengelernt, aber die Kategorie abstrakt haben Sie bisher noch nicht kennengelernt. Abstrakten Interfaces fehlt die Angabe der Senderichtung. Dies bedeutet, dass sie in beiden Richtungen verwendet werden können. Abstrakte Interfaces können ausschließlich in Integrationsprozessen verwendet werden. EnvImpactCustomerRequest_Async_Abstract Das folgende Service Interface wird verwendet, um die Anfrage des Kunden innerhalb des Integrationsprozesses asynchron zu verarbeiten. Legen Sie das neue Service Interface an. Sie können nun direkt im Namensraum http://www.springer.de/bpm/sap den Eintrag Service Interfaces auswählen und über das Kontextmenü ein neues Interface anlegen. Nehmen Sie die folgenden Einstellungen vor: x x x x

Category: Abstract Mode: Asynchronous Request Message: EnvImpactCustomerRequest Request Message Namespace: http://www.springer.de/bpm/sap

Im Rahmen des Interfaces wird der Modus Asynchron zur Verarbeitung von Messages verwendet. Asynchrone Verarbeitung bedeutet, dass das Sendersystem einer Nachricht nicht auf eine direkte Antwort des Empfängersystems wartet. Mit Hilfe von

160


asynchronen Verarbeitungen können Sender- und Empfängersystem entkoppelt werden, da der Sender auch ohne eine Antwort weiterarbeiten kann. EnvImpactIntegrationProcessResponse_Async_Abstract Mit Hilfe dieses Service Interfaces werden die asynchronen Antworten der drei verschiedenen Systeme (ERP, EMIS und Supplier) in einer Antwort zur Verfügung gestellt. Legen Sie das Service Interface anhand der folgenden Daten an. x x x x

Category: abstract Mode: Asynchronous Request Message: EnvImpactERPResponse Request Message Namespace: http://www.srpinger.de/bpm/sap

EnvImpactCustomerResponse_Async_Abstract Das nächste Service Interface umfasst die aggregierten Emissionen in Form des CO2-Äquivalents. Legen Sie das Service Interface mit der Kategorie Abstract und dem Modus Asynchronous an. Geben Sie als Request Message den Message-Typen EnvImpactCustomerResponse aus dem Namensraum http://www.springer.de/bpm/sap an, und speichern Sie das Service Interface anschließend ab. Z_BPM_SAP_GET_PREC_DOCS_Sync_Abstract Im folgenden Service Interface wird die synchrone Schnittstelle zum ERP-System definiert. Fügen Sie im Namensraum http://www.springer.de/bpm/sap ein weiteres Service Interface mit den folgenden Daten hinzu. Achten Sie darauf, dass Sie bei den beiden Messages den Typ RFC Message auswählen. x x x x x x

Category: Abstract Mode: Synchronous Request-Message: Z_BPM_SAP_GET_PREC_DOCS Request-Message-Namensraum: urn:sap-com:document:sap:rfc:functions Response-Message: Z_BPM_SAP_GET_PREC_DOCS.Response Response-Message-Namensraum: urn:sap-com:document:sap:rfc:functions

Z_BPM_SAP_GET_PREC_DOCS_REQUEST_Async_Abstract Fügen Sie anhand von Abb. 7.8 das nächste Service Interface hinzu, es beinhaltet die asynchrone Anfrage an das ERP-System.

Design

161

Abb. 7.8: Anlegen des Service Interfaces Z_BPM_SAP_GET_PREC_DOCS_REQUEST_ Async_Abstract

Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_Async_Abstract Fügen Sie das nächste Service Interface analog zum Service Interface Z_BPM_SAP_GET_PREC_DOCS_REQUEST_Async-Abstract hinzu. Es umfasst die asynchrone Antwort des ERP-Systems. Wählen Sie als Request-Message die RFC-Message Z_BPM_SAP_GET_PREC_DOCS.Response aus dem Namensraum urn:sap-com:document:sap:rfc:functions aus. Sie haben nun alle notwendigen Service Interfaces im Namensraum http://www.springer.de/bpm/sap angelegt und können mit dem Anlegen der Service Interfaces im Namensraum http://services.springer.de/supplier fortfahren. ProdEnvImpactSupplier_Sync_Abstract Das erste Service Interface definiert die synchrone Schnittstelle zwischen PI und Webservice des Suppliers. Wählen Sie aus Ihrer Software-Komponentenversion den Namensraum http://services.springer.de/supplier aus und im Kontextmenü des Namensraums den Eintrag New um ein neues Service Interface anzulegen. Wählen Sie aus der Objektkategorie Interface Objects den Eintrag Service Interface aus und geben Sie den Namen des Interfaces ProdEnvImpactSupplier_ Sync_Abstract ein bevor Sie auf Create klicken. Nehmen Sie die weiteren Einstellungen des Service Interfaces anhand von Abb. 7.9 vor.

162


Abb. 7.9: Service Interface ProdEnvImpactSupplier_Sync_Abstract

ProdEnvImpactSupplierRequest_Async_Abstract Das folgende Service Interface beschreibt die asynchrone Anfrage an den Webservice des Lieferanten. Sie können nun direkt im Namensraum http://services.springer.de/supplier den Eintrag Service Interfaces auswählen und über das Kontextmenü ein neues Interface anlegen. Nehmen Sie die folgenden Einstellungen vor: x x x x

Category: Abstract Mode: Asynchronous Request Message: ProductCradleToGateGreenhouseGasImpactRequest Request Message Namespace: http://services.example.org/SupplierService

ProdEnvImpactSupplierResponse_Async_Abstract Das Service Interface ProdEnvImpactSupplierResponse_Async_Abstract ist ebenfalls von der Kategorie Abstract und sendet Nachrichten im Modus Asynchronous. Es beschreibt die Antwort des Webservices auf die Anfrage der SAP PI. Das Interface verwendet als Request Message die externe Message ProductCradle ToGateGreenhouseGasImpactResponse aus dem Namensraum http://services.example.org/SupplierService. Damit haben Sie alle notwendigen Service Interfaces im Namensraum http://services.springer.de/supplier angelegt und können mit den Service Interfaces im Namensraum http://services.springer.de/emis fortfahren. ProdOrdEnvImpactEMIS_Sync_Abstract Im folgenden Service Interface wird die Schnittstelle zwischen EMIS und SAP PI beschrieben.Wählen Sie aus Ihrer Software-Komponentenversion den Namensraum http://services.springer.de/emis aus und im Kontextmenü des Namensraums den Eintrag New, um ein neues Service Interface anzulegen. Wählen Sie aus der

Design

163

Objektkategorie Interface Objects den Eintrag Service Interface aus und geben Sie den Namen des Interfaces ProdOrdEnvImpactEMIS_Sync_Abstract ein, bevor Sie auf Create klicken. Die weiteren Einstellungen des Interfaces entnehmen Sie Abb. 7.10.

Abb. 7.10: Service Interface ProdOrdEnvImpactEMIS_Sync_Abstract

ProdOrdEnvImpactEMISRequest_Async_Abstract Im Service Interface ProdOrdEnvImpactEMISRequest_Async_Abstract wird die asynchrone Anfrage an das EMIS-System beschrieben. Sie können nun direkt im Namensraum http://services.springer.de/emis den Eintrag Service Interfaces auswählen und über das Kontextmenü ein neues Interface anlegen. Nehmen Sie die folgenden Einstellungen vor: x x x x

Category: Abstract Mode: Asynchronous Request Message: ProductionOrderItemGreenhouseGasImpactRequest Request Message Namespace: http://services.example.org/EMIS/

ProdOrdEnvImpactEMISResponse_Async_Abstract Das Service Interface ProdOrdEnvImpactRequestResponse_Async_Abstract ist ebenfalls von der Kategorie Abstract und sendet Nachrichten im Modus Asynchronous. Es beschreibt die Antwort des EMIS-Systems an die SAP PI. Das Interface verwendet als Request Message die externe Message ProductCradleToGateGreenhouseGasImpactResponse aus dem Namespace http://services.example.org/SupplierService. Sie haben nun alle notwendigen Service Interfaces angelegt und können mit dem Anlegen der Message- und Operation Mappings fortfahren.

164


7.5.3 Operation Mappings Im Rahmen dieser Fallstudie sind die folgenden Operation Mappings zusätzlich anzulegen: x EnvImpactCustomerRequest_Async_Abstract_To_Z_BPM_SAP_GET_ PREC_DOCS_REQUEST_Async_Abstract x Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_Async_Abstract_To_ ProdOrdEnvImpactEMISRequest_Async_Abstract x Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_Async_Abstract_To_ ProdEnvImpactSupplierRequest_Async_Abstract x EnvImpactAccumulation_To_EnvImpactIntegrationProcessResponse_ Async_Abstract x EnvImpactIntegrationProcessResponse_Async_Abstract_To_ EnvImpactCustomerResponse_Async_Abstract EnvImpactCustomerRequest_Async_Abstract_To_Z_BPM_SAP_GET_ PREC_DOCS_REQUEST_Async_Abstract Das Operation Mapping definiert die Transformation zwischen zwei asynchronen abstrakten Service Interfaces, die später als Containerelemente in einem Integrationsprozess verwendet werden. In diesem Fall beinhaltet die Ausgangs-Operation die Anfrage des Kunden, die in veränderter Form an das ERP-System weitergeleitet werden soll. Dabei transformiert das Message Mapping die Anfrage des Kunden in das Zielformat des ERP-Systems. Zum Anlegen des ersten Operation Mappings wählen Sie innerhalb Ihrer Software-Komponentenversion den Namensraum http://www.springer.de/bpm/sap aus und über das Kontextmenü den Eintrag New. Wählen Sie aus der Objektkategorie Mapping Objects den Eintrag Operation Mapping aus und geben Sie den Namen ein, bevor Sie auf Create klicken. Wählen Sie als Quell-Operation das Service Interface EnvImpactCustomerRequest_Async_Abstract und als Ziel-Operation aus dem Namensraum http://www.springer.de/bpm/sap das Service Interface Z_BPM_SAP_GET_PREC_DOCS_REQUEST_Async_Abstract aus. Klicken Sie auf die Schaltfläche Read Operations, um die Ausgangs- und Ziel-Message aus den beiden Interfaces auszulesen. Fügen Sie zum Operation Mapping anschließend ein Mapping-Programm hinzu, indem Sie im Bereich Mapping-Programm das Dokumentensymbol anklicken und damit ein neues Message Mapping anlegen. Geben Sie als Namen des Message Mappings EnvImpactCustomerRequest_ To_Z_BPM_SAP_GET_PREC_DOCS ein und versichern Sie sich, dass das Message Mapping in den Namensraum http://www.springer.de/bpm/sap eingefügt wird, bevor Sie auf Create klicken. Die Ausgangs- und Ziel-Message werden automatisch aus dem Operation Mapping übernommen, sodass Sie sofort mit dem Mappen beginnen können. Verbinden Sie die Elemente der Ausgangs- und ZielMessage wie in Abb. 7.11 dargestellt.

Design

165

Abb. 7.11: Anlegen des Message Mappings EnvImpactCustomerRequest_To_Z_BPM_SAP_ GET_PREC_DOCS

Nachdem Sie die Elemente miteinander verbunden haben, können Sie das Mapping im Reiter Test testen. Geben Sie beim Test beliebige Daten ein. Wenn der Test fehlerfrei war, können Sie das Mapping abspeichern. Kehren Sie anschließend zu Ihrem Operation Mapping zurück und speichern Sie dieses ebenfalls ab. Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_Async_Abstract_To_ProdO rdEnvImpactEMISRequest_Async_Abstract Mit Hilfe des zweiten Operation Mapping werden aus der Antwort des ERPSystems die ermittelten Fertigungspositionen an das Zielformat des EMIS angepasst. Legen Sie ein weiteres Operation Mapping nach dem bekanntem Prinzip an. Wählen Sie die folgende Source Operation: x Name: Z_BPM_SAP_GET_PREC_DOCS_REPONSE_Async_Abstract x Namespace: http://www.springer.de/bpm/sap x Occurence: 1 Fügen Sie das folgende Service Interface als Target Operation hinzu: x Name: ProdOrdEnvImpactSupplierRequest_Async_Abstract x NameSpace: http://services.springer.de/emis x Occurence: 0..unbounded Lesen Sie die Ausgangs- und Ziel-Message über die Schaltfläche Read Operations ein und fügen Sie wiederum im Bereich Mapping-Programm ein neues Message Mapping durch Klick auf das Dokumentensymbol hinzu. Vergewissern Sie sich, dass das neue Message Mapping tatsächlich zu dem Namensraum http://www.springer.de/bpm/sap hinzugefügt wird, geben Sie den Namen Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_To_ProductionOrderItem GreenhouseGasImpactRequest ein und klicken Sie auf Create. Die Ausgangsund Ziel-Message werden automatisch aus dem Operation Mapping übernommen. Führen Sie nun das Mapping mit Hilfe von Abb. 7.12 durch.

166


Abb. 7.12: Message Mapping Z_..._PREC_DOCS_RESPONSE_To_...GasImpactRequest

Über den Reiter Test können Sie Ihr Mapping wiederum testen und anschließend abspeichern. Kehren Sie dann zum Operation Mapping zurück, um auch dieses abzuspeichern. Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_Async_Abstract_To_ProdEnv ImpactSupplierRequest_Async_Abstract Dieses Operation Mapping extrahiert aus der Antwort des ERP-System die Beschaffungspositionen und konvertiert sie in das Format des Lieferantensystems. Fügen Sie über den bekannten Weg ein neues Operation Mapping zum Namensraum http://www.springer.de/bpm/sap hinzu. Und nehmen Sie die folgenden Einstellungen vor. Source Operation: x Name: Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_Async_Abstract x Namespace: http://www.springer.de/bpm/sap x Occurence: 1 Target Operation: x Name: ProdEnvImpactSupplierRequest_Async_Abstract x Namespace: http://services.springer.de/supplier x Occurence: 0..unbounded Lesen Sie die Operationen der Service Interfaces ein, und legen Sie ein neues Message Mapping im Bereich Mapping Program an. Geben Sie den als Namen Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_To_ProductionCradleToGateGre enhouseGasImpactRequest ein und stellen Sie sicher, dass das Message Mapping zum Namensraum http://www.springer.de/bpm/sap hinzugefügt wird. Führen Sie nun das Mapping anhand von Abb. 7.13 durch.

Design

167

Abb. 7.13: Verwendung der Funktion DateTrans im Mapping-Editor

Testen Sie das Mapping über den Reiter Test, und speichern Sie es anschließend ab. Kehren Sie zum Operation Mapping zurück, und speichern Sie dieses ebenfalls ab. EnvImpactAccumulation_To_EnvImpactIntegrationProcessResponse_Async _Abstract Das Operation Mapping übernimmt die Daten des Datentyp SalesDocItem aus der Anfrage des Kunden und kumuliert die vom Lieferanten und EMIS bezogenen Treibhausgasemissionen. Erstellen Sie ein neues Operation Mapping nach dem bekanntem Prinzip. Wählen Sie die folgenden Service Interfaces als Source Operation aus: x x x x x x x x x

Name: EnvImpactCustomerRequest_Async_Abstract Namespace: http://www.springer.de/bpm/sap Occurence: 1 Name: ProdEnvImpactSupplierResponse_Async_Abstract Namespace: http://services.springer.de/supplier Occurence: 0..unbounded Name: ProdOrdEnvImpactEMISResponse_Async_Abstract Namespace: http://services.springer.de/emis Occurence: 0..unbounded

Als Target Operation wählen Sie das folgende Service Interface aus: x Name: EnvImpactIntegrationProcessResponse_Async_Abstract x Namensraum: http://www.springer.de/bpm/sap Das Mapping findet in diesem Fall mit Hilfe eines Java-Programms statt. Sie finden den Quellcode des Java-Mappings im Anhang des Buches oder auf der zum Buch gehörenden Homepage. Um das Java-Mapping verwenden zu können, müssen Sie es zunächst als Jar-File auf die lokale Festplatte kopieren und dann in Ihre Softwarekomponente importieren. Wählen Sie dafür im Kontextmenü der Softwarekomponente http://www.springer.de/bpm/sap den Eintrag New. Wählen Sie im Fenster Create Object aus der Kategorie Mapping Objects den Eintrag Imported Archive aus. Geben Sie als Namen EnvImpactAccumulation ein und be-

168


achten Sie, dass das Archiv der richtigen Softwarekomponente hinzugefügt wird. Klicken Sie auf Create. Wählen Sie im folgenden Fenster wie in Abb. 7.14 dargestellt die Datei EnvImpactAccumulation.jar von Ihrer lokalen Festplatte aus.

Abb. 7.14: Import des Java-Mappings

Damit das Java-Mapping korrekt funktioniert, müssen Sie ein weiteres Archiv in Ihre Softwarekomponente importieren. Laden Sie sich hierfür von der Homepage des Buches die Datei JDOM.jar herunter. Importieren Sie das Archiv anschließend nach dem oben beschriebenen Prinzip. Geben Sie als Namen des importierten Archivs JDOM ein. Nun können Sie zu Ihrem Operation Mapping EnvImpactAccumulation_To_ EnvImpactIntegrationProcessResponse_Async_Abstract zurückkehren und das neu importierte Java-Mapping als Mapping-Programm auswählen. Abb. 7.15 zeigt die Auswahl des Java-Mappings als Mapping-Programm im Operation Mapping.

Abb. 7.15: Auswahl der Java-Klasse EnvImpactAccumulation als Mapping-Programm

Testen Sie das Mapping mit entsprechenden Testdaten im Reiter Test, und speichern Sie es anschließend ab. EnvImpactIntegrationProcessResponse_Async_Abstract_To_EnvImpactCust omerResponse_Async_Abstract Mit diesem Operation Mapping wird das CO2-Äquivalent berechnet und in das Format des Webservices des Kunden transformiert. Geben Sie als Quell-Operation das Service Interface EnvImpactIntegrationProcessResponse_Async_Abstract und als Ziel-Operation das Service Interface CustomerResponse_Async_Abstract an. Lesen Sie die Operationen ein und fügen Sie das Message Mapping EnvImpactERPResponse_To_EnvImpactCustomerResponse, das Sie mit der Releaseübernahme in die zweite Software-Koponenentenversion übernommen haben, hinzu. Speichern Sie anschließend das Operation Mapping ab.

Design

169

7.5.4 Integrationsprozess Nun werden Sie einen BPEL-basierten Integrationsprozess anlegen. In der SAP PI wird hierfür ein grafischer Prozesseditor innerhalb des Enterprise Services Builder zur Verfügung gestellt. Abb. 7.16 stellt den Aufbau des Prozesseditors dar. Enterprise Services Builder Main Menü Navigation Area

Header Working Area

Overview Area

Properties Area

Processing Area

Container Area

Abb. 7.16: Aufbau des grafischen Prozesseditors der PI

Mit einem Integrationsprozess wird der abstrakte Nachrichtenaustausch zwischen verschiedenen Interfaces definiert. Bei einem Integrationsprozess handelt es sich um einen ausführbaren systemübergreifenden Prozess zur Verarbeitung von Nachrichten. Mit einem Integrationsprozess können komplexe systemübergreifende Prozesse realisiert werden, bei denen eine zustandslose Verarbeitung von Nachrichten nicht ausreicht. In Integrationsprozessen können komplexe Abläufe über Schleifen abgewickelt werden. Ein Integrationsprozess setzt sich aus mehreren Integrationsschritten zusammen. Die Modellierung eines Integrationsprozesses erfolgt in SAP PI über einen grafischen Editor. Wählen Sie im Namensraum http://www.springer.de/bpm/sap der aktuellen Softwarekomponentenversion im Kontextmenü den Eintrag New, um einen neuen Integrationsprozess anzulegen. Navigieren Sie im Fenster Create Object in der Ka-

170


tegorie Process Integration Scenario Objects zum Eintrag Integration Process. Geben Sie als Name SupplyCarbonFootprint ein und klicken Sie auf Create. Einen Überblick über den zu erstellenden Integrationsprozess bietet Abb. 7.17. Die nummerierten Prozessschritte spiegeln den Verlauf der Erstellung des Integrationsprozesses wieder.

Abb. 7.17: Gesamtübersicht über den Integrationsprozess

Containerelemente Bevor Sie mit der eigentlichen Prozessmodellierung starten können, müssen Sie verschiedene Containerelemente anlegen. Containerelemente werden verwendet, um Messages während des Prozesses referenzieren zu können. Containerelemente werden innerhalb eines Integrationsprozesses benötigt, um Daten verarbeiten zu können. Sie lassen sich mit den Variablen in einer Programmiersprache vergleichen und sind nur innerhalb des Integrationsprozesses verfügbar. Containerelemente können eine Liste aus gleichartigen Containerelementen sein, wodurch z.B. mehrere gleichartige Nachrichten innerhalb eines Containerelements gesammelt werden. Bei Containerelementen unterscheidet man drei Kategorien. Containerelemente, die Messages referenzieren können, gehören der Kategorie Abstract Interface an und werden vor allem in Empfangs- und Sendeschritten verwendet. Innerhalb eines Prozesses können Elemente benötigt werden, die die Prozesssteuerung beeinflussen. Ein Beispiel hierfür ist der Zähler innerhalb einer Schleife. Solche Elemente können durch Containerelemente der Kategorie Simple Type definiert werden. Um während der Laufzeit des Prozesses den Empfänger einer Nachricht zu ermitteln, werden Containerelemente der Kategorie Receiver verwendet. Beginnen Sie nun, die verschiedenen Containerelemente dieser Fallstudienphase anzulegen. Containerelemente werden im Objektbereich des Prozesseditors angelegt. Legen Sie die Containerelemente wie in Tabelle 7.5 dargestellt an. Alle Con-

Design

171

tainerelemente sind von der Kategorie Abstract Interface und haben den Scope Process. Tabelle 7.5: Liste der Containerelemente des Integrationsprozesses Name

Type

Multiline

CustomerRequest

EnvImpactCustomerRequest_Async_Abstract

Nein

IntegrationProcess Response

EnvImpactIntegrationProcessResponse_Async_Abstract

Nein

CustomerResponse

EnvImpactCustomerResponse_Async_Abstract

Nein

ERPRequest

Z_BPM_SAP_GET_PREC_DOCS_REQUEST_ Async_Abstract

Nein

ERPResponse

Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_ Async_Abstract

Nein

SupplierRequestList


Ja

SupplierResponseList

ProdEnvImpactSuppplierResponse_Async_Abstract

Ja

EMISRequestList


Ja

EMISResponseList


Ja

1.Schritt: ReceiveCustomerRequest (Receive) Der erste Schritt im Integrationsprozess ist ein Empfangsschritt, der die Anfrage des Kunden entgegennimmt. Der erste Schritt instanziiert den Integrationsprozess und öffnet gleichzeitig die Sync/Async-Bridge des Integrationsprozess. Mit Hilfe einer Sync/Async-Bridge kann eine synchrone Kommunikation innerhalb eines Integrationsprozesses zeitweise in eine asynchrone Kommunikation umgewandelt werden bzw. eine asynchrone in eine synchrone Kommunikation. Eine Sync/Async-Bridge wird durch einen Empfangsschritt geöffnet und später durch einen Sendeschritt geschlossen. Innerhalb eines Integrationsprozesses kann nur eine Sync/Async-Bridge eingesetzt werden. Die Sync/Async-Bridge ermöglicht, das synchrone abstrakte Interface EnvImpactRequest_Async_Abstract in einen quasi asynchronen Empfangs- und Sendeschritt aufzuteilen. Der letzte Schritt des Integrationsprozesses wird zum Schließen der Sync/Async-Bridge verwendet. Legen Sie nun den Empfangsschritt an. Benutzen Sie dafür den Bearbeitungsbereich des Prozesseditors. Wählen Sie aus der Liste der verfügbaren Schritte den Schritt Receive aus, und ziehen Sie ihn wie in Abb. 7.18 dargestellt per Drag&Drop in den Bearbeitungsbereich des Prozesseditors zwischen den Startund den Endknoten.

172


Abb. 7.18: Einfügen eines neuen Prozessschrittes im grafischen Prozesseditor

Geben Sie anschließend wie in Abb. 7.19 dargestellt die Daten des Empfangsschritts im Eigenschaftenbereich des Prozesseditors ein.

Abb. 7.19: Eigenschaften des Empfangsschritts ReceiveCustomerRequest

2.Schritt: TransformCustomerRequest (Transformation) Fügen Sie nach demselben Prinzip einen weiteren Prozessschritt zum Integrationsprozess hinzu. Achten Sie darauf, dass es sich diesmal um einen Transformations-Schritt handelt und Sie ihn hinter dem Empfangsschritt einfügen. Der Transformatios-Schritt transformiert die Anfrage des Kunden in eine Anfrage an das ERP-System unter der Verwendung des zuvor angelegten Operation Mappings EnvImpactRequestRequest_Async_Abstract_To_Z_BPM_SAP_ORDER_DETAIL_ REQUEST_Async_Abstract. Geben Sie im Eigenschaftenbereich die folgenden Werte für den Transformationsschritt ein. x Step Name: TransformCustomerRequest x Operation Mapping: EnvImpactCustomerRequest_Async_Abstract_ To_Z_BPM_SAP_GET_PREC_DOCS_REQUEST_Async_Abstract x Create New Transaction: nein x Source Message: CustomerRequest x Target Message: ERPRequest 3.Schritt: SendERPRequest (Send) Fügen Sie als nächstes einen Sende-Schritt zum Integrationsprozess hinzu. Der Schritt wird zum Senden der Anfrage an das ERP-System verwendet. Geben Sie die Eigenschaften unter Zuhilfenahme von Abb. 7.20 ein.

Design

173

Abb. 7.20: Eigenschaften des Sende-Schritts SendERPRequest

4.Schritt: ParallelFlow (Fork) Fügen Sie als nächstes einen parallelen Abschnitt zum Integrationsprozess hinzu. Der Schritt wird verwendet um die Anfragen an der betriebliche Umweltinformationssystem und das Lieferantensystem nebenläufig durchzuführen. Nachdem die beiden Anfragen durchlaufen sind, findet die Synchronisation des Prozessablaufs statt. Geben Sie in den Eigenschaften ParallelFlow als Namen des Schritts ein und als Necessary Branches den Wert 2. 5.Schritt: TransformERPResponseToEMISRequest (Transformation) Beim nächsten Schritt handelt es sich wiederum um eine Transformation. Der Schritt transformiert die Antwort des ERP-Systems in eine Anfrage an das betriebliche Umweltinformationssystem. Achten Sie darauf den Transformations-Schritt wie in Abb. 7.21 dargestellt auf den oberen Zweig des parallelen Abschnitts zu ziehen.

Abb. 7.21: Einfügen eines Prozessschritts im parallelen Abschnitt

174


Geben Sie anschließend die folgenden Werte für den Transformations-Schritt ein. x Step Name: TransformERPResponseToEMISRequest x Operation Mapping: Z_BPM_SAP_GET_PREC_DOCS_RESPONSE _Async_Abstract_To_ProdOrdEnvImpactEMISRequest_Async_Abstract x Create New Transaction: nein x Source Message: ERPResponse x Target Message: EMISRequestList 6.Schritt: EMISBlock (Block) Als nächsten Schritt fügen Sie einen Block zum Integrationsprozess hinzu. Der Block wird verwendet um die beiden folgenden Schritte 7 und 8 zunächst logisch zusammenzufassen. Achten Sie darauf den Block hinter den letzten Transformations-Schritt einzufügen. Später werden Sie den Modus For Each für den Block auswählen. Dadurch wird festgelegt, dass der Block für jede Zeile des Containerelements EMISRequestList durchlaufen wird. Erst nachdem alle Zeilen des Containerelements bearbeitet wurden, wird der Block verlassen. Nachdem Sie den Block angelegt haben, müssen Sie zwei weitere Containerelemente anlegen, bevor Sie mit der Konfiguration des Block-Schrittes fortfahren können. Legen Sie nun mit Hilfe von Tabelle 7.6 die zwei Containerelemente an. Achten Sie darauf, dass bei beiden Elementen als Scope der EMISBlock ausgewählt ist. Dadurch sind die beiden Containerelemente nur innerhalb dieses Blocks verfügbar. Zudem sind beide Containerelemente von der Kategorie Abstract Interface. Tabelle 7.6: Containerelemente des Blocks EMISBlock Name

Type

Multiline

EMISRequest


Nein

EMISResponse


Nein

Nun können Sie mit der Konfiguration des Block-Schritts mit Hilfe von Abb. 7.22 fortfahren. 7.Schritt: SendEMISRequest (Send) Fügen Sie einen Senden-Schritt zum Block EMISBlock hinzu. Mit Hilfe des Schritts werden die einzelnen Anfragen an das betriebliche Umweltinformationssystem gesendet. Legen Sie für den Schritt die folgenden Eigenschaften an: x x x x x x

Step Name: SendEMISRequest Mode: Synchronous Synchrones Interface: ProdOrdEnvImpactEMIS_Sync_Abstract Request Message: EMISRequest Response Message: EMISResponse Receiver From: Send Context

Design

175

Abb. 7.22: Eigenschaften des Blocks EMISBlock

8.Schritt: ContainerOperationEMISResponse (Container Operation) Der nächste Schritt wird verwendet, um die einzelnen Antworten des betrieblichen Umweltinformationssystems zum Containerelement EMISResponseList hinzuzufügen. Fügen Sie auch diesen Schritt zum Block hinzu, und legen Sie die folgenden Eigenschaften an. x x x x

Step Name: ContainerOperationEMISResponse Target: EMISResponseList Operation: Append Expression: EMISResponse

9.Schritt: TransformERPResponseToSupplierRequest (Transformation) Bei dem nächsten Schritt handelt es sich wieder um einen TransformationsSchritt. Beachten Sie jedoch, dass dieser Schritt auf dem anderen Zweig des parallelen Abschnitts ParallelFlow stattfindet. Dieser Transformations-Schritt transformiert die Antwort des ERP-Systems in das Format des Lieferantensystems. Ziehen Sie den Transformations-Schritt wie in Abb. 7.23 dargestellt auf den zweiten Zweig des parallelen Abschnitts.

Abb. 7.23: Einfügen eines Prozessschritts auf dem zweiten Weg des parallelen Abschnitts

176


Legen Sie anschließend die folgenden Eigenschaften für den TransformationsSchritt fest: x Step Name: TransformERPResponseToSupplierRequest x Operation Mapping: Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_Async_ Abstract_To_ProdEnvImpactSupplierRequest_Async_Abstract x Create New Transaction: nein x Source Message: ERPResponse x Target Message: SupplierRequestList 10.Schritt: SupplierBlock (Block) Analog zum 6. Schritt wird ein weiterer Block eingefügt. Der Block wird verwendet, um die Schritte 11. und 12. logisch zusammenzufassen und einen mehrmaligen Durchlauf der beiden Schritte zu ermöglichen. Ziehen Sie den Block zunächst auf den zweiten Zweig des parallelen Abschnitts ParallelFlow, und geben Sie als Namen des Blocks SupplierBlock ein. Fügen Sie zunächst wie im 6. Schritt zwei weitere Containerelemente an, die nur innerhalb des Blocks SupplierBlock verfügbar sind. Dafür muss der Scope der Containerelemente auf SupplierBlock verweisen. Die Kategorie der beiden Elemente ist abstract Interface. Legen Sie die beiden Containerelemente aus Tabelle 7.7 an. Tabelle 7.7: Containerelemente des Blocks SupplierBlock Name

Type

Multiline

SupplierRequest


Nein

SupplierResponse

ProdEnvImpactSupplierResponse_Async_Abstract

Nein

Nun können Sie die fehlenden Eigenschaften des Blocks SupplierBlock festlegen: x x x x x

Mode: For Each Block Start: No New Transaction Block End: No New Transaction Multiline Element: SupplierRequestList Current Line: SupplierRequest

11.Schritt: SendSupplierRequest (Send) Mit diesem Schritt werden die einzelnen Anfragen an das Lieferantensystem gesendet. Achten Sie darauf, den Schritt innerhalb des Blocks SupplierBlock hinzuzufügen. Geben Sie die Eigenschaften wie folgt an: x x x x

Step Name: SendSupplierRequest Mode: Synchronous Synchronous Interface: ProdEnvImpactSupplier_Sync_Abstract Request Message: SupplierRequest

Design

177

x Response Message: SupplierResponse x Receiver From: Send Context 12.Schritt: ContainerOperationSupplierResponse (Container Operation) Dieser Schritt wird verwendet, um die einzelnen Antworten des Lieferantensystems zu dem Containerelement SupplierResponseList hinzuzufügen. Integrieren Sie diesen Schritt ebenfalls in den Block SupplierBlock. Legen Sie anschließend die folgenden Eigenschaften fest: x x x x

Step Name: ContainerOperationSupplierResponse Target: SupplierResponseList Operation: Append Expression: SupplierResponse

13.Schritt: TransformEnvImpactAccumulation (Transformation) Fügen Sie einen Transformations-Schritt wie in Abb. 7.24 dargestellt zum Integrationsprozess hinzu.

Abb. 7.24: Einfügen des Transformations-Schritt hinter den parallelen Abschnitt

Mit Hilfe des Transformationsschrittes werden aus der Anfrage des Kunden und den Antworten des Lieferantensystems sowie der Antwort des betrieblichen Umweltinformationssystems die Emissionen kumuliert. Geben Sie die folgenden Eigenschaften des Transformationsschrittes an: x Step Name: TransformEnvImpactAccumulation x Operation Mapping: EnvImpactAccumulation_To_EnvImpactIntegrationPro cessResponse_Async_Abstract x Source Message 1: CustomerRequest x Source Message 2: SupplierResponseList x Source Message 3: EMISResponseList x Target Message: IntegrationProcessResponse

178


14.Schritt: TransformGHGImpactToCO2e (Transformation) Mit diesem Transformationsschritt wird aus den im vorherigen Schritt kumulierten Emissionen der CarbonFootprint des Produkts berechnet. x Step Name: TransformGHGImpactToCO2e x Operation Mapping: EnvImpactIntegrationProcessResponse_Async_Abstract_ To_EnvImpactCustomerResponse_Async_Abstract x Create New Transaction: nein x Source Message: IntegrationProcessResponse x Target Message: CustomerResponse 15.Schritt: SendCustomerResponse (Send) Der letzte Schritt des Integrationsprozesses schließt die im ersten Schritt geöffnete Sync/Async-Bridge und sendet das berechnete CO2-Äquivalent an den Kunden. Der Schritt hat die folgenden Eigenschaften: x x x x

Step Name: SendCustomerResponse Mode: Closes S/A-Bridge Message: CustomerResponse Opened By: ReceiveCustomerRequest

Speichern Sie anschließend den Integrationsprozess ab. Aktivieren der Änderungsliste Sie haben nun alle notwendigen Designobjekte angelegt. Wechseln Sie in den Reiter Change Lists und aktivieren Sie die Standard Changelist der zweiten Softwarekomponentenversion. Sie können nun den Enterprise Services Builder verlassen.

7.5.5 Darstellung des Integrationsprozesses als BPEL-Prozess Im letzten Abschnitt wurde der Prozess als BPEL-basierten Integrationsprozess in der SAP PI erfasst. Eine Darstellung der Prozessdefinition als BPEL XMLDokument wird im Prozesseditor unter View -> BPEL Dipslay angeboten (Abb. 7.25). Im Folgenden soll an ausgewählten Beispielen erläutert werden, wie die in der SAP PI zur Erfassung der Prozessdefinition eingesetzten Step Types in BPELAktivitäten umgesetzt werden.

Design

179

Abb. 7.25: Anzeige eines Integrationsprozesses als BPEL-Dokument

Die Definition des BPEL-Prozesses erfolgt innerhalb einer process-Anweisung, in der zunächst einigen Rahmendaten des Prozesses (Namensräume, Partner, auszutauschende Nachrichten, globale Variablen) und anschließend die Ablaufbeschreibung definiert wird. In der BPEL 2.0 Spezifikation wird zwischen abstrakten und ausführbaren (deskriptiven) BPEL-Prozessen unterschieden. Der im Prozesseditor dargestellte BPEL Prozess ist formal ein ausführbarer Prozess, was an dem verwendeten Namensraum docs.oasis-open.org/wsbpel/2.0/process /executable zu erkennen ist. Da entscheidende Informationen, wie etwa Sender und Empfänger von Nachrichten, zur Designzeit nicht vorliegen ist der BPEL-Prozess unvollständig. In dem folgenden Listing ist dies etwa an der generischen Definition der PartnerLinks zu erkennen. So gesehen hat der im SAP Integration Repository dargestellte BPEL-Prozess einen eher deskriptiven Charakter. Das folgende Listing stellt die Kopfdaten des BPEL-Prozesses dar: […]

180

Fallstudie zur Geschäftsprozessautomatisierung […] […] […]

Der Deklaration der globalen Variablen schließt sich die eigentliche Ablauflogik des Prozesses an, die in der SAP PI mit einer Receive-Aktivität beginnt und mit einer Send-Aktivität endet. Beide Step Types lassen sich eins zu eins in entsprechende BPEL-Aktivitäten übersetzen. Das folgende Listing zeigt die BPELKontrollstruktur für sequentielle Verarbeitung zusammen mit der Empfangs und Sende-Aktivität:

[…] […]

Design

181

Anderen in der SAP PI zur Verfügung stehenden Aktivitäten, etwa den Transformationen, stehen in BPEL keine Aktivitäten vergleichbarer Funktion gegenüber. Hierzu zählen neben blockinternen Iterationen auch Parallelsierungen (Forks) oder Transformationen. Das folgende Listing zeigt am Beispiel des ersten Transformationsschrittes, wie solche komplexen Step Types unter Verwendung von BPEL Aktivitäten abgebildet werden. Das eigentliche Mapping wird dabei technisch als invoke, also als Aufruf eines internen Webservices, abgebildet. Die erforderlichen Umformatierungen werden über die Aktivitäten assign und copy abgebildet:

sap-extn:packMsgInTransformParam('Transform_packedInMsg', 'inMsg' , 'CustomerRequest','EnvImpactCustomerRequest_ Async_Abstract', 'http://www.springer.de/bpm/sap', '', 'EnvImpactCustomerRequest')

sap-extn:unpackMsgOutofTransformParam('Transform_packedOutMsg', 'outMsg' , 'Z_BPM_SAP_GET_PREC_DOCS_REQUEST_ Async_Abstract', 'http://www.springer.de/bpm/sap', 'Z_BPM_SAP_GET_PREC_DOCS')

Die in dem Integrationsprozess verwendeten iterativen Blöcke (Step Type Block) werden über die BPEL-Aktivitäten scope und forEach abgebildet:

182


1 count(EMISRequestList) EMISRequestList[$counter_EMISRequest] […] […] /invoke> […]

Die weiterführenden BPEL-Konzepte wie Korrelationen oder Ausnahmebehandlungen werden erst in der Fallstudie des folgenden Kapitels verwendet.

7.6 Konfiguration Zur Konfiguration des Szenarios der zweiten Fallstudie werden Sie wieder den Integration Builder der SAP PI verwenden. Öffnen Sie daher den Integration Builder über das Webportal der SAP PI und loggen Sie sich mit Ihren Zugangsdaten ein.

Konfiguration

183

7.6.1 Konfigurationsszenario Sie haben bereits in der ersten Fallstudie die Funktionsweise eines Konfigurationsszenarios kennengelernt. Zur Gruppierung der Objekte der zweiten Fallstudie werden Sie ein weiteres Konfigurationsszenario anlegen. Dazu wählen Sie im Menü Object – New und aus dem Bereich Administration den Eintrag Configuration Scenario aus. Tragen Sie als Namen BPM_SAP_2 ein und klicken abschließend auf den Button Create. Fügen Sie im Folgenden alle Konfigurationsobjekte zum neuen Konfigurationsszenario hinzu.

7.6.2 Integrationsprozess Damit Sie den in der Designphase entwickelten und im Integration Repository gespeicherten Integrationsprozess für Ihre Systemlandschaft installieren können, wählen Sie im Reiter Objects in der Kategorie Communication Component den Eintrag Integration Process aus, und wählen Sie anschließend im Kontextmenü des Eintrags den Punkt New, um den bereits angelegten Integrationsprozess aus der Designphase in das Integration Directory zu importieren. Dadurch wird ein Wizard gestartet, mit dem Sie Ihren Integrationsprozess importieren können. Wählen Sie im 2. Schritt des Wizards Select Process den Integrationsprozess SupplyCarbonFootprint aus und geben Sie an, dass der Integrationsprozess zu Ihrem Konfigurationsszenario BPM_SAP_2 hinzugefügt wird. Geben Sie im 3. Schritt Select Name den Namen BPM_SAP_2 für den Integrationsprozess ein, und klicken Sie anschließend auf Finish.

7.6.3 Business-System Hersteller-ERP Damit Sie das ERP-System des Unternehmens innerhalb Ihres Konfigurationsszenarios verwenden können, müssen Sie dieses als Objekt zum Konfigurationsszenario hinzufügen. Da es sich um ein internes SAP System handelt, das im System Landscape Directory verzeichnet ist, legen Sie das System als Business-System an. Wählen Sie dafür im Reiter Objects den Pfad Communication Component Business-System und im Kontextmenü des ERP-Systems den Eintrag Assign Configuration Scenarios. Aktivieren Sie die Checkbox vor dem Namen des Konfigurationsszenarios BPM_SAP_2 und klicken Sie auf Assign. Öffnen Sie nun das Business-System zur Bearbeitung. Überprüfen Sie, ob das Inbound-Interface Z_BPM_SAP_ORDER_DETAIL im Reiter Receiver des Business-Systems angezeigt wird. Sollte dies nicht der Fall sein, müssen Sie die zweite Softwarekomponentenversion auf dem Business-System im System Landscape

184


Directory installieren. Öffnen Sie dafür im Webportal der SAP PI das SLD und loggen Sie sich mit Ihrem Benutzernamen ein. Lassen Sie sich anschließend alle technischen Systeme anzeigen, indem Sie im Bereich Landscape auf den Link Technical Systems klicken. Wählen Sie aus der Liste das technische System Ihres Business-Systems aus, und wechseln Sie in den Reiter Installed Software. Markieren Sie in der linken Tabelle das Softwareprodukt BPM_SAP_1. Dadurch werden in der rechten Tabelle die zugehörigen Softwarekomponentenversionen geladen. Aktivieren Sie die Checkbox vor der zweiten Softwarekomponentenversion und klicken Sie auf Save. Kehren Sie nun in das Integration Directory zurück. Bevor Sie das BusinessSystem wieder öffnen, sollten Sie den Zwischenspeicher löschen. Wählen Sie hierfür im Menü Environment – Clear SLD Data Cache und öffnen Sie anschließend das Business-System durch Doppelklick auf den Namen im Reiter Objects. Im Reiter Receiver finden Sie nun das Outbound-Interface Z_BPM_SAP_GET_PREC_DOCS auf der zweiten Softwarekomponentenversion. Nun müssen Sie einen RFC-Empfängerkanal für das Business-System anlegen. Klicken Sie hierfür im Business-System im Bereich Communikation Channel auf das Dokumenten-Symbol. Geben Sie den Namen des Kommunikationskanals an _2_RFC_ReceiverChannel. Im Feld Communication Component wurde bereits automatisch der Name des Business-Systems eingetragen. Stellen Sie sicher, dass der Kommunikationskanal zum Konfigurationsszenario BPM_SAP_2 hinzugefügt wird und klicken Sie auf Create. Nehmen Sie anschließend die folgenden Einstellungen für den Kommunikationskanal vor: x x x x x x x x x x x

Adapter Type: RFC (Empfänger) Transport Protocol: RFC Message Protocol: RFC (RFC XML) Adapter Engine: Central Adapter Engine Application Server: as1 System Number: ohne g Authentication Mode: Use Logon Data for SAP System Logon User: Ihr Benutzername Logon Password: Ihr Kennwort Logon Language: DE Logon Client:

Speichern Sie den Kommunikationskanal anschließend ab, und kehren Sie in die Ansicht des Business-Systems zurück. Schließen Sie die Ansicht. Sollten Sie gefragt werden, ob Änderungen gespeichert werden sollen, bestätigen Sie den Dialog.

Konfiguration

185

7.6.4 Business-Komponente Kundensystem Da das Kundensystem nicht zur internen Systemlandschaft gehört, wird es im Konfigurationsszenario nicht als Business-System, sondern als BusinessKomponente angelegt. Wählen Sie hierfür im Reiter Objects im Kontextmenü des Eintrags Business Component den Punkt New. Sie finden den Eintrag BusinessComponent in der Kategorie Communication Component. Die neue BusinessKomponente trägt den Namen BPM_SAP_CUSTOMER_2. Achten Sie darauf, dass die Business-Komponente zu dem aktuellen Konfigurationsszenario hinzugefügt wird, bevor Sie auf Create klicken. Wechseln Sie innerhalb der neuen Business-Komponente in den Reiter Sender und fügen Sie das Outbound-Interface EnvImpactCustomer_Sync_Out aus der zweiten Softwarekomponentenversion zur Business-Komponente hinzu. Speichern Sie anschließend die Business-Komponente ab. Fügen Sie dann im Reiter Sender der Business-Komponente einen Kommunikationskanal mit dem Namen BPM_SAP_CUSTOMER_2_SOAP_SenderChannel hinzu. Achten Sie wiederum darauf, dass der Kommunikationskanal zum aktuellen Konfigurationsszenario hinzugefügt wird. Konfigurieren Sie den Kommunikationskanal anhand der folgenden Daten. x x x x x x


Speichern Sie den Kommunikationskanal anschließend ab. Nun müssen Sie wie in der ersten Fallstudie eine WSDL-Datei für die spätere Implementierung des Webservices erzeugen. Wählen Sie hierfür im Menü Tools – Display WSDL, um den Assistenten zur Erzeugung von WSDL-Dateien zu starten. Den ersten Schritt des Assistenten können Sie durch Klick auf Continue überspringen. Lassen Sie sich im zweiten Schritt Specify the URL of the Web Server eine URL vorschlagen, Achten Sie darauf, dass die korrekte URL angegeben wird, und klicken Sie anschließend auf Continue. Im dritten Schritt Specify the Interface wählen Sie das Interface EnvImpactCustomer_Sync_Out aus der zweiten Softwarekomponentenversion aus. Fahren Sie mit dem nächsten Schritt fort. Im vierten Schritt Specify Sender nehmen Sie die folgenden Einstellungen vor. x Communication Component: BPM_SAP_CUSTOMER_2 x Interface Name: EnvImpactCustomer_Sync_Out x Interface Namespace: http://www.springer.de/bpm/sap Kontrollieren Sie im letzten Schritt alle getätigten Eingaben, und stellen Sie Ihre Eingabe anschließend fertig. Dadurch wird eine WSDL-Datei erzeugt. Speichern

186


Sie sich diese Datei auf Ihrer lokalen Festplatte unter dem Namen EnvImpactCustomer_Sync_Out_CaseStudy2.wsdl. Schließen Sie anschließend den Assistenten.

7.6.5 Business-Komponente Lieferantensystem Für das Lieferantensystem legen Sie ebenfalls eine Business-Komponente an. Diese trägt den Namen BPM_SAP_SUPPLIER_2. Denken Sie daran, dass die Business-Komponente beim Anlegen zum aktuellen Konfigurationsszenario hinzugefügt wird. Fügen Sie im Reiter Receiver das Inbound-Interface ProdEnvImpactSupplier_Sync_Abstract zur Business-Komponente hinzu. Achten Sie darauf, dass Sie bei der Auswahl des Interfaces wie in Abb. 7.26 dargestellt in den Search Criteria die Category auf Abstract umstellen und anschließend die Liste mit den Search Result aktualisieren.

Abb. 7.26: Einstellen der Suchkriterien

Speichern Sie die Business-Komponente ab, und legen Sie anschließend im Bereich Kommunikationskanal einen neuen Kanal mit dem Namen BPM_SAP_SUPPLIER_2_SOAP_ReceiverChannel an. Denken Sie wie immer daran, dass der Kommunikationskanal zum Konfigurationsszenario hinzugefügt wird. Konfigurieren Sie den Kommunikationskanal wie folgt: x Adapter Type: SOAP (Receiver) x Transport Protocol: HTTP x MessageProtocol: SOAP 1.1

Konfiguration

187

x Adapter Engine: Central Adapter Engine x Target URL: http://rzserv2.uni-lueneburg.de:8080/EnvironmentalServices/services/ SupplierService Speichern Sie den Kommunikationskanal anschließend ab.

7.6.6 Business-Komponente EMIS Beim betrieblichen Umweltinformationssystem handelt es sich um ein internes System des Herstellers, allerdings nicht um ein SAP-System. Wie SAP-Systeme können auch solche non-SAP-Systeme grundsätzlich im System Landscape Directory abgebildet und dann analog zum ERP-System des Unternehmens als Business-System eingebunden werden. Da Sie das EMIS nicht im SLD erfasst haben, binden Sie es analog zu den Kunden- bzw. Lieferanten-Systemen als BusinessKomponente in unser Konfigurationsszenario ein. Legen Sie hierzu eine neue Business-Komponente für das betriebliche Umweltinformationssystem mit dem Namen BPM_SAP_EMIS_2 an. Sie sollten beim Anlegen darauf achten, dass die Business-Komponente zum aktuellen Konfigurationsszenario hinzugefügt wird. Fügen Sie im Reiter Receiver der neuen Business-Komponente das InboundInterface ProdOrdEnvImpactEMIS_Sync_Abstract hinzu. Beachten Sie, dass Sie wie beim Lieferantensystem in den Search Criteria die Kategorie auf abstract abändern müssen, damit Sie das Interface in den Suchergebnissen finden. Speichern Sie danach die Business-Komponente ab. Nun müssen Sie wiederum einen neuen Kommunikationskanal innerhalb der Business-Komponente anlegen. Der Kommunikationskanal trägt den Namen BPM_SAP_EMIS_2_SOAP_ReceiverChannel und muss ebenfalls dem aktuellen Konfigurationsszenario hinzugefügt werden. Nehmen Sie die folgenden Einstellungen am neuen Kommunikationskanal vor: x x x x x

Adapter Type: SOAP (Receiver) Transport Protocol: HTTP Message Protocol: SOAP 1.1 Adapter Engine: Central Adapter Engine Target URL: http://rzserv2.uni-lueneburg.de:8080/EnvironmentalServices/ services/EMISService

Speichern Sie anschließend den Kommunikationskanal ab.

7.6.7 Nachrichtenstrecken In der zweiten Fallstudie findet ein Nachrichtenaustausch zwischen dem Integrationsprozess und dem Kundensystem, dem Lieferantensystem, sowie dem EMIS

188


statt. Zur Konfiguration der drei Nachrichtenstrecken setzen Sie den Konfigurations-Assistenten ein, den Sie bereits in der ersten Fallstudie kennengelernt haben. Nachrichtenstrecke zwischen Integrationsprozess und Kundensystem Wählen Sie im Menü Tools – Configuration Wizard um den Assistenten zu starten. Wählen Sie im ersten Schritt als Kommunikationsart den Typ Party Communication aus und fahren Sie mit dem zweiten Schritt fort. Die eingehende Message stammt von einem internal System und wird über den Adapter Type SOAP gesendet. Spezifizieren Sie den Sender im nächsten Schritt mit Hilfe von Abb. 7.27. Achten Sie darauf, dass Sie das Interface EnvImpactCustomer_Sync_Out aus der zweiten Softwarekomponentenversion auswählen.

Abb. 7.27: Spezifikation der Business-Komponente BPM_SAP_CUSTOMER_2 als Sender

Der Empfänger der Message im nächsten Schritt ist wiederum ein internes System, das über den Adaptertyp XI angesprochen wird. Im folgenden Schritt spezifizieren Sie den Empfänger der Nachricht. Dabei handelt es sich um den Integrationsprozess. Wählen Sie deshalb als Communication Component Type den Eintrag Integration Process aus. Über die Wertehilfe können Sie anschließend als Communication Component den Integrationsprozess BPM_SAP_2 auswählen. Als namensraum tragen Sie das Interface EnvImpactCustomer_Sync_Abstract ein. Als Namespacetragen Sie http://www.springer.de/bpm/sap ein. Achten Sie im nächsten Schritt SenderAgreement darauf, dass der Communication Channel BPM_SAP_CUSTOMER_2_SOAP_SenderChannel angegeben ist. In den folgenden Schritten Receiver Determination, Interface Determination und Receiver Agreement sind keine Eingaben notwendig. Achten Sie im letzten Schritt des Assistenten darauf, dass die generierten Objekte zum Konfigurationsszenario BPM_SAP_2 hinzugefügt werden. Nachrichtenstrecke zwischen Integrationsprozess und ERP-System Starten Sie den Konfigurations-Assistenten erneut, um die Nachrichtenstrecke zwischen Integrationsprozess und ERP-System zu konfigurieren. Wählen Sie im ersten Schritt wieder als Kommunikationsart Party Communication aus und fahren Sie mit dem nächsten Schritt fort. Die eingehende Nachricht stammt von einem internen System, das über den Adaptertyp XI kommuniziert. Der Sender ist der Integrationsprozess BPM_SAP_2. Als Interface tragen Sie Z_BPM_SAP_GET_PREC_DOCS_Sync_Abstract, und als Namensraum http://www.springer.de/bpm/sap ein. Im nächsten Dialogschritt wählen Sie inter-

Konfiguration

189

nal System und den Adaptertyp RFC. Spezifizieren Sie den Empfänger im nächsten Schritt anhand der folgenden Daten: x x x x

Communication Component Type: Business System Communication Component: CLNT Interface: Z_BPM_SAP_GET_PREC_DOCS Namespace: com:document:sap:rfc:functions

Die folgenden drei Schritte Sender Agreement, Receiver Determination und Interface Determination können Sie unverändert lassen. Achten Sie im Schritt Receiver Agreement darauf, dass der CommunicationChannel CLNT_1_PI_ReceiverChannel ausgewählt ist. Im letzten Schritt fügen Sie wieder alle neuen Objekte zum Konfigurationsszenario BPM_SAP_2 hinzu. Nachrichtenstrecke zwischen Integrationsprozess und Lieferantensystem Starten Sie den Konfigurations-Assistenten, um die Nachrichtenstrecke zwischen Integrationsprozess und Lieferantensystem zu konfigurieren. Hierbei handelt es sich wiederum um eine Party Communication. Auch diese eingehende Nachricht stammt von einem internen System über den Adaptertyp XI. Der Sender ist der Integrationsprozess BPM_SAP_2. Als Interface tragen Sie ProdEnvImpactSupplier_ Sync_Abstract und als Namensraum http://services.springer.de/supplier ein. Auch der Empfänger ist ein ein internes System, die Nachricht wird über den Adaptertyp SOAP versendet. Spezifizieren Sie den Empfänger anhand der folgenden Daten: x x x x

Communication Component Type: Business Component Communication Component: A_BPM_SAP_SUPPLIER_2 Interface: ProdEnvImpactSupplier_Sync_Out Namespace: http://services.springer.de/supplier

Überspringen Sie die folgenden drei Schritte Sender Agreement, Receiver Determination und Interface Determination. Stellen Sie sicher, dass im Schritt Receiver Agreement der Kommunikationskanal BPM_SAP_SUPPLIER_2_SOAP_ ReceiverChannel eingetragen ist. Fügen Sie im letzten Schritt alle neuen Objekte dem Konfigurationsszenario BPM_SAP_2 hinzu. Nachrichtenstrecke zwischen Integrationsprozess und EMIS Verwenden Sie auch zur Konfiguration der Nachrichtenstrecke zwischen Integrationsprozess und betrieblichem Umweltinformationssystem den KonfigurationsAssistenten. Auch bei dieser Nachrichtenstrecke handelt es sich um eine Party Communication. Die eingehende Message stammt von einem internen System über den Adaptertyp XI. Beim Sender handelt es sich wieder um den Integrationsprozess BPM_SAP_2. Tragen Sie das Interface ProdOrdEnvImpactEMIS_ Sync_Abstract und den Namensraum http://services.springer.de/emis ein. Die Message wird wiederum an ein über den SOAP-Adapter an ein internes System gesendet. Spezifizieren Sie den Empfänger anhand der folgenden Daten:

190

x x x x


Communication Component Type: Business Component Communication Component: BPM_SAP_EMIS_2 Interface: ProdOrdEnvImpactEMIS_Sync_Abstract Namespace: http://services.springer.de/emis

Überspringen Sie die folgenden drei Schritte Sender Agreement, Receiver Determination und Interface Determination. Stellen Sie sicher, dass im Schritt ReceiverAgreement derKommunikationskanal PM_SAP_EMIS_2_SOAP_Receiver Channel eingetragen ist. Fügen Sie im letzten Schritt alle neuen Objekte dem Konfigurationsszenario BPM_SAP_2 hinzu. Änderungsliste aktivieren Zum Abschluss der Konfiguration aktivieren Sie die Standard-Änderungsliste über den Reiter Change Lists.

7.6.8 Ablauf Um das konfigurierte Szenario zu starten, müssen Sie wieder eine geeignete Kundenanfrage an die Integrationsplattform senden. Analog zur ersten Fallstudie implementieren wir hierzu den Webservice des Kunden unter Einsatz der lokal installierten Webserviceplattform. Verwenden Sie zur Erzeugung des Webservices die zuvor lokal gespeicherte WSDL-Datei EnvImpacteCustomer_Sync_ Out_CaseStudy2.wsdl. Aus Gründen der Übersichtlichkeit und zur Vermeidung von Namenskonflikten sollten Sie für den neuen Client ein neues Projekt in Ihrer Entwicklungsumgebung anlegen. Nachfolgend wird die Vorgehensweise für die Implementierung des Webservices mit der Webserviceplattform Eclipse Web Tool Platform (WTP) beschrieben. Legen Sie zunächst ein neues Projekt an, und importieren Sie die zuvor im PISystem erzeugte WSDL-Datei. Nun können Sie im Menü über New – Web Services – Web Service Client einen neuen Webservice Client erzeugen. Dadurch werden mehrere Java-Klassen erstellt. Bevor Sie den Webservice aus Eclipse heraus aufrufen können, müssen Sie zwei Anpassungen vornehmen. Öffnen Sie die bei der Webservice-Client-Generierung erstellte Java-Klasse EnvImpactCustomer_Sync_OutBindingStub.java und fügen Sie die folgenden Zeilen ergänzt durch Ihre Zugangsdaten hinzu. public EnvImpactCO2ESalesDocItem envImpactRequest_Sync_Out(SalesDocItemenv ImpactRequestRequest) throws java.rmi.RemoteException { [...] _call.setUsername("Ihr Benutzername"); _call.setPassword("Ihr Benutzerkennwort"); [...]}

Konfiguration

191

Für den Aufruf des Webservices aus Eclipse heraus müssen Sie eine weitere JavaKlasse in Ihrem Projekt anlegen. Verwenden Sie dafür das folgende Listing. Durch das Ausführen der Klasse Client in Eclipse können Sie den Webservice aufrufen. package de.springer.bpm.sap; import java.math.BigInteger; import java.rmi.RemoteException ; import javax.xml.rpc.ServiceException; public class Client{ public static void main (String[]args){ SalesDocItem item = new SalesDocItem(); item.setPartnerId("100005"); item.setDocumentId("900002"); item.setDocumentItem("20"); item.setMaterial("P• 100"); item.setQuantity(new BigInteger("4")); EnvImpactRequest_Sync_OutServiceLocator locator = new EnvImpactRequest_Sync_OutServiceLocator(); try { EnvImpactCO2ESalesDocItem impact; impact = locator.getEnvImpactRequest_Sync_OutPort() .envImpactRequest_Sync_Out(item); System.out.println("Material : " + impact.getSalesDocItem() .getMaterial()); System.out.println("Menge : " + impact.getSalesDocItem() .getQuantity().toString()); System.out.println("Carbon Footprint : " + impact .getEnvImpactCO2EItem().getCO2E_Impact() + impact.getEnvImpactCO2EItem().getCO2E_Unit()); } catch (RemoteException ex) { ex.printStackTrace(); } catch (ServiceException ex) { ex.printStackTrace(); } } }

192


7.6.9 Monitoring Nachdem Sie den Webservice Client implementiert und aufgerufen haben, können Sie die vom Integration Server verarbeiteten Messages im Monitoring der SAP PI nachvollziehen. Melden Sie sich dafür über den SAP Logon am PI-System mit Ihren Zugangsdaten an, und rufen Sie die Transaktion SXMB_MONI auf. Wählen Sie den Punkt Monitoring for Processed XML Messages und führen Sie die Anfrage aus. Es werden nun alle im Selektionszeitraum verarbeiteten Messages angezeigt. Auch die Webservices des Lieferanten und des betrieblichen Umweltinformationssystems verfügen über eigene Monitoring-Funktionen. Sie erreichen die Monitoring-Funktionen über die Webseite des Buches. Abb. 7.28 stellt das Monitoring des Lieferantensystems dar.

Abb. 7.28: Monitoring des Lieferantensystems



Frage


1

Aus welchen Gründen können bei der Definition von Namensräumen im Enterprise Services Repository Verbindungsdaten zu SAP-Systemen hinterlegt werden?

7.3

2

Wodurch unterscheiden sich RFC-Bausteine von allgemeinen Funktionsbausteinen und BAPIs?

7.4

3

Welche Design-Artefakte werden in der Fallstudie aus externen Systemen importiert? Handelt es sich hierbei um einen InsideOut- oder Outside-In-Ansatz?

7.4

4

Beschreiben Sie am Beispiel der Fallstudie die Bedeutung von abstrakten Service Interfaces.

7.5.2

5

Beschreiben Sie anhand eines Beispiels die Notwendigkeit der Kopplung synchroner und asynchroner Prozesse? Über welche Step Types wird diese Kopplung in der SAP PI abgebildet?

7.5.4

6

Erläutern Sie die Iterationsfunktionen innerhalb von Blöcken am Beispiel des Objektes EMISBlock. Welche Änderung würde dazu führen, dass die Anfragen an das EMIS nicht sequentiell, sondern parallel gesendet würden? Wie ließe sich eine alternative sequentielle Abwicklung über den Step-Type Loop implementieren?

7.5.4

7

In der Fallstudie wird vereinfachend angenommen, dass ein einziges Lieferantensystem anzubinden ist. Beschreiben Sie die Anpassungen am Integrationsprozess, die zur Anbindung zusätzlicher Lieferantensysteme vorzunehmen wären.

8

Erläutern sie, warum in der Fallstudie dieses Kapitels mit einem neuen SOAP-Kommunikationskanal gearbeitet wird.

9

Welche zusätzlichen Konfigurationsschritte sind zur Anbindung weiterer Lieferantensysteme erforderlich (vgl. Frage 7)?

10

Erläutern Sie am Beispiel der Fallstudie die Bedeutung des System Landscape Directory für die Konfiguration des Integrationsprozesses. Welche der beteiligten Systeme können im SLD beschrieben werden, welche müssen dort erfasst werden?

11

Beschreiben Sie die Ziele und das Vorgehen der zweiten Fallstudie.

7.6.4

193

8 Fallstudie zur Benutzerinteraktion 8.1 Lernziele Nach Bearbeitung des Kapitels sind Sie in der Lage, Workflows in SAP-Systemen zu entwickeln und diese über die bereits in den vorherigen Kapiteln erlernten Mechanismen aus der SAP PI anzusprechen. Darüber hinaus lernen Sie fortgeschrittene Konzepte der Process Engine und von BPEL kennen und können die folgenden Fragen beantworten x Welche Schritte sind für die Entwicklung und Konfiguration von SAP Business Workflows erforderlich? Welche technischen Konzepte bietet die SAP hierzu? x Welche Bedeutung übernehmen Business Objects in SAP Business Workflows? x Wie können Integrationsprozesse mit anderen Objekten innerhalb der SAP PI asynchron kommunizieren? x Wie können innerhalb der SAP PI weitere Adapter wie Email genutzt werden?

8.2 Einleitung In der zweiten Fallstudie wird angenommen, dass die Ermittlung der Umweltwirkung von Vorprodukten und Produktionsprozessen durch Einbindung von Lieferanten und Umweltinformationssystemen (EMIS) in jedem Fall automatisch möglich ist. Diese Annahme wird in der dritten Fallstudie fallen gelassen: Falls ein Lieferant oder das EMIS nicht alle erforderlichen Informationen liefern können, so wird eine manuelle Nachbearbeitung durch einen Experten angestoßen und der Kunde darüber informiert.

8.2.1 Aufgabenstellung Wie der Einleitung zu entnehmen ist, wird in der dritten Fallstudie die Aufgabenstellung der zweiten Fallstudie erweitert. Nachwievor soll der Kunde in die Lage versetzt werden, das CO2e eines vom Unternehmen bezogenen Produkts abfragen zu können. Das ERP-System des Unternehmens liefert – wie in der zweiten Fallstudie – zu jedem gelieferten Produkt die zugrundeliegenden Fertigungsaufträge und Beschaffungspositionen.

196

Fallstudie zur Benutzerinteraktion

Die bei der Herstellung des Produkts verursachten Emissionen stammen aus dem betrieblichen Umweltinformationssystem des Unternehmens, welches auf Basis von Fertigungsaufträgen die induzierten Emissionen ableitet. Die Emissionen der Vorketten werden auf Basis der Beschaffungspositionen bei den Lieferanten abgefragt. In der zweiten Fallstudie wurde davon ausgegangen, dass die Lieferanten in der Lage sind, alle angeforderten Informationen zu liefern. Diese Annahme wird im Rahmen der dritten Fallstudie fallen gelassen. Es kann also der Fall eintreten, dass ein Lieferant nicht in der Lage ist, die benötigten Informationen bereitzustellen. Ist dies der Fall, wird der Materialstamm im ERPSystem des Unternehmens auf Emissionsdaten geprüft. Da ein Material prinzipiell von mehreren Lieferanten bezogen werden kann, können im Materialstamm lediglich Mittelwerte gepflegt werden (deshalb wird, um genaue Werte zu erhalten, weiterhin zunächst der Lieferant befragt). Sind nach der Prüfung des Materialstamms noch immer nicht alle Daten vorhanden, wird ein Workflow im ERPSystem des Unternehmens gestartet, der die manuelle Nachpflege der Daten im Materialstamm zum Ziel hat. Die Herausforderungen der dritten Fallstudie liegen in der Umsetzung des Workflows und der daraus resultierenden asynchronen Kommunikation zwischen dem ERP-System und der SAP PI.

8.2.2 Umsetzung Neben der SAP Process Integration werden zur Umsetzung der Benutzerintegration in dieser Fallstudie SAP Business Workflows verwendet. Systemlandschaft Die aus der zweiten Fallstudie bekannte Systemlandschaft bleibt weitgehend unverändert. Es wird lediglich davon ausgegangen, dass die Mitarbeiter des Unternehmens Zugriff auf eine LCA-Datenbank haben, die nicht direkt über eine technische Schnittstelle angebunden wird, sondern die Mitarbeiter bei der manuellen Ermittlung der Umweltwirkung und der anschließenden Pflege der Materialstammdaten im SAP ERP unterstützt. Abb. 8.1 zeigt die Systemlandschaft der dritten Fallstudie. Die SAP Business Workflows werden im ERP-System des Unternehmens, also im selben System implementiert, in dem auch die Beschaffungspositionen und Fertigungsaufträge vorliegen. Ablauf der Szenarios Der Business Process wird durch die Anfrage des Kunden initialisiert, der hierzu die Daten eines Verkaufsbelegs (Kundenummer, Auftragsnummer und Materialnummer) an das Unternehmen sendet. Das PI-System instanziiert einen Integrationsprozess, der die Steuerung des weiteren Ablaufs übernimmt. Zunächst werden die Fertigungsaufträge und Beschaffungspositionen, die dem vom Kunden angefragten Produkt zugrundeliegen,

Einleitung

197

im ERP-System des Unternehmens abgefragt. Dabei wird der aus der zweiten Fallstudie bekannte Funktionsbaustein verwendet. Informationen zur Umweltwirkung der eigenen Produktionsprozesse werden vom EMIS zur Verfügung gestellt. Da das EMIS vom Unternehmen selbst betrieben wird, wird in der Fallstudie davon ausgegangen, dass es alle benötigten Informationen zurückliefert.

Lieferant

Unternehmen

Kunde


«executable» Webservice supplier



«executable» Webservice EMIS

«executable» LCA Database

Abb. 8.1: Systemlandschaft der dritten Fallstudie

Parallel zur Anfrage an das EMIS werden anhand der Beschaffungspositionen die Informationen zur Umweltwirkung der Vorprodukte bei den Lieferanten abgefragt. Da es sich bei den Lieferantensystemen um Fremdsysteme handelt, wird zunächst überprüft, ob die Informationen der Lieferanten vollständig sind. Ist dies der Fall, können alle Daten aggregiert und in CO2e umgerechnet werden, bevor sie an den Kunden gesendet werden. Sind die Informationen der Lieferanten nicht vollständig, wird der Materialstamm auf Informationen zur Umweltwirkung überprüft. Falls die Informationen anschließend vollständig vorliegen, wird die Prozessinstanz wie oben beschrieben beendet. Andernfalls wird dem Kunden eine leere Nachricht gesendet und ihm so signalisiert, dass eine Ermittlung des CO2e vorläufig nicht möglich war. Parallel zur Abfrage der Lieferantendaten wird ein zweiter Integrationsprozess gestartet, der analog zum zuvor beschriebenen Integrationsprozess ermittelt, für welche Materialien weder der Lieferant noch der jeweilige Materialstamm Informationen zur Umweltwirkung enthalten. Für jedes unvollständige Material wird ein Workflow im ERP-System des Unternehmens gestartet. Dabei wartet der Integrationsprozess auf die Antwort des Workflows. Nachdem alle Workflows beendet wurden, sind die Materialdaten komplett und können in CO2e umgerechnet werden. Das Ergebnis wird dem Kunden in einer Email zugesandt.

198


8.3 Vorbereitungen SAP PI Um möglichst viele Objekte aus der zweiten Fallstudie übernehmen zu können, wird die dritte Fallstudie wieder als neue Version der Softwarekomponente BPM_SAP abgebildet. Hierzu wird zunächst die neue Softwarekomponentenversion im SLD erstellt und anschließend alle Designobjekte aus der zweiten Softwarekomponentenversion kopiert.

8.3.1 Softwarekomponentenversion Rufen Sie die Startseite des PI-Systems im Browser auf, und öffnen Sie das System Landscape Directory. Nachdem Sie sich mit Ihrem Benutzernamen eingeloggt haben, öffnen Sie den Software Catalog zur Anzeige der vorhandenen Softwarekomponenten durch Klick auf Software Components. Zum Anlegen einer neuen Softwarekomponentenversion wählen Sie im Software Catalog den Button New. Verwenden Sie im ersten Dialogfenster die Option Create a new version for an existing software component und klicken Sie auf Next. Wählen Sie im folgenden Dialogfenster im Feld Product Version aus der Dropdownliste Ihr Softwareprodukt BPM_SAP 1 of www.springer.de aus. Dadurch werden die beiden Felder Unit und Vendor automatisch ausgefüllt. Wählen Sie im Feld Name den einzig verfügbaren Eintrag BPM_SAP aus der Dropdownliste aus, geben Sie als Version 3 an und achten Sie darauf, dass der Production State auf released steht, bevor Sie die Erstellung der Softwarekomponentenversion durch Klick auf Finish abschließen. Bevor Sie mit der Arbeit in der neuen Softwarekomponentenversion beginnen können, müssen Sie diese wiederum in das Enterprise Services Repository importieren. Rufen Sie dafür die Startseite der SAP PI auf und öffnen Sie das Enterprise Services Repository durch Klick auf Enterprise Services Builder. Nach erfolgreichem Login wählen Sie im Reiter Design Objects im Kontextmenü des Eintrags Local Software Component Versions den Punkt New. Dadurch wird ein Wizard gestartet, mit dem Sie die soeben angelegte Softwarekomponentenversion in das Enterprise Services Repository importieren können. Wählen Sie dafür die Option Import from SLD aus und klicken Sie anschließend auf Display, um sich die Liste der Softwarekomponentenversionen anzeigen zu lassen. Suchen Sie aus der Liste der Softwarekomponentenversionen Ihre Softwarekomponente BPM_SAP in der Version 3 heraus. Dadurch werden die Felder Name, Vendor und Version im Wizard automatisch ausgefüllt, und Sie können den Wizard durch Klick auf Create schließen. Geben Sie in der Softwarekomponentenversion die folgenden Verbindungsdaten zum ERP-System ein. x System: x Client: x Message Server: z

Vorbereitungen SAP PI

199

Speichern Sie das Fenster Edit Software Component Version, nachdem Sie die Original Language auf English gestellt haben. Nun können Sie im Enterprise Services Repository direkt auf die Softwarekomponentenversion zugreifen.

8.3.2 Namensräume Im Verlauf der dritten Fallstudie werden wieder verschiedene Designobjekte aus unterschiedlichen externen Systemen in die SAP PI importiert. Deshalb werden Sie auch hier wieder verschiedene Namensräume verwenden. Suchen Sie in der linken Liste im Reiter Design Objects die Softwarekomponente BPM_SAP. Wählen Sie im Kontextmenü der dritten Softwarekomponentenversion den Eintrag Open Namespace Definitions und bestätigen Sie die erscheinende Meldung durch Klick auf Create. Geben Sie die folgenden Bezeichnungen der Namensräume in der Liste ein. x http://www.springer.de/bpm/sap x http://services.springer.de/supplier x http://services.springer.de/emis Speichern Sie das Fenster Edit Namespace Definition ab und aktivieren Sie die Standardänderungsliste.

8.3.3 Release-Übernahme von Designobjekten Im Rahmen der dritten Fallstudie können alle Designobjekte aus der zweiten Fallstudie mithilfe der Release-Übernahme übernommen werden. Wählen Sie hierzu im Menü des Enterprise Services Builder Tools – Transfer Design Objects. Überspringen Sie den Startbildschirm des Wizards. Wählen Sie als Source die zweite Softwarekomponentenversion und als Target die dritte Softwarekomponentenversion Ihrer Softwarekomponente BPM_SAP und fahren Sie mit der Auswahl der Objekte im nächsten Dialogschritt fort. Stellen Sie sicher, dass in der Dropdownliste Object Set der Eintrag All Objects of a Software Component Version ausgewählt ist und deaktivieren Sie ggf. die Option Skip Preview. Führen Sie die Übernahme der Designobjekte durch, indem Sie den Wizard abschließen.

200


8.3.4 Import des Datentyps Mail Da es bei der dritten Fallstudie vorkommen kann, dass dem Kunden die angeforderte Auskunft nicht sofort erteilt werden kann, wird dieser per Email benachrichtigt, sobald die manuelle Nachpflege von Informationen im Rahmen der Workflows abgeschlossen ist. Dafür wird der Datentyp Email vom SAP Service Marketplace (http://service.sap.com) verwendet. Den kompletten Datentypen Mail können Sie vom SAP Service Marketplace aus SAP-Hinweis 748024 beziehen. Eine vereinfachte Version finden Sie auf der zum Buch gehörenden Homepage. Im Kontextmenü des Namensraums http://www.springer.de/bpm/sap wählen Sie den Eintrag New und legen eine neue externe Definition an. Geben Sie den Namen Mail_XSD ein und klicken Sie auf Create. Wählen Sie anschließend als Category xsd aus und fügen Sie im Feld File die zuvor lokal gespeicherte Datei Mail.xsd ein. Speichern Sie die externe Definition anschließend ab.

8.4 Vorbereitungen im SAP ERP Der Funktionsbaustein Z_BPM_SAP_GET_PREC_DOCS dient der Bereitstellung der Beschaffungspositionen und Fertigungsaufträge und kann aus der zweiten Fallstudie ohne Veränderungen wiederverwendet werden. Zur Anbindung der Workflows müssen weitere Objekte im ERP-System des Unternehmens angelegt werden. Alle neuen Objekte können in dem Entwicklungspaket Z_BPM_SAP aus der zweiten Fallstudie angelegt werden. Im Rahmen der Implementierung müssen die in Tabelle 8.1 dargestellten Entwicklungsobjekte angelegt werden. Dies sind insb. Datenstrukturen, Businessobjekte sowie deren Methoden und Ereignisse.

8.4.1 Datenstrukturen Für die Ablaufsteuerung des Workflows und Zwischenspeicherung der Treibhausgase werden im Business Workflow entsprechende Datenstrukturen benötigt. Verwenden Sie zum Anlegen der Datenstrukturen den Object Navigator im ERPSystem. Loggen Sie sich im SAP ERP-System ein und rufen Sie die Transaktion (SE80) über den Menüpfad Tools – ABAP Workbench – Overview auf. Wählen Sie den Repository Browser aus und lassen Sie sich das Package Z_BPM_SAP anzeigen. Zum Anlegen der beiden Datenstrukturen wählen Sie im Kontextmenü des Paktes Z_BPM_SAP Create – Dictionary Object – Structure. Die anzulegende Struktur trägt den Namen ZBPM_STR_GAS_ IMPACT und dient als Container für die Treibhausgase im SAP-System des Unternehmens. Als Short Description ge-

Vorbereitungen im SAP ERP

201

ben Sie Emission values ein. Wechseln Sie anschließend in den Reiter Components, und geben Sie die Daten mit Hilfe von Abb. 8.2 ein. Tabelle 8.1: Entwicklungsobjekte der dritten Fallstudie. Hierbei stehen die Abkürzungen für: BO – Business Object, BOE – Business Object Event, BOM – Business Object Method, DS – Datenstruktur, FB – Funktionsbaustein, FG – Funktionsgruppe, WFA – WorkflowStandardaufgabe und WFM – Workflow-Muster Name

Typ

Beschreibung

Z_BPM_SAP_MWF

FG

Trennt den Funktionsbaustein der zweiten Fallstudie von den Funktionsbausteinen der dritten Fallstudie

ZBPM_STR_MAT_ CLASSIFICATION

DS

Gibt an, ob eine Materialklassifikation vorhanden ist

ZBPM_STR_GAS_ IMPACT

DS

Datenstruktur für die unterschiedlichen Treibhausgase

ZSPBUS1001

BO

Stellt eine Verfeinerung des Businessobjekts BUS1001 (Materialstamm) dar.

RequestLcaClassification

BOE

Startet den Workflow

LcaClassificationDone

BOE

Beendet den Workflow mit dem Ergebnis „Klassifizierung durchgeführt“

LcaClassificationNotPossible BOE

Beendet den Workflow mit dem Ergebnis „Klassifizierung konnte nicht durchgeführt werden“

CheckClassification

BOM

Prüft, ob eine Materialklassifikation vorhanden ist. Nutzt die Datenstruktur ZBPM_STR_MAT_CLASSIFICATION

Z_BPM_SAP_MWF_ CHECK_CLASS

FB

Wird benutzt, um das Vorhandensein einer Klassifizierung eines Materials zu prüfen

Z_BPM_SAP_MWF_ RESULT

FB

Stellt die Hülle für die Nachricht des Workflows an das PI-System dar

Z_BPM_SAP_MWF_ RESULT_EVENT

FB

Stellt die Implementierung der Events LcaClassificationDone und LcaClassificationNotPossible dar

Z_BPM_SAP_MWF_ START

FB

Wird von der PI verwendet, um einen Workflow über das Event RequestLcaClassification zu initiieren.

mm_lca_edit

WFA

Kapselt die BO-Methode ZSPBUS1001.EDIT zur Materialpflege MM02

mm_lca_check

WFA

Kapselt die BO-Methode ZSPBUS1001.CHECKCLASSIFICATION zur Prüfung, ob die Materialklassifizierung durchgeführt wurde

mm_lca_class

WFM

Workflow-Muster für das auslösende Event ZSPBUS1001.RequestLcaClassification

202


Abb. 8.2: Anlegen der Struktur ZBPM_STR_GAS_IMPACT

Speichern Sie die Struktur ab und fügen Sie sie dabei zu dem Paket hinzu. Fügen Sie eine weitere Struktur ZBPM_STR_MAT_CLASSIFICATION zu dem Paket hinzu. Diese dient im weiteren Verlauf als Indikator, ob bereits eine manuelle Pflege des Materials stattgefunden hat. Als Short Description geben Sie Material Classification ein. Im Reiter Components muss lediglich ein Element hinzugefügt werden. x x x x x

Component: FLAG Component Type: FLAG Data Type: CHAR Length: 1 Decimal PI: 0

Speichern Sie die Struktur ab, und fügen Sie sie zum Paket hinzu. Aktivieren Sie nun die beiden Strukturen über den Menüeintrag Structure – Activate.

8.4.2 Anlegen des Businessobjektes Alle realen Objekte in einem Unternehmen (z.B. Mitarbeiter oder Kundenaufträge) werden in SAP als Business Object abgebildet. Business Objects kapseln die Daten und Geschäftsprozesse eines Objekts. Zur Verfeinerung von Business Objekten können Subtypen angelegt und auf die jeweiligen Bedürfnisse angepasst werden.


203

In der dritten Fallstudie ist es erforderlich, dass das im SAP-Standard enthaltene Businessobjekt Material (BUS1001) um weitere Methoden und Ereignisse zur manuellen Pflege und Speicherung der Umweltwirkung erweitert wird. Zu diesem Zweck erbt das anzulegende Material ZSPBUS1001 die Eigenschaften von BUS1001 und wird anschließend erweitert. Starten Sie die Transaktion im Easy Access Menü über den Menüpfad Tools – ABAP Workbench – Development – Business Object Builder. Legen Sie ein neues Businessobjekt an, indem Sie im Feld Object/Interface Type den Namen ZSPBUS1001 eingeben, die Category Object type auswählen und auf Create klicken. Geben Sie in dem sich öffnenden Fenster folgende Daten ein: x x x x x x x

Supertype: BUS1001 Object Type: ZSPBUS1001 Object name: MaterialWorkflow Name: ZSPBUS1001 Description: Specialisation of BUS1001 Program: ZSPBUS1001 Application: M

Fügen Sie das Businessobjekt im nächsten Schritt zum Package Z_BPM_SAP hinzu und speichern Sie es ab. Verwenden Sie den üblichen Transportauftrag und Sie gelangen in das Fenster Change Object Type ZSPBUS1001. Businessobjekt-Events Mit einem Businessobjekt-Event (Ereignis) wird die Kommunikation zwischen verschiedenen Softwaremodulen ermöglicht. Events werden u.a. in der Workflow-Entwicklung verwendet, um einen Workflow zu starten oder den weiteren Ablauf einer pausierenden Workflow-Instanz zu veranlassen. Ein Event kann entweder direkt im Programmcode ausgelöst werden, oder wenn eine Statusänderung eines Businessobjekts stattgefunden hat. In der Fallstudie zeigen die Ereignisse auf dem zuvor angelegten Businessobjekt an, ob eine manuelle Pflege durchgeführt werden soll und ob diese abschließend möglich war oder nicht (letzteres wird im Rahmen der Benutzerentscheidung festgelegt). Das heißt, es werden drei unterschiedliche Ereignisse benötigt, die im Folgenden angelegt werden. Dazu klicken Sie auf das Baumelement Event und anschließend auf das Dokumentensymbol in der Funktionsleiste. Legen Sie das Event RequestLca Classification (Abb. 8.3) an. Es zeigt an, dass eine Anfrage auf manuelle Pflege vorliegt und wird ausgelöst durch die Anfrage aus dem PI-System.

204


Abb. 8.3: Anlegen des Events RequestLcaClassification

Die beiden anderen Ereignisse bilden die möglichen Ergebnisse des Pflegeprozesses ab. Sie werden analog zu RequestLcaClassification mit den in Fehler! Ungültiger Eigenverweis auf Textmarke. dargestellten Werten angelegt. Tabelle 8.2: Anlegen der Events LcaClassificationDone und LcaClassificationNotPossible Event


LcaClassificationNotPossible

Name

LcaClassDone

LcaClassNotPoss

Description


LcaClassificationNotPossible

Businessobjekt-Methode Eine Businessobjekt-Methode ist eine Operation die auf einem bestimmten BO ausgeführt wird. Der Zugriff auf Daten eines BO ist nur durch Methoden möglich. Eine Methode wird durch ihren Namen und eine Reihe von Parametern und Ausnahmen beschrieben und kann z.B. von anderen Programmen aufgerufen werden. Im Folgenden wird die Methode CheckClassification auf dem BO ZSPBUS1001 implementiert. Diese Methode wird zur Laufzeit vom BPEL-Prozess aufgerufen, um im Falle einer fehlenden Angabe des Lieferanten zu prüfen, ob bereits zuvor eine manuelle Pflege der Umweltwirkung stattgefunden hat. Die Implementierung erfolgt durch einen Funktionsbaustein, der grundsätzlich Dummy-Werte für die Treibhausgase liefert. Zum Anlegen der Methode klicken Sie auf das Baumelement Methods und anschließend auf das Dokumentensymbol in der Funktionsleiste. Legen Sie die neue Methode ohne ein Template an. Geben Sie die folgenden Daten ein und sorgen Sie dafür, dass die Checkbox Dialog im Reiter General deaktiviert ist, bevor Sie die Methode anlegen.


205

x Method: CheckClassification x Name: CheckClass x Description: CheckClassification Nachdem Sie die BO-Methode angelegt haben, muss diese noch implementiert werden. Dies erfolgt, wie zuvor erwähnt, durch den Aufruf des Funktionsbausteins Z_BPM_SAP_MWF_CHECK_CLASS. Klicken Sie zunächst in der Baumstruktur auf die Methode MaterialWorkflow.CheckClassification und anschließend den Button Program in der Funktionsleiste. Es kommt ein Hinweis, dass die Methode CheckClassification noch nicht implementiert ist. Bestätigen Sie den Hinweis mit Yes. Implementieren Sie die Methode anhand von Abb.8.4.

Abb.8.4: Implementierung der Methode CheckClassification

Überprüfen Sie die Korrektheit der Methode über den Menüpfad Object Type – Check. Kehren Sie zum Fenster Change Object Type ZSPBUS1001 zurück. Ändern Sie den Freigabestatus des Businessobjekts über den Menüpfad Edit - Change Release Status – Object Type – To implemented.

8.4.3 Funktionsbausteine Um die Kommunikation zwischen PI- und ERP-System herzustellen und Daten für die Treibhausgase eines Materials zu liefern, werden mehrere Funktionsbausteine benötigt. Diese lösen einerseits das Ereignis zum Start des Workflows aus und zeigen das Ergebnis an und dienen andererseits dem Transport der Daten zu den Treibhausgasen. Zum Anlegen der Funktionsbausteine wird die Transaktion Object Navigator im ERP-System verwendet. Rufen Sie die Transaktion im Easy Access Menü über den Menüpfad Tools – ABAP Workbench – Overview auf, und lassen Sie sich das Package Z_BPM_SAP anzeigen. Zur Gruppierung der Funktionsbausteine der dritten Fallstudie legen Sie zunächst eine Funktionsgruppe Z_BPM_SAP_MWF

206


an. Sie können dies über das Kontextmenü Ihres Pakets tun. Geben Sie für die Funktionsgruppe die Kurzbeschreibung Function Group Case Study 3 BPM an. Z_BPM_SAP_MWF_CHECK_CLASS Der Funktionsbaustein Z_BPM_SAP_MWF_CHECK_CLASS umfasst die Abfrage des Materialstamms auf Emissionswerte. Dabei handelt es sich um einen Dummy, der für eine beliebige Materialnummer Emissionen und ein Flag zur Anzeige des Vorhandenseins der Emissionswerte zurückgibt. Legen Sie über das Kontextmenü der Funktionsgruppe Z_BPM_SAP_MWF den Funktionsbaustein Z_BPM_SAP_MWF_CHECK_CLASS an. Im Feld Short text tragen Sie Check Material Classification ein. Achten Sie darauf, dass im Reiter Attributes der Processing Type Remote-Enabled Module ausgewählt ist. Dadurch wird der Funktionsbaustein für den Integrationsprozess aufrufbar. Der Funktionsbaustein wird verwendet, um den Materialstamm auszulesen. Geben Sie im Reiter Import die folgenden Daten ein (Tabelle 8.3): x x x x x

Parameter Name: I_MATNR Type spec.: TYPE Associated Type: MATNR Pass Value: X Short text: Material Number

Tabelle 8.3: Funktionsbaustein Z_BPM_SAP_MWF_CHECK_CLASS - Reiter Export Parameter Name

Type spec. Associated Type

Pass

Short text

E_CLASSIFICATION_ EXISTS

TYPE

FLAG

X

‚X‘: Classification exists

ES_GAS_IMPACT

TYPE

ZBPM_STR_ GAS_IMPACT

X

Emission values

Value

Fügen Sie anschließend im Reiter Source Code das folgende Listing hinter die Definition der lokalen Schnittstelle ein e_classification_exists = 'X'. * Material lesen * ... dummy es_gas_impact-co2 = '1.2'. es_gas_impact-co2_unit = 't'. es_gas_impact-ch4 = '2.5'. es_gas_impact-ch4_unit = 't'. es_gas_impact-n2o = '6.7'. es_gas_impact-n2o_unit = 't'. es_gas_impact-hfc = '1.8'. es_gas_impact-hfc_unit = 't'. es_gas_impact-pfc = '8.9'. es_gas_impact-pfc_unit = 't'. es_gas_impact-sf6 = '11.2'.


207

es_gas_impact-sf6_unit = 't'. ENDFUNCTION.

Speichern Sie den Funktionsbaustein ab und überprüfen Sie ihn über den Menüeintrag Function Module – Check – Syntax. Wenn keine Syntaxfehler festgestellt werden konnten, können Sie den Funktionsbaustein über den Menüeintrag Function Module – Activate aktivieren. Z_BPM_SAP_MWF_RESULT Legen Sie in der Funktionsgruppe Z_BPM_SAP_MWF den Funktionsbaustein Z_BPM_SAP_MWF_RESULT an. Dieser Funktionsbaustein dient als Bindeglied zum PI-System und trägt keine weitere Funktion. Im Feld Short text tragen Sie Send Check Result ein. Achten Sie darauf, dass im Reiter Attributes der Processing Type Remote-Enabled Module ausgewählt ist. Der Funktionsbaustein umfasst keine Funktionalität, sondern stellt nur die Hülle für die Antwort des Workflows dar. Deshalb sind lediglich im Reiter Import weitere Eingaben notwendig. Entnehmen Sie die Eingaben Tabelle 8.4. Speichern Sie den Funktionsbaustein ab und aktivieren Sie ihn über den Menüeintrag Function Module – Activate. Tabelle 8.4: Funktionsbaustein Z_BPM_SAP_MWF_RESULT - Reiter Import Parameter Name

Type Spec.Associated Type

Pass Value Short Text

I_MATNR

TYPE

MATNR

X

Material Number

I_CLASSIFICATION_ DONE

TYPE

FLAG

X

X: Classification done

IS_GAS_IMPACT

TYPE

ZBPM_STR_ GAS_IMPACT

X

Emission values

Z_BPM_SAP_MWF_RESULT_EVENT Der Funktionsbaustein Z_BPM_SAP_MWF_RESULT_EVENT verarbeitet das Ergebnis des Workflows. Ein wichtiges Element des Funktionsbausteins stellt das übergebene BO-Event dar. Wenn der Workflow mit dem Event LCACLASSIFICATIONDONE beendet wurde, bedeutet dies, dass eine Klassifikation des Materials vorhanden ist. Dementsprechend werden in dem Fall die Emissionswerte mithilfe des Funktionsbausteins Z_BPM_SAP_MWF_RESULT versandt. Wie an anderen Stellen auch wird hier lediglich ein Dummy verwendet. Im praktischen Einsatz würden hier die nachgepflegten Werte aus dem Materialstamm ausgelesen werden. Tritt der Fall ein, dass der Workflow durch ein beliebiges anderes Event beendet wird, werden keine Emissionswerte versendet. Mit dem Funktionsbaustein Z_BPM_SAP_MWF_RESULT wird in diesem Fall ein leeres Flag gesendet, das anzeigt, dass keine Klassifikation vorhanden ist. Legen Sie den Funktionsbaustein Z_BPM_SAP_MWF_RESULT_EVENT wiederum in der Funktionsgruppe Z_BPM_SAP_MWF an. Im Feld Short text tragen Sie Event: Workflow Result ein. Auch bei diesem Funktionsbaustein handelt es

208


sich um ein Remote-Enabled Module. Führen Sie die Eingaben im Reiter Import anhand von Abb. 8.5 durch.

Abb. 8.5: Funktionsbaustein Z_BPM_SAP_MWF_RESULT_EVENT - Reiter Import

Fügen Sie im Reiter Tables den folgenden Eintrag ein: x x x x x

Parameter Name: EVENT_CONTAINER Type spec.: LIKE Associated Type: SWCONT Optional: X Short text: Entity Structure

Implementieren Sie den Funktionsbaustein im Reiter Source code, indem Sie die lokale Schnittstellendefinition durch das folgende Listing ergänzen. DATA: l_matnr TYPE matnr, ls_gas_impact TYPE zbpm_str_gas_impact. * Materialnummer konvertieren l_matnr = objkey. IF event = 'LCACLASSIFICATIONDONE'. * Klassifizierung durchgeführt * Material lesen * ... dummy ls_gas_impact-co2 = '1.2'. ls_gas_impact-co2_unit = 't'. ls_gas_impact-ch4 = '2.5'. ls_gas_impact-ch4_unit = 't'. ls_gas_impact-n2o = '6.7'. ls_gas_impact-n2o_unit = 't'. ls_gas_impact-hfc = '1.8'. ls_gas_impact-hfc_unit = 't'. ls_gas_impact-pfc = '8.9'. ls_gas_impact-pfc_unit = 't'. ls_gas_impact-sf6 = '11.2'. ls_gas_impact-sf6_unit = 't'. CALL FUNCTION 'Z_BPM_SAP_MWF_RESULT' IN BACKGROUND TASK DESTINATION zbpm_sap_cl_types=>pi_rfc_dest EXPORTING


209

is_gas_impact = ls_gas_impact i_matnr = l_matnr i_classification_done = 'X'. ELSE. * keine Klassifizierung durchgeführt CLEAR: ls_gas_impact. CALL FUNCTION 'Z_BPM_SAP_MWF_RESULT' IN BACKGROUND TASK DESTINATION zbpm_sap_cl_types=>pi_rfc_dest EXPORTING is_gas_impact = ls_gas_impact i_matnr = l_matnr i_classification_done = space. ENDIF. ENDFUNCTION.

Nach Speicherung und syntaktischer Prüfung des Funktionsbausteins können Sie diesen wie zuvor dargestellt aktivieren. Z_BPM_SAP_MWF_START Mit dem Funktionsbaustein Z_BPM_SAP_MWF_START wird der Workflow im ERP-System gestartet. Der Funktionsbaustein ruft das Programm SAP_WAPI_ CREATE_EVENT auf und löst das entsprechende Ereignis aus. Dem Programm werden die Materialnummer und das zu startende BO-Event REQUESTLCA CLASSIFICATION übergeben. Den letzten Funktionsbaustein legen Sie analog zu den anderen Funktionsbausteinen an. Geben Sie als Kurzbeschreibung Start Material Workflow ein und wählen Sie als Processing Type Remote-Enabled Module aus. Mithilfe dieses Funktionsbausteins wird der Materialworkflow durch Aufruf des Events RequestLcaClassification gestartet. Geben Sie im Reiter Import die folgenden Daten ein: x x x x x

Parameter Name: I_MATNR Type spec.: TYPE Associated Type: MATNR Pass Value: X Short Text: Material Number

Implementieren Sie den Funktionsbaustein, indem Sie das folgende Listing im Reiter Source code hinter der lokalen Schnittstellendefinition einfügen. DATA: l_object_key TYPE swo_typeid. * Materialnummer in Objekt-Key für Event konvertieren l_object_key = i_matnr. * Event für Workflow starten CALL FUNCTION 'SAP_WAPI_CREATE_EVENT' EXPORTING object_type = 'ZSPBUS1001' object_key = l_object_key event = 'REQUESTLCACLASSIFICATION' commit_work = 'X'. ENDFUNCTION.

210


Speichern Sie den Funktionsbaustein, führen Sie die Überprüfung durch und aktivieren Sie ihn.

8.4.4 Workflow-Implementierung Die Implementierung von Workflows umfasst die Definition eines WorkflowMusters, auf dessen Basis zur Laufzeit die Workflow-Instanzen erzeugt werden. Die einzelnen Schritte werden als Aufgaben bezeichnet und können entweder wie in Kap. 3 beschrieben Hintergrundaufgaben, also solche, die im System automatisch ausgeführt werden, oder Dialogaufgaben sein, die eine Benutzerinteraktion bedingen. Sowohl Hintergrund- als auch Dialogaufgaben sind schließlich mit Methoden auf Business-Objekten verbunden. In der Fallstudie ist dies das Material. Workflow-Standardaufgaben Workflow-Standardaufgaben beschreiben einen einzelnen Schritt innerhalb eines Workflows. Sie können in mehreren Workflows verwendet werden und sind mit einer Methode eines Business-Objektes verbunden. Zur Laufzeit korrespondieren die Standardaufgaben mit entsprechenden Workitems. Das Erstellen der Workflow-Standardaufgaben erfolgt über den Object Navigator im ERP-System. Wählen Sie hierfür im Kontextmenü des Entwicklungspakets Z_BPM_SAP den Eintrag Create – Business Engineering – Workflow Standard Task. Legen Sie die Workflow-Standardaufgabe mm_lca_edit anhand von Abb. 8.6 an. Die Standardaufgabe wird verwendet, um die Treibhausgase des Material im Materialstamm nachzupflegen, sofern keine Klassifikation im Materialstamm hinterlegt ist. Die Standardaufgabe verwendet die bereits bestehende Methode EDIT des Object Types ZSPBUS1001, die dieses von BUS1001 geerbt hat. Speichern Sie die Workflow-Standardaufgabe ab, und legen Sie im Anschluss die Workflow-Standardaufgabe mm_lca_check anhand von Abb. 8.7 an. Die Workflow-Standardaufgabe wird für die Überprüfung der Materialklassifikation verwendet. Dabei greift die Standardaufgabe auf die zuvor angelegte BO-Methode CHECKCLASSIFICATION zu. Ist die Klassifikation vorhanden, können die Emissionsdaten zurückgegeben und der Workflow beendet werden. Fehlt die Klassifikation, müssen die Emissionen manuell nachgepflegt werden. Dabei wird im weiteren Verlauf des Workflows die zuvor angelegte Standardaufgabe mm_lca_edit aufgerufen.


Abb. 8.6: Anlegen der Workflow-Standardaufgabe mm_lca_edit

Abb. 8.7: Anlegen der Workflow-Standardaufgabe mm_lca_check

211

212


Workflow-Muster Ein Workflow-Muster setzt sich aus mehreren Standardaufgaben zusammen und bildet so einen Prozess ab. Mit der Auslieferung von SAP-Systemen werden eine Reihe von Workflow-Mustern zur Verfügung gestellt, die entweder in der gegebenen Form verwendet oder bei denen einzelnen Schritte ersetzt werden können. Darüber hinaus können wie in der Fallstudie Workflow-Muster neu definiert werden. In der Fallstudie bildet das Workflow-Muster den Rahmen für den zur manuellen Pflege verwendeten Workflow. Workflow-Muster werden über den Object Navigator im ERP-System erstellt. Wählen Sie hierfür im Kontextmenü des Entwicklungspakets Z_BPM_SAP den Eintrag Create – Business Engineering – Workflow Template. Geben Sie im Reiter Basic data des Workflow-Musters folgende Daten ein: x Abbr.: mm_lca_class x Name: Material Classification x Release status: Implemented Im Reiter Container legen Sie ein neues Container Element anhand von Abb. 8.8 an.

Abb. 8.8: Anlegen des Container Elements Material

Wählen Sie im Reiter Properties des Container Elements den Eintrag Import aus. Legen Sie ein weiteres Container Element mit dem Namen ClassificationExists an. Dabei handelt es sich um einen ABAP Dictionary Data Type. Tragen Sie den


213

Type Name Flag ein. Wechseln Sie in den Reiter Triggering events und nehmen Sie dort die folgenden Eingaben vor: x x x x

Object Category: BOR Object Type Object Type: ZSPBUS1001 Event: RequestLcaClassification Name: RequestLcaClassification

Speichern Sie anschließend das Workflow-Muster ab. Workflowdefinition Nachdem Sie die wesentlichen Aufgaben innerhalb des Workflows angelegt haben, können Sie nun mit dessen Definition – also der Festlegung der einzelnen Schritte und ihrer Reihenfolge – beginnen. Diese erfolgt über den WorkflowBuilder, der über das Workflow-Muster aufgerufen werden kann, indem Sie im Reiter Basic data auf den Button Workflow Builder klicken. Abb. 8.9 stellt den Aufbau des Workflow Builders dar. Die hauptsächlichen Arbeiten während der Definition des Workflows finden in der Design Area statt. Der Bereich enthält bereits die folgenden vier Elemente. x x x x

Workflow started (Startzustand des Workflows) Workflow completed (Endzustand des Workflows) RequestLcaClassification (Auslösendes Event) Undefined (Undefinierter Schritt)

Workflow Builder Menu Information Area

Graphical Model Design Area

Overview Area

Navigation Area

Step Area

Message Area

Abb. 8.9: Aufbau des Workflow Builders

Do Material Classification Beim ersten Schritt des Workflows handelt es sich um eine User Decision. Der Workflow wurde ausgelöst, nachdem die Überprüfung des Materialstamms ergeben hatte, dass keine Klassifikation vorhanden ist. Nun muss der Benutzer selbst

214


entscheiden, ob er in der Lage ist die Emissionswerte manuell nachzupflegen. Dabei gibt es zwei Möglichkeiten: x Die Materialklassifikation kann manuell nachgepflegt werden x Die Materialklassifikation kann nicht manuell nachgepflegt werden Gibt der Benutzer an, dass die Klassifikation manuell nachgepflegt werden kann, werden weitere Workflowschritte zur Nachpflege der Daten aufgerufen. Entscheidet sich der Benutzer für den zweiten Fall, weil er z.B. keinen Zugriff auf die benötigten Daten hat, liefert der Workflow eine entsprechende Meldung und wird beendet. Definieren Sie den ersten Schritt des Workflows, indem Sie per Doppelklick die Eigenschaften des undefinierten Schritts bearbeiten. Geben Sie den Title Do Material Classification ein. Wählen Sie als ersten Parameter die Material Number aus dem Container Element Material aus. Im Bereich Agent wählen Sie die Option User aus und tragen Ihren Benutzernamen ein. Geben Sie anschließend die folgenden beiden Decision Options an. x Undertake Material Classification x Material Classification Not Possible Kehren Sie anschließend wieder zur Design Area zurück. Der Workflow hat sich bereits geändert, indem nach dem Schritt Undertake Material Classification nun zwei Pfade vorhanden sind. Für jede Option wurde ein Pfad angelegt. LCA Classification Not Possible Der Ereignis LCA Classification Not Possible wird ausgelöst, wenn sich der Benutzer im Schritt Do Material Classification für die zweite Option entscheidet. Durch den Schritt wird das zuvor angelegte BO-Event LcaClassificationNotPossible ausgelöst. Anschließend wird der Workflow beendet. Legen Sie auf dem Pfad Material Classification Not Possible einen neuen Schritt an. Ziehen Sie dafür einen Schritt Event Creator auf den Pfad. Sie gelangen automatisch zur Konfiguration des Schritts. Geben Sie den Namen LCA Classification Not Possible sowohl als Step Name, als auch als Outcome Name ein. Wählen Sie das Container Element Material und das Event LcaClassificationNotPossible aus dem Object Type ZSPBUS1001 aus. Kehren Sie anschließend zur Design Area zurück. Edit Material Classification Hat der Benutzer die erste Option gewählt, ist er in der Lage die Klassifikation manuell nachzupflegen. In diesem Fall wird zunächst der Schritt Edit Material Classification ausgeführt. Im Rahmen des Schritts wird die BO-Methode EDIT mithilfe der Workflow-Standardaufgabe mm_lca_edit aufgerufen, durch die der Benutzer die Klassifikation nachpflegen kann. Fügen Sie einen Schritt auf dem noch leeren Pfad ein. Dabei handelt es sich um eine Activity mit dem Namen Edit Material Classification. Wählen Sie den Task mm_lca_edit aus dem Object Type ZSPBUS1001 aus, und tragen Sie als Agent Ihren User ein. Bestätigen Sie die auf-


215

tretende Meldung, dass zusätzliche Bindings notwendig sind. Kehren Sie anschließend zur Design Area zurück. Check Material Classification Nachdem der Schritt Edit Material Classification abgeschlossen wurde, wird der Schritt Check Material Classification aufgerufen. Der Schritt ruft die BO-Methode CHECKCLASSIFICATION mithilfe der Workflow-Standardaufgabe mm_lca_check auf. Es wird somit die Tätigkeit des Benutzers überwacht, indem überprüft wird, ob die Materialklassifikation nun vollständig ist. Wählen Sie den Task mm_lca_check aus, und tragen Sie den Namen des Schritts ein. Bestätigen Sie die auftretende Meldung, dass zusätzliche Bindings notwendig sind und kehren Sie zur Design Area zurück. LCA Classification Exists Nach Beendigung des Schritts Check Material Classification wird geprüft, ob mit dem Schritt Check Material Classification die Treibhausgase für das Material erfolgreich ermittelt werden konnten (dies wird über ein entsprechendes Flag gesteuert). Ist das Fall, kann der Workflow beendet und eine entsprechende Meldung zurückgegeben werden. Andernfalls muss der Benutzer die Klassifikation nochmal überarbeiten. Dies wird erreicht, indem der Workflow neu gestartet wird. Fügen Sie nun eine Condition hinter dem vorherigen Schritt ein. Die Condition überprüft, ob eine LCA-Klassifikation vorhanden ist. Dafür wird überprüft ob das Flag ClassificationExists den Wert X enthält. Geben Sie den Namen LCA Classification Exists des Schritts ein, und konfigurieren Sie die Condition. Erstellen Sie die Condition mithilfe der folgenden Daten. x Expression 1: &ClassificationExists& x Operator: = x Expression 2: X Konfigurieren Sie die Outcomes mit folgenden Daten und kehren Sie zur Design Area zurück. x True: Existent x Flase: Nonexistent Der aktuelle Pfad hat sich hinter dem Schritt LCA Classification Exists geteilt. Fügen Sie zunächst einen Schritt auf dem Pfad ein, der den Fall behandelt, dass die Klassifikation vorhanden ist.

216


Abb. 8.10: Graphisches Modell des Workflows in der SAP-eigenen Notation

LCA Classification Done Das Ereignis LCA Classification Done tritt ein, wenn die Treibhausgase bestimmt werden konnten. Als Folge wird der Workflow beendet. Fügen Sie einen Event creator Schritt auf dem Pfad Existent ein. Geben Sie den Namen LCA Classification Done sowohl als Step Name, als auch als Outcome Name an. Wählen Sie das Container Element Material und das Event LcaClassificationDone aus dem Object Type ZSPBUS1001 aus. Kehren Sie zur Design Area zurück. Restart LCA Classification Das Ereignis tritt ein, wenn die Treibhausgase für das Material nicht bestimmt werden konnten, und bewirkt, dass der Workflow neu gestartet wird. Fügen Sie auf dem Pfad Nonexistent einen Event Creator Schritt ein. Geben Sie den Namen Restart LCA Classification sowohl als Step Name, als auch als Outcome Name an. Wählen Sie das Container Element Material und das Event RequestLca Classification aus dem Object Type ZSPBUS1001 aus. Kehren Sie zur Design Area zurück.


217

Sie können den Workflow über den Menüpfad Workflow – Syntax Check überprüfen. Wenn keine Fehler bei der Überprüfung aufgetreten sind können Sie den Workflow abspeichern. Der fertige Workflow ist in Abb. 8.10 in der SAPeigenen Notation und in Abb. 8.11 als EPK dargestellt. Der Wechsel zwischen den Darstellungsarten erfolgt über Extras – Options – View.

Abb. 8.11: EPK-Ansicht der Workflow-Definition

Im letzten Schritt der Workflow-Implementierung müssen Sie die EventKopplung der folgenden beiden Events mit dem Funktionsbaustein Z_BPM_SAP_MWF_RESULT_EVENT aktiveren. Dieser fängt also die beiden möglichen Ereignisse, mit denen der Workflow beendet werden kann, ab und erlaubt die unterschiedliche Behandlung im zuvor genannten Funktionsbaustein. Dort wird über die if-Bedingung die Antwort an das PI-System differenziert. Die folgenden Kopplungen sind anzulegen: x Event BO ZSPBUS1001 LCACLASSIFICATIONDONE x Event BO ZSPBUS1001 LCACLASSIFICATIONNOTPOSSIBLE Rufen Sie hierfür über das Easy Access Menü den Pfad Tools – ABAP-Workbench – Development – SAP Business Workflow – Definition tools – Events – Event Linkages – Type Linkages auf, und aktivieren Sie die beiden Kopplungen. Beachten Sie, dass Sie nicht das Event BO ZSPBUS1001 REQUEST LCACLASSIFICATION bearbeiten.

218


8.5 Design Importieren Sie nun alle vorliegenden Schnittstellen in Ihre Softwarekomponentenversion. Dabei handelt es sich lediglich um die ERP-Schnittstellen, da Sie die EMIS-Schnittstelle und die Supplier-Schnittstelle bereits durch die ReleaseÜbernahme übernommen haben. Für die erweiterten Integrationsszenarien fehlen noch mehrere abstrakte Service Interfaces und zugehörige Operation Mappings, die die Anbindung der noch zu erstellenden BPEL-Prozesse an die Nachrichtenkommunikation der SAP PI ermöglichen. Zum Abschluss der Designphase werden Sie die beiden Integrationsprozesse anlegen. Verwenden Sie für die Designphase erneut den Enterprise Services Builder.

8.5.1 Import der externen Interfaces Zum Import der Funktionsbausteine navigieren Sie in Ihrer Softwarekomponentenversion zum Eintrag Imported Objects. Wählen Sie im Kontextmenü Import of SAP-Objectes, um den Wizard für den Import von Objekten aus einem SAPSystem zu starten. Geben Sie im ersten Schritt des Wizards die folgenden Daten ein. Falls Sie die Felder Application Server und System Number nicht sehen, klicken Sie auf den Pfeil-Button neben dem Systemnamen. x x x x

Application Server: as1 System Number: Systemnummer aus der System-ID Name: Benutzername für das SAP-System Password: Kennwort für das SAP-System

Expandieren Sie im zweiten Schritt den Objekttypen RFC, um die verfügbaren RFC-Funktionsbausteine im SAP-System anzeigen zu lassen. Je nach Systemperformance kann die Abfrage einige Minuten in Anspruch nehmen. Wählen Sie aus der Liste der verfügbaren RFC-Funktionsbausteine die folgenden Bausteine aus und fahren Sie mit dem nächsten Schritt fort. x Z_BPM_SAP_MWF_CHECK_CLASS x Z_BPM_SAP_MWF_RESULT x Z_BPM_SAP_MWF_START Ein Import des Funktionsbausteins Z_BPM_SAP_MWF_RESULT_EVENT ist nicht erforderlich, da dieser die Steuerung der Antwort innerhalb des ERPSystems des Unternehmens übernimmt, aber nicht direkt an der Nachrichtenkommunikation teilnimmt. Im letzten Schritt des Wizards werden nochmals die ausgewählten Objekte dargestellt. Führen Sie den Import durch einen Klick auf Finish aus. Nachdem der Import erfolgreich war, können Sie den Wizard schließen.

Design

219

8.5.2 Abstrakte Service Interfaces Aufgrund der Anforderungen der dritten Fallstudie müssen einige weitere abstrakte Service Interfaces im Namensraum http://www.springer.de/bpm/sap erstellt werden. Noch einmal zur Erinnerung: die abstrakten Service Interfaces dienen der Anbindung der BPEL-Engine an die Nachrichtenkommunikation innerhalb der SAP PI. Die folgende Liste gibt einen Überblick über die zu erstellenden abstrakten Service Interfaces. x x x x x x

Z_BPM_SAP_MWF_CHECK_CLASS_Request_Async_Abstract Z_BPM_SAP_MWF_CHECK_CLASS_Response_Async_Abstract Z_BPM_SAP_MWF_CHECK_CLASS_Sync_Abstract Z_BPM_SAP_MWF_RESULT_Async_Abstract Z_BPM_SAP_MWF_START_Async_Abstract EnvImpactIntegrationProcessMailResponse_Async_Abstract

Starten Sie mit dem Anlegen der abstrakten Service Interfaces. Z_BPM_SAP_MWF_CHECK_CLASS_Request_Async_Abstract Wählen Sie im Kontextmenü des Namensraums http://www.springer.de/bpm/sap den Eintrag New. Anschließend können Sie in der Objektkategorie Interface Objects den Eintrag Service Interface auswählen, um ein neues Interface anzulegen. Geben Sie den Namen des Interfaces ein und klicken Sie auf Create. Das Service Interface definiert die Schnittstelle für die Asynchrone Anfrage an den Funktionsbaustein Z_BPM_SAP_MWF_CHECK_CLASS. Konfigurieren Sie das Service Interface anhand von Abb. 8.12 und speichern es ab.

Abb. 8.12: Konfiguration des abstrakten CHECK_CLASS_Request_Async_Abstract

Service

Interfaces

Z_BPM_SAP_MWF_

220


Z_BPM_SAP_MWF_CHECK_CLASS_Response_Async_Abstract Legen Sie das nächste Service Interface nach demselben Prinzip an. Das Service Interface Z_BPM_SAP_MWF_CHECK_CLASS_Response_Async_Abstract stellt das Gegenstück zum vorherigen Service Interface dar. Konfigurieren Sie das Service Interface mithilfe der folgenden Daten. x x x x x

Category: Abstract Mode: Asynchronous Request Message Type: RFC Message Request Message: Z_BPM_SAP_MWF_CHECK_CLASS.Response Request Message Namespace: urn:sap-com:document:sap:rfc:functions

Speichern Sie das Service Interface ab. Verfahren Sie analog mit den verbleibenden Interfaces. EnvImpactIntegrationProcessMailResponse_Async_Abstract Das letzte Service Interface wird zum Versenden der Email an den Kunden verwendet. Legen Sie es auf die bekannte Weise an. Das Interface ist von der Category Abstract und im Mode Asynchronous. Wählen Sie als Message die External Message Mail aus. Speichern Sie das Service Interface anschließend ab.

8.5.3 Operation Mappings Im Rahmen der dritten Fallstudie müssen fünf weitere Operation Mappings angelegt werden. Die folgende Liste gibt einen Überblick über die anzulegenden Operation Mappings. x ProdEnvImpactSupplierRequest_Async_Abstract_ To_Z_BPM_SAP_MWF_CHECK_CLASS_Request_Async_Abstract x ProdEnvImpactSupplierRequest_Async_Abstract_ To_Z_BPM_SAP_MWF_START_Async_Abstract x Z_BPM_SAP_MWF_CHECK_CLASS_Response_Async_Abstract_ To_ProdEnvImpactSupplierResponse_Asnyc_Abstract x Z_BPM_SAP_MWF_RESULT_Async_Abstract_ To_ProdEnvImpactSupplierResponse_Asnyc_Abstract x EnvImpactCustomerResponse_Async_Abstract_ To_EnvImpactIntegrationProcessMailResponse_Async_Abstract Starten Sie nun mit dem Anlegen der Operation Mappings.

Design

221

ProdEnvImpactSupplierRequest_Async_Abstract_ To_Z_BPM_SAP_MWF_CHECK_CLASS_Request_Async_Abstract Das folgende Operation Mapping transformiert die Anfrage an den Lieferanten in eine Anfrage, die der Funktionsbaustein Z_BPM_SAP_MWF_CHECK_CLASS verarbeiten kann. Zum Anlegen des ersten Operation Mappings wählen Sie innerhalb Ihrer Softwarekomponentenversion den Namensraum http://www.springer.de/bpm/sap aus und über das Kontextmenü den Eintrag New. Wählen Sie aus der Objektkategorie Mapping Objects den Eintrag Operation Mapping aus und geben Sie den Namen ein bevor Sie auf Create klicken. Wählen Sie als Source Operation das Service Interface ProdEnvImpactSupplierRequest_Async_Abstract aus dem Namensraum http://services.springer.de/supplier und als Target Operation das Service Interface Z_BPM_SAP_MWF_CHECK_CLASS_REQUEST_Async_Abstract aus dem Namensraum http://www.springer.de/bpm/sap aus. Klicken Sie auf den Button Read Operations, um die Ausgangs- und Ziel-Message aus den beiden Interfaces auszulesen. Fügen Sie zum Operation Mapping anschließend ein Mapping-Programm hinzu, indem Sie im Bereich Mapping-Programm das Dokumentensymbol klicken und damit ein neues Message Mapping anlegen. Geben Sie als Namen des Message Mappings ProductCradleToGate GreenhouseGasImpactRequest_To_Z_BPM_SAP_MWF_CHECK_CLASS ein und stellen Sie sicher, dass das Message Mapping in den Namensraum http://www.springer.de/bpm/sap eingefügt wird, bevor Sie auf Create klicken. Die Ausgangs- und Ziel-Message werden automatisch aus dem Operation Mapping übernommen, sodass Sie sofort mit dem Mappen beginnen können. Mappen Sie das Element Material der Ausgangsnachricht mit dem Element I_MATNR der Zielnachricht. Speichern Sie das Message Mapping und danach das Operation Mapping ab. ProdEnvImpactSupplierRequest_Async_Abstract_ To_Z_BPM_SAP_MWF_START_Async_Abstract Legen Sie nach demselben Prinzip ein weiteres Operation Mapping an. Wählen Sie die folgende Source Operation: x Name: ProdEnvImpactSupplierRequest_Async_Abstract x Namespace: http://services.springer.de/supplier Fügen Sie das folgende Service Interface als Target Operation hinzu: x Name: Z_BPM_SAP_MWF_START_Async_Abstract x NameSpace: http://www.springer.de/bpm/sap Lesen Sie die Ausgangs- und Zielnachricht ein und fügen Sie ein neues Message Mapping durch Klick auf das Dokumentensymbol hinzu. Vergewissern Sie sich, dass das neue Message Mapping zu dem Namensraum http://www.springer.de/bpm/sap hinzugefügt wird, geben Sie den Namen ProductCradleToGateGreenhouseGasImpactRequest_To_Z_BPM_SAP_MWF_ START ein und klicken Sie auf Create. Die Ausgangs- und Zielnachricht werden

222


automatisch aus dem Operation Mapping übernommen. Mappen Sie das Element Material der Ausgangsnachricht mit dem Element I_MATNR der Zielnachricht. Speichern Sie das Message Mapping und danach das Operation Mapping ab. Z_BPM_SAP_MWF_CHECK_CLASS_Response_Async_Abstract_ To_ProdEnvImpactSupplierResponse_Asnyc_Abstract Das nächste Operation Mapping legen Sie mit der folgenden Source Operation an: x Name: Z_BPM_SAP_MWF_CHECK_CLASS_Response_Async_Abstract x Namespace: http://www.springer.de/bpm/sap Fügen Sie das folgende Service Interface als Target Operation hinzu: x Name: ProdEnvImpactSupplierResponse_Async_Abstract x NameSpace: http://services.springer.de/supplier Lesen Sie die Ausgangs- und Zielnachricht ein, und fügen Sie ein neues Message Mapping hinzu. Stellen Sie sicher, dass das neue Message Mapping zu dem Namensraum http://www.springer.de/bpm/sap hinzugefügt wird und geben Sie den Namen Z_BPM_SAP_MWF_CHECK_CLASS_To_ProductCradleToGate GreenhouseGasImpactResponse ein und klicken Sie auf Create. Die Ausgangsund Zielnachricht werden automatisch aus dem Operation Mapping übernommen. Führen Sie das Mapping anhand von Abb. 8.13 durch.

Abb. 8.13: Message Mapping zwischen Materialstamm-Antwort und Supplier-Antwort

Speichern Sie das Message Mapping und danach das Operation Mapping ab.

Design

223

Z_BPM_SAP_MWF_RESULT_Async_Abstract_ To_ProdEnvImpactSupplierResponse_Asnyc_Abstract Legen Sie das letzte Operation Mapping an wählen als Source-Operation: x Name: Z_BPM_SAP_MWF_RESULT_Async_Abstract x Namespace: http://www.springer.de/bpm/sap Wählen Sie als Target Operation: x Name: ProdEnvImpactSupplierResponse_Async_Abstract x NameSpace: http://services.springer.de/supplier Lesen Sie die Ausgangs- und Zielnachricht ein und fügen Sie ein neues Message Mapping hinzu. Stellen Sie sicher, dass das neue Message Mapping zu dem Namensraum http://www.springer.de/bpm/sap hinzugefügt wird, geben Sie den Namen Z_BPM_SAP_MWF_RESULT_To_ProductCradleToGateGreenhouseGas ImpactResponse ein und klicken Sie auf Create. Die Ausgangs- und Zielnachricht werden automatisch aus dem Operation Mapping übernommen. Das Mapping können Sie wiederum anhand von Abb. 8.13 durchführen. Speichern Sie das Message Mapping und danach das Operation Mapping ab. EnvImpactCustomerResponse_Async_Abstract_ To_EnvImpactIntegrationProcessMailResponse_Async_Abstract Legen Sie das nächste Operation Mapping auf die bekannte Weise an. Wählen Sie als Source Operation: x Name: EnvImpactCustomerResponse_Async_Abstract x Namespace: http://www.springer.de/bpm/sap Fügen Sie das folgende Service Interface als Target Operation hinzu: x Name: EnvImpactIntegrationProcessMailResponse_Async_Abstract x NameSpace: http://services.springer.de/supplier Lesen Sie die Ausgangs- und Zielnachricht ein. Das Message Mapping soll in diesem Fall über ein XSLT-Dokument erfolgen. XSLT steht für Extensible Stylesheet Language Transformation und ermöglicht die Auswahl, Umwandlung und Weiterverarbeitung von beliebigen Elementen eines XML-Dokuments. In der Fallstudie wird der Carbon Footprint (Menge und Einheit) aus dem Ergebnis-XML-Dokument ausgewählt und in eine HTML-Email übersetzt. Dieses muss, ähnlich wie das Java-Mapping in der zweiten Fallstudie, zunächst als externes Archiv importiert werden. Fügen Sie daher ein Imported Archive im Namensraum http://www.springer.de/bpm/sap hinzu (den vollständigen Quellcode des XSLT-Mappings finden Sie auf der Webseite des Buchs zum Download). Dies ist wie folgt aufgebaut:

224


Dieser Teil selektiert den Body des XML-Dokumentes, das die Treibhausgase enthält. Wenn dieser im Dokument gefunden wird (in XSLT gekennzeichnet durch), so wird der auf folgende XML-Code in das Zielnachricht übertragen. Der Tag extrahiert die entsprechenden Elemente aus der Ausgangsnachricht und führt diese in die Zielnachricht ein: Your Request Sender

[...]

CO2e_Impact CO2e_Unit

Design

225

Nachdem Sie das Archiv hochgeladen haben, können Sie das Message-Mapping zu dem Operation-Mapping hinzufügen. Wählen Sie im Bereich Mapping Program den Typ XSL und anschließend das Message-Mapping EnvImpact_To_Mail aus. Testen Sie das Operation-Mapping über den Reiter Test und speichern Sie es anschließend ab.

8.5.4 Integrationsprozess Die dritte Fallstudie setzt sich aus zwei Integrationsprozessen zusammen. Beide Integrationsprozesse ähneln dem in der zweiten Fallstudie erstellten Integrationsprozess und können daher auf Basis des übernommenen Integrationsprozesses erstellt werden. Der erste Integrationsprozess SupplyCarbonFootprint unterscheidet sich von dem der zweiten Fallstudie darin, dass die Antwort der Lieferanten auf Vollständigkeit geprüft und ggf. eine Abfrage der im ERP-System gespeicherten Treibhausgase auf Ebene der Materialien erfolgt. Schlägt auch das fehl, wird eine Exception ausgelöst und der zweite Integrationsprozess gestartet. Dieser hat die Aufgabe, für die noch nicht beauskunfteten Materialien jeweils einen Workflow im ERP-System des Unternehmens zu starten (indirekt über den Aufruf des Funktionsbausteins, der das entsprechende Startereignis für den Workflow auslöst). Navigieren Sie im Reiter Design Objects zu der aktuellen Softwarekomponentenversion. Wählen Sie im Namensraum http://www.springer.de/bpm/sap im Kontextmenü des Integrationsprozess SupplyCarbonFootprint den Eintrag Copy Object, um den bestehenden Integrationsprozess zu kopieren. Geben Sie als Namen SupplyCarbonFootprintWorkflow ein und stellen Sie sicher, dass die Kopie in dem korrekten Namensraum und der korrekten Softwarekomponentenversion erstellt wird. Es existieren nun zwei Integrationsprozesse in der dritten Softwarekomponentenversion, und Sie können mit der Anpassung der beiden Integrationsprozesse anfangen. SupplyCarbonFootprint Beginnen Sie zunächst mit der Anpassung des ersten Integrationsprozesses SupplyCarbonFootprint. Dabei handelt es sich in der Grundfunktion um den – aus der zweiten Fallstudie bekannten – Integrationsprozess. Ein Überblick über den zu erstellenden Integrationsprozess geben Abb. 8.14 und Abb. 8.15.

226


Abb. 8.14: Erster Teil des Integrationsprozess SupplyCarbonFootprint (Fortsetzung in Abb. 8.15)

Abb. 8.15: Zweiter Teil des Integrationsprozess SupplyCarbonFootprint

In den Abbildungen sind die erforderlichen Änderungen gegenüber dem Integrationsprozess der zweiten Fallstudie durch die Zahlen 1 bis 9 gekennzeichnet. Container Elements Bevor Sie mit dem Anlegen der neuen Prozessschritte beginnen können müssen Sie zwei Container Elements ergänzen. Sie können die Ergänzungen Tabelle 8.5 entnehmen. Sie stellen die erforderlichen Service Interfaces zur Verfügung, die über den entsprechenden Funktionsbaustein ermitteln, ob im ERP-System für das Material bereits die Treibhausgase gepflegt wurden.

Design

227

Tabelle 8.5: Zu ergänzende Container Elements im Integrations Prozess SupplyCarbonFootprint Name

Category

Type

MMRequest Abstract Interface

Z_BPM_SAP_MWF_CHECK_CLASS_Request_Async_Abstract

MMResponse Abstract Interface

Z_BPM_SAP_MWF_CHECK_CLASS_Response_Async_Abstract

1. Schritt: MMBlock (Switch) Fügen Sie als erstes einen Switch Block wie in Abb. 8.16 dargestellt zwischen dem Sende-Schritt und die Container Operation im SupplierBlock ein. Mithilfe des neuen Prozessschritts wird überprüft, ob die vom Lieferanten erhaltenen Daten vollständig sind. Geben Sie den Step Name MMBlock ein und fügen Sie eine neue Condition hinzu. Dabei müssen Sie zunächst weitere Condition Variables anlegen. Legen Sie die Condition Variables mithilfe von Tabelle 8.6 an.

Abb. 8.16: Einfügen des Switch-Blocks MMBlock Tabelle 8.6: Definition der Condition Variables für den MMBlock Name

Category

Type

CO2Unit

Simple Type

xsd:string

CH4Unit

Simple Type

xsd:string

N2OUnit

Simple Type

xsd:string

HFCUnit

Simple Type

xsd:string

PFCUnit

Simple Type

xsd:string

SF6Unit

Simple Type

xsd:string

Fügen Sie im Bereich Bindings der jeweiligen Condition Variable den Wert aus dem Container Element SupplierResponseList hinzu. Fügen Sie anschließend die Condition Variables per Drag&Drop in den Editor Condition hinzu. Ziehen Sie für jede Variable die Überprüfungsmethode EX in den Editor. Diese Methode überprüft, ob die entsprechende Variable einen Wert enthält. Verbinden Sie anschließend die verschiedenen Überprüfungen jeweils mit der Operation Logical OR. Abb. 8.17 zeigt das Anlegen der Condition im Condition Editor.

228


Abb. 8.17: Anlegen der Condition im Switch-Block MMBlock

Der obere Pfad des Switch Blocks behandelt den Fall, dass die überprüften Felder Werte enthalten. In diesem Fall ist keine zusätzliche Aktivität notwendig, sodass in dem Pfad kein weiterer Prozessschritt hinzugefügt werden muss. Der untere Pfad behandelt den Fall, dass eines der Felder leer ist. Tritt dieser Fall auf, soll der Materialstamm auf Informationen überprüft werden. Vereinfachend wird im Rahmen der dritten Fallstudie davon ausgegangen, dass der Lieferant entweder alle Werte liefert oder gar keine Werte. Daher müssen im unteren Pfad drei weitere Prozessschritte eingefügt werden. 2. Schritt: TransformSupplierRequestToMMRequest (Transform) Fügen Sie im unteren Pfad des Switch Blocks MMRequest einen Transformationsschritt ein. Durch diesen Schritt wird die Anfrage an den Lieferanten in eine Anfrage an den Materialstamm umgewandelt. Nehmen Sie die folgenden Einstellungen vor. x Step Name: TransformSupplierRequestToMMRequest x Operation Mapping: ProdEnvImpactSupplierRequest_Async_Abstract_To_ Z_BPM_SAP_MWF_CHECK_CLASS_Request_Async_Abstract x Source Message: SupplierRequest x Target Message: MMRequest 3. Schritt: SendMMRequest (Send) Fügen Sie den nächsten Schritt hinter dem vorherigen Transformationsschritt ein. Dieser Sendeschritt sendet die Anfrage des Materialstamms an das ERP-System. Konfigurieren Sie den Schritt wie folgt. x x x x x x

Step Name: SendMMRequest Mode: Synchronous Synchronous Interface: Z_BPM_SAP_MWF_CHECK_CLASS_Sync_Abstract Request Message: MMRequest Response Message: MMResponse Receiver Form: Send Context

Design

229

4. Schritt: TransformMMResponseToSupplierResponse (Transform) Der vierte Schritt wird direkt hinter dem vorherigen Sendeschritt eingefügt und transformiert die Antwort aus dem Materialstamm des ERP-Systems in die Antwort des Lieferanten. Nehmen Sie die folgenden Einstellungen vor. x Step Name: TransformMMResponseToSupplierResponse x Operation Mapping: Z_BPM_SAP_MWF_CHECK_CLASS_Response_ Async_Abstract_To_ProdEnvImpactSupplierResponse_Async_Abstract x Source Message: MMResponse x Target Message: SupplierResponse 5. Schritt: CheckSupplierResponse (Block) Der nächste Schritt (Abb. 8.15) wird hinter der parallelen Verarbeitung eingefügt. Dabei handelt es sich um einen Block, innerhalb dessen geprüft wird, ob durch die Abfrage des Materialstamms alle Daten eingefügt werden konnten. Sind alle angeforderten Daten in der Antwort des Lieferanten vorhanden, kann der Prozess wie gewohnt abgeschlossen werden. Sind jedoch nicht alle Daten vorhanden, wird der zweite Integrationsprozess durch Auslösung einer Exception gestartet und eine leere Antwort an den Kunden geschickt. Konfigurieren Sie den Block anhand der folgenden Daten: x Step Name: CheckSupplierResponse x Mode: Default x Exceptions: SupplierResponseNotExists Bevor Sie den nächsten Schritt einfügen können, müssen Sie eine weitere Einstellung am aktuellen Block vornehmen. Wählen Sie hierfür im grafischen Editor den Block CheckSupplierResponse aus, und öffnen Sie per Rechtsklick das Kontextmenü. Wählen Sie im Kontextmenü Insert – Exception Branch. Dadurch wird der Block in zwei Pfade aufgeteilt. Der obere Pfad beinhaltet den Exception Branch. Dort können Schritte eingefügt werden, die beim Auftreten einer Exception ausgeführt werden sollen. Der untere Pfad beschreibt den regulären Prozessablauf innerhalb des Blocks. Wählen Sie im Feld Exception Handler in den Einstellungen der Exception Branch den Eintrag SupplierResponseNotExists aus. 6. Schritt: SendWFRequest (Send) Innerhalb der Exception Branch muss ein Sendeschritt eingefügt werden. Der Schritt sendet die vom ERP-System erhaltene Antwort an den zweiten Integrationsprozess. Konfigurieren Sie den Schritt unter Zuhilfenahme der folgenden Daten: x x x x x

Step Name: SendWFRequest Mode: Asynchronous Message: ERPResponse Acknowledgment: None Receiver From: Send Context

230


7. Schritt: CheckSupplierResponseList (Block) Fügen Sie im unteren Pfad des Blocks CheckSupplierResponse einen weiteren Block mit dem Namen CheckSupplierResponseList ein. Fügen Sie ein neues Container Element mit den folgenden Daten ein: x x x x

Name: SupplierResponse Category: Abstract Interface Type: ProdEnvImpactSupplierResponse_Async_Abstract Scope: CheckSupplierResponseList

Konfigurieren Sie anschließend den Block wie folgt: x x x x

Step Name: CheckSupplierResponseList Mode: ForEach Multiline Element: SupplierResponseList Current Line: SupplierResponse

8. Schritt: SupplierResponseExists (Switch) Fügen Sie im Block CheckSupplierResponse einen Switch-Block ein. Konfigurieren Sie den Schritt anhand von Abb. 8.18

Abb. 8.18: Konfiguration des Switch-Blocks SupplierResponseExists

Achten Sie darauf, dass Sie auch in diesem Block eine Condition definieren müssen. Dies geschieht analog zu dem Vorgehen im 1. Schritt, mit der Ausnahme, dass die Überprüfungsmethode NX anstellen von EX verwendet wird. Mit der Methode NX wird überprüft, ob die Variable gültige Werte enthält. In diesem SwitchBlock symbolisiert der obere Pfad den Fall das die Antwort des Lieferanten nicht korrekt ist. Daher muss beim unteren Pfad kein weiterer Schritt eingefügt werden, denn dort wird der Fall behandelt, dass die Daten des Lieferanten korrekt sind.

Design

231

9. Schritt: SupplierResponseNotExists (Control) Beim neunten Schritt handelt es sich um eine Kontrollsequenz. Wird dieser Schritt erreicht, wird eine Exception ausgelöst und der erste Schritt im Exception Branch des Blocks CheckSupplierResponse ausgeführt. Dies passiert, wenn die Antwort des Lieferanten trotz Überprüfung des Materialstamms nicht vollständig ist. Laut Aufgabenstellung soll in diesem Fall ein Workflow gestartet werden, der die manuelle Pflege der Daten ermöglicht. Dies erfolgt später im zweiten Integrationsprozess. Fügen Sie die Kontrollsequenz SupplierResponseNotExists im oberen Pfad des Switch Blocks SupplierResponseExists ein. Wählen Sie als Action Throw Exception aus. Anschließend können Sie im Feld Exception den Eintrag SupplierResponseNotExists auswählen. Speichern Sie den Integrationsprozess anschließend ab. SupplyCarbonFootprintWorkflow Fahren Sie mit der Anpassung des zweiten Integrationsprozesses fort. Auch dieser Integrationsprozess basiert auf dem Integrationsprozess aus der zweiten Fallstudie. Daher müssen nur wenige Änderungen vorgenommen werden. Innerhalb dieses Integrationsprozesses findet der Workflowaufruf statt. Abb. 8.19 gibt einen Überblick über die Änderungen im SupplierBlock des Integrationsprozess. Zusätzlich wir im zehnten Schritt eine weitere Transformation durchgeführt. Der zehnte Schritt wird direkt vor dem finalen Sendeschritt eingefügt.

Abb. 8.19: Überblick über Änderunen im SupplierBlock im Integrationsprozess SupplyCarbonFootprintWorkflow

Im Gegensatz zum Integrationsprozess SupplyCarbonFootprint findet die Kommunikation im Integrationsprozess SupplyCarbonFootprintWorkflow komplett als asynchrone Kommunikation statt. Da der Integrationsprozess SupplyCarbonFootprintWorkflow durch das Empfangen der Antwort des ERPSystems gestartet wird, ist keine erneute Anfrage an das ERP-System notwendig.

232


Aus diesem Grund können im späteren Verlauf dieses Abschnitts die entsprechenden Schritte aus dem Prozess entfernt werden. Zudem muss der Startschritt und der Endschritt des Prozesses angepasst werden, da ausschließlich asynchrone Kommunikation verwendet wird. Tabelle 8.7: Zusätzliche Container Elements im Integrationsprozess SupplyCarbonFootprintWorkflow (die Abkürzung AI steht für Abstract Interface) Name

Category Type

MMRequest

AI

Z_BPM_SAP_MWF_CHECK_CLASS_Request_Async_Abstract

MMResponse

AI

Z_BPM_SAP_MWF_CHECK_CLASS_Response_Async_Abstract

MWFRequest

AI

Z_BPM_SAP_MWF_START_Async_Abstract

MWFResponse

AI

Z_BPM_SAP_MWF_RESULT_Async_Abstract

MailResponse

AI

EnvImpactIntegrationProcessMailResponse_Async_Abstract

Bevor Sie mit dem Anlegen der einzelnen Prozessschritte beginnen, müssen Sie wiederum zwei Container Elements ergänzen. Sie können die Ergänzungen Tabelle 8.7 entnehmen. Korrelationen In der asynchronen Nachrichtenkommunikation schickt eine Prozessinstanz eine Anfrage an einen Service, der nicht die direkt – also synchron – antwortet. Stattdessen meldet sich der aufgerufene Service zu einem späteren Zeitpunkt mit der Antwort zurück, in dem der Service der ursprünglich aufrufenden Prozessinstanz eine Nachricht schickt. Damit die Nachricht an die richtige Prozessinstanz innerhalb der SAP PI geleitet wird, werden sog. Korrelationen verwendet. Diese kann man als eindeutiger Identifikator interpretieren. In der Fallstudie sind Korrelationen notwendig, da die Kommunikation zwischen Integrationsprozess und Workflow asynchron stattfindet und gleichzeitig mehrere Workflows gestartet werden können. Dies bedeutet, dass die Antworten des Workflows nicht in der Reihenfolge eintreffen müssen, in der die Anfragen versendet wurden. Damit eine Antwort des Workflows einer Anfrage zugeordnet werden kann wird deshalb eine Korrelation verwendet. Als Element der Korrelation dient in diesem Fall die Materialnummer. Für jedes Material, für das keine Emissionsdaten vorhanden sind, wird ein Workflow gestartet. Die Materialnummer kann daher als eindeutiger Identifikator der Prozessinstanz verwendet werden. Die Materialnummer innerhalb der Antwort des Workflows wird beim Eintreffen der Nachricht ausgelesen und mit den Materialnummern der offenen Anfragen verglichen, um die zugehörige Anfrage zu identifizieren. Um eine Korrelation anzulegen, wählen Sie im Bereich Container das Listensymbol Switch View. Wählen Sie aus der Liste der Alternativfunktion den Eintrag Correlation List aus. Geben Sie im Bereich Correlation List anschließend den

Design

233

Namen MWF für die Korrelation ein. Markieren Sie den neuen Eintrag und klicken Sie anschließend den Button Details. Dadurch wird der grafische BPELEditor durch den Correlation Editor ersetzt. Geben Sie im Bereich Correlation Container den Namen Material ein und wählen Sie den Type xsd:string aus. Fügen Sie im Bereich Involved Messages die folgenden beiden abstrakten Service Interfaces hinzu: x Z_BPM_SAP_MWF_START_Async_Abstract x Z_BPM_SAP_MWF_RESULT_Async_Abstract Beide Service Interfaces stammen aus dem Namensraum http://www.springer.de/bpm/sap. Nun können Sie für beide Interfaces jeweils den Wert auswählen. Dafür müssen Sie in beiden Fällen wie in Abb. 8.20 dargestellt im Expression Editor bei Auswahl von Container Element das Element I_MATNR auswählen.

Abb. 8.20: Expression Editor beim Anlegen der Korrelation MWF

Anschließend können Sie über den Button Switch Editor wieder zur Ansicht Graphical Definition zurückkehren.

234


Löschen nicht verwendeter Schritte Entfernen Sie die folgenden Schritte aus dem Prozess: x TransformCustomerRequest x SendERPRequest Ändern bestehender Schritte Ändern Sie die Einstellungen des Schritts ReceiveCustomerRequest anhand der folgenden Daten: x x x x

Step Name: ReceiveERPResponse Start Process: X Mode: Asynchronous Message: ERPResponse

Deshalb muss der letzte Schritt, in dem die Antwort an den Kunden gesendet wird, ebenfalls angepasst werden: x x x x

Step Name: SendCustomerResponse Mode: Asynchronous Message: MailResponse Receiver From: Send Context

1. Schritt: MMBlock (Switch) Der erste Schritt erfolgt analog zum ersten Schritt im Integrationsprozess SupplyCarbonFootprint. Fügen Sie anhand von Abb. 8.16 einen neuen Switch Block zwischen Sendeschritt und Containeroperation innerhalb des SupplierBlocks ein. Geben Sie den Namen ein und legen Sie dieselbe Condition wie im vorherigen Integrationsprozess an. Eine Gesamtübersicht über die Definition der Condition bietet Abb. 8.17. Der obere Pfad des Switch Blocks beschreibt wiederum den Fall, dass alle Daten vorhanden sind. 2. Schritt: TransformSupplierRequestToMMRequest (Transform) Fügen Sie im unteren Pfad des Switch Blocks MMRequest einen Transformationsschritt ein. Durch diesen Schritt wird die Anfrage an den Lieferanten in eine Anfrage an den Materialstamm umgewandelt. Nehmen Sie die folgenden Einstellungen vor: x Step Name: TransformSupplierRequestToMMRequest x Operation Mapping: ProdEnvImpactSupplierRequest_Async_Abstract_ To_Z_BPM_SAP_MWF_CHECK_CLASS_Request_Async_Abstract x Source Message: SupplierRequest x Target Message: MMRequest 3. Schritt: SendMMRequest (Send) Fügen Sie den nächsten Schritt hinter dem vorherigen Transformationsschritt ein. Dieser Sendeschritt sendet die Anfrage des Materialstamms an das ERP-System. Konfigurieren Sie den Schritt wie folgt:

Design

x x x x x x

235

Step Name: SendMMRequest Mode: Synchronous Synchronous Interface: Z_BPM_SAP_MWF_CHECK_CLASS_Sync_Abstract Request Message: MMRequest Response Message: MMResponse Receiver Form: Send Context

4. Schritt: MWFBlock (Switch) Fügen Sie einen Switch Block hinter den vorherigen Sendeschritt ein. Geben Sie den Step Name MWFBlock ein und fügen Sie eine neue Condition hinzu. Erstellen Sie eine neue Condition Variable mit dem Namen MMClassification. Die Variable ist von der Category Simple Type und vom Type xsd:string. Wählen Sie anschließend das Element E_CLASSIFICATION_EXISTS aus dem Container Element MMResponse als Wert der Variable aus. Definieren Sie anschließend die Condition, indem Sie überprüfen, ob die Condition Variable MMClassification ein X enthält. Sie können die Definition anhand von Abb. 8.21 überprüfen.

Abb. 8.21: Definition der Condition für die Condition Variable MMClassification

Der obere Pfad des angelegten Switch-Blocks beschreibt den Fall, dass die angeforderten Daten im Materialstamm gepflegt waren. Dann muss lediglich die Antwort des Materialstamms in die Antwort des Lieferanten transformiert werden, bevor der Prozess beendet werden kann. Sind die Daten nicht im Materialstamm vorhanden, werden die Schritte im unteren Pfad des Switch-Blocks ausgeführt. Dabei handelt es sich um den Aufruf des Workflows. Erst wenn eine Antwort des Workflows vorliegt, wird der Prozess wie gewohnt beendet. 5. Schritt: TransformMMResponseToSupplierResponse (Transform) Der fünfte Schritt wird auf dem oberen Pfad des Switch-Blocks MWFBlock eingefügt und transformiert die Antwort aus dem Materialstamm des ERP-Systems in die Antwort des Lieferanten. Nehmen Sie die folgenden Einstellungen vor:

236


x Step Name: TransformMMResponseToSupplierResponse x Operation Mapping: Z_BPM_SAP_MWF_CHECK_CLASS_Response_ Async_Abstract_To_ProdEnvImpactSupplierResponse_Async_Abstract x Source Message: MMResponse x Target Message: SupplierResponse 6. Schritt: TransformSupplierRequestToMWFRequest (Transform) Der folgende Transformationsschritt wird auf dem unteren Pfad des MWFBlocks angelegt. In diesem Schritt wird die Anfrage an den Lieferanten in die Anfrage für den Workflow transformiert. Konfigurieren Sie den Schritt mithilfe der folgenden Daten: x Step Name: TransformSupplierRequestToMWFRequest x Operation Mapping: ProdEnvImpactSupplierRequest_Async_Abstract_To_ Z_BPM_SAP_MWF_START_Async_Abstract x Source Message: SupplierRequest x Target Message: MWFRequest 7. Schritt: SendMWFRequest (Send) Fügen Sie den nächsten Schritt direkt hinter den vorherigen Transformationsschritt ein. Dabei handelt es sich um einen Sendeschritt mit dem Namen SendMWFRequest. Der Schritt sendet eine Anfrage an das ERP-System des Unternehmens und initiiert dadurch einen Workflow. Die Einstellungen des Schritts entnehmen Sie der folgenden Liste: x x x x x

Step Name: SendMWFRequest Mode: Asynchronous Message: MWFRequest Receiver From: Send Context Activate Correlations: MWF

8. Schritt: ReceiveMWFResponse (Receive) Der nächste Schritt wird direkt hinter dem Sendeschritt SendMWFRequest eingefügt. Der Schritt wird verwendet, um die Antwort des Workflows zu empfangen. Die Einstellungen entnehmen Sie der folgenden Liste: x Step Name: ReceiveMWFResponse x Message: MWFResponse x Use Correlations: MWF 9. Schritt: TransformMWFResponseToSupplierResponse (Transform) Der vorletzte Schritt, der eingefügt werden muss, transformiert die Antwort des Workflows in die Antwort des Lieferanten und wird direkt hinter dem vorherigen Empfangsschritt eingefügt. Der Schritt trägt den Namen TransformMWFResponseToSupplierResponse, umfasst das Operation Mapping Z_BPM_SAP_MWF_RESULT_Async_Abstract_To_ProdEnvImpactSupplierRespo nse_Async_Abstract, sowie die Source Message MWFResponse und die Target Message SupplierResponse.

Konfiguration

237

10. Schritt: TransformCustomerResponseToMailResponse (Transform) Dieser Schritt wird direkt vor dem finalen Sendeschritt SendCustomerResponse eingefügt. Dabei wird die Antwort an den Kunden in eine Email umgewandelt und kann zur Laufzeit über einen Mailserver verschickt werden. Nehmen Sie die folgenden Einstellungen vor. x Operation Mapping: EnvImpactCustomerResponse_Async_Abstract_To_ EnvImpactIntegrationProcessMailResponse_Async_Abstract x Source Messages: CustomerResponse x Target Messages: MailResponse Speichern Sie den Integrationsprozess ab und aktivieren Sie die Standardänderungsliste.

8.6 Konfiguration Wie gewohnt wird zur Konfiguration der dritten Fallstudie der Integration Builder verwendet. Neben dem Hinzufügen der Business-Systeme und der Integrationsprozesse zum Konfigurationsszenario ist der Kommunikationskanal für die Versendung der Email an den Kunden zu konfigurieren. Darüber hinaus müssen aufgrund der Vielzahl der beteiligten Systeme und Prozesse eine Reihe von Nachrichtenstrecken definiert werden.

8.6.1 Konfigurationsszenario Auch für die dritte Fallstudie soll ein eigenständiges Konfigurationsszenario verwendet werden. Legen Sie daher ein neues Konfigurationsszenario an. Zum Anlegen eines neuen Konfigurationsszenarios wählen Sie im Menü Object – New und aus dem Bereich Administration den Eintrag Configuration Scenario. Verwenden Sie als Namen BPM_SAP_3. Fügen Sie die folgenden Konfigurationsobjekte zum neuen Konfigurationsszenario hinzu.

8.6.2 Integrationsprozesse Wie bereits aus der zweiten Fallstudie bekannt, müssen die Integrationsprozesse in das Integration Directory importiert werden. Wählen Sie im Reiter Objects in der Kategorie Communication Component den Eintrag Integration Process aus. Wählen Sie anschließend im Kontextmenü des Eintrags den Punkt New, um einen Integrationsprozess zu importieren.

238


Im zweiten Schritt des Wizards wählen Sie den Integrationsprozess SupplyCarbonFootprint aus der dritten Softwarekomponente aus und geben an, dass der Integrationsprozess zu Ihrem Konfigurationsszenario BPM_SAP_3 hinzugefügt wird. Geben Sie im dritten Schritt Select Name den Namen BPM_SAP_3 für den Integrationsprozess ein und beenden den Dialog. Fügen Sie den Integrationsprozess SupplyCarbonFootprintWorkflow analog zum ersten hinzu. Verwenden Sie diesmal jedoch den Namen BPM_SAP_MWF_3.

8.6.3 Business-System des Unternehmens Fügen Sie das ERP-System des Unternehmens zu Ihrem Konfigurationsszenario BPM_SAP_3 hinzu. Wählen Sie dafür im Reiter Objects den Pfad Communication Component - Business-System und im Kontextmenü des ERP-Systems den Eintrag Assign Configuration Scenarios. Aktivieren Sie die Checkbox vor dem Namen des Konfigurationsszenarios BPM_SAP_3 und klicken Sie auf Assign. Öffnen Sie nun das Business-System zur Bearbeitung. Legen Sie einen RFCEmpfängerkanal für das Business-System anlegen. Klicken Sie hierfür im Business-System im Bereich Communikation Channel auf das Dokumenten-Symbol. Geben Sie den Namen des Kommunikationskanals an _3_RFC_ReceiverChannel. Im Feld Communication Component wurde bereits automatisch der Name des Business-Systems eingetragen. Stellen Sie sicher, dass der Kommunikationskanal zum Konfigurationsszenario BPM_SAP_3 hinzugefügt wird und klicken Sie auf Create. Nehmen Sie anschließend die folgenden Einstellungen für den Kommunikationskanal vor: x x x x x x x x x x x

Adapter Type: RFC (Empfänger) Transport Protocol: RFC Message Protocol: RFC (RFC XML) Adapter Engine: Central Adapter Engine Application Server: as1 System Number: Authentication Mode: Use Logon Data for SAP System Logon User: Ihr Benutzername Logon Password: Ihr Kennwort Logon Language: DE Logon Client:

Speichern Sie den Kommunikationskanal anschließend ab, und kehren Sie in die Ansicht des Business-Systems zurück.

Konfiguration

239

8.6.4 Business-Komponente Kundensystem Legen Sie nun das Kundensystem als Business-Komponente an. Wählen Sie hierfür im Reiter Objects im Kontextmenü des Eintrags Business Component den Punkt New. Sie finden den Eintrag BusinessComponent in der Kategorie Communication Component. Die neue Business-Komponente trägt den Namen BPM_SAP_CUSTOMER_3. Achten Sie darauf, dass die Business-Komponente zu dem aktuellen Konfigurationsszenario hinzugefügt wird, bevor Sie auf Create klicken. Wechseln Sie innerhalb der neuen Business-Komponente in den Reiter Sender und fügen Sie das Outbound-Interface EnvImpactCustomer_Sync_Out aus der dritten Softwarekomponentenversion zur Business-Komponente hinzu. Speichern Sie anschließend die Business-Komponente ab. Fügen Sie im Reiter Sender der Business-Komponente einen Kommunikationskanal mit dem Namen BPM_SAP_CUSTOMER_3_SOAP_SenderChannel hinzu. Achten Sie wiederum darauf, dass der Kommunikationskanal zum aktuellen Konfigurationsszenario hinzugefügt wird. Konfigurieren Sie den Kommunikationskanal anhand der folgenden Daten: x x x x x x


Speichern Sie den Kommunikationskanal anschließend ab. Generieren Sie nun wie in den anderen beiden Fallstudien eine WSDL-Datei für die spätere Implementierung des Webservices. Den ersten Schritt des Assistenten können Sie durch Klick auf Continue überspringen. Lassen Sie sich im zweiten Schritt Specify the URL of the Web Server eine URL vorschlagen. Achten Sie darauf, dass die korrekte URL angegeben wird. Im dritten Schritt Specify the Interface wählen Sie das Interface EnvImpactCustomer_Sync_Out aus der dritten Softwarekomponentenversion aus. Fahren Sie mit dem nächsten Schritt fort. Im vierten Schritt Specify Sender nehmen Sie die folgenden Einstellungen vor. x Communication Component: BPM_SAP_CUSTOMER_3 x Interface Name: EnvImpactCustomer_Sync_Out x Interface Namespace: http://www.springer.de/bpm/sap Kontrollieren Sie im letzten Schritt alle getätigten Eingaben und stellen Sie Ihre Eingabe anschließend fertig. Dadurch wird eine WSDL-Datei erzeugt. Speichern Sie sich diese Datei auf Ihrer lokalen Festplatte unter dem Namen EnvImpactCustomer_Sync_Out_CaseStudy3.wsdl.

240


8.6.5 Business-Komponente Lieferantensystem Das Lieferantensystem wird als Business-Komponente mit dem Namen BPM_SAP_SUPPLIER_3 angelegt. Fügen Sie im Reiter Receiver das abstrakte Interface ProdEnvImpactSupplier_Sync_Abstract zur Business-Komponente hinzu. Speichern Sie die Business-Komponente ab und legen Sie anschließend im Bereich Kommunikationskanal einen neuen Kanal mit dem Namen BPM_SAP_SUPPLIER_3_SOAP_ReceiverChannel an. Fügen Sie den Kommunikationskanal dem Konfigurationsszenario hinzu und konfigurieren Sie den Kommunikationskanal wie folgt: x x x x x

Adapter Type: SOAP (Receiver) Transport Protocol: HTTP MessageProtocol: SOAP 1.1 Adapter Engine: Central Adapter Engine Target URL: http://rzserv2.uni-lueneburg.de:8080/EnvironmentalServices/ services/SupplierService

Sollten Sie den Webservice des Lieferanten selbst implementiert haben, können Sie diesen alternativ verwenden.

8.6.6 Business-Komponente EMIS Auch das betriebliche Umweltinformationssystem wird wie in der zweiten Fallstudie als Business-Komponente angelegt. Die neue Business-Komponente trägt den Namen BPM_SAP_EMIS_3. Fügen Sie im Reiter Receiver der neuen Business-Komponente das abstrakte Interface ProdOrdEnvImpactEMIS_ Sync_Abstract hinzu. Speichern Sie danach die Business-Komponente ab. Nun müssen Sie wiederum einen neuen Kommunikationskanal innerhalb der BusinessKomponente anlegen. Der Kommunikationskanal trägt den Namen BPM_SAP_EMIS_3_SOAP_ ReceiverChannel und muss ebenfalls dem aktuellen Konfigurationsszenario hinzugefügt werden. Nehmen Sie die folgenden Einstellungen am neuen Kommunikationskanal vor. x x x x x

Adapter Type: SOAP (Receiver) Transport Protocol: HTTP Message Protocol: SOAP 1.1 Adapter Engine: Central Adapter Engine Target URL: http://rzserv2.uni-lueneburg.de:8080/ EnvironmentalServices/services/EMISService

Speichern Sie anschließend den Kommunikationskanal ab.

Konfiguration

241

8.6.7 Kommunikationskanal Mail Zum Versand der Email-Nachricht muss ein entsprechender Kommunikationskanal angelegt werden. Dies geschieht innerhalb der bereits bestehenden BusinessKomponente BPM_SAP_CUSTOMER_3. Öffnen Sie die Komponente und fügen Sie im Reiter Receiver das Service Interface EnvImpactIntegrationProcessMail Response_Async_Abstract hinzu. Legen Sie im gleichen Reiter einen Kommunikationskanal an. Die Kommunikationskomponente wird automatisch ausgewählt. Geben Sie den Namen BPM_SAP_Mail_ReceiverChannel ein und fügen Sie den Kanal beim Anlegen zum Integrationsszenario BPM_SAP_3 hinzu. Konfigurieren Sie den Kanal wie folgt: x x x x x x x x x x x

Adapter Type: Mail (Receiver) Transport Protocol: SMTP Message Protocol: XIPAYLOAD Adapter Engine: Central Adapter Engine URL: smtp:// Configure User Authentication: X Authentication Methode: Plain User: Password: Use Mail Package: X Content Encoding: base64

Speichern Sie den Kommunikationskanal und anschließend die BusinessKomponente ab.

8.6.8 Nachrichtenstrecken In der dritten Fallstudie findet ein Nachrichtenaustausch zwischen den beiden Integrationsprozessen, dem Kundensystem, dem Lieferantensystem sowie dem EMIS statt. Die Konfiguration erfolgt über den Konfigurations-Assistenten. Eine Übersicht über die zu konfigurierenden Nachrichtenstrecken der beiden Integrationsprozesse finden Sie in Abb. 8.22 und Abb. 8.23. Ergänzend muss eine weitere Nachrichtenstrecke für die Kommunikation der beiden Integrationsprozesse untereinander angelegt werden.

242


Abb. 8.22: Zu konfigurierende Nachrichtenstrecken des Integrationsprozess BPM_SAP_3

BPM_SAP_3 in Abb. 8.22 bezeichnet den Integrationsprozess im Pi-System, der zunächst über den Webservice durch den Kunden aufgerufen wird. Dieser Integrationsprozess sollte nicht verwechselt werden mit dem gleichnamigen Konfigurationsszenario. Abb. 8.23 die erforderlichen Nachrichtenstrecken, die die Kommunikation des zweiten Integrationsprozesses mit den übrigen Systemen beschreiben.

Abb. 8.23: Zu konfigurierende Nachrichtenstrecken des Integrationsprozess BPM_SAP_MWF_3

Nachrichtenstrecke zwischen Kundensystem und BPM_SAP_3 Wählen Sie im Menü Tools – Configuration Wizard, um den Assistenten zu starten. Wählen Sie im ersten Schritt als Kommunikationsart den Typen Party Communication aus, und fahren Sie mit dem zweiten Schritt fort. Die eingehende Message stammt von einem Internal System und wird über den Adapter Type SOAP gesendet. Spezifizieren Sie den Sender im nächsten Schritt mithilfe der folgenden Daten. x Communication Component Type: Business Component x Communication Component: BPM_SAP_CUSTOMER_3

Konfiguration

243

x Interface: EnvImpactCustomer_Sync_Out x Namespace: http://www.springer.de/bpm/sap Achten Sie darauf, dass Sie das Interface EnvImpactCustomer_Sync_Out aus der dritten Softwarekomponentenversion auswählen. Der Empfänger der Nachricht im nächsten Schritt ist wiederum ein internal System und wird über den Adapter Type XI angesprochen. Im nächsten Schritt spezifizieren Sie den Empfänger der Nachricht. Dabei handelt es sich um den Integrationsprozess. Wählen Sie deshalb als Communication Component Type Integration Process aus. Über die Wertehilfe können Sie anschließend als Communication Component den Integrationsprozess BPM_SAP_3 auswählen. Als Interface tragen Sie das Interface EnvImpactCustomer_Sync_Abstract ein. Als Namespace tragen Sie http://www.springer.de/bpm/sap ein. Da in der zweiten und dritten Softwarekomponentenversion jeweils gleichnamige Integrationsprozesse vorhanden sind, müssen Sie die richtige Softwarekomponentenversion explizit auswählen. Achten Sie im nächsten Schritt SenderAgreement darauf, dass der Communication Channel BPM_SAP_CUSTOMER_3_SOAP_SenderChannel angegeben ist. In den folgenden Schritten Receiver Determination, Interface Determination und Receiver Agreement sind keine Eingaben notwendig. Achten Sie im letzten Schritt des Assistenten darauf, dass die generierten Objekte zum Konfigurationsszenario BPM_SAP_3 hinzugefügt werden. Nachrichtenstrecke zwischen BPM_SAP_3 und ERP-System Starten Sie den Konfigurations-Assistenten erneut, um die Nachrichtenstrecke zwischen Integrationsprozess und ERP-System zu konfigurieren. Wählen Sie im ersten Schritt wieder als Kommunikationsart Party Communication aus, und fahren Sie mit dem nächsten Schritt fort. Die eingehende Nachricht stammt von einem Internal System das über den Adapter Type XI kommuniziert. Der Sender ist der Integration Process BPM_SAP_3. Als Interface tragen Sie das Interface Z_BPM_SAP_GET_PREC_DOCS_Sync_Abstract ein. Als Namespace tragen Sie http://www.springer.de/bpm/sap ein. Spezifizieren Sie den richtigen Integrationsprozess, indem Sie die korrekte Softwarekomponentenversion auswählen. Im nächsten Dialogschritt wählen Sie Internal System und den Adapter Type RFC. Spezifizieren Sie den Empfänger im nächsten Schritt anhand der folgenden Daten. x x x x

Communication Component Type: Business System Communication Component: CLNT Interface: Z_BPM_SAP_GET_PREC_DOCS Namespace: com:document:sap:rfc:functions

Die folgenden drei Schritte Sender Agreement, Receiver Determination und Interface Determination können Sie unverändert lassen. Achten Sie im Schritt Receiver Agreement darauf, dass der CommunicationChannel CLNT_3_RFC_ReceiverChannel ausgewählt ist. Im letzten Schritt fügen Sie wieder alle neuen Objekte zum Konfigurationsszenario BPM_SAP_3 hinzu.

244


Nachrichtenstrecke zwischen Integrationsprozess und Lieferantensystem Starten Sie den Konfigurations-Assistenten um die Nachrichtenstrecke zwischen Integrationsprozess und Lieferantensystem zu konfigurieren. Hierbei handelt es sich wiederum um eine Party Communication. Die eingehende Message stammt von einem Internal System über den Adapter Type XI. Der Sender ist der Integration Process BPM_SAP_3. Als Interface tragen Sie ProdEnvImpactSupplier_Sync_Abstract und als Namespace http://services.springer.de/supplier ein. Wählen Sie die dritte Softwarekomponentenversion aus um den Sender zu spezifizieren. Die Nachricht geht wiederum an ein Internal System und wird über den Adapter Type SOAP versendet. Spezifizieren Sie den Empfänger anhand der folgenden Daten: x x x x

Communication Component Type: Business Component Communication Component: A_BPM_SAP_SUPPLIER_3 Interface: ProdEnvImpactSupplier_Sync_Abstract Namespace: http://services.springer.de/supplier

Überspringen Sie die folgenden drei Schritte Sender Agreement, Receiver Determination und Interface Determination. Stellen Sie sicher, dass im Schritt Receiver Agreement der Communication Channel BPM_SAP_SUPPLIER_3_SOAP_ ReceiverChannel eingetragen ist. Fügen Sie im letzten Schritt alle neuen Objekte dem Konfigurationsszenario BPM_SAP_3 hinzu. Konfigurieren Sie dieselbe Nachrichtenstrecke nochmals. Verwenden Sie diesmal jedoch den Integrationsprozess BPM_SAP_MWF_3. Analog konfigurieren Sie die Nachrichtenstrecke zwischen dem Integrationsprozess und dem EMIS. Nachrichtenstrecke zwischen Integrationsprozess und Materialstamm Auch bei dieser Nachrichtenstrecke handelt es sich um eine Party Communication. Die eingehende Message stammt von einem internal System über den Adapter Type XI. Beim Sender handelt es sich wieder um den Integration Process BPM_SAP_3. Tragen Sie das Interface Z_BPM_SAP_MWF_CHECK_ CLASS_Sync_Abstract und den Namespace http://www.springer.de/bpm/sap ein. Die Message wird wiederum an ein internal System über den Adapter Type RFC gesendet. Spezifizieren Sie den Empfänger anhand der folgenden Daten. x x x x

Communication Component Type: Business System Communication Component: CLNT Interface: Z_BPM_SAP_MWF_CHECK_CLASS Namespace: com:document:sap:rfc:functions

Überspringen Sie die folgenden drei Schritte Sender Agreement, Receiver Determination und Interface Determination. Stellen Sie sicher, dass im Schritt Receiver Agreement der Communication Channel CLNT_3_ RFC_ReceiverChannel eingetragen ist. Fügen Sie im letzten Schritt alle neuen Objekte dem Konfigurationsszenario BPM_SAP_3 hinzu.

Konfiguration

245

Konfigurieren Sie dieselbe Nachrichtenstrecke nochmals. Verwenden Sie diesmal jedoch den Integrationsprozess BPM_SAP_MWF_3. Nachrichtenstrecke zwischen BPM_SAP_3 und BPM_SAP_MWF_3 Bei dieser Nachrichtenstrecke handelt es sich um eine Party Communication. Die eingehende Message stammt von einem internal System über den Adapter Type XI. Beim Sender handelt es sich wieder um den Integration Process BPM_SAP_3. Tragen Sie das Interface Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_ Async_Abstract und den Namespace http://www.springer.de/bpm/sap ein. Die Message wird wiederum an ein Internal System über den Adapter Type XI gesendet. Spezifizieren Sie den Empfänger anhand der folgenden Daten. x x x x

Communication Component Type: Integration Process Communication Component: BPM_SAP_MWF_3 Interface: Z_BPM_SAP_GET_PREC_DOCS_RESPONSE_Async_Abstract Namespace: http://www.springer.de/bpm/sap

Schließen Sie den Assistenten ab, es sind keine weiteren Eingaben notwendig. Nachrichtenstrecke zwischen BPM_SAP_MWF_3 und Workflow Es handelt sich wiederum um eine Party Communication. Die eingehende Message stammt von einem internal System über den Adapter Type XI. Beim Sender handelt es sich wieder um den Integration Process BPM_SAP_MWF_3. Tragen Sie das Interface Z_BPM_SAP_MWF_START_Async_Abstract und den Namespace http://www.springer.de/bpm/sap ein. Die Message wird wiederum an ein internal System über den Adapter Type RFC gesendet. Spezifizieren Sie den Empfänger anhand der folgenden Daten. x x x x

Communication Component Type: Business System Communication Component: CLNT Interface: Z_BPM_SAP_MWF_START Namespace: com:document:sap:rfc:functions

Überspringen Sie die folgenden drei Schritte Sender Agreement, Receiver Determination und Interface Determination. Stellen Sie sicher, dass im Schritt Receiver Agreement der Communication Channel CLNT_ 3_RFC_ReceiverChannel eingetragen ist. Fügen Sie im letzten Schritt alle neuen Objekte dem Konfigurationsszenario BPM_SAP_3 hinzu. Nachrichtenstrecke zwischen Workflow und BPM_SAP_MWF_3 Es handelt sich wie gewohnt um eine Party Communication. Spezifizieren Sie den Sender (internal System, RFC) mit den folgenden Daten. x x x x

Communication Component Type: Business System Communication Component: CLNT Interface: Z_BPM_SAP_MWF_RESULT Namespace: com:document:sap:rfc:functions

246


Die Message wird an ein internal System über den Adapter Type XI gesendet. Spezifizieren Sie den Empfänger anhand der folgenden Daten. x x x x

Communication Component Type: Integration Process Communication Component: BPM_SAP_MWF_3 Interface: Z_BPM_SAP_MWF_RESULT_Async_Abstract Namespace: http://www.springer.de/bpm/sap

Schließen Sie den Assistenten anschließend ab. Nachrichtenstrecke zwischen BPM_SAP_MWF_3 und Kunden Es handelt sich wie gewohnt um eine Party Communication. Spezifizieren Sie den Sender (Internal System, XI) mit den folgenden Daten. x x x x

Communication Component Type: Integration Process Communication Component: BPM_SAP_MWF_3 Interface: EnvImpactIntegrationProcessMailResponse_Async_Abstract Namespace: http://www.springer.de/bpm/sap

Die Message wird an ein Internal System über den Adapter Type Mail gesendet. Spezifizieren Sie den Empfänger anhand der folgenden Daten. x x x x

Communication Component Type: Business Component Communication Component: BPM_SAP_CUSTOMER_3 Interface: EnvImpactIntegrationProcessMailResponse_Async_Abstract Namespace: http://www.springer.de/bpm/sap

Achten Sie darauf, dass im Schritt Receiver Agreement der Kommunikationskanal BPM_SAP_MAIL_ReceiverChannel ausgewählt ist und schließen Sie den Assistenten anschließend ab. Aktivieren Sie die Standardänderungsliste.

8.6.9 Ablauf Um das konfigurierte Szenario zu starten, müssen Sie erneut eine Kundenanfrage an die Integrationsplattform senden. Analog zu den ersten beiden Fallstudien implementieren Sie hierzu den Webservice des Kunden anhand der zuvor erstellten WSDL-Datei EnvImpacteCustomer_Sync_Out_CaseStudy3.wsdl. Aus Gründen der Übersichtlichkeit und zur Vermeidung von Namenskonflikten sollten Sie für den neuen Client ein neues Projekt in Ihrer Entwicklungsumgebung anlegen. Die Umsetzung erfolgt wie in der ersten und zweiten Fallstudie. Wenn Sie eine Anfrage über den Webservice-Client des Kunden an das PISystem schicken, werden zunächst wie in der zweiten Fallstudie über den entsprechenden Funktionsbaustein im ERP-System des Unternehmens die Beschaffungspositionen und Fertigungsaufträge ermittelt. Da Sie den in der vorhergehenden Fallstudie entwickelten SupplierService verwenden, liefert dieser direkt die Treib-


247

hausgase der angefragten Beschaffungspositionen zurück, so dass der erste BPELProzess wie zuvor direkt die Antwort liefern kann. Um nun den Start des zweiten BPEL-Prozesses zu bewirken, modifizieren Sie den Webservice des Lieferanten so, dass Daten zu den Treibhausgasen nur mit einer (frei wählbaren) Wahrscheinlichkeit zurückgegeben werden. Erhält der BPELProzess eine leere Antwort, bedeutet dies, dass der Lieferant nicht alle angeforderten Daten liefern konnte. Es wird eine Prozessinstanz des zweiten BPELProzesses erzeugt. Dieser prüft im ersten Schritt, ob Daten zu den Treibhausgasen im Materialstamm gepflegt wurde. Mit der oben gezeigten Implementierung ist dies immer der Fall, so dass der zweite BPEL-Prozess eine entsprechende Email an den Kunden schickt. Um den implementierten Workflow zu testen, muss deshalb der Funktionsbaustein Z_BPM_SAP_MWF_CHECK_CLASS modifiziert werden, so dass auch dieser bei der ersten Anfrage kein Ergebnis liefert. Wenn das der Fall ist, wird ein Workflow im ERP-System des Unternehmens angelegt. Loggen Sie sich im ERPSystem ein und öffnen Sie den Business Workplace. In der Inbox finden Sie daher mindestens einen neuen Workflow. Pflegen Sie die Daten im Materialstamm nach und schließen Sie den Workflow anschließend ab. In der Outbox können Sie sich anschließend den Ablauf des Workflows anschauen. Wählen Sie dafür den soeben abgeschlossenen Workflow aus und rufen Sie den Workflow Log auf. Abb. 8.24 zeigt einen möglichen Workflow Log.

Abb. 8.24: Workflow Log zur Materialklassifizierung

Zusätzlich können Sie den Ablauf der Verarbeitung wiederum über die Monitoringfunktionen der SAP PI oder der Webservices nachvollziehen.

248


8.7 Kontrollfragen und weiterführende Aufgaben Nr.

Frage


1

Beschreiben Sie den Ablauf der Kommunikation zwischen den beteiligten Systemen in der dritten Fallstudie.

8.2

2

Erläutern Sie am Beispiel von ZBPM_STR_GAS_IMPACT die Funktion von Datenstrukturen in der Fallstudie.

8.4

3

Warum kann als Businessobjekt nicht das vorhandene BUS1001 im Workflow verwendet werden? Welche Erweiterungen werden vorgenommen?

8.4.2

4

Welche BO-Ereignisse werden in der Fallstudie definiert? Durch was werden diese ausgelöst und was bedingen sie?

8.4.2

5

Wofür wird der Funktionsbaustein Z_BPM_SAP_MWF_

8.4.3

RESULT_EVENT verwendet? 6

Erläutern Sie die Begriffe Workflow-Standardaufgabe und Muster.

8.4.4

7

Warum weist die Darstellung des Workflows in Form von EPKs eine höhere Komplexität auf als in der SAP-eigenen Notation?

8.4.4

8

Warum führen die Ereignisse, die sich als Ergebnis der Workflow-Bearbeitung einstellen, zur Beantwortung der initialen, asynchronen Anfrage aus dem PI-System?

8.4.4

9

Erläutern Sie die Funktion des XSLT-Mappings. Verwenden Sie dafür die Test-Funktion des Message Mappings.

8.5.3

10

Erläutern Sie das Exception-Handling am Beispiel Supplier-

8.5.4

ResponseNotExists? Wann wird diese fachlich/ technisch ausgelöst? Was passiert anschließend? 11

Warum werden zwei Integrationsprozesse benötigt? Welche Aufgaben erfüllen sie?

8.5.4

12

Wofür wird die Correlation MWF in der Fallstudie verwendet? Wie wird diese definiert? Erläutern Sie die Umsetzung im BPEL-Code der SAP PI.

8.5.4

13

Warum ist die Zahl der zu konfigurierenden Nachrichtenstrecken in der dritten Fallstudie im Vergleich zur zweiten deutlich gestiegen?

8.6.8

14

Beschreiben Sie im Allgemeinen die Bedeutung von Businessobjekten in Workflows. Recherchieren Sie dazu in der SAP Bibliothek (Achtung: verwechseln Sie Businessobjekte, die bspw. in Workflows verwendet werden, nicht mit der BusinessObjects-Lösung von SAP)

15

Beschreiben Sie die Ziele und das inhaltliche Vorgehen der dritten Fallstudie.

9 Ausblick Das abschließende Kapitel skizziert erwartete Entwicklungen in den zwei Themenfeldern des Buches – der Geschäftsprozessintegration sowie der Umweltwirkung in ERP-Systemen. Zunächst werden Anregungen zur Erweiterung der Fallstudien gegeben.

9.1 Anregungen zur Erweiterung der Fallstudien Die in diesem Buch präsentierten Fallstudien haben den Anspruch, die wesentlichen technischen Aspekte der Geschäftsprozessintegration am Beispiel eines praxisnahen, betriebswirtschaftlichen Prozesses zu erörtern. Aus didaktischen Gründen werden dabei nicht alle Funktionen und Konzepte der SAP PI eingesetzt. Ein Ansatz zur Erweiterung der Fallstudien besteht nun darin, bestehende Teilprozesse mit geeigneten Alternativkonzepten zu implementieren, ein anderer darin, die Fallstudie fachlich so zu erweitern, dass zur Abbildung zusätzlicher Anforderungen weitere SAP PI Konzepte eingesetzt werden können. Um dem Leser beide Wege offenzuhalten geben wir im Folgenden zunächst einen Überblick über geeignete weiterführende Konzepte der SAP PI. Anschließend skizzieren wir ein Fallstudienszenario, zu dessen Implementierung die vorgestellten Konzepte eingesetzt werden können. Details zu den im Folgenden skizzierten Konzepten finden Sie etwa in (Nicolescu et al. 2009, Krimmel et al. 2009). Viel Spielraum für Erweiterungen bietet die Empfängerermittlung. In den Fallstudien ist der Empfänger von Nachrichten zur Konfigurationszeit grundsätzlich bekannt und im SAP PI-System als Kommunikationskomponente gepflegt. In der Praxis findet die Wahl des passenden Empfängers häufig erst zur Laufzeit und in Abhängigkeit von dem Inhalt der zugrundeliegenden Nachricht statt. In der SAP PI stehen zwei Ansätze zur Abbildung komplexer Empfängerermittlungen zur Verfügung. Falls zur Konfigurationszeit alle möglichen Empfänger im Integration Directory bekannt sind, können Regeln in dem Konfigurationsobjekt Empfängerermittlung hinterlegt werden, mit denen dann zur Laufzeit der (oder die) Empfänger abgeleitet werden. Falls der Empfänger zum Zeitpunkt der Konfiguration noch nicht bekannt ist, kann er mit dem Ansatz der dynamischen Empfängerermittlung zur Laufzeit über spezielle Mapping-Mechanismen aus der Payload der Nachricht abgeleitet werden. Zur Erweiterung der Fallstudien bietet sich auch die Verwendung zusätzlicher Adapter an. Das im Kapitel 4 vorgestellte Adapter-Framework stellt neben den in der Fallstudie behandelten SOAP- und Mail-Adaptern eine Vielzahl weiterer Adapter zur Verfügung. Für den Einsatz in der Fallstudie eignen sich der JDBCAdapter und der File-Adapter. Über den JDBC-Adapter ist es möglich, Datenbanken als Sender bzw. Empfänger von Nachrichten einzusetzen. Um eine Datenbank

250

Ausblick

als Sender zu konfigurieren, werden in dem entsprechenden Kommunikationskanal SQL-Abfragen hinterlegt, deren Ergebnisliste dann die Payload der zu sendenden Nachricht ausmacht. Wird der JDBC-Adapter als Empfänger einer Nachricht konfiguriert, können Datenbanken über passende SQL-Befehle fortgeschrieben werden. Über den JDBC-Adapter können alle Datenbanken angesprochen werden, welche die JDBC-API implementiert haben (darunter fallen u.a. die Open Source Datenbanken mySQL oder MaxDB). Der File-Adapter ermöglicht den Zugriff auf interne oder externe Dateiverzeichnisse über das File Transfer Protocol (FTP). Analog zum JDBC-Adapter führt der Einsatz des File-Adapters auf der Senderseite dazu, dass eine Datei aus einem im Kommunikationskanal spezifizierten Verzeichnis ausgelesen und dann als Payload der zu versendenden Nachricht verwendet wird. Verwendet man den File-Adapter als Empfänger von Nachrichten, können entsprechend Dateien in Dateiverzeichnisse geschrieben werden. Die Fallstudien könnten auch über die Implementierung einer durchgehenden Fehlerbehandlung erweitert werden. Zu jedem Service Interface (synchron oder asynchron) kann im Enterprise Service Repository ein Datentyp hinterlegt werden, mit dem etwaige Fehlermeldungen an den Sender der Nachricht geschickt werden können. Im Sinne einer einheitlichen Fehlerbehandlung, in der auftretende Fehler immer an den Initiator der Nachrichtenstrecke zurückgespielt werden, ist es hier sinnvoll alle Service Interfaces mit demselben Datentyp für Fehlermeldungen zu versehen. Bei der Implementierung von Integrationsprozessen wurde in den Fallstudien nicht von allen BPEL-Aktivitäten Gebrauch gemacht. Bei Erweiterungen der Fallstudie könnten die in Kapitel 4 beschriebenen Step Types User Decision, Loop und Receiver Determination Step verwendet werden. Um ein oder mehrere der oben genannten Konzepte in einem zusammenhängenden Fallbeispiel einzusetzen, bietet sich die Erweiterung der zweiten oder dritten Fallstudie um zusätzliche Lieferantensysteme an. Diese könnten über neue Adaptertypen angebunden werden, was neben der Verwendung zusätzlicher Adapter den oben beschriebenen Einsatz einer komplexen Empfänger-Ermittlung erfordert. Eine vertiefte Anwendung der Integrationsprozesse wird etwa dann erforderlich, wenn zusätzlich ein Lieferant angebunden wird, der die gewünschten Emissionsdaten ausschließlich asynchron zur Verfügung stellt. Die Implementierung einer durchgehenden Fehlerbehandlung könnte die erweiterte Fallstudie abrunden.

Perspektiven der Geschäftsprozessintegration und -automatisierung

251

9.2 Perspektiven der Geschäftsprozessintegration und automatisierung

9.2.1 Aktuelle Probleme Modellierungsnotationen wie z.B. WS-BPEL, BPMN oder UML haben eine relativ komplexe Semantik und sehr umfangreiche Syntax (d.h. zur Verfügung stehende Modellierungskonstrukte), was zu einer komplexen und fehlerträchtigen Integration von Geschäftsprozessen führen kann. Ebenso ist eine automatisierte Analyse der Modelle hinsichtlich formaler Kriterien und Leistungsparameter (z.B. Model Checking, Model Mining, Process Monitoring) erschwert (Hoheisel et al. 2009). Eine Transformation, Integration und Analyse von Geschäftsprozessen erfordert in der betrieblichen Praxis daher derzeit noch eine Vielzahl manueller Arbeitsschritte, die den Aufwand zur Realisierung automatisierter, integrierter Prozesse erhöhen. Eine (halb-)automatisierte syntaktische und insbesondere semantische Analyse von Geschäftsprozessen ist für viele Anwendungszwecke wie z.B. für das Benchmarking von integrierten Geschäftsprozessen daher wünschenswert. Aufgrund der Vielzahl unterschiedlicher Notationen im Bereich der Geschäftsprozessmodellierung, die zur Anwendung kommen können (beispielhaft seien hier die Ereignisgesteuerte Prozesskette (EPK), die Unified Modeling Language (UML) sowie BPMN (Business Process Modeling Notation) (Object Management Group 2009) genannt) sowie eines oftmals divergierenden Verständnisses der Modellierer von dem jeweils abzubildenden Realitätsausschnitt ist eine (teil-)automatisierte Analyse und ein Vergleich von Geschäftsprozessen entlang einer Supply Chain jedoch meist nicht direkt zu realisieren (Kluth et al. 2008, Teuteberg et al 2009). In der betrieblichen Praxis erfolgen die Analyse und der Vergleich von in unterschiedlichen Modellierungssprachen erstellten Geschäftsprozessmodellen daher weitestgehend noch manuell. Prozessanalysen und -vergleiche (Prozess-Benchmarking) können somit oftmals nur sehr zeitaufwändig durchgeführt werden und verursachen dementsprechend vergleichsweise hohe Kosten. Ein zentrales Ziel, welches durch das Prozess-Benchmarking verfolgt wird, ist die kontinuierliche Steigerung der Leistungsfähigkeit von Prozessabläufen. Es wird hierbei durch Analyse und Vergleich von Prozessmodellen innerhalb eines Unternehmens oder über Unternehmensgrenzen entlang der Supply Chain hinweg versucht, Verbesserungspotenziale der einzelnen Abläufe aufzudecken und umzusetzen. Beim automatisierten Vergleich und der Analyse von Prozessen wird ein einheitliches semantisches und syntaktisches Verständnis aller bei der Modellierung und Transformation der Modelle in automatisierte Prozesse beteiligten Personen vorausgesetzt. Semantisch spiegelt sich dies in einem Konsens über den zu be

252

Ausblick

trachtenden Realitätsausschnitt und die Verwendung einheitlicher Begriffe für die jeweiligen Bezeichner der Prozesselemente (Prozessaktivitäten) wieder (Kluth et al. 2008; Teuteberg et al. 2009). Syntaktisch in einem einheitlichen Verständnis bezüglich der Konstrukte der jeweils gewählten Modellierungssprache (z.B. EPK, BPMN, UML). Das Ziel einer semantischen Annotierung von Prozessen besteht darin, automatisierte semantische Analysen dieser Prozesse zu ermöglichen und semantische Fragestellungen bezüglich dieser Prozesse beantworten zu können. Bezogen auf ein semantisches Prozess-Benchmarking lassen sich zum Beispiel folgende Fragen identifizieren (Ahlemann et al. 2006, Kluth et al. 2008, Teuteberg et al. 2009): x Wie ähnlich sind sich die am Prozess-Benchmarking beteiligten Prozessmodelle hinsichtlich ihrer Abdeckung der rekonstruierten Problemdomäne? x Welche Stärken und Schwächen zeigen die einzelnen Prozesse hinsichtlich ihrer Leistungsinformationen im Vergleich zu einem Best Practice Prozess? x In welchen Prozessschritten ergibt sich das größte Verbesserungspotenzial? x Welches der Prozessmodelle deckt die zu betrachtende Problemdomäne (z.B. Messung des Carbon Footprint) am vollständigsten ab und kann dementsprechend als Best Practice Prozess identifiziert werden? Die Bezeichnung eines Prozessmodellelements mit Hilfe der natürlichen Sprache bringt jedoch große Interpretationsspielräume (Sprach- oder Begriffsdefekte) mit sich. Durch eine Zuordnung (Verknüpfung) von in Ontologien formalisierten Begriffen (Konzepten) zu Prozessmodellelementen lässt sich jedoch die in natürlicher Sprache formulierte Semantik der Prozessmodellelement-Bezeichner maschinenverarbeitbar repräsentieren und das Problem der Unschärfe natürlicher Sprache mindern. Sollten zur Prozessmodellierung zudem noch unterschiedliche Modellierungssprachen eingesetzt werden, so ist für den Vergleich somit zunächst ein Konsens bezüglich der Syntax der einzelnen Modelle und Modellkonstrukte zu schaffen. Zum Vergleich von Prozessmodellen unterschiedlicher Sprachen werden daher Transformationen der Modelle in ein von allen Beteiligten akzeptiertes Modell vorgeschlagen. Die Analyse von Prozessmodellen sollte grundsätzlich unabhängig von der konkreten Modellierungssprache sein, d.h. nicht an ein spezifisches Metamodell der gewählten Modellierungssprache gebunden sein. Aus diesem Grund kann ein einheitliches Referenz-Metamodell zum Einsatz kommen. In diesem ReferenzMetamodell sind beispielhaft für die Sprachkonstrukte der verwendeten Modellierungssprachen entsprechende Ausdrucksmöglichkeiten, Sprachelemente und Konstruktionsregeln definiert und diesen zugeordnet. Die Verwendung von Ontologien und Metamodellen erlaubt es zudem, zusätzliche Prozess-Informationen (Kennzahlen) wie z.B. Kosten, Durchlaufzeiten oder weitere Leistungsdaten einzelner Prozessschritte zu erfassen sowie Prozess-Benchmarking-Initiativen (teil-)automatisiert und somit unter Kosten- und Zeitaspekten auch effizienter durchzuführen (Kluth et al. 2008; Teuteberg et al. 2009).

Perspektiven der Geschäftsprozessintegration und -automatisierung

253

9.2.2 Lösungsmöglichkeiten Ansätze, die eine Verbesserung der Transformation von Prozessmodellen in ausführbare, integrierte und automatisiert analysierbare Prozesse intendieren, finden sich im Umfeld der Semantic Webservices, Metamodelle und Ontologien (vgl. (Cardoso, Sheth 2005) sowie (Cabral et al. 2004)). Ontologien und Semantic Webservices können helfen, semantische Differenzen zwischen verschiedenen Prozessen und Diensten zu beheben. Ontologien sind maschinenlesbare Modelle, die durch eine Menge von Konzepten (Klassen, Begriffen), Relationen, Instanzen, logischen Aussagen (Axiome) beschrieben werden. Die verwendeten Konzepte, deren Randbedingungen sowie Datentypen werden explizit spezifiziert. Der Geltungsbereich einer Ontologie wird von einer Gruppe von menschlichen und maschinellen Akteuren als Kommunikationsgrundlage akzeptiert. Die Verknüpfung von Prozessmodellelementen mit Elementen der Ontologie wird als semantische Annotation bezeichnet (Thomas, Fellmann 2009). Mit Hilfe von Ontologien können durch Verfahren des maschinellen Schließens neue Fakten generiert werden. Die Suche nach einem Prozessmodell mit einem Element „Kundenauftrag erfassen“ kann so bspw. ein Prozessmodell mit einem Element „Kundendaten eingeben“ zurückliefern, da in der zugrunde liegenden Ontologie in einer maschinenlesbaren Form die Information hinterlegt ist, dass die Eingabe der Kundendaten eine Teilaufgabe der Auftragserfassung ist. So kann zum Beispiel auch in einem Prozessmodell von „Liefertermin prüfen“ gesprochen werden, während in einem anderen Modell „Wareneingangstermin prüfen“ zur Bezeichnung einer Prozessaktivität verwendet wird. In der natürlichen Sprache werden beide Begriffe weitestgehend synonym verwendet, für einen Computer sind dieses jedoch völlig unterschiedliche Zeichenketten (Kluth et al. 2008). Durch eine maschinenverarbeitbare, semantische Beschreibung von Prozessen soll insbesondere ein leichteres Integrieren von Prozessen ermöglicht werden (höhere Interopertabilität) sowie eine Überbrückung semantischer Differenzen im Rahmen von Webservice-Kompositionen (Orchestration) erreicht werden (Hoheisel et al. 2009). Hierzu sind jedoch umfangreiche ontologiebasierte Beschreibungen der Prozesse notwendig, wozu eine Vielzahl an Ontologiesprachen wie z.B. WSMO (Web Service Modeling Ontology) (Arroyo et al. 2005) oder OWL-S (Web Ontology Language for Web Services) (Martin et al. 2004) entwickelt worden sind. Die Ontologiesprache Web Ontology Language (OWL) basiert auf RDF (Ressource Description Framework) und RDF-Schema und nutzt die XML-Syntax von RDF. OWL entstand aufgrund der begrenzten Aussagekraft des RDF-Schema und den daraus resultierenden nicht eindeutigen Schlussfolgerungen über Aussagen einer in ihr verfassten Ontologie. In den letzten Jahren hat sich OWL (OWL 2008) aufgrund ihrer weiten Verbreitung und der Standardisierung durch das World Wide Web Consortium (W3C) zur Standard-Ontologiesprache entwickelt.

254

Ausblick

Die Verwendung von Ontologien in Bezug auf Prozessmodelle, wurde in den letzten Jahren in vielen Beiträgen mit unterschiedlichen Zielsetzungen beschrieben und motiviert (Kluth et al. 2008, Teuteberg et al. 2009). So nutzt etwa (Höfferer 2007) Ontologien mit dem Ziel der Verbesserung der semantischen Interoperabilität von Prozessmodellen. (Hepp et al. 2005), (Thomas, Fellmann 2007) und (Celino et al 2007) verwenden sie zur semantischen Beschreibung der Prozessmodelle und deren automatischer Auswertung. Hingegen nutzen (Ehrig et al. 2007) Ontologien im Zusammenhang mit Petri-Netzen zur Messung von Ähnlichkeiten in Prozessmodellen. In der Literatur lassen sich weiterhin zahlreiche Beiträge zur Verwendung von Meta-Modellen finden. Mit den Meta-Modellen wird das Ziel einer Vereinheitlichung bzw. Transformation von Prozessmodellen unterschiedlicher Modellierungssprachen verfolgt. So nutzen (Vanderhaeghen et al. 2005) Metamodelle mit dem Ziel des interorganisationalen Geschäftsprozessmanagements und (Kappel et al. 2006) zur transparenten Transformation von Modellen zwischen verschiedenen Modellierungswerkzeugen. (Murzek, Kramler 2007) nutzen ein integriertes MetaModell, das alle Konzepte einer Sprache einer Domäne beinhaltet, um Szenarien wie die Transformation, Integration und Synchronisation in der Geschäftsprozessmodellierung zu verwirklichen (Kluth et al. 2008). Als Anwendungsbereiche, in denen die hier skizzierte semantische Geschäftsprozessmodellierung und -integration zum Einsatz kommen können, sind neben dem Benchmarking zum Beispiel auch ein „Process Model Mining“ und eine (halb-)automatische Referenzmodellkonstruktion denkbar (Ahlemann et al. 2006). Mittels „Process Model Mining“ ließen sich aus einer Menge von Prozessmodellen automatisch neue Erkenntnisse gewinnen. Bei der (halb-)automatischen Referenzmodellkonstruktion kann eine Prozessmodell-Datenbank eine sehr weitreichende Hilfe sein, indem auf Basis der mittels einer Datenbank dokumentierten, empirischen Fälle automatisch Vorschläge für Referenzmodellstrukturen generiert werden. Weiterhin kann bspw. automatisiert geprüft werden, ob die in den Prozessmodellen beschriebenen Geschäftsprozesse bestimmte regulatorische (gesetzliche) Anforderungen, Richtlinien oder Standards verletzten (Compliance Management). Es ist hierbei jedoch zu beachten, dass der Aufwand zur Erweiterung von Prozessmodellen durch Meta-Modelle, Ontologien sowie Prozesskennzahlen und eine Transformation der Modelle und Ontologien in ausführbare Prozesse (z.B. Semantic Webservices) vergleichsweise hoch sein kann und daher ggf. in keinem angemessenen Verhältnis zum entsprechenden Nutzen eines semantischen GPM stehen kann. Die weitere Forschung in diesem Bereich wird sich daher auch mit Wirtschaftlichkeitsfragen zur Anwendung der semantischen Geschäftsprozessmodellierung und der Geschäftsprozessintergration beschäftigen müssen (vgl. hierzu auch Thomas, Fellmann, 2009, Ahlemann et. al 2006, Teuteberg et al. 2009, Heinrich et al. 2008).

Umweltwirkung in betrieblichen Informationssystemen

255

9.3 Umweltwirkung in betrieblichen Informationssystemen Umweltinformationssysteme werden heute meist parallel und unabhängig von den betrieblichen Informationssystemen eines Unternehmens, insb. den ERPSystemen, betrieben. Dies führt dazu, dass Informationen in Umweltinformationssystemen eher deskriptiver Natur sind und nur selten zur Absicherung von unternehmerischen Entscheidungen herangezogen werden. So werden Werkzeuge wie Umberto eingesetzt, um Produktionsprozesse zu modellieren und evtl. Optimierungspotenziale z.B. im Hinblick auf die Reduzierung ungewünschter Nebenprodukte zu identifizieren. Eine automatische Berücksichtigung der Ergebnisse oder die Einbeziehung von Informationen aus anderen Quellen (z.B. Lieferanten, Umweltdatenbanken) in betriebliche Entscheidungen erfolgt aufgrund der fehlenden Integration nicht. Im Folgenden wird zunächst der Stand der Wissenschaft und Praxis zur Ermittlung des Carbon Footprints von Produkten dargestellt. Es folgt ein Überblick zum Stand der Forschung zur EMIS/ERP-Integration.

9.3.1 Carbon Footprint Der in der öffentlichen Diskussion häufig verwendete Begriff Carbon Footprint erfreut sich auch in der Wissenschaft einer lebendigen Diskussion (Wiedmann, Minx 2008). Je nach Autor umfasst der Carbon Footprint eines Produktes oder eines Unternehmens entweder sämtliche Treibhausgase oder ausschließlich die Kohlendioxid-Emissionen (in den Fallstudien wird der ersten Interpretation gefolgt). Einig sind sich Wissenschaftler (siehe bspw. Wiedmann, Minx 2008), dass der Carbon Footprint sowohl direkte (eigene Wertschöpfung) als auch indirekte (Energieversorgung und Vorstufen der Supply Chain) Emissionen umfassen sollte. Die Ermittlung des Carbon Footprints kann aus zwei Richtungen erfolgen – entweder anhand einer detaillierten Prozessanalyse (bottom-up) oder einer InputOutput-Analyse (top-down). Prozessanalysen dienen insb. der Ermittlung der Emissionen von Produkten von ihrer Entstehung bis zur Entsorgung. Aus Komplexitätsgründen beschränken sich diese Analysen ausschließlich auf die direkten Emissionen der Wertschöpfung eines Unternehmens (sog. Scope 1-Emissionen) und ggf. den Energieverbrauch (Scope 2). Während dieser Ansatz also eine detaillierte Betrachtung auf Produktebene zulässt, liegt die Schwierigkeit in der angemessenen Wahl der Systemgrenzen (Matthews et al. 2008). Vor dem Hintergrund, dass die Scope 1 und Scope 2-Emissionen im Durchschnitt über alle Industrien nur etwa 25% der Gesamtemissionen ausmachen, ist eine Berücksichtigung der übrigen Emissionen der Supply Chain (Scope 3), also von Lieferanten und Kunden, von großer Bedeutung.

256

Ausblick

Hier liegt die Stärke der Environmental Input-Output-Analyse (Wiedmann et al. 2006), die auf ökonomischen IO-Tabellen (einem Abbild sämtlicher ökonomischen Aktivitäten einer Volkswirtschaft) aufsetzt. Zugrunde liegt diesem Ansatz die Annahme, dass Geldströme eine Abschätzung der Umweltwirkung zulassen. Die EIO-Analyse ermöglicht eine robuste Abschätzung des Carbon Footprints von Industriezweigen und -ländern, während eine Bewertung auf Produktebene nicht möglich ist. Aktuell wird in der Wissenschaft die Verbindung von top-down- und bottomup-Ansätzen unter dem Namen Hybrid-EIO-LCA diskutiert (Heijungs et al. 2006). Parallel dazu werden in der Praxis erste Standardisierungsversuche (z.B. PAS 2050) unternommen. Die Etablierung eines allgemeinen anerkannten Verfahrens, das verursachungsgemäß die Treibhausgasemissionen vollständig und ohne Mehrfachzählungen auf Produkt-/Unternehmensebene ermittelt, wird – falls überhaupt erreichbar – noch viele Jahre in Anspruch nehmen, so dass Zwischenlösungen zwingend erforderlich sind.

9.3.2 Stand der EMIS- und ERP-Integration Bereits Anfang der 1990er Jahre wurde das Potenzial einer Integration zwischen Umweltinformationssystemen und betrieblichen Informationssystemen von mehreren Wissenschaftlern erkannt (Rautenstrauch 1997). Wie in Kap. 5 erwähnt konzentrieren sich die entwickelten Konzepte auf die Integration von Produktionsplanungs- und Steuerungs- sowie Stoffstrommanagementsystemen. Eine Reihe von Forschungsprojekten wurde seit Mitte der 1990er Jahre zu dem Themenkomplex durchgeführt (u.a. Krcmar et al. 2000, Bullinger et al. 2000, Lang et al. 2004, Abele et al. 2007). Im Ergebnis zeigen diese Projekte, dass eine Integration der Umweltwirkung in ERP-Systeme möglich ist. Die entwickelten Referenzarchitekturen und Konzepte sind jedoch mit Ausnahme einzelner Pilotprojekte bisher in der Praxis nicht umgesetzt bzw. von Softwareherstellern nicht aufgegriffen worden. Die Gründe dafür sind vielschichtig – zwei Aspekte sind allerdings von besonderer Bedeutung: Einerseits besteht aus Sicht der Unternehmen häufig (noch) nicht die Notwendigkeit, umweltrelevante Informationen in der Entscheidungsfindung zu berücksichtigen bzw. ggü. Kunden zu kommunizieren. Andererseits reduzieren die durch die Forschungsprojekte vorgeschlagenen Lösungskonzepte den Aufwand zur Ermittlung der Umweltwirkung kaum. Denn die dafür erforderliche Bewertung der von anderen Herstellern bezogenen Vorprodukte und der eigenen Produktionsprozesse ist mit manuellem Aufwand verbunden. Auf der einen Seite werden zukünftige regulative Anforderungen (z.B. die mögliche Ausweitung des Emissionsrechtehandels auf weitere Industrien oder dessen Überführung in eine allgemeine CO2-Besteuerung) und das steigende Umweltbewußtsein der Endverbraucher den Druck auf Unternehmen erhöhen, um-

Literatur

257

weltrelevante Informationen zu ermitteln, zu berücksichtigen und anderen Anspruchsgruppen zur Verfügung zu stellen. Aus wissenschaftlicher Sicht geht es auf der anderen Seite darum, Verfahren zu entwickeln, die die Ermittlung der Umweltwirkung mit geringerem manuellem Aufwand als bisher erlauben. Dabei besteht die wesentliche Herausforderung darin, existierende Daten und Erkenntnisse zur Umweltwirkung von Materialien aus externen Quellen (z.B. LCADatenbanken) soweit möglich zu übernehmen. D.h. wenn ein Material bereits in einer LCA-Datenbank beschrieben wurde, so ist es wünschenswert, die dortigen Daten automatisiert bei der Ermittlung des Produktes zu berücksichtigen. Dies ist meist jedoch nicht möglich, da kein einheitliches Vokabular über Systemgrenzen hinweg definiert ist. Man spricht in diesem Zusammenhang von einer sog. semantischen Lücke (Funk et al. 2009). Die Überwindung der semantischen Lücke ist Voraussetzung für eine weitergehende Automatisierung der Bestimmung der produktorientierten Umweltwirkung. Fortschritte sind in diesem Thema durch die Übertragung von Methoden und Konzepten aus anderen Feldern der Informatik und Wirtschaftsinformatik (z.B. Ontologien, Fuzzy Matching, Textanalyse, Modellierung) zu erwarten. Gelingt eine weitergehende Automatisierung im obigen Sinne, sind verschiedene Anwendungsszenarien in ERP-Systemen denkbar; drei Beispiele: (i) Bereits in der Designphase könnten dann Produktvarianten im Hinblick auf ihre erwartete Umweltwirkung beurteilt werden. (ii) Die Bewertung von Lieferantenbeziehungen bspw. nach Preisvorteilen, Qualität und Zuverlässigkeit könnte um Umweltaspekte ergänzt werden. (iii) Im Rahmen des Risikomanagements könnten die Auswirkungen möglicher Gesetzesänderungen (CO2-Steuer) auf das Ergebnis eines Unternehmens untersucht werden. Bis dies möglich sein wird, sind noch eine Reihe von Fragen zu beantworten – sicher ist, dass die Methoden und Technologien der Geschäftsprozessintegration dabei eine wichtige Rolle spielen werden.

9.4 Literatur Abele E, Anderl R, Birkhofer H, Rüttinger B (Hrsg) (2007) EcoDesign: Von der Theorie in die Praxis. Springer, Berlin, Heidelberg Ahlemann F, Teuteberg F, Brune G (2006) Ontologie-basierte Attributierung von Informationsmodellen: Grundlagen und Anwendungsgebiete. ISPRI-Arbeitsbericht 01/2006, Universität Osnabrück Arroyo S, Cimpian E, Domingue J, Feier C, Fensel D, König-Ries B, Lausen H, Polleres A, Stollberg M (2005) Web Service Modeling Ontology Primer: W3C Member Submission 3 June 2005. DERI, Innsbruck. http://www.w3.org/Submission/2005/SUBM-WSMO-primer20050603/. Abruf 11.02.2010 Bullinger HJ, Eversheim W, Haasis HD, Klocke F (Hrsg) (2000) Auftragsabwicklung optimieren nach Umwelt- und Kostenzielen. OPUS – Organisationsmodelle und Informationssysteme für einen produktionsintegrierten Umweltschutz. Springer, Berlin

258

Ausblick

Cabral L, Domingue J, Motta E, Payne TR, Hakimpour F (2004) Approaches to Semantic Web Services: an Overview and Comparisons. In: Bussler C, Davies J, Fensel D, Studer R (Hrsg) The Semantic Web: Research and Applications: Proceedings of the First European Semantic Web Symposium, ESWS 2004, Heraklion, Crete, Greece, May 10-12, 2004. Springer, Berlin, S 225-239 Cardoso J, Sheth AP (2005) Introduction to Semantic Web Services and Web Process Composition. In: Cardoso J, Sheth AP (Hrsg) Semantic Web Services and Web Process Composition: First International Workshop, SWSWPC 2004, San Diego, CA, USA, July 6, 2005. LNCS 3387. Springer, Berlin, Heidelberg, S 1-13 Celino I, de Medeiros AKA, Zeissler G, Oppitz M, Facca FM, Zoeller S (2007) Semantic Business Process Analysis. In: Hepp M, Hinkelmann K, Karagiannis D, Klein R, Stojanovic N (Hrsg) Proceedings of the Workshop on Semantic Business Process and Product Lifecycle Management (SBPM 2007) in conjunction with the 3rd European Semantic Web Conference (ESWC 2007), CEUR Workshop Proceedings, 251, 2007. S 44-47 Ehrig M, Koschmider A, Oberweis A (2007) Measuring Similarity between Semantic Business Process Models. In: Roddick JF, Hinze A (Hrsg) Proceedings of the Fourth Asia-Pacific Conference on Conceptual Modelling (APCCM 2007), Ballarat, Australia, January 30February 2, 2007. Australian Computer Society, S 71-80 Funk B, Möller A, Niemeyer P (2009) A reference architecture for the integration of EMIS and ERP-systems. In: Fischer S, Maehle E, Reischuk R (Hrsg) Proceedings of Informatik 2009 – Im Fokus das Leben. LNI 154. Köllen, Bonn, S 3393-3401 Heijungs R, de Koning A, Suh S, Huppes G (2006) Toward an Information Tool for Integrated Product Policy: Requirements for Data and Computation. Journal of Industrial Ecology 3:147-158 Heinrich B, Bewernik MA, Henneberger M, Krammer A, Lautenbacher F (2008) SEMPA – Ein Ansatz des Semantischen Prozessmanagements zur Planung von Prozessmodellen. Wirtschaftsinformatik 6:445-460 Hepp M, Roman D (2007) An Ontology Framework for Semantic Business Process Management. In: Oberweis A, Weinhardt C, Gimpel H, Koschmider A, Pankratius V, Schmizler B (Hrsg) eOrganisation: Service-, Prozess, Market-Engineering, 8. Internationale Tagung Wirtschaftsinformatik, Band 1. Universitätsverlag Karlsruhe, Karlsruhe, S 423-440 Hepp M, Leymann F, Domingue J, Wahler A, Fensel D (2005) Semantic Business Process Management: A Vision Towards Using Semantic Web Services for Business Process Management. In: Lau FCM, Lei H, Meng X, Wang M (Hrsg) 2005 IEEE International Conference on e-Business Engineering (ICEBE 2005), 18-21 October 2005, Beijing, China.. IEEE Computer Society, Los Alamitos, S 535-540 Höfferer P (2009) Achieving Business Process Model Interoperability Using Metamodels and Ontologies. In: Österle H, Schelp J, Winter R (Hrsg) Proceedings of the Fifteenth European Conference on Information Systems, St. Gallen, Switzerland, June 7-9 2007, S 1620-1631 Hoheisel A, Dollmann T, Fellmann M (2009) Überführung von EPK-Modellen in ausführbare Grid- und Cloud-Prozesse. In: Nüttgens M, Rump FJ, Mendling J, Gehrke N (Hrsg) 8. Workshop der Gesellschaft für Informatik e.V. (GI) und Treffen ihres Arbeitskreises „Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten (WI-EPK)“, Berlin, 26.-27. November 2009. GI, Bonn, S 178-194 Kappel G, Kapsammer E, Kargl H, Kramler G, Reiter T, Retschitzegger W, Schwinger W, Wimmer M (2006) On Models and Ontologies – A Semantic Infrastructure Supporting Model Integration. In: Mayr HC, Breu R (Hrsg) Modellierung 2006, 22.-24.03.2006, Innsbruck, Tirol, Austria. Proceedings. LNI 82. Köllen, Bonn, S 11-27 Kluth M, Ahlemann F, Teuteberg F (2008) SEMAT – Ein Werkzeug zur ontologiebasierten Analyse und zum Vergleich von Prozessmodellen. In: Loos P, Nüttgens M, Turowski K, Werth D (Hrsg) Modellierung betrieblicher Informationssysteme (MobIS 2008), Modellierung zwischen SOA und Compliance Management, 27.-28. November 2008, Saarbrücken. LNI P-141. Köllen, Bonn, S 128-148

Literatur

259

Krcmar H, Dold G, Fischer H, Strobel M, Seifert E (2000) Informationssysteme für das Umweltmanagement – Das Referenzmodell ECO-Integral. Oldenbourg, München Krimmel M, Orb J (2009) SAP NetWeaver Process Integration. SAP Press, Bonn Lang C, Steinfeldt M, Loew T, Beucker S, Heubach D, Keil M (2004) Konzepte zur Einführung und Anwendung von Umweltcontrollinginstrumenten in Unternehmen, Endbericht des Forschungsprojekts INTUS. http://elib.uni-stuttgart.de/opus/volltexte/2004/1907/. Abruf 12.02.2010 Martin D, Burstein M, Lassila O, Paolucci M, Payne T, McIlraith SA (2004) Describing Web Services using OWL-S and WSDL. http://www.daml.org/services/owl-s/1.1/owl-s-wsdl.html. Abruf 12.02.2010 Matthews HS, Hendrickson C, Weber C (2008) The Importance of Carbon Footprint Estimation Boundaries. Environmental Science & Technology 16:5839-5842 McGuinness DL, van Harmelen F (2004) OWL Web Ontology Language Overview. http://www.w3.org/TR/owl-features/. Abruf 12.02.2010 Murzek M, Kramler G (2007) The Model Morphing Approach – Horizontal Transformations between Business Process Models. In: Nummenmaa J, Söderström E (Hrsg) Proceedings of the 6th International Conference on Perspectives in Business Information Research – BIR 2007. Department of Computer Sciences, University of Tampere, Tampere, Finnland, S 88-103 Nicolescu V, Funk B, Niemeyer P, Heiler M, Wittges H, Morandell T, Visintin F, Kleine Stegemann B, Kienegger H (2009) Praxishandbuch SAP NetWeaver PI – Entwicklung. SAP Press, Bonn Object Management Group (2009) Business Process Modeling Notation (BPMN) – Version 1.2. http://www.omg.org/spec/BPMN/1.2/. Abruf 20.09.2009 Rautenstrauch C (1997) Fachkonzept für ein integriertes Produktions-, Recyclingplanungs undsteuerungssystem. de Gruyter, Berlin. Teuteberg F, Kluth M, Ahlemann F, Smolnik S (2009) Semantic Benchmarking of Process Models – An Ontology-Based Approach. In: Proceedings of the 30th International Conference on Information Systems (ICIS), December 15-18, 2009, Phoenix, Arizona, USA. Thomas O, Fellmann M (2007) Semantic Business Process Management: Ontology-Based Process Modeling Using Event-Driven Process Chains. International Journal of Interoperability in Business Information Systems 1:29-44 Thomas O, Fellmann M (2009) Semantic Process Modeling – Design and Implementation of an Ontology-Based Representation of Business Processes. In: Business & Information Systems Engineering 6. – Dt. Übersetzung in: Wirtschaftsinformatik 6:506-518, u. d. T.: Semantische Prozessmodellierung – Konzeption und informationstechnische Unterstützung einer ontologiebasierten Repräsentation von Geschäftsprozessen Vanderhaeghen D, Zang S, Scheer AW (2005) Interorganisationales Geschäftsprozessmanagement durch Modelltransformation. Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 182, Saarbrücken. http://www.econbiz.de/archiv/sb/usb/iwi/geschaeftsprozessmanagement_modelltransformatio n.pdf. Abruf 12.02.2010 Wiedmann T, Minx J (2008) A Definition of ‘Carbon Footprint’. In: Pertsova CC (Hrsg) Ecological Economics Research Trends. Nova Science, Hauppauge, S 1-11 Wiedmann T, Minx J, Barrett J, Wackernagel M (2006) Allocating ecological footprints to final consumption categories with input-output analysis. Ecological Economics 1:28-48

Stichwortverzeichnis A ABAP-Proxy 137 ABAP-Workbench 152 Abstraktes Interface 219 Abstraktes Service-Interface 158 Adapter Engine 91 ARIS 30, 73 ARIS Business Architect 74 ARIS for NetWeaver 74 ARIS Value Engineering 76 Asynchrone Kommunikation 231 Asynchrone Schnittstelle 95

B Benchmarking 10 Block 100, 174 Bottom-up-Ansatz 19 BPEL4People 99 Business Component 239 Business Intelligence 69 Business Object 201, 202 Business Object Builder 66 Business Process Engine 91 Business Process Execution Language 12, 29, 37, 92, 195 Business Process Modeling Language 29 Business Process Modeling Notation 36 Business Reengineering 11 Business System 117, 238 Business Task Management 59 Business Workflow Explorer 66 Business Workplace 66 Businesskomponente 240 Business-System 90

C Carbon Footprint 107, 108, 113, 121, 126 Condition Variable 227 Container Operation 100, 175, 177 Containerelement 226, 232 Control 101

D Data Type 95, 119, 120, 121, 133 Datenkonflikt 88 Datenstruktur 154, 200 Designobjekt 94, 199

E Eclipse Web Tool Platform 190 EMIS 108, 195, 197 Empfängerkanal 130, 131 Enterprise Services Builder 93, 94

Enterprise Services Repository 90, 198 Entwicklungsobjekt 200 EPK 11, 29, 217 Erweiterte ereignisorientierte Prozesskette 31 Exception 229, 231 Extended Notification 78 Externes Interface 218

F Fallstudie 105 Fork 101, 173 Funktionsbaustein 200, 205, 207, 209, 219 Funktionsgruppe 152, 206, 207

G Geschäftprozessmanagement 7 Geschäftsprozessmodellierung 7 Grundsätze ordnungsgemäßer Prozessmodellierung 27 Guided Procedures 61

I Import von WSDL-Dateien 157 Import von RFC-Bausteinen 157 Inbound Interface 95 Integration Builder 182 Integration Engine 91 Integration Server 91 Integrationsplattform 88 Integrationsprozess 169, 197, 206, 225, 231, 243 Integrationsszenario 218 Interface Determination 102, 136

J Java-Mapping 167

K Kommunikationsart 242 Kommunikationskanal 130, 131, 186, 189, 238, 241 Konfiguration 129, 237 Konfigurationsobjekt 130 Konfigurationsszenario 130, 131, 183, 237, 238, 240 Kontrollflusskante 31

L Life Cycle Assessment 106, 196 Loop 101

M Mail 200 Mandant 90, 117

262

Stichwortverzeichnis

Mapping 97 Mapping-Editor 127 Mapping-Programm 129 Materialstamm 196 Message Mapping 119, 125, 129, 165, 221 Message Type 95, 119, 123, 125 Methodenbezogener Aspekt 25 Methodik 26 Microsoft BizTalk Server 79 Microsoft Dynamics 81 Microsoft Sharepoint 80 Modellbezogener Aspekt 25 Monitoring 94, 141

N Nachrichtenstrecke 94, 136, 242, 244, 245 Nachrichtenverarbeitung 135, 141 Namensraum 94, 118, 150, 199, 219

O Ökobilanz 106 Operation Mapping 95, 119, 129, 164, 220 Organisationsbezogener Aspekt 25 Outbound Interface 95 Outside-In-Ansatz 146 Outside-In-Modell 114

P Plan-Do-Act-Check-Zyklus 15 Process Architecture Model 75 Process Configuration Model 75 Process Execution Model 76 Programmiermodell 108 Proxy 137 Proxy-Generierung 124 Prozesskennzahl 10 Prozesswegweiser 31

Q Qualitätskriterien 28 Qualitätsmanagement 10

R Receive Step 99, 171 Receiver Agreement 102, 136 Receiver Determination 102, 136 Receiver Determination Step 100 Reifegradmodell 16 Remote Function Call 97 RFC-Funktionsbausteine 151, 157 Rollen 68 Runtime Workbench 103

S SAP Business Workflow 60, 105 SAP MAPI 78 SAP NetWeaver 58 SAP Process Integration 87

SAP Solution Manager 76 SAP WebFlow 71 SAP Workflow 58 SAP-WAPI 78 Schemakonflikt 88 Send Step 100, 174, 176 Sender Agreement 102, 135 Senderkanal 130, 131 Service Interface 95, 119, 120, 124, 134, 219, 222 Service Registry 93 SOAP 40, 114 Softwarekomponente 90, 116, 198 Softwarekomponentenversion 91, 94, 149, 218, 221, 225 Softwareprodukt 90, 116 Step Type 99 Step Types 65 Steps 62 Switch 100 Switch Block 227, 228 Sync/Async-Bridge 171 Synchrone Schnittstelle 95 System Landscape Directory 116, 149, 198 Systemlandschaft 196

T Technisches System 117 Technologiebezogener Aspekt 25 Top-down-Ansatz 18 Transformation 173, 175, 177, 228, 234 Transformation Step 100, 172 Transportaufträge 152 Treibhauspotenzial 107

U UDDI 93 Umweltinformationssystem Siehe EMIS Umweltwirkung 105 Unified Modeling Language 28 Universal Description, Discovery and Integration 43 User Decision 100

V Verknüpfungsoperator 31 Versionierung 110 Vorkette 196

W Wait 101 Web Service Description Language 41 Webservice 38, 114, 132 Webservice-Client 139 Wf-XML 71

Stichwortverzeichnis Workflow 58, 195, 197, 210 Workflow Builder 66, 213 Workflow Definition 63 Workflow Design 65 Workflow Engine 58 Workflow Management System 58 Workflow Runtime 66 Workflow Wizard Explorer 66 Workflowdefinition 213 Workflow-Instanzen 99 Workflow-Muster 201, 210, 212 Workflow-Standardaufgabe 201, 210, 211 Workflow-System 11

Workitem 65 Workitem-Manager 65 Worklist 60 WSDL 132, 239 WSDL Standard 123 WSDL-Dokument 97

X XML Process Definition Language 29 XML-Nachricht 92 XSLT 223 XSLT Mapping 98

263

Geschäftsprozessintegration mit SAP: Fallstudien zur Steuerung von Wertschöpfungsprozessen entlang der Supply Chain

Steuerung von Supply Chains: Strategien - Methoden - Beispiele

Optimierungsverfahren zur adaptiven Steuerung von Fahrzeugantrieben

Wertorientiertes Supply Chain Management: Strategien zur Mehrung

Entlang der tödlichen Klippen

Supply Chain and Finance

Supply Chain Project Management

Supply Chain Optimization

Supply Chain Logistics Management

Supply chain management

Supply Chain Engineering

Strategic Supply Chain Management

Supply Chain Management

Supply Chain Logistics Management

Greening the Supply Chain

Supply Chain Management

Food Supply Chain Management

Supply Chain Management

Supply Chain Scheduling

Dispositionsparameter in der Produktionsplanung mit SAP

Mit der Ölwaffe zur Weltmacht

Testautomation mit SAP®: SAP Software erfolgreich einführen

Mit der Ölwaffe zur Weltmacht

Mit der Ölwaffe zur Weltmacht

Mit der Ölwaffe zur Weltmacht

Die Eignung von New Public Management zur Steuerung offentlicher Kulturbetriebe

Supply Chain: Theory and Applications

Logistics and Supply Chain Integration

Global Integrated Supply Chain Systems

Steuerung im Bildungswesen: Zur Zusammenarbeit von Ministerien, Schulaufsicht und Schulleitungen

Geschäftsprozessintegration mit SAP: Fallstudien zur Steuerung von Wertschöpfungsprozessen entlang der Supply Chain

Steuerung von Supply Chains: Strategien - Methoden - Beispiele

Optimierungsverfahren zur adaptiven Steuerung von Fahrzeugantrieben

Wertorientiertes Supply Chain Management: Strategien zur Mehrung

Entlang der tödlichen Klippen

Supply Chain and Finance

Supply Chain Project Management

Supply Chain Optimization

Supply Chain Logistics Management

Supply chain management

Supply Chain Engineering

Strategic Supply Chain Management

Supply Chain Management

Supply Chain Logistics Management

Greening the Supply Chain

Supply Chain Management

Food Supply Chain Management

Supply Chain Management

Supply Chain Scheduling

Dispositionsparameter in der Produktionsplanung mit SAP

Mit der Ölwaffe zur Weltmacht

Testautomation mit SAP®: SAP Software erfolgreich einführen

Mit der Ölwaffe zur Weltmacht

Mit der Ölwaffe zur Weltmacht

Mit der Ölwaffe zur Weltmacht

Die Eignung von New Public Management zur Steuerung offentlicher Kulturbetriebe

Supply Chain: Theory and Applications

Logistics and Supply Chain Integration

Global Integrated Supply Chain Systems

Steuerung im Bildungswesen: Zur Zusammenarbeit von Ministerien, Schulaufsicht und Schulleitungen

Recommend Documents