zenos goes messaging neue kopplungsarchitektur bei der ... · event basis- skalierung get queuename...

Kopplungsarchitektur bei der BARMER GEK ZENOS-Forum │ 28.02.2013 │ Seite 1

ZENOS goes Messaging Neue Kopplungsarchitektur bei der BARMER GEK Fritz Weichbrodt BLUECARAT AG


Agenda   Worum geht es fachlich: oscare®-Einführung bei der BARMER GEK   Was ist der Businesspartner (BP)   Worum geht es bei der Kopplungsarchitektur   Kurzer Überblick über die Kopplungsarchitektur BP   Ist die Kopplungsarchitektur ein Widerspruch zum ESB-Ansatz?   Fazit und Ausblick


Worum geht es überhaupt?   Einführung der SAP-basierten Standardsoftware oscare® (AOK-Systems)

–  CRM (der enthält den BP) –  SAP HR, SAP FI –  FSCD –  PKM (Privatkundenmanagement) –  Claims (das ist das Leistungswesen)

  Projektbeteiligte –  BARMER GEK (Kunde) –  IBM (Projektlead) –  ACTUM (ZENOS-Lead) –  BLUECARAT

  ZENOS bei BARMER GEK bereits eingeführt


Worum geht es bei der Kopplungsarchitektur?   Replikation von Businesspartnern(BP) (zwischen MeldeBeitragsWesen MBWCRM)

–  hier in der Rolle PK (Privatkunde) –  FK (Firmenkunde)

  Was ist ein Businesspartner (bei der BARMER GEK)? –  Alle Informationen, die den BP identifizieren und zur Person/Firma gehören

–  Rollen, Adressen, Kommunikationsdaten, Beziehungen (zu anderen BPs), Schlüsselbegriffe (Mitgliedsnummer, Rentenversicherungsnummern, EGK-Nr, et.) und vieles mehr

–  Aber auch Meldungen, Merkmale, Entgelte (das ist Krankenversicherungsspezifisch)

  Wo ist der Businesspartner abgelegt? –  im BUS (zOS Legacysystem der BARMER B-Welt) –  im MBW (zOS Legacysystem der BARMER G-Welt) –  im SAP-CRM –  im SAP-Core (mit FS CD und Claims) –  in diversen sonstigen internen und externen Systemen


Wo gibt es den BP bei der BARMER? (sehr stark vereinfacht)

CRM (SAP-

oscare®)

Claims (SAP-

oscare®)

BUS (zOS)

PK

FK

PK

FK

Situation 2007

enthält alle BPs Wurde mit ZENOS

umgesetzt


Wo gibt es den BP bei der BARMER? (ursprüngliches Ziel)

CRM (SAP-

oscare®)

Claims (SAP-

oscare®)

BP (PK/FK)

2010 das war das

ursprüngliche Ziel


Wo gibt es den BP bei der BARMER GEK? (Die Fusion mit der GEK ändert das Bild)

CRM (SAP-

oscare®)

Claims (SAP-

oscare®)

BUS (zOS)

PK

FK

PK

FK

2009 Fusion mit GEK

MBW (zOS)

MeldeBeitrags-Wesen


Wo gibt es den BP bei der BARMER? (MBW übernimmt einen großen Teil von oscare®)

CRM (SAP-

oscare®)

Claims (SAP-

oscare®)

BUS (zOS)

PK

FK

PK

FK

2010 Entscheidung für MBW als PKM

MBW (zOS)

PK


Wo gibt es den BP bei der BARMER? (jetzt hat MBW alle PKs)

CRM (SAP-

oscare®)

Claims (SAP-

oscare®)

BUS (zOS)

PK

FK

PK(G/B) FK

2012 MBW hat alle PK

MBW (zOS)

PK(B) PK

X

darum geht es


Wo gibt es den BP bei der BARMER? (jetzt hat MBW auch die FKs)

CRM (SAP-

oscare®)

Claims (SAP-

oscare®)

BUS (zOS)

PK

FK

PK(G/B) FK

2013 MBW hat alle PK/

FK

MBW (zOS)

PK(B) PK

FK

darum geht es


Wo gibt es den BP bei der BARMER? (Ziel erreicht)

CRM (SAP-

oscare®)

Claims (SAP-

oscare®)

FK

PK(G/B)

2014 BUS entfällt

MBW (zOS)

PK

FK


Das ist schon eher die ganze Wahrheit!!


Rahmenbedingungen?   asynchrone Replikation ist gesetzt!   keine strategische Entscheidung für einen ESB (Enterprise Service BUS) vorhanden bzw.

kurzfristig umsetzbar   die Replikation von BPs erfordert komplexe Logik im jeweiligen Zielsystem (und im

Quellsystem)   Die Verbuchungszeiten liegen im Schnitt bei 0,5-2 sec   Verbuchungs- und Anwendungstransaktion sind nur lokal (nicht verteilt)   In den Anwendungssystemen und bei den Verbuchungen sind nur lokale Transaktionen

erlaubt   Es müssen täglich 300.000 Replikationen durchgeführt werden in Spitzen bis 500.000   Serialisierung (zumindestens auf Partnerebene) muss gewährleistet sein

  Skalierung notwendig   Logik muss im Quell- und Zielsystem implementiert werden


Wie replizieren? (Entscheidungsprozess stark verkürzt)

  ESB (Enterprise Service Bus) –  es gibt aber keinen Standard in der BARMER GEK und auf den kann man sich

kurzfristig nicht einigen –  es gibt kein Geld, wenn der Mehrwert nicht gegeben ist (wegen der komplexen Logik

im Zielsystem fungiert der ESB hier nur als Durchlauferhitzer und das reicht nicht für die Einführung)

  also: zunächst kein ESB

  WebSphere MQ auf zOS (HOST) gesetzt! –  aber SAP kann kein MQ, was tun?

  SAP kann doch MQ (zumindest mit dem HOST) –  SAP kann native SQL (natürlich auch remote) –  DB2 bietet MQ-Funktionalität auf SQL-Syntax Details??


SAP-Zugriff auf MQ

EXEC SQL. Connect to zOS. ENDSQL.

EXEC SQL. SELECT MQGET(„QUEUE“) FROM SYSIBM.SYSDUMMY1 INTO :P_msg ENDSQL.

Insert Msg Into SAP_TABLE.

COMMIT WORK.

TwoPhase-Commit

native SQL Open SQL (SAP)

zurück


Entwicklungsumgebung   zOS

–  Innovator (MDA-Tool) –  COOL (COBOL-Generator) –  GUI auf WIN32 mit C#

  SAP –  ABAP –  ZENOS


Messageaufbau

FachMsg (RPC, DI-Struktur, XML, …)

QMsgHeader Kennung, Funktionscode,

Länge

Metainformation


verteilte Transaktion

MBW SAP-CRM


lokale Transaktion

Sender

Basis- Baustein (BP-PK)

Replikator

Replikations- Event

Basis- Skalierung

get Queuename

MQ PK-Out

MBW- DB

Repl- Tabs

LokaleQ PK-In Kontroller Kontroller LVQ-Reader

PK-Replikation mit der Kopplungsarchitektur Externer Trigger

Auftrags- Replikator MQ

PK-Auftrag

BEK_1011 Basis-

Baustein (Verbuchung)

BPStat Mapping

MQ over DB2

MQ over DB2

MQ-Reader (Inbound)

native SQL

Quittungs- Verarbeit.

MsgStat

Repl Auftrag

Q-Leser Quittungs-

Prozessor

MQ-Sender (Outbound) native SQL

lokale Msg-

Queue

Q-Checker (Prozess- Kontrolle)

Auftrags- Prozessor PK-Outb.-

Verarbeit.


ZENOS-Komponenten

Eingangs Queue

ZENOS

im PK-Szenario

MQ- READER

Liest Daten aus der

Eingangs-Q

PK-SST Verarbeitung der PK-Daten

LVQ ZENOS lokale Q

RPC Handler

Anwendungs- FB

RPC-Error Handler

LVQ- READER

Liest Daten aus der

LVQ

LVQ- READER

Liest Daten aus der

LVQ Basis-Skalierung

PK-SST Verarbeitung

der PK-Daten

PK-SST Verarbeitung

der PK-Daten

BP-Error Handler

RCODE4

LVQ- READER

Liest Daten aus LVQ

Dynamische

Parallelisierung

Fehlerklasse A

Erneute Verarbeitung

Q - CHECKER Fehlerklasse > A

Anforderung Komplettlieferung Prüfende Instanz

Auftrags Queue

MQ-SENDER Liest Daten aus der lokalen

Sende-Q und schreibt diese in die ferne

MQ

Lokale Sende- Queue


MQ-Reader (Daemon: Instanz je INB-Queue)

QMsg lesen

Begin Tra

Remote Queue

stopped? ja

Start Customizing lesen

ZielQ lokale ZENOSQ

Msg- Stat

Status remote gespeichert

Kennung- Versteher

(RfC)

das ist die allg. INBOUND-Schnittstelle

Fehler?

Rollback

ja

Ende

Queue leer?

ja warten

Fehler?

Verbindung aufbauen

Verbindung trennen

ja


MQ-Sender (Daemon: Instanz je INB-Queue)

QMsg lesen

Begin Tra

lokale Queue

stopped? ja

Start Customizing lesen

ZielQ Remote MQ

Msg- Stat

Status remote gespeichert

mqsend (RfC)

das ist die allg. OUTBOUND-Schnittstelle

Fehler?

Rollback

ja

Ende

Queue leer?

ja warten

Fehler?

Verbindung aufbauen

Verbindung trennen

ja


Wie kann man die Kopplungsarchitektur in einen ESB integrieren?

  die Schnittstellen sind bereits vorhanden   Es entfällt der MQ-Prozess MQ-Reader, dessen Funktionalität wird vom ESB übernommen



MBW SAP-CRM


lokale Transaktion

Sender


Replikator

Replikations- Event

Basis- Skalierung

get Queuename

MQ PK-Out

MBW- DB

Repl- Tabs


PK-Replikation (ohne ESB) Externer Trigger

Auftrags- Replikator MQ

PK-Auftrag

BEK_1011 Basis-


BPStat Mapping

MQ over DB2

MQ over DB2

MQ-Reader (Inbound)

native SQL


MsgStat

Repl Auftrag

Q-Leser Quittungs-

Prozessor


lokale Msg-

Queue



Verarbeit.



MBW SAP-CRM


lokale Transaktion

Sender


Replikator

Replikations- Event

Basis- Skalierung

get Queuename

MQ PK-Out

MBW- DB

Repl- Tabs


PK-Replikation (mit ESB) Externer Trigger

Auftrags- Replikator

MQ PK-Auftrag

BEK_1011 Basis-


BPStat Mapping


MsgStat

Repl Auftrag

Q-Leser Quittungs-

Prozessor


lokale Msg-

Queue



Verarbeit.

RfC

ESB (z.B. PI)

jms-Reader

jms-Writer RfC


Architektur BP(PK und FK) Gesamtübersicht BARMER GEK BP(PK/FK)-Gesamtsicht (mit „alter S11 und S14")

SAP CRM

MBW

MBWCRM.FK.REPLAUFTRAG

MQ-ReaderMBW_MQ02FK

MQ-SenderMBW_MQ12FK

lokaleSende-Queue

CRMMBW.FK.REPLIKATOR

SAP-BP-Transaktion

MBWCRM.FK.REPLIKATOR FK-Inbound-Replikation

CRMMBW.FK.REPLAUFTRAG

FK-Outbound-Replikation

FK-OutboundAufträge und Quittungen

FK-Inbound-Replikation MQ-ReaderMBW_MQ03FK

FK-OutboundAufträge und Quittungen

FK-IntboundAufträge und Quittungen

FK-InboundAufträge und Quittungen

MQ-SenderMBW_MQ13FK

Legende:

FK-InboundÜbergangsreplikation

FK-Outboundfinale Replikation

S14-Auslöser

BUS (bis Stufe 4)

DSNACICS

BUS-S14-Replikation FK

FK-Outbound-Replikation

MQ-SenderMBW_MQ11

(PK)

CRMMBW.PK.REPLAUFTRAG

PK-Outbound-Replikation

MBWCRM.PK.REPLIKATOR

MQ-ReaderMBW_MQ01

(PK)PK-InboundReplikation

PK-Outbound-Auslöser

BUS-S11-Replikation PK

PK-InboundAufträge und Quittungen

PK-InboundReplikation

PK-InboundAufträge und Quittungen

SAP-BP

PK-In/-OutboundReplikation

BUSMBW.FK.REPLIKATOR

BUSMBW-S11-

Replikation

MBWBUS.PK.REPLAUFTRAG

S11-Aufträge PKS11-

Aufträge PK


technische Daten   Repliziert werden

–  ca. 13 Mio BPs (Privatkunden) Inbound –  ca 5 Mio BPs (Firmenkunden) Outbound

  durchschnittliche Verfügbarkeit einer Replikation: ca. 3 Sekunden –  d.h. nach 3 Sekunden ist die Verbuchung im abhängigen System erfolgt

  Durchsatz –  ca. 50.000 Msg pro Remote Queue pro Stunde –  diese Messages werden mit 10-40 Dialogprozessen in einer Stunde verarbeitet

  Verfügbarkeit –  7x22 (nur während der SAP-TV wird das Inbound-Messaging gestoppt)


Fazit und Ausblick   ZENOS eignet sich sehr gut, um SAP in Standard-Messaging-Architekturen einzubinden

–  mit ESB –  ohne ESB

  genügend Performance erreicht –  weitere Skalierungen sind möglich

–  mehrere Queues –  weitere Anzahl von Verbuchungsprozessen –  …

  jede Menge an technischen und fachlichen Monitoringfunktionalitäten implementiert   gut in den Betrieb integrierbar

–  Problemmails –  Tickets –  BLOG

  Verallgemeinerung jederzeit möglich –  an andere Queueingsysteme –  an „Queue-ähnliche“ Systeme –  …


Snapshots: Lastverteilungsmonitor


Snapshots: Q-Monitor


Snapshots: BP-Replikationsstatus


ZENOS goes Messaging Vielen Dank für Ihre Aufmerksamkeit! Fritz Weichbrodt BLUECARAT AG

Und vielen Dank an das Actum-Team (für die gute und erfolgreiche Zusammenarbeit)!

zenos goes messaging neue kopplungsarchitektur bei der ... · event basis- skalierung get queuename...

Documents