Norm 220 Kommunikationsmodell

Transkript

1 1 Norm 220 Kommunikationsmodell 2 3 Release und Version Release 1, Version 1.0, vom 19. Juni Status Offizielle Norm 6 7 Editor Jörg Treiner, IDEAL Gruppe Autoren Markus Heussen, RheinLand Gruppe (markus.heussen@creditlife.net) Marc Pellmann, inubit AG (marc.pellmann@inubit.com) Sascha Klose, VHV Versicherung (sklose@vhv.de) Dr. Dieter Ackermann, VOLKSWOHL BUND (dieter.ackermann@volkswohl-bund.de) Dr. Thomas Kippenberg, Nürnberger (thomas.kippenberg@nuernberger.de) Dr. Torsten Schmale, inubit AG (ts@inubit.com) Jörg Treiner, IDEAL Gruppe (treiner@ideal-versicherung.de) Stefan Hauptmann, VDV Klaus Reimer GmbH (stefan.hauptmann@v-d-v.de) John Bodenstein, AssFiNET AG (john.bodenstein@assfinet.de) Sören Chittka, VOLKSWOHL BUND, (soeren.chittka@volkswohl-bund.de) Thomas Belting, RheinLand Gruppe, (thomas.belting@rheinland-versicherungen.de) Gegenstand der Norm Die Norm 220 definiert das grundsätzliche Kommunikationsmodell der BiPRO zwischen Service Provider und Service Consumer. Insbesondere die synchrone und asynchrone Kommunikation sind hier von zentraler Bedeutung Voraussetzung Norm 200, Release 1 Version Seite 1 von 6 -

2 Hinweis zur Veröffentlichung Die anliegend überreichte Norm ist urheberrechtlich für die BiPRO geschützt. Das Dokument wird Ihnen im Rahmen Ihrer Mitgliedschaft bei der BiPRO und damit als Mitglied dieses geschlossenen Empfängerkreises überlassen. Dementsprechend stellt die Überlassung an Sie keine Erstveröffentlichung der Norm dar. Zur Erstveröffentlichung gegenüber Dritten bleibt somit die BiPRO alleine berechtigt. Die Veröffentlichung erfolgt gemäß Norm100. Aufgrund der besonderen Wertigkeit der Normen für die Mitglieder sind wir gehalten, Verstöße gerichtlich zu ahnden Seite 2 von 6 -

3 38 Inhaltsverzeichnis Norm 220 Kommunikationsmodell... 1 Inhaltsverzeichnis... 3 Kommunikations- und Verarbeitungsmodell... 4 Verwendung des Statusobjekts Seite 3 von 6 -

4 44 Kommunikations- und Verarbeitungsmodell Das Kommunikations- und Verarbeitungsmodell beschreibt die prinzipiellen Aktivitäten auf Seiten des Service Consumers und des Service Providers, die im Rahmen der BiPRO von Bedeutung sind Der Service Consumer ist der Nachfrager eines Prozesses und eine Client-Anwendung. Dies kann z.b. das Verwaltungssystem eines Versicherungsmaklers sein. Der Service Provider ist der Anbieter eines Prozesses und eine Server-Anwendung. Dies kann z.b. ein Vertriebssystem eines Versicherungsunternehmens sein In diesem Abschnitt werden exemplarisch alle Aktivitäten zur Steuerung von Prozessen nach einer erfolgreichen Authentifizierung beschrieben. Die Authentifizierung selbst wird in der Norm 260 ausführlich behandelt Service Consumer 1. Feststellung der zu erfassenden Daten (WSDL- und XML Schema-Analyse) Interpretation der durch den Service Provider beschriebenen Individualitäten (XML Schema- und WS-Policy-Analyse) Mapping vorhandener Daten auf die zu erfassenden Standard-Objekte Generierung eines Eingabeformulars zur Visualisierung vorhandener bzw. zu erfassender Daten (optional) Prüfung der erfassten Daten auf XML Schema-Konformität und optional auf WS- Policy-Konformität Übertragung der Daten an den Service Provider mittels gesicherter Internetverbindung Analyse des Verarbeitungsergebnisses aufgrund des Status-Objektes Speicherung bzw. Visualisierung des Ergebnisses Service Provider 1. Entgegennahme der Daten über eine gesicherte Internet-Verbindung Prüfung der Berechtigung des Clients zur Ausführung der Funktion (gültige Session) - Seite 4 von 6 -

5 70 3. Prüfung der Daten gemäß individuellem XML Schema Optionale Prüfung der WS-Policy Optionale Anwendung weiterer Prüfregeln (Geschäftslogik) Durchführung der angeforderten Aktionen (z. B. Beitragsermittlung) Aufbereitung der Ergebnisdaten inkl. Status-Objekt Rückgabe der Daten über eine gesicherte Internet-Verbindung Einer Anfrage eines Service Consumers MUSS eine synchrone Antwort eines Service Providers folgen. Der Service Provider MUSS dem Consumer in der Antwort immer ein Status-Objekt zurückliefern. Dies gilt auch für den Statusservice (getstatus) selbst. Nur wenn aufgrund eines fatalen Fehlers keine Verarbeitung der eingehenden Daten erfolgen konnte, MUSS der Service Provider eine Fehlernachricht im SOAP-Fault (Bereich details) zurückliefern. 82 Hinweise zur Verarbeitung auf Provider-Seite: In der Serververarbeitung dienen die inhaltsbezogenen Policies zur zusätzlichen Validierung der eingehenden Nachrichten. Über die XML-Schema Validierung hinaus KANN auf die VU- individuellen erforderlichen Felder und die nicht relevanten Felder geprüft werden. 86 Hinweise zur Verarbeitung auf Consumer-Seite: Dem Consumer wird über die Policies mitgeteilt welche im XML-Schema als optional gekennzeichneten Datenfelder er für diesen Provider liefern muss bzw. welche nicht geliefert werden dürfen. Diese Informationen können schon innerhalb des GUI-Clients ausgewertet werden, um die entsprechenden Felder ein- bzw. auszublenden. Der jeweilige XPath der Policy KANN dabei als Identifier des Feldes betrachtet werden Wird der Client dynamisch (Generischer Client) aus dem Schema und den Policies erstellt, KANN bei jedem Feld, das aus der Hierarchie des XML Schema erstellt wird, noch einmal gegen den XPath der Policy geprüft werden, und in Abhängigkeit vom Ergebnis das jeweilige Feld mit in den Client aufzunehmen oder wegzulassen. 96 Konnte die Verarbeitung mit einem Ergebnis abgeschlossen werden, sendet der Service - Seite 5 von 6 -

6 Provider das Ergebnis an den Service Consumer, ansonsten erfolgt eine entsprechende Meldung (Fehler, Hinweis). In beiden Fällen ist der Prozess beendet und ein erneuter Request führt zu einem neuen Prozess mit eigener Prozess-ID Verwendung des Statusobjekts Ein vom Service Provider zurückgeliefertes Status-Objekt MUSS Informationen zum aktuellen Zustand des zuvor vom Service Consumer eingeleiteten Prozesses beeinhalten: Asynchroner Prozess: Die Information dass der Prozess mit der synchronen Antwort vom Provider nicht abgeschlossen wurde, sondern weitere Zeit beansprucht und damit asynchron zur Anfrage des Consumers weiterläuft. In diesem Fall wird zusätzlich eine ProcessID und ein Zeitstempel im Status-Objekt an den Consumer transportiert. Mittels dieser Informationen ist der Consumer in der Lage über den so genannten Statusservice (getstatus) zum angegebenen oder einem anderen Zeitpunkt beim Provider anzufragen, um das eigentliche Ergebnis des Prozesses abzuholen oder erneut signalisiert zu bekommen, dass das Ergebnis noch nicht vorliegt usw Fehlerfall: Informationen zu ggf. aufgetretenen fachlichen oder technischen Fehlern bei der Prozessdurchführung im Provider Der Statusservice getstatus(processid) MUSS als Antwort wie alle anderen Anfragen auch ein Status-Objekt zurückliefern. Dieses Status-Objekt MUSS sich inhaltlich auf den Prozess, der durch die Prozess ID eindeutig beim Service Provider bestimmt ist, beziehen Bei asynchronen Prozessen MUSS der Statusservice bis zum Erreichen des Prozessendes Information über den Zustand dieses Prozesses zurückliefern Wurde eine Anfrage vom Provider synchron verarbeitet und trat hierbei ein Fehler auf, so MUSS das Status-Objekt eine prozessabschliessende Fehlermeldung enthalten Traten bei der synchronen oder asynchronen Prozessabarbeitung im Provider mehrere Fehler auf, so MUSS das Status-Objekt den ersten aufgetretenen Fehler enthalten auch wenn in Folge weitere Fehler im Provider auftraten. - Seite 6 von 6 -