SOA-Fallbeispiel: LifeSensor - Die Gesundheitsakte. Matthias Bohlen. Organized by:

Transkript

1 Do 7.1a January 22 th -26 th, 2007, Munich/Germany SOA-Fallbeispiel: LifeSensor - Die Gesundheitsakte Matthias Bohlen Organized by: Lindlaustr. 2c, Troisdorf, Tel.: +49 (0) , Fax.: +49 (0)

2 SOA-Fallstudie: LifeSensor Die Gesundheitsakte OOP-Konferenz, München Matthias Bohlen / 25. Januar 2007 Überblick Telematik im Gesundheitswesen Was bietet LifeSensor? LifeSensor als SOA und EDA Architektur: Prozesse, s, Komponenten, Infrastruktur Integrations-Szenario: Kundenregistrierung Erfahrungen und Ausblick ICW AG LlifeSensor Fallstudie für die OOP

3 Telematik im Gesundheitswesen: Beispiel ICW AG LlifeSensor Fallstudie für die OOP LifeSensor kann mehr als das... Mobile Applikationen Telemonitoring Klinische Basisdaten Arzneimitteldokumentation Dokumentenaustausch Chron. Erkrankungen (LifeSensor-Assistenten): Diabetes, Brustkrebs, Asthma, Herzinsuffizienz Labordatenintegration Notfalldatensatz Integriertes Sicherheits-, Berechtigungs- und Rollenkonzept Präventionsmaßnahmen (LifeSensorAssistenten): Fitness, Ernährung, Mutter/Kind ICW AG LlifeSensor Fallstudie für die OOP

4 LifeSensor 4-Schichten SOA Geschäftsprozess (Makroprozess) Eine Schicht greift jeweils auf die nächstniedrigere zu. s (Ebene der Systeme) Geschäftslogik (Mikroprozesse) inter system intra system s (Komponenten-Ebene) ICW AG LlifeSensor Fallstudie für die OOP SOA und EDA: ideale Partner SOA: oriented architecture Aufruf von s, Übergabe von Parametern Call-Stack hält den Aufrufzustand Aufrufender kennt den aufgerufenen (zumindest dessen Schnittstelle) EDA: Event driven architecture Publizieren und Abonnieren von Ereignissen (publisher/subscriber) Äußerst lose Kopplung, kein Call-Stack Publisher kennt den/die Subscriber nicht EDA ermöglicht nachträgliches Einfügen von Prozessschritten, ohne dass das ereigniserzeugende System etwas darüber zu wissen braucht bei ICW als Ergänzung zu SOA eingesetzt, um größtmögliche Prozessflexibilität zu erreichen ICW AG LlifeSensor Fallstudie für die OOP

5 Ereignisse verursachen -Aufrufe : External system external event ESB : Event listener : Workflow internal event internal event enriched event Map event to system specific domain, enrich event with service response dm1 : Data mapper dm2 : Data mapper dm3 : Data mapper specific request specific response : 1 : 2 : 3 ICW AG LlifeSensor Fallstudie für die OOP LifeSensor: Intra-System s Browser Mobile Devices Medical Devices Primary System Kiosk System HTTPS ICW SDK ICW SDK LifeSensor External Medical s SOAP Health Record s External Medical Content Connector SOAP Workplace Codesystem LifeSensor system boundary Registration Authentication Authorization LifeSensor service External system developed by ICW External system developed by 3 rd party SOAP User management Account LDAP User Repository ICW AG LlifeSensor Fallstudie für die OOP

6 ) ( ) ) ( ( Registrierung: Inter-System s UserManagement LifeSensor AccountManagement Auxiliary s User Management Account Management IdentitiyGenerator ( Auxiliaries Registration Registration (synchronous part) inubit IS Queue Registration (asynchronous part) ( Document Distrubtion Management Customer )Product Management ProductMangement ERP CustomerMangement Contract Management ContractMangement Contract Change Listener CardAuthorization Payment Provider Credit Card authorization ICW AG LlifeSensor Fallstudie für die OOP Im Makroprozess integrierte Systeme Zweck Art Verantwortung Schnittstelle Produktmanagement SAP R/3 ICW oder provider BAPI Kundenmanagement SAP R/3 ICW oder provider BAPI Vertragsmanagement SAP R/3 ICW oder provider BAPI, IDOC Benutzermanagement User Repository ICW, Kunde Webservice Accountmanagement LifeSensor ICW Webservice Kreditkartenautorisierung Electronic payment system Payment Provider Webservice -Server ICW SMTP ICW AG LlifeSensor Fallstudie für die OOP

7 Makroprozess entwerfen ICW AG LlifeSensor Fallstudie für die OOP In technische Workflows zerlegen ICW AG LlifeSensor Fallstudie für die OOP

8 Client: Selbstregistrierung für Endkunden ICW AG LlifeSensor Fallstudie für die OOP Clients für bestimmte Nutzergruppen Webclient Im Internet oder am Kiosksystem ProfessionalClient ICW Praxis4More mit Anbindung an vorhandene Primärsysteme Praxisverwaltungssystem Desktop-Oberfläche Technologie: Microsoft.Net oder Java Kommuniziert per Webservice-Call mit LifeSensor Für das Call Center Pflege der Kundenkontakte Intranet-Weboberfläche Integriert in HP OpenView Desk Technologie: Java, JSF-Client, Aufrufe an Webservice-Stack weitere ProfessionalClients in der Realisierung ICW AG LlifeSensor Fallstudie für die OOP

9 Im Projekt involvierte Teams Team Fachabteilung LifeSensor Entwicklung BPM-Entwicklung BPM-SAP IT Marketing Technische Redaktion Datenschutz-Experten Professional s Test-/Assembly-Center Aufgaben Anforderungen spezifizieren Mikro-s und -Prozesse als Makroservices gepackt bereitstellen Client, Makroprozess und Auxiliary s bereitstellen Backend-s für Makroprozess bereitstellen Infrastruktur bereitstellen Texte und Bilder zuliefern Texte redigieren und übersetzen Prozesse auf sicherheitskritische Aspekte prüfen Gesamtsystem für den Einsatz in verschiedenen Ländern und Projekten anpassen Lauffähige, qualitätsgesicherte Gesamtkonfigurationen herstellen ICW AG LlifeSensor Fallstudie für die OOP Organisatorische Herausforderungen Kommunikation im Projekt Bei 10 beteiligten Teams kein Kinderspiel! Releaseverwaltung / Versionierung In der Anwendungsentwicklung existieren Verfahrensweisen für Branch und Merge, also die Erstellung von Bug-Fixes für eine bereits freigegebenes Release, zeitgleich mit der Weiterentwicklung des Quellcodes in Richtung des nächsten, größeren Releases Branch und Merge war auf die Workflows im verwendeten Integrationsserver nicht anwendbar Versionierung von Schnittstellen ist schwierig Qualitätssicherung / Test Durch die starke Entkopplung mittels Events und den Einfluss von asynchronen Vorgängen wurde es schwierig, reproduzierbare und gleichzeitig aussagekräftige Tests zu automatisieren ICW AG LlifeSensor Fallstudie für die OOP

10 Erfahrungen (positiv) EAI ist eine sehr mächtige Technologie/Methodik, mit der man anpassbare Prozesse für unterschiedliche Kunden-Szenarios implementieren kann Sehr heterogene Systeme lassen sich damit verbinden Die EAI-Infrastruktur sorgt dafür, dass man sich um Details wie z.b. SAP-BAPI oder IDOC-Schnittstellentechnologien nicht zu kümmern braucht ICW AG LlifeSensor Fallstudie für die OOP Erfahrungen (negativ) Die Technik ist beim ersten Mal schwierig zu beherrschen Für XML gibt es keine wirklich guten Tools wie für OO-Sprachen; Refactoring, Testing, Bugfixing sind deshalb auf XML-Ebene schwierig Arbeiten am laufenden, integrierten ESB ohne Checkout/Checkin- Semantik ist ungewohnt und fehleranfällig Die Herausforderung steckt in der Projektorganisation Wenn sich s noch parallel zur Integration entwickeln, wird s komplex Wenn sich Anforderungen unterwegs ändern, hat das zum Teil teamübergreifende Auswirkungen Mit n Systemen zu einem gemeinsamen Releasezeitpunkt fertig zu werden, benötigt besondere Aufmerksamkeit und Entschlossenheit Was heißt eigentlich fertig für jedes Teilprojekt? Projektmanagement ist der Schlüssel! ICW AG LlifeSensor Fallstudie für die OOP

11 Vielen Dank für Ihre Aufmerksamkeit 10