bpel pm in einer hochverfügbarkeitsumgebung - … · consulting technical manager (oracle...

BPEL PM in einer HochverfügbarkeitsumgebungErfahrungsberichtVersion 1.0 – 7. November 2007

André Schippeinz – T-Systems GEI GmbH

Unterstützt durchNatascha Schönfeld – Oracle Consulting Deutschland

Seite 1

André Schippeinz.V1.0, 22.11.2007

BPEL PM in einer Hochverfügbarkeitsumgebung Vorstellung Personen und T-Systems

Natascha Schönfeld (ORACLE Deutschland GmbH )� Consulting Technical Manager (ORACLE Deutschland GmbH )� seit 1996 als Consultant bei Oracle beschäftigt� bereits 2003 bei der Einführung des OAI als Schnittstellenplattform für das SAP

R/3 System tätig� maßgeblich am Design, der Implementierung und der Produktivsetzung des BPEL

PM beteiligt

André Schippeinz (T-Systems GEI GmbH)� Projektmanager (IT-Architekt) für Technologieprojekte� seit 1999 im Unternehmen T-Systems tätig� seit 2001 Einsatz in verschiedenen Projekten des Mautsystems (ETC – Electronic

Toll Collect) � Projektmanager der Entwicklung für das Projekt zur Ablösung des OAI durch den

BPEL PM

T-Systems ist die Geschäftskundensparte der Deutschen Telekom. Der Dienstleister bietet die gesamte Palette der Informations- und Kommunikationstechnik aus einer Hand. Auf Basis des umfassenden Know-hows aus diesen beiden Welten entwickelt T-Systems integrierte ICT-Lösungen (ICT = Information and Communication Technology) und ist damit einer der Innovationstreiber der Branche. Im Geschäftsjahr 2006 erzielte das Unternehmen einen Umsatz von 12,6 Milliarden Euro und beschäftigte in mehr als 20 Ländern etwa 56.000 Mitarbeiter. Unter anderem entwickelt und betreibt T-Systems im Auftrag der Toll Collect das deutsche LKW-Mautsystem (ETC).

Seite 2


BPEL PM in einer Hochverfügbarkeitsumgebung Vorwort

� Der Einsatz neuer, serviceorientierter Infrastruktur zur Integration bestehender Anwendungen unterliegt sehr oft der Restriktion an den bestehenden Applikationen keine Änderungen vorzunehmen.

� Der support-bedingte, vermeintlich leichte Upgrade, des Integrationstools Oracle Application InterConnect (OAI) wurde aber durch mangelhafte Softwarequalität, fehlende Funktionalität und unausgereifte Produktpartnerschaften erheblich erschwert.

� Der Vortrag beschreibt, wie trotz dieser Rahmenbedingungen - über einen Zeitraum von rund 20 Monaten - die Integration des Oracle BPEL ProcessManagers 10.1.3.1 (inkl. Applikationsadapter) in eine hochverfügbare Produktionsumgebung (7x24 Stunden) Ende Juli 2007 erfolgreich abgeschlossen wurde.

Seite 3


BPEL PM in einer Hochverfügbarkeitsumgebung Agenda

� Ausgangssituation und Historie� Einführung BPEL PM

� Rahmenbedingungen � Projektfocus� Know-How Aufbau� Projektverlauf� Perfomance und Failovertests� Softwarequalität

� BPEL PM Architektur� Prozesse� Fehlerhandling

� Infrastruktur � Entwicklung� Gesamtintegration� Produktion

� Lessons learned� Allgemein� Zusammenarbeit mit Oracle und iWay� Benefit für Oracle

� Ausblick & Visionen

Seite 4


BPEL PM in einer Hochverfügbarkeitsumgebung Ausgangssituation Oracle InterConnect

Oracle Application InterConnect (OAI)� OAI diente als Schnittstellenplattform

für das SAP R/3-System zur Kommunikation mit den AdvancedQueues (AQ) der Vorsysteme

� 19 Schnittstellen zu 6 Partnersystemen

� hoher Datendurchsatz in der Schnittstelle SAP - PreBilling => Übertragung und Transformation von bis zu 2 Mio. Fahrtdatensätzen in 8 Stunden

heavyload

SAPR/3

CRM

PreBilling

4 otherSystems

OAI

SA

P-A

dapt

er

6 interf.

11 interf.

AQ

-&

DB

Ada

pter

RF

C &

IDoc

heavy

load

14 interf.

OAI - Architektur� OAI arbeitete mit 3 Adaptern (SAP, AQ, Datenbank)� pro Partnersystem wurden separate AQ- und DB-Adapter konfiguriert� PreBilling - SAP Schnittstelle: AQ-Adapter: 4fach parallelisiert – SAP-Adapter: 8fach

parallelisiert

Advanced Queuing (AQ)� In der Infrastruktur des ETC Systems (LKW-Maut Deutschland) wurde die

Schnittstellentechnologie Oracle Advanced Queuing (AQ) als Standard zum Austausch von Nachrichten und Daten zwischen den Zentralsystemen definiert.

� Das u.a. zur Abrechnung der Mautdaten eingesetzte SAP R/3-System (4.6C) unterstützt diese Technologie nicht.

Seite 5


BPEL PM in einer Hochverfügbarkeitsumgebung Historie der OAI-Ablösung

Historie der OAI-Ablösung

� Ende 2005 � Oracle kündigt das Auslaufen des Supports für OAI 4.1 für Ende 2006 an

� Mitte Januar 2006� Upgrade OAI 4.1 (Oracle8) nach OAI 10g mittels Migrationspfad von Oracle � Upgrade technisch nicht machbar – Bestätigung von Oracle: Upgrade funktioniert

nicht

� Mitte Februar 2006� Start einer Neuimplementierung aller bestehenden Schnittstellen mit OAI 10g� massive Probleme bereits bei der Umsetzung eines Prototypen

� Ende März 2006� Bestätigung von Oracle, dass OAI 10g im Zusammenspiel mit dem SAP Adapter

(von iWay) die notwendige Performance nicht leisten kann� Oracle Empfehlung: OAI-Ablösung durch BPEL Process Manager 10.1.2

� April 2006� Aufbau eines Prototypen BPEL PM 10.1.2� Funktionalität bestätigt, aber keine Lasttests� Entscheidungsvorlage für T-Systems Management

Seite 6


BPEL PM in einer Hochverfügbarkeitsumgebung Einführung BPEL PM: Rahmenbedingungen

Rahmenbedingungen OAI Support

� Eine von T-Systems gewünschte Verlängerung des Support für OAI 4.1 über 2006 hinaus war seitens Oracle nicht möglich

� OAI als Schnittstellenplattform kann nicht weiter genutzt werden => Ablösung zwingend notwendig, da der Betrieb eines 7x24 Stunden Hochverfügbarkeitssystems ohne Herstellersupport für T-Systems als Host-Dientsleister „grob fahrlässig“ wäre

� Advanced Queuing ist eine proprietäre Technologie der Firma Oracle => wird nur von wenigen EAI- oder SOA-Plattformen direkt unterstützt

⇒ Aufgrund von Zeitdruck und mangelnder Alternativen für die AQ-Anbindung, entscheidet T-Systems , der Oracle Empfehlung zur Ablösung des OAI durch den BPEL PM zu folgen.

Rahmenbedingungen BPEL PM

� BPEL PM ist eine Komponente der Oracle SOA Suite� BPEL PM ist nicht das Nachfolgeprodukt bzw. die Weiterentwicklung des OAI� eigentliches Nachfolgetool wäre der Oracle ESB, aber dessen Verfügbarkeit war im

Frühjahr 2006 nicht absehbar

⇒ Einführung von BPEL PM ist mit erheblichen Risiken verbunden

Seite 7


Projektfocus

Ziel des Projektes war die 1:1 Ablösung des OAI durch den BPEL PM, d.h.:� das neue System BPEL PM muss die gleiche Funktionalität abbilden und die gleichen

betrieblichen Anforderungen wie der OAI erfüllen� keine Implementierung von neuen oder zusätzlichen Funktionalitäten� keine Änderungen an den Partnersystemen – vor allem keine Änderungen im SAP R/3-

System oder den AQ‘s� Keine Änderungen an der bestehenden Hardware-Infrastruktur� für die lastintensive PreBilling-SAP Schnittstelle soll im BPEL PM ein Datendurchsatz

von 2 Millionen Datensätzen in 5 Stunden möglich sein (laut Oracle soll BPEL PM schneller sein OAI)

⇒ Oracle bewertete diese Anforderungen als „machbar“ und stellte dem Projekt kostenfrei erfahrene BPEL Process Manager Spezialisten bei

BPEL PM in einer Hochverfügbarkeitsumgebung Einführung BPEL PM: Projektfocus

… … OAI SAP

BPEL PM 1:11:1

Seite 8


BPEL PM in einer Hochverfügbarkeitsumgebung Einführung BPEL PM: KnowHow Aufbau

KnowHow Aufbau für BPEL PM

� KnowHow Aufbau in Sachen BPEL PM stellte zu Projektbeginn die größte Herausforderung dar

� Das bestehende „OAI-Team“ der Entwicklung musste sich in kürzester Zeit in die neue Software einarbeiten.

� Hilfsmittel: � unvollständige Dokumentation� Oracle Consultants (Parttime vor Ort)� Metalink (Bug-Database) � OTN (Foren)

� hilfreiche Schulungen zum BPEL PM waren bei Projektbeginn nicht verfügbar� Oracle konnte weltweit keine vergleichbaren Projekte zwecks Erfahrungsaustausch

finden⇒ Frei nach dem Prinzip: „Versuch macht klug“.

Entwicklungsteam

� Von anfänglich 2-3 Mitarbeitern wurde das Team schrittweise auf bis zu 10 Mitarbeiter erweitert.

� Einarbeitung neuer Mitarbeiter in die BPEL PM Software und die kundenspezifischen Prozesse dauert ca. 8-10 Wochen

� Oracle-Unterstützung: 1-2 Consultants vor Ort und „A-Team“ (US-Development)

Seite 9


BPEL PM in einer Hochverfügbarkeitsumgebung Einführung BPEL PM: Projektverlauf

Projektverlauf der BPEL PM Einführung

� Anfang Mai 2006:� Managemententscheidung für BPEL PM Einführung� Start des Projekts zur Ablösung des OAI durch BPEL PM 10.1.2� Zieltermin für Produktivsetzung: Mitte September 2006

� Anfang September 2006:� massive Probleme mit der Software-Qualität ( zu viele offene Prio1 Bugs!) führen

zum Projektaufschub bis Rel. 10.1.3 verfügbar ist

� November 2006:� Fortsetzung des Projekts mit BPEL PM 10.1.3.1“beta“

� Ende März 2007:� offizieller Abschluss der Entwicklungsarbeiten nach erfolgreichen Lasttests in der

Entwicklung� Beginn der funktionalen und betrieblichen Tests (einige „Bugs“ noch in

Bearbeitung bei Oracle)

� Ende Juli 2007:� Erfolgreiche Produktivsetzung des BPEL PM 10.1.3.1

Seite 10


BPEL PM in einer Hochverfügbarkeitsumgebung Einführung BPEL PM: Performance- und Failover-Tests

Performance- und Failover-Tests

� Zum Lastverhalten des BPEL PM konnte Oracle keine belastbaren Aussagen oder Zahlen bereitstellen.

� Im Rahmen des Entwicklungsprojektes wurde das Lastverhalten verifiziert.� Vor Ort unterstützt von verschiedenen Oracle Spezialisten (teilweise aus den USA)

wurden die BPEL-Engine, die Adapter, die Datenbanken und der iAS optimiert, so dass mit zwei BPEL PM Instanzen ein Datendurchsatz von fast 7.000 Ds pro Minute (ca. 2,1Mio Ds in 5h) erreicht wurde.

⇒ Einsatz von mind. zwei BPEL PM Instanzen, da zwei JVM‘s zur Speicheradressierung notwendig

� Im Rahmen der betrieblichen Tests wurde die entwickelte Lösung in diversen Vollast-Testszenarien vom T-Systems Rechenzentrum überprüft.

� es wurden integrierte End-to-End Tests gefahren, um ein möglichst produktionsnahes Verhalten zu simulieren

� verschiedene Failover-Szenarien (inkl. Wiederanlauf) wurden getestet, wobei sich diverse Probleme und Fehler beim Zusammenspiel der verschiedenen BPEL PM Komponenten (BPEL Engine, Adapter, Datenbanken) herausstellten.

� Die Optimierung des BPEL PM zur Erreichung der Performance- und Failover-Anforderungen war und ist eine sehr zeitaufwendige „Filigranarbeit“ für Experten.

Seite 11


BPEL PM in einer Hochverfügbarkeitsumgebung Einführung BPEL PM: Softwarequalität (1/2)

Probleme mit BPEL PM Software

� Reifegrad des BPEL Process Manager Releases 10.1.2 war schlecht� es fehlten diverse zugesagte oder in der Dokumentation beschriebene Funktionalitäten� die Behebung von Fehlern verlief sehr schleppend

⇒ erster Produktivsetzungstermin im September 2006 aufgrund der mangelhaften Softwarequalität und nicht nachweisbarer Performance abgesagt

�zu diesem Zeitpunkt 16 offene SR‘s, die in dieser Version nicht behoben werden konnten

⇒ Release 10.1.3.1 (Nov. 2006) war deutlich besser, hatte aber immer noch Schwachstellen und Fehler

Service Requests bei der BPEL PM Einführung

� im Rahmen des Projektes insgesamt ca. 120 Service Requests im Metalink geöffnet� davon 73 SR direkt gegen den BPEL PM� teilweise Fehler für normale betriebliche Use-Cases eingestellt, weil diese Funktionen

seitens Oracle nicht vorgesehen waren (Bsp.: Deployment von Prozessen ohne Aktivierung dieser Prozesse).

� 5 von T-Systems eingestellte Enhancement Requests wurden von Oracle akzeptiert und im Release 10.1.3.1 umgesetzt

� 8 Patche zum BPEL PM 10.1.3 und 5 Patche für mySAP-Adapter => insgesamt mehr als 40 Bugfixe

� letzten beiden BPEL PM Bugfixes (Patche für SAP-Adpater und AQ-Adapter) von Oktober 2007

Seite 12


BPEL PM in einer Hochverfügbarkeitsumgebung Einführung BPEL PM: Softwarequalität (2/2)

Partnerschaft zwischen Oracle und iWay

� SAP-Adapter des BPEL PM wird von der Firma iWay Software entwickelt und von Oracle vertrieben

� Produktpartnerschaft zwischen Oracle und iWay ist ein schwerer Kritikpunkt� offiziell ist Oracle „Premier Partner“ von iWay – gibt aber keine erkennbaren SLA‘s für

Qualität und Support� mySAP-Adapter von iWay hatte absolut schlechte Qualität� Oracle ist kaum in Lage die Qualität des mySAP-Adapter zu verifizieren � iWay-Support war und ist nicht in der Lage Probleme zeitnah zu analysieren und zu

lösen� iWay hat kein Support-Team in Europa (nur Indien und USA)� im Laufe des Projektes keine sichtbare Verbesserung bei Lieferqualität und

Zusammenarbeit

⇒ Nur durch ständige massive Managementeskalationen konnte Oracle die Firma iWayzur Lieferung von Patchen und Informationen bewegen.

Seite 13


BPEL PM in einer Hochverfügbarkeitsumgebung Agenda

� Ausgangssituation und Historie� Einführung BPEL PM

� Rahmenbedingungen � Projektfocus� Know-How Aufbau� Projektverlauf� Perfomance und Failovertests� Softwarequalität

� BPEL PM Architektur� Prozesse� Fehlerhandling

� Infrastruktur � Entwicklung� Gesamtintegration� Produktion

� Lessons learned� Allgemein� Zusammenarbeit mit Oracle und iWay� Benefit für Oracle

� Ausblick & Visionen

Seite 14


BPEL PM in einer Hochverfügbarkeitsumgebung BPEL PM Architektur: Prozesse

BPEL PM Prozesse

� Grundarchitektur der Schnittstellen konnte weitgehend vom OAI übernommen werden� Änderungen an den Schnittstellenpartnersystemen (vor allem SAP) waren nicht zulässig � Einsatz von 3 Adaptern (wie OAI):

� AQ-Adapter und DB-Adapter (Oracle Technologie Adapter)� mySAP–Adapter (iWay-Adapter)

� der eigentlich hinter BPEL stehende Prozess- bzw. Servicegedanke wurde nur beim Fehlerhandling genutzt.

� Implementierung der 16 Schnittstellen als sehr einfache BPEL Prozesse

� bestehend im wesentlichen aus nur drei Aktivitäten:

� Receive - Annehmen der Daten von einem Adapter

� Transfom - Mapping/Transformieren von bis zu 150 Parametern

� Invoke - Übergabe der Nachrichten an Zielsystem via Adapter

� wirklich komplex nur Prozess des Fehlerhandlings

Seite 15


BPEL PM in einer Hochverfügbarkeitsumgebung BPEL PM Architektur: Fehlerhandling

Fehlerhandling

� im Gegensatz zum OAI gibt es im BPEL PM kein generelles systemweites Fehlerhandling

� Fehlerbehandlung muss für jeden einzelnen BPEL-Prozess manuell implementiert werden (Änderung ab Release 10.1.3.3)

� als eigener Service implementierte Fehlerhandler wurde durch einige Javaklassen ergänzt und dient in erster Linie zum Abfangen betrieblicher Fehler

� folgenden Fehlerarten werden abgefangen:� Remotefault (System- und Kommunikationsfehler)� Bindingfault (Transformationsfehler, Syntaxfehler)� Rejected Message (ungültige Nachrichten)� Standardfault (alle anderen Fehler)

� Zur Vermeidung von Massenfehlern werden Prozesse automatisch deaktiviert, wenn innerhalb eines konfigurierbaren Zeitintervalls mehrfach Fehler des gleichen Typs auftreten.

� Verfahren und Scripte zum Wiederanlauf fehlerhafter Nachrichten / Instanzen entwickelt

Seite 16


BPEL PM in einer Hochverfügbarkeitsumgebung Infrastruktur: Entwicklung

Infrastruktur - allgemein

� Entwicklungsarbeiten laufen in einem separaten Rechenzentrum� Rechenzentrum für Gesamtintegration und Produktion betreibt drei getrennte

Umgebungen � funktionale End-to-End Tests�betriebliche Tests auf einer produktionsähnlichen Umgebung�Produktion

Entwicklungsumgebung

� 3 kleine SUN Solaris Systeme (je 2CPU, 2GB RAM) zum Entwickeln und Testen der BPEL-Prozesseund des Fehlerhandlings

� extra Server für Spoke-Datenbank(en)� je ein DB-Schema pro BPEL Entwicklungssystem

� extra Entwicklungsserver für Last- und Perfomancetests� SUN V1280 mit 12 CPU’s und 48GB RAM� zwei BPEL Instanzen zu Parallelisierung

� für alle Entwicklungs- und Testsysteme ein gemeinsamesSAP-R/3 Testsystem

⇒ bei Systemtests max. zwei Tester pro BPEL PM System - sonst gegenseitige Behinderungen

Seite 17


BPEL PM in einer Hochverfügbarkeitsumgebung Infrastruktur: Gesamtintegration

Gesamtintegration

� funktionale End-to-End Tests mit allen beteiligten Systemen� beginnend mit der Erzeugung von Fahrtdatensätzen bis zur Abrechnung und

Rechnungserstellung im SAP R/3-System� Tests mit Massendaten (synthetischen Daten)� Verifikation von Spezialfällen (Umlaute / Unicode, Feldlängen u.ä.)

� Testen von Prozessabläufen im gesamten Mautsystem

� betriebliche Tests auf einer produktionsähnlichen Hardwareumgebung� Ausfall- und Failover-Szenarien� Wiederanlauf-Tests� Last- und Perfomancetests mit produktionsähnlichem Volumen (bis zu 2

Millionen Fahrtdatensätzen) inkl. Übergabe an SAP R/3

Seite 18


BPEL PM in einer Hochverfügbarkeitsumgebung Infrastruktur: Produktion

BPEL PM Produktionsumgebung

� als hochverfügbares 7x24h System ausgelegt� Das Ziel, für den BPEL PM die gleichen OAI-Hardwareressourcen zu nutzen, wurde

nicht erreicht!� BPEL PM benötigt mehr Hardware� Optimierungen zur Reduzierung der Hardware laufen teilweise noch (zusammen

mit Oracle)

� BPEL PM als Cluster mit insgesamt 4 Instanzen � jeweils 2 BPEL-Instanzen auf zwei Server� zwei SUN F15k-Server mit je 8x1200MHz-CPU u.

16GB RAM (SUN OS 5.8)� bei Ausfall eines Servers können die beiden

verbleibenden BPEL Instanzen die Last alleinbearbeiten (kein Hardware Failover)

� Auslastung der zwei Server jeweils rund 60%

(in der lastintensiven Zeit - 8h pro Tag)

� die zugehörigen Spoke-Datenbanken (für AQ‘s und Schnittstellen-DB‘s) laufen auf einem SUN-Cluster

� im Cluster (2xF15k) stehen ca. 12 CPU‘s und 20GB RAM zur Verfügung – Rest andere DB‘s

� Absicherung über SUNCluster 3.1

dtcuxo09 dtcuxo10

dtcuxo13 dtcuxo14

PRBDB

Dehyd.DB

SpokeDB

XyDB

SAP1 DB-Serv, 1 CI, 4 AS

BP

EL

1

BP

EL

3

BP

EL

4

BP

EL

2

Seite 19


BPEL PM in einer Hochverfügbarkeitsumgebung Lessons Learned: Allgemein

Allgemein

� Seit 27. Juli 2007 läuft der BPEL PM stabil und performant in der Produktion!� Insgesamt war die zwangsweise Ablösung des OAI durch den BPEL PM ein teuerer

„Leidensweg“ für alle Beteiligten.� über 20 Monate Laufzeit � sehr hohe Kosten bei T-Systems� Mehrere hundert Beratertage (Top-Experten-Level) seitens Oracle� Image- und Vertrauensverlust für Oracle SOA-Suite

� Softwarequalität – wie beschrieben� hohe Zeit- und Reibungsverluste durch Zeitverschiebung zwischen Europa und USA

� Nächtliche Telefonkonferenzen� „Mail Ping Pong“

� Kommunikationsprobleme� Metalink als Kommunikationsplattform schwierig – nicht besonders

anwenderfreundlich� seitenlange SR-Diskussionen� „keep the customer busy“ – immer wieder die gleichen Fragen von

verschiedenen „Supportlern“ und Organisationseinheiten� teilweise unabgestimmte Fehlerbearbeitung

Seite 20


BPEL PM in einer Hochverfügbarkeitsumgebung Lessons Learned: Zusammenarbeit mit Oracle und iWay

� Zusammenarbeit mit dem Oracle Support gestaltete sich anfangs als sehr schwierig� Nach massiver Managementeskalation seitens T-Systems wurde das US Management

eingeschaltet und es gab dann ein klares Commitment des US-Managements zur Unterstützung des Projektes.

� wirksame Massnahmen:� Support wurde weitgehend von deutschen Kollegen übernommen => deutlich

bessere und effizientere Zusammenarbeit� Zusammenstellung eines speziellen „A-Team“ (Consultants vor Ort, US-

Productmanagement und deutscher Support), welches sich intensiv und sehr kompetent um die Probleme kümmerte

� wöchentliche „ConferenceCalls“ zwischen T-Systems und Oracle (inkl. US Management)

� Zusammenarbeit mit den Oracle-Consultants vor Ort war von hohem Engagement und klarer Kundenorientierung geprägt

⇒ ohne direkte Einbindung des US-Produktmanagements wäre das Projekt nicht erfolgreich geworden

� trotz nachweisbar sehr schlechter Softwarequalität (fehlende Funktionen, Bugs usw.) war der Support von iWay sehr schleppend und unflexibel

� Reaktions- und Bearbeitungszeiten sowie die Einhaltung von zugesagten Termin war (sind) sehr schlecht.

� Kurzfristige Terminabsagen (Stunden vorher) und -verschiebungen (um 1-2 Wochen)

Seite 21


BPEL PM in einer Hochverfügbarkeitsumgebung Lessons Learned: Benefit für Oracle (Natascha Schönfeld)

Einfluss des Projektes auf die Entwicklung bei Oracle

Das Projekt hatte einen erheblichen Einfluss auf die Erweiterungen und Optimierung der Funktionalitäten des BPEL Process Managers, des Adapter Framework und des mySAP Adapter von iWay.

� Erweiterung der Optionen zu Parallelisierung der Adapterthreads durch die Einführung neuer Parameter (Activation Instances)

� kontrolliertes Deployment-Modell mit Hilfe von neuen Domain Konfigurationsparametern� Online Änderungen und Anpassungen der Anzahl von lesenden Adapter-Threads durch

die BPEL PM Console� gezielte Behandlung der SAP spezifischen Fehler durch die Einführung des Exception

Filter Frameworks� Erweiterung der mySAP Adapter Funktionalität, durch die Möglichkeit, fehlerhafte

Nachrichten zurück an das SAP Gateway zu melden� Erweiterung der von mySAP Adapter unterstützten SAP Datentypen� Verbesserung der Cluster Funktionalität bei allen BPEL Komponenten

Danke T-Systems!

Seite 22


BPEL PM in einer Hochverfügbarkeitsumgebung Ausblick & Visionen

laufende Projekte

� Ergänzungs- und Erweiterungspackage (Behebung kleinerer Fehler und Optimierung der Wiederanlauf-Szenarien) – Zieltermin für Produktion: Ende November / Anfang Dezember 2007

Geplante Projekte

� Upgrade BPEL PM nach 10.1.3.3

� Einführung ESB 10.1.3.3 (inkl. BPEL PM Upgrade) und schrittweise Ablösung anderer „Verteil- und Zwischenspeicher“ Systeme

Langfristige Projekte / Strategien

� Schrittweise Einführung Serviceorientierter Architektur für verschiedene Applikationen (u.a. PeopleSoft 9.0) auf Basis ESB und BPEL PM

Seite 23


BPEL PM in einer Hochverfügbarkeitsumgebung Kontaktadressen

André Schippeinz� T-Systems GEI GmbH� Goslarer Ufer 35, 10589 Berlin

� Mail: [email protected]

Natascha Schönfeld� ORACLE Deutschland GmbH� Riesstrasse 25, 80992 München

� Mail: : [email protected]

bpel pm in einer hochverfügbarkeitsumgebung - … · consulting technical manager (oracle...

Documents