Es gibt oft Datensätze in SAP, die so groß gewachsen sind, dass es fast unmöglich ist, sie regelmäßig in einem vernünftigen Zeitraum zu extrahieren. Außerdem macht es keinen Sinn, Datensätze zu übermitteln, die schon im Zielsystem zu finden sind und sich seit der letzten Synchronisierung nicht geändert haben. In diesem Fall ist die logische Lösung die Deltaprozessbehandlung: nur solche Datensätze werden übermittelt, die seit der letzten Synchronisierung erfasst oder geändert wurden.

Das hört sich einfach an, aber es in SAP zu implementieren, kann auch kompliziert sein. Der einfachste Fall ist, wenn Sie ein – für die Identifizierung – geeignetes Feld in Ihrer Datenbank haben. In diesem Fall können Sie eine dynamische Variante in SAP definieren, um Datensätze mit dem aktuellen Datum ausfiltern zu können (im Fall eines täglichen Jobs) und Sie sind bereits fertig, um loslegen zu können – Sie können diese Variente auch in VirtDB Jobs verwenden.

Allerdings ist das nicht immer so einfach. Was passiert, wenn es kein geeignetes Feld für die Ermittlung der Deltas in Ihrem Datensatz gibt? Zum Beispiel, wenn Sie eine Kunden Mastertabelle (KNA1) aus SAP exportieren möchten? Es wurden keine Informationen darüber gespeichert, wann ein Datensatz geändert wurde.

VirtDB bietet eine flexible und effektive Lösung, um mit diesen Situationen umgehen zu können. In einem solchen Fall können Sie die normale SAP Logging-Funktion, das sog.  „Change Documents“ benutzen, und VirtDB Mass Data Extractor kann die von SAP registrierten Datenänderungen nachverfolgen.

Das ermöglicht Ihnen:

  • Ladevorgänge für inkrementelle Datenmengen in SAP durch die Benutzung Ihrer bestehenden SAP Anwendergruppe festzulegen (Keine Strafen für indirekte Nutzung werden verhängt.)
  • Die SAP Server- und Netzwerkauslastung durch die Vermeidung von unnötigen Vollauszügen zu reduzieren
  • Mehr Einblick für Ihre Business-Anwender durch die noch öfter aktualisierten Daten in Ihrer BI Systeme zu gewähren
  • Die Kosten und die Anstrengung Ihrer ABAP Entwicklung und ETL Leistungen zu sparen

Sie können die Transaktion SCDO benutzen, um zu prüfen, welche Einstellungen in der Kundenanpassung definiert sind.  Das Default-Objekt für Kunden ist „DEBI“:

Hier gibt es, wie Sie sehen, viele Tabellen, die für einen Kunden in SAP relevant sein können. KNA1 ist eine von diesen. Wenn Sie jetzt die normale Logging-Funktion aktivieren, werden alle Änderungen in diesen Tabellen in den CDHDR und CDPOS Tabellen registriert und gespeichert.

Sie können jetzt VirtDB Mass Data Extractor benutzen, um inkrementelle Datenmengen aus KNA1 exportieren zu können. Zuerst werden wir einen Vollauszug einstellen, der als Grund für die weiteren inkrementellen Ladungen dient.

Definieren Sie einfach die Tabelle / Ansicht, das Zielsystem (in diesem Beispiel MS SQL) und weitere relevante Einstellungen für die Extraktion (Name der Tabelle in MS SQL und den Upload-Modus 1 = Überschreiben):

Wenn diese Einstellungen definiert sind, speichern Sie es als eine Variante:

Wir können jetzt durch die Benutzung des Buttons in der Symbolleiste einen Vollauszug aufführen:

Die normale SAP-Job-Scheduling Schnittstelle wird aufgerufen. Hier können Sie die Einstellungen für den Job festlegen: diese werden nur einmal ausgeführt, direkt nach der Speicherung des Jobs.

Wir sind jetzt bereit, SAP Job-Monitor zu öffnen, und zu schauen, was passiert ist. Wie sie sehen wurde der Job in 12 Sekunden durchgeführt.

Prüfen sie das detaillierte Anwendungsprotokoll der Extraktion:

Wie Sie sehen wurden alle Rekorde erfolgreich zum MS SQL Zielsystem exportiert. Prüfen sie, wie sie aussehen!

Die Tabelle wurde durch die Benutzung von allen SAP Metadaten (Datentype, Primärschlüssel usw.) zusammengestellt und die Daten wurden in die Tabelle hochgeladen. Außerdem wurde eine Ansicht für diese Tabelle erfasst, um die vernünftigen Feldbezeichnungen anzeigen zu können. Sie können diese Ansicht jetzt in jedem BI Tool für die Analyse ihrer SAP ERP Daten benutzen.

Als Nächstes werden wir den markierten Kunden ändern, um die Deltaprozessbehandlung-Funktion von VirtDB demonstrieren zu können. Wir werden die Transaktion XD02 durchführen, um die Telefon- und Faxnummern zu ändern:

Nach der Speicherung der Änderungen wird SAP sie in den CDHDR und CDPOS Tabellen abspeichern. Danach sollen wir die tägliche Deltabehandlung einstellen. Zwei Sachen sollten geändert werden: zuerst wählen Sie „Use Change Documents“ in den Einstellungen der inkrementellen Extraktion aus:

Der zweite Parameter, den wir ändern müssen ist der Upload-Modus. Wir wählen „Merge“ aus: das wird die Delta-Rekorde in der MS SQL Datenbank entweder hinzufügen oder aktualisieren (wenn sie schon existieren oder wenn sie nicht auf den Primärschlüssel basieren).

Wenn diese Änderungen durchgeführt sind, speichern Sie die Einstellungen als eine Variante und definieren Sie das Datum und den Zeitraum, wann VirtDB Mass Data Extractor Change Dokuments lesen soll. Für diese Einstellungen können wir den normalen dynamischen SAP Variantenkonfigurator benutzen:

Dieser wird die „from_date“ und „to_date“ Felder immer mit Systemdaten ausfüllen, also werden immer nur die geänderten und (die neuen) Datensätze des aktuellen Tages geladen, wenn der tägliche Job durchgeführt wird.

Der Delta-Job wurde in 5 Sekunden durchgeführt:

Schauen wir an, was passiert ist!

Wie Sie sehen, gab es nur einen einzigen Datensatz, der heute geändert wurde (der, den wir geändert haben) und dieser wurde erfolgreich auf MS SQL hochgeladen. Wenn wir den Inhalt der MS SQL Tabelle abfragen, zeigt er die neuen Telefon- und Faxnummern des Kundens, den wir geändert haben.

 

Wir haben Ihnen gezeigt, wie einfach die Deltaprozessbehandlung durch die Benutzung von VirtDB sein kann. Es gibt keinen unnötigen Vollauszug, und keine Entwicklungskosten von der SAP- oder Zielsystemseite.

Wenn Sie sich in smart SAP Datenextraktion interessieren,

fordern Sie eine Demo von uns an!