Flexible Automatisierung von Geschäftsprozessen mit BPMN und Web Services

Transkript

1 Flexible Automatisierung von Geschäftsprozessen mit BPMN und Web Services Wolfgang Bauhardt, Jochen Göpfert Kurzfassung Der Beitrag zeigt Möglichkeiten der Modellierung von Geschäftprozessen mit der Business Process Modelling Notation (BPMN), Version 2.0 Beta. Die graphische Darstellung schließt eine präzise Definition der Prozesse und des Nachrichtenflusses zwischen den Prozessen ein. Die Prozessbeschreibung im XML-Format muss nach dem BPMN-Standard in Form einer Menge von XML Schemen gültig sein. Eine Process Engine interpretiert die Prozessbeschreibung und führt sie aus. Dafür benötigt sie einen Prozess-Kontext, bestehend aus diversen Geschäftsdokumenten oder ggf. auch einzelnen Daten. Besonders günstig gestaltet sich die Prozess-Automatisierung, wenn die Prozess-Steuerung auf vorhandene Komponenten, meist in Gestalt von Web Services, zurückgreifen kann. Im Beispiel dient der vereinfachte Prozess der Bearbeitung eines Kreditantrags. Es stehen die beiden Web Services Signieren eines Dokuments und Verifikation einer Signatur zur Verfügung. Die Flexibilität kommt daher, dass Prozessänderungen lediglich eine Änderung der Prozessbeschreibung erfordern, die Process Engine ihre ausgezeichneten Dienste aber ohne Programmänderungen jederzeit leistet. 1 Modellierung von Geschäftsprozessen mit der Business Process Modelling Notation (BPMN) 1.1 Entwicklungsstand, Vorzüge und Nachteile von BPMN Die Business Process Modelling Notation BPMN 2.0 steht kurz vor ihrer Veröffentlichung. Gegenüber der Version 1.2 gibt es eine entscheidende Weiterentwicklung: die präzise Beschreibung der graphischen Elemente und der Symbole mittels XML Schema. Dies ermöglicht die Entwicklung von BPMN Engines und damit die native Ausführung von BPMN. Als erste Firma hat SAP eine native BPMN Engine vorgestellt (siehe [1] und [2]). Die Business Process Engine, die BPMN interpretieren und ausführen kann, ist Teil des SAP NetWeaver. Dieser neue Baustein hat die Bezeichnung NetWeaver BPM erhalten. Die Fähigkeit, BPMN direct ausführen zu können, ist ein unschätzbarer Vorteil, verglichen mit dem Mapping von BPMN auf WS-BPEL 2.0, da nicht alle Konstrukte von BPMN 2.0 auf WS- BPEL 2.0 abgebildet werden können. 1.2 Kurzbeschreibung der Collaboration Kreditantrag stellen und bearbeiten Das BPMN-Diagramm zeigt eine sogenannte Kollaboration (collaboration), in diesem Fall zwischen einem (potenziellen) Kunden und einer Hypothekenbank. Es gibt also zwei Teilnehmer (participants) an dieser Zusammenarbeit. Die beiden Teilnehmer werden durch die beiden Pools (Potenzieller) Kunde und Hypothekenbank dargestellt. Zwischen den Pools werden Nachrichten (messages) in Form von Geschäftsdokumenten, im Beispiel Kreditantrag, Ablehnungsschreiben oder Kreditangebot versandt. Der Gesamtprozess besteht aus zwei Geschäftsprozessen. Der eine Prozess ist der Kundenprozess, der zweite Prozess ist der Bankenprozess. Der Kunde formuliert einen Kreditantrag durch Ausfüllen eines Web- Formulars als User Task. Das Formular wird automatisch durch einen Service Task signiert und zur Hypothekenbank gesendet (Send Task). Die Bank empfängt den Kreditantrag 10. Wissenschaftstage der Hochschule Lausitz (FH)

2 (Receive Task) und verifiziert die Signatur (User Task). Danach prüft die Bank den Antrag und entscheidet über den Antrag (beides User Tasks). Im Falle der Ablehnung erhält der Kunde einen entsprechenden Ablehnungsbescheid (Send Task), sonst wird ein Kreditangebot erarbeitet und an den Kunden gesendet (User Task und Send Task). Der Kundenprozess verzweigt an einem Event-based Gateway. Es wird derjenige Zweig verfolgt, dessen Catching Intermediate Message Event zuerst eintritt. Die beiden Zweige werden wieder vereinigt und der Kundenprozess wird beendet. Analog werden die beiden Zeige des Bankenprozesses zusammengeführt und der Prozess schließlich beendet. Abb 1: BPMN-Diagramm Kreditantrag stellen und bearbeiten, vereinfacht 10. Wissenschaftstage der Hochschule Lausitz (FH)

3 1.3 XML-Darstellung des Beispiel-Prozesses und seine Validierung Die XML-Darstellung einer Collaboration und der daran beteiligten Prozesse müssen nach BPMN20.xsd und Semantics.xsd gültig sein. <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns=" xmlns:xsd=" xmlns:di=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified" > <xsd:include schemalocation="semantic.xsd"/> <xsd:element name="definitions" type="tdefinitions"/> <xsd:complextype name="tdefinitions"> <xsd:sequence> <xsd:element ref="rootelement" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:id" use="optional"/> <xsd:attribute name="name" type="xsd:string"/> <xsd:attribute name="targetnamespace" type="xsd:anyuri" use="required"/> <xsd:attribute name="expressionlanguage" type="xsd:anyuri" use="optional" <xsd:attribute default=" name="typelanguage" type="xsd:anyuri" use="optional" default=" <xsd:anyattribute namespace="##other" processcontents="lax"/> </xsd:complextype> <xsd:element name="import" type="timport"/> </xsd:schema> Listing 1: Auszug aus BPMN20.xsd <xsd:element name="collaboration" type="tcollaboration" substitutiongroup="rootelement"/> <xsd:complextype name="tcollaboration"> <xsd:complexcontent> <xsd:extension base="trootelement"> <xsd:sequence> <xsd:element ref="participant" minoccurs="0" maxoccurs="unbounded"/> <xsd:element ref="messageflow" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:string"/> </xsd:extension> </xsd:complexcontent> </xsd:complextype> Listing 2: Auszug aus Semantics.xsd <?xml version="1.0" encoding="utf-8"?> <definitions targetnamespace="" xmlns=" xmlns:xsi=" xsi:schemalocation=" BPMN20.xsd"> <collaboration name="hypothekendarlehen" id="collaboration001" > <participant name="" id="participant001" processref="kunde" /> <participant name="" id="participant002" processref="hypothekenbank" /> 10. Wissenschaftstage der Hochschule Lausitz (FH)

4 </collaboration> <process name="hypothekendarlehenbeantragen" id="kunde" processtype="private"> <startevent name="startkundenprozess" id="startevent001" /> <endevent name="endkundenprozess" id="endevent001" /> <eventbasedgateway id="eventbasedgateway001" gatewaydirection="diverging" /> <exclusivegateway id="exclusivegateway001" gatewaydirection="converging" /> <usertask name="enterformulardata" id="usertask001" /> <servicetask name="signdocument" id="servicetask001" /> <sendtask name="versende Antrag auf Hypothekendarlehen" id="sendtask001" /> <receivetask name="empfangeablehnung" id="receivetask001" /> <receivetask name="empfangeangebot" id="receivetask002" /> <sequenceflow sourceref="startevent001" targetref="usertask001" id="sequenceflow001" /> <sequenceflow sourceref="usertask001" targetref="servicetask001" id="sequenceflow002" /> <sequenceflow sourceref="servicetask001" targetref="sendtask001" id="sequenceflow003" /> <sequenceflow sourceref="sendtask001" targetref="eventbasedgateway001" id="sequenceflow004" /> <sequenceflow sourceref="eventbasedgateway001" targetref="receivetask001" id="sequenceflow005" /> <sequenceflow sourceref="eventbasedgateway001" targetref="receivetask002" id="sequenceflow006" /> <sequenceflow sourceref="receivetask001" targetref="endevent001" id="sequenceflow007" /> <sequenceflow sourceref="receivetask002" targetref="endevent001" id="sequenceflow008" /> </process> <process name="darlehensantragentscheiden" id="hypothekenbank" processtype="private"> <startevent name="startbankprozess" id="startevent002" /> <endevent name="endbankprozess" id="endevent002" /> <receivetask name="empfangedarlehensantrag" id="receivetask003" /> <servicetask name="verifizieresignatur" id="servicetask002" /> <usertask name="pruefewerthaltigkeit" id="usertask002" /> <usertask name="entscheideueberantrag" id="usertask003" /> <exclusivegateway name="antrag positiv entscheiden?" gatewaydirection="diverging" id="exclusivegateway003" /> <usertask name="kreditangebot erarbeiten" id="usertask004" /> <sendtask name="versende Ablehnungsschreiben" id="sendtask002" /> <sendtask name="versende Angebot" id="sendtask003" /> <exclusivegateway gatewaydirection="converging" id="exclusivegateway004" /> <sequenceflow sourceref="startevent002" targetref="receivetask003" id="sequenceflow0011" /> </process> </definitions> Listing 3: Fragment aus Beschreibung des Beispielprozesses im XML-Format, vereinfacht 1.4 Der Prozess-Kontext am Beispiel Kreditantrag stellen und bearbeiten Der Prozess-Kontext besteht im Beispiel aus dem Kreditantrag oder genauer, dem Antrag auf ein Hypothekendarlehen. Für diesen Antrag existiert ein XML-Schema. <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="darlehensantrag"> <xs:complextype> <xs:sequence> <xs:element name="liste_darlehensnehmer" type="tliste_darlehensnehmer"/> <xs:element name="liste_darlehen" type="tliste_darlehen"/> <xs:element name="liste_beleihungsobjekte" type="tliste_beleihungsobjekte"/> <xs:element name="c_besonderheiten" type="tc_besonderheiten"/> <xs:element name="d_auszahlungsvoraussetzungen" type="td_auszahlungsvoraussetzungen"/> <xs:element name="e_weitere_darlehensbedingungen" type="te_weitere_darlehensbedingungen"/> <xs:element name="einzugsermaechtigung" type="teinzugsermaechtigung"/> <xs:element name="feststellung_des_wirtschaftlich_berechtigten" 10. Wissenschaftstage der Hochschule Lausitz (FH)

5 type="tfeststellung_des_wirtschaftlich_berechtigten"/> <xs:element name="unterschriften" type="tunterschriften"/> <xs:element name="zustimmung_der_ehegatten" type="tzustimmung_der_ehegatten"/> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> Listing 4: Auszug aus XML-Schema für Darlehensantrag 2 Web Service zum Signieren und Verifizieren von Dokumenten 2.1 Motivation Es gibt zwei typische Aktionen innerhalb einer Geschäftsprozessanwendung: (1) Die Anwendung signiert ein Dokument. (2) Die Anwendung verifiziert die Unterschrift einer dritten Instanz, hier z.b. des Bankkunden. Das Ziel ist die Entwicklung einer Softwarekomponente mit dieser Funktionalität, die unternehmensweit zur Verfügung steht und mit geringen Anpassungskosten in beliebige Geschäftsprozessanwendungen integrierbar ist. Als Softwarekomponente bietet sich ein Web-Service an, da: (1) neben einer ohnehin vorhandenen unternehmensinternen Web-Infrastruktur keine zusätzliche Infrastruktur notwendig ist, (2) ein Web-Service eine maschinenlesbare Dienstbeschreibung hat, die Interoperabilität unterstützt insbesondere die einfache Nutzung des Dienstes von unterschiedlichen Business Process Engines und (3) ein Web-Service lose gekoppelt werden kann insbesondere die Funktionalität des Web-Service reimplementiert werden kann, ohne Reimplementierung der Geschäftsprozessanwendung. Vorstellbar ist auch dass dieser Dienst in einem unternehmensinternen Service-Repository abgelegt wird, aus dem sich verschiedene Geschäftsprozessanwendungen bei Bedarf bedienen können. Neben den funktionalen Anforderungen sind folgende minimale Sicherheitsanforderungen sinnvoll: (1) Authentizität der Dienstnutzer. (2) Integrität der Nachrichten: Dokument und Dokumentsignatur dürfen nicht auf dem Übertragungsweg durch Angreifer veränderbar sein. Realisieren lassen sich die Sicherheitsanforderungen durch Anwendung der Werkzeuge des WS-Security-Standards, vgl: [3, 4]. Hier beschränken wir uns auf die funktionalen Anforderungen. Für den vorliegenden Geschäftsprozess benötigen wir also für die Service-Tasks SignDocument und verifizieresignatur einen Web-Service, der von der Business Process Engine NetWeaver BPM genutzt werden kann. 10. Wissenschaftstage der Hochschule Lausitz (FH)

6 2.2 Dienstbeschreibung Eine maschinenlesbare Dienstbeschreibung soll folgende zwei Anforderungen an das Design unseres Web-Service realisieren: (1) Der Web-Service ist aktionsorientiert, d.h. der Nachrichtenstil hat die Form eines Funktionsaufrufes. Ein Nachrichtenelement mit dem Funktionsnamen - z.b. Sign für das Signieren - enthält weitere Elemente, die die Argumente dieser Funktion repräsentieren. (2) Die Nachrichten, die Dienstnutzer und Dienst zum Signieren bzw. Verifizieren eines Dokuments austauschen, werden im Format SOAP über das Transport-Protokoll HTTP übertragen. Ein Dienstnutzer-Aufruf zum Signieren sieht beispielsweise so aus: POST /axis2/services/signaturservice Host: ebccmupad:8080 <?xml version='1.0' encoding='utf-8'?> <Envelope> <Body> <ns:sign xmlns:ns=" <ns:keyalias>wb1</ns:keyalias> <ns:keypass>wb1ks1</ns:keypass> <ns:data> JVBERi0xLjYNJeLjz9CjM IDAgb2JqDTw8L0xpbmVhm6ZQg DE2DQolJUVPRg0K </ns1:data> </ns:sign> </Body> </Envelope> Listing 5: SOAP-Nachricht In diesem Beispiel wird das zu signierende Dokument als data-element kodiert in Base64 übertragen. Alternativ ist das natürlich auch in binärer Form in einem Anhang außerhalb der SOAP-Hülle möglich. Das würde zwar die Nachrichtengröße verringern aber die Anpassungskosten beim Einbinden in eine Geschäftsprozessanwendung erhöhen, zumal Anhänge in einer leichtgewichtigen maschinenlesbaren Dienstbeschreibung nicht darstellbar sind. Das folgende WSDL-Fragment stellt einen Auszug aus einer maschinenlesbaren Dienstbeschreibung dar, die das geforderte Design realisiert: <xsd:element name="sign"> <xsd:complextype> <xsd:sequence> <xsd:element name="keyalias" type="xsd:string" /> <xsd:element name="keypass" type="xsd:string" /> <xsd:element name="data" type="xsd:base64binary" /> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="signature" type="xsd:base64binary" /> <wsdl:message name="signrequest"> <wsdl:part element="sign" /> </wsdl:message> <wsdl:message name="signresponse"> <wsdl:part element="signature" /> 10. Wissenschaftstage der Hochschule Lausitz (FH)

7 </wsdl:message> <wsdl:operation name="sign"> <wsdl:input message="signrequest" /> <wsdl:output message="signresponse" /> </wsdl:operation> <wsdl:operation name="verify"> </wsdl:operation> <soap:binding style="document" transport=" <wsdl:operation name="sign"> <soap:operation /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> </soap:binding> <wsdl:port > <soap:address location=" /> </wsdl:port> Listing 6: Auszug aus Service.wsdl Das port-element gibt eine URI für eine Instanz des Web-Service an, der die verlangte Funktionalität zur Verfügung stellt. 3 Referenzen [1] Volker Stiehl: Vermittler zwischen den Welten Business Process Management Notation Teil 3 In: Java Magazin , Software & Support Verlag GmbH 2009 [2] Volker Stiehl: Vermittler zwischen den Welten Business Process Management Notation - Teil 4 In: Java Magazin , Software & Support Verlag GmbH 2009 [3] OASIS Web Services Security (WSS) TC, [4] T. Frotscher, D. Wang, M. Teufel: Java Web Services mit Apache Axis2, entwickler.press, 2. Auflage, Zu den Autoren Dr. rer. nat. Wolfgang Bauhardt ist seit 1993 wissenschaftlicher Mitarbeiter an der Hochschule Lausitz (FH). Nach dem Studium der Mathematik war er von 1973 bis 1990 wiss. Assistent an der Sektion Mathematik der Friedrich-Schiller-Universität Jena. Er gehörte dort der Forschungsgruppe Funktionalanalysis an (Promotion 1977). Von 1990 bis 1993 arbeitete er als Systemberater bei der Dr. G. & K. Unternehmensberatung und Softwareentwicklung GmbH in Jena. Seine Publikationen behandeln Themen aus der Funktionalanalysis (Operatorenideale, s-zahlen) und der Mathematischen Physik (Integration von nichtlinearen Wellengleichungen). Dr. oec. habil. Jochen Göpfert ist Professor für Wirtschaftsinformatik und Business Software an der Hochschule Lausitz. Nach seinem Studium an der TU Chemnitz arbeitete er von 1972 bis 1978 als Programmierer, Systemanalytiker und Projektleiter am Institut für Automatisierung der Truppenführung in Dresden. Von 1978 bis 1990 war an der TU Chemnitz als Dozent für Wirtschaftsinformatik beschäftigt. Promotion (1978) und Habilitation (1991) mit Arbeiten zur Analyse, Planung und Steuerung von Produktionsprozessen. Von 1991 bis 2002 arbeitete er als Chefberater bei der Integrata AG in Frankfurt am Main, als Consulting-Leiter bei der Oracle Deutschland GmbH in Dresden und als Leiter des Anwendungsentwicklungszentrums der Deutschen Post AG in Dresden. Seine Publikationen behandeln Themen aus der Produktionsplanung und -steuerung, der Entwicklung von IT-Anwendungssystemen sowie der Modellierung und Steuerung von Geschäftsprozessen. 10. Wissenschaftstage der Hochschule Lausitz (FH)