So nutzen Sie SAP Databricks zur Integration von ServiceNow-Daten

Vor kurzem haben SAP und Databricks ihre strategische Partnerschaft bekannt gegeben, in deren Rahmen Databricks als native Komponente in die SAP Business Data Cloud integriert wird. Die nahtlose Kommunikation zwischen den beiden Systemen ermöglicht es Datenexperten, Data-Science-Lösungen zu entwickeln, Machine-Learning-Funktionen wie das Verfolgen von Experimenten und die Versionierung bereitgestellter Modelle zu nutzen, sowie von Delta Lake, dem leistungsstarken Open-Source-Storagesystem, zu profitieren. Die Einbindung von Databricks- Workspaces in das SAP-Ökosystem kann eine Lösung für zwei Themen sein, die bisher als besonders problematisch galten: kostengünstiger, aber leicht zugänglicher Massenspeicher und die Verfügbarkeit von nativen Tools zur Erfassung von Daten von Drittanbietern. Dieser Artikel zeigt ein Beispiel dafür, wie Sie Letzteres jetzt ohne zusätzliche lizenzierte Integrationstools und -produkte erreichen können.

In einem kürzlich erschienenen Artikel haben wir einen Überblick aus der Vogelperspektive zu der SAP Databricks-Integration gegeben und einige wichtige Fragen zur strategischen Bedeutung, zur Architektur und zu einigen potenziellen Einschränkungen beantwortet. Nun ist es Zeit für ein praktisches Beispiel. Wir werden eine einfache Datenapplikation entwickeln, die Daten aus der ServiceNow-API als reales Beispiel abruft und in eine historisierte Tabelle in SAP Datasphere einspeist. Der Prozess wird so geplant, dass er in einem vorab festgelegten Zeitrahmen ausgeführt wird, wobei die Planungsfunktionen von Databricks genutzt werden, die standardmäßig Überwachungs- und Warnfunktionen bieten. Beginnen wir mit einem Überblick über die Architektur der Anwendung.

Architektur

Die Anwendung besteht aus einem einzigen Python-Notebook, das den Datenfluss koordiniert. Die Verwendung von Notebooks ermöglicht die Zusammenarbeit zwischen Ingenieuren und Datenanalysten und bietet eine schnelle und einfache Möglichkeit, den gesamten Prozess zu planen. Das folgende Diagramm zeigt den Datenfluss und wie die einzelnen Komponenten miteinander in Beziehung stehen.

Das Quellsystem ist ServiceNow, eine cloudbasierte Plattform, die Unternehmen dabei unterstützt, digitale Workflows in den Bereichen IT, Personalwesen, Kundenservice und anderen Geschäftsbereichen zu automatisieren und zu verwalten. Wir werden die REST-API abfragen und Tickets des Kundensupports schrittweise abrufen. Dabei werden jedes Mal nur die zuletzt aktualisierten Einträge zurückgegeben, wodurch sich die Größe der Datenmenge erheblich reduziert. Das Ziel ist eine historisierte Tabelle in Databricks oder SAP Datasphere. Eine historisierte Tabelle verfolgt historische Änderungen von Dimensionsdaten im Laufe der Zeit, indem sie den Zeitraum angibt, in dem jeder Datensatz als aktiv gilt. Wenn eine Änderung in einem bestimmten Datensatz festgestellt wird, wird ein neuer Eintrag hinzugefügt und der aktuellste Datensatz entfernt. Eine typische historisierte Tabelle vom Typ SCD 2 besteht aus zwei Metadaten-Spalten (Zeitstempel „valid_from“ und „valid_to“), natürlichen und Ersatzschlüsseln sowie mehreren anderen Attributen, die Änderungen unterliegen können.

Solche historisierten Tabellen lassen sich ganz einfach mit dlt (Data Load Tool) erstellen und pflegen, einer Open-Source-Python-Bibliothek, die leichtgewichtige APIs für das Laden von Daten aus mehreren Quellen, das Speichern in gängigen Datenbankformaten oder Cloud-Speichern und eine intuitive Möglichkeit zur Verfolgung von Änderungen in Datensätzen enthält. Es geht lediglich darum, unsere Quelle und unser Ziel zu definieren - in diesem Fall die ServiceNow REST API und SAP Datasphere. Anschließend müssen wir noch einige Konfigurationen vornehmen und die Pipeline starten. dltHub übernimmt dann die schrittweise Datenextraktion aus der Quelle und die Übernahme in das Zielsystem.

Implementierung

Die Anwendung besteht aus drei einfachen Methoden, die die Quellkonfiguration definieren, eine Verbindung zum Ziel (SAP Datasphere) herstellen und die dltHub-Pipeline ausführen. Sensible Informationen wie Anmeldedaten können sicher im Secret Scope von Databricks gespeichert und innerhalb des Notebooks abgerufen werden.

Die Planung des Prozesses ist unkompliziert und kann über die SAP Databricks-Benutzeroberfläche erfolgen. Es ist möglich, komplexe Cron-Ausdrücke für das Intervall zu definieren, Benachrichtigungs-E-Mails bei Erfolg und Misserfolg zu erhalten und sogar Parameter für die Ausführung anzugeben.

Das Ergebnis ist eine vollständig historisierte Tabelle mit Daten aus der ServiceNow-Tabellen-API. Bei jeder nachfolgenden Pipeline-Ausführung werden nur neue Daten aufgenommen und Änderungen und Aktualisierungen in bestehenden Datensätzen auf der Grundlage des definierten zusammengesetzten Schlüssels verfolgt.

Interoperabilität in der Praxis

Der vorgestellte Ansatz ist in hohem Maße portabel und ein Paradebeispiel dafür, was die Interoperabilität von Systemen in einem Ökosystem aus offenen API-Spezifikationen und Open-Source-Tools leisten kann: Das Python-Modul „dlt“, das wir für das Laden von Daten im ELT-Stil verwenden, verfügt über zahlreiche vordefinierte Schnittstellen zu Quell- und Zielsystemen und harmonisiert alle Datentransporte auf einen Mindeststandard. Anstatt Daten aus der ServiceNow-API zu extrahieren, könnten wir problemlos zu jeder REST-API, relationalen Datenbank oder Objektspeicherquelle wechseln. Zu den unterstützten Datenquellen zählen Salesforce, Shopify, Google Analytics, Jira, Asana und viele mehr. Die Konfiguration verschiedener Zielsysteme erfordert hingegen nur geringfügige Änderungen an der Pipeline-Konfiguration und eröffnet vielfältige Möglichkeiten für die Verwendung von Databricks und SAP-Systemen. Der Databricks Unity Catalog ist ein typisches Zielsystem für die Datenübermittlung und kann problemlos als dauerhafte, vollständig wiederholbare permanente Erfassung der aus der Quelle abgerufenen Änderungen genutzt werden. Bewahren Sie eine Delta-Tabelle wie diese als Archivierungsebene auf und erstellen Sie von dort aus alle verfeinerten nachgelagerten Datenobjekte.

SAP-Systeme können unter Verwendung von SAP HANA ODBC-Verbindungen direkt angesteuert werden. Auf diese Weise können wir die vorgestellte Pipeline nutzen, um Daten aus praktisch jedem Quellsystem in jedes SAP-System zu übernehmen, auf dem eine HANA-Datenbank läuft: S4, BW oder Datasphere. Und das Beste daran: Damit dies funktioniert, benötigen wir nicht einmal Zugriff auf einen SAP Databricks- Workspace. Jeder Databricks- Workspace auf Azure, Google Cloud oder AWS kann zur Ausführung dieser Art von Pipeline verwendet werden. Wenn Sie die Grenzen der Effizienz wirklich ausreizen wollen, brauchen Sie nicht einmal Databricks. Der Python-Code kann überall ausgeführt werden - in serverlosen Applikationsframeworks, auf lokalen Servern oder innerhalb von Apache Airflow-Tasks. Ein schönes Beispiel für Interoperabilität und die unendlichen Möglichkeiten der Optimierung automatisierter Datenverarbeitungssysteme, um Ihren spezifischen Prozessanforderungen oder technischen Präferenzen gerecht zu werden.

Die nun unmittelbar bevorstehende Zukunft mit SAP Databricks und dessen nativer Delta Sharing-Integration in die SAP Business Data Cloud macht diesen Ansatz für uns besonders attraktiv: Anstatt Daten über eine langsame ODBC-Verbindung zu übertragen, kann SAP Databricks alle eingehenden Daten in seinem nativen Delta Table-Format speichern und diese Daten ohne Datenreplikation an BDC weitergeben.

ServiceNow-Daten mit SAP Databricks integrieren: unser Fazit

Dieses praktische Beispiel veranschaulicht einen einfachen, aber effektiven Anwendungsfall von SAP Databricks für die Erstellung einer Anwendung zur Datenextraktion und -erfassung.

Durch die Verwendung von dltHub können wir Informationen aus ServiceNow schrittweise in SAP Datasphere oder jede andere HANA-Datenbank einlesen und so eine konsistente und überprüfbare Änderungsverfolgung ermöglichen. Die Integration optimiert nicht nur die Entwicklung und Planung durch eine intuitive Pro-Code-Schnittstelle, sondern erhöht auch die Betriebssicherheit durch integrierte Überwachungs- und Warnfunktionen.

Während sich unser Beispiel auf eine einfache ServiceNow-Integration konzentrierte, lässt sich derselbe Ansatz auch auf komplexe Unternehmensszenarien übertragen und bildet somit eine solide Grundlage für erweiterte Analysen, maschinelles Lernen und (nahezu) Echtzeit-Datenprodukte in der SAP Business Data Cloud.

Wenn Sie mehr erfahren möchten, nehmen Sie einfach Kontakt zu uns auf - wir freuen uns auf den Austausch mit Ihnen!