Blog
This second part of the streaming ETL series will discuss the typical ETL challenges data lineage, error handling and data quality with a special focus on the specificities to be considered in a streaming approach. Relating batch reporting requirements to streaming ETL is also tackled. The series is concluded with an overview on testing streaming ETL systems and a summary.
The new central data system for the banking and insurance sector by SAP is FSDP, the Financial Services Data Platform. It is meant to constitute the central analytical platform in a financial services IT architecture and uses SAP’s state-of-the-art in-memory database HANA, which was developed specially for analytical purposes.
Wie funktioniert der ADWEKO FSDM2OneSomX Adapter als standardisierte Integrationslösung und wie können kundenspezifische Erweiterungen und Anpassungen für Wolters Kluwer OneSumX und SAP FSDP berücksichtigt werden.
Fragt man Anwender, was ein modernes Data Warehouse auf Basis von SAP HANA ausmacht, dann werden zumeist die großen Geschwindigkeitsvorteile herausgestellt. Allerdings sind die Auswirkungen des in-Memory-Ansatzes viel tiefgreifender, als sie auf den ersten Blick erscheinen, denn sie betreffen die
Am Anfang der Kooperation mit Wolters Kluwer stand die Ablösung des SAP Credit Risk Analyzers (CRA), dessen Support 2025 auslaufen wird. Als technisches Fundament dient die Financial Services Datenplattform (FSDP) der SAP, die auf der neuen In-Memory Datenbank SAP HANA aufbaut. Das Datenmodell der SAP FSDP ist bewusst so offen und umfassend gewählt, dass sämtliche analytische Bankprozesse abgebildet werden können. Als idealer Partner für eine auf SAP FSDP aufbauende Risiko-Engine stellte sich Wolters Kluwer mit OneSumX heraus. Die Software umfasst Kredit- und Marktpreisrisiken als auch ein Liquiditätsmanagement.
Erste Umsetzungen für einen ADWEKO FSDM2OneSumX Adapter im Bereich Marktpreisrisiken und Liquiditätsmanagement sind bereits 2019 erfolgt. Der Rückadapter von OneSumX in SAP FSDP wird 2020 abgeschlossen.
Zu den bereits implementierten Lösungen zählt zum einen eine FX-Adjustment Kalkulation und zum anderen diverse Kosten-Allokationen. Beide Themen sind fachlich nicht außerordentlich anspruchsvoll, stellen jedoch aufgrund der großen Anzahl an zu verarbeitenden Datensätzen eine Herausforderung im Hinblick auf die Performance dar. Oftmals fallen diese Performance bezogenen Probleme aufgrund der relativ geringen Datenmengen im Entwicklungssystem allerdings erst in einem der späteren Test-Systeme auf. Dies bedeutet leider auch, dass die zur Verbesserung der Performance implementierten Lösungen nicht umgehend getestet werden können, was zu Verzögerungen im Arbeitsablauf führt.
Aus technischer Sicht wird SAP FPSL als Add-on zu SAP S/4HANA eingesetzt. Dies bedeutet jedoch nicht unbedingt, dass S/4HANA eine Voraussetzung für FPSL ist. Durch die nahtlose Integration der Nebenbuchlösung SAP FPSL und des S/4HANA-Hauptbuchs, können Kunden durch die Kombination beider SAP-Produkte jedoch Synergien innerhalb ihrer Buchhaltungs- und Finanzabteilung nutzen.
WIE FUNKTIONIERT SAP PAPM?
Die Anwendung folgt in seiner Umsetzung einem Baukastenprinzip. Dabei werden innerhalb eines Modells (auch Calculation Unit genannt) vorgefertigte Funktionen, die mittels verschiedener Einstellungsmöglichkeiten kundenindividuell angepasst werden können, so zusammengesetzt, dass eine logische Arbeitskette entsteht. Dies ermöglicht zwar die Entwicklung vieler kundenindividueller Lösungen, setzt aber bei deren Umsetzung eine gewisse Erfahrung mit SAP PaPM voraus.
Die Entscheidung fiel zugunsten der SAP Financial Services Datenplattform (FSDM) zur Ablage aller relevanten Daten eines Finanzinstitutes als Architekturgrundlage. Als fachliche Anwendung soll daran OneSumX von Wolters Kluwer angebunden werden. Diese bereits viele Jahre am Markt etablierte Software bietet bereits wesentliche Kreditrisiko-Funktionen.
Seit SPS 03 unterstützt HANA 2 “system-versioned tables”. Mit SPS 04 kommt das Feature für “application-versioned tables” hinzu . Mit diesen beiden Konzepten lässt sich eine bi-temporale Versionierung auf Datenbankebene ohne extensive Applikationslogik realisieren.