Real-Time Data Acquisition

Wir empfehlen, Real-Time Data Acquisition zu verwenden, wenn die Daten in kürzeren Zeitabständen als bei eingeplanter Datenübertragung ins BW übertragen werden sollen (einmal in der Stunde bis zu einmal in der Minute), und in Analyse und Reporting die Daten mehrmals am Tag aktualisiert verwendet werden müssen.

Die folgende Übersicht zeigt die Abgrenzung zwischen der Standard-Datenbereitstellung über eingeplante Datenanforderungen und Real-Time Data Acquisition:

• Die DataSource muss Real-Time Data Acquisition unterstützen.

  Unterstützung von Real-Time Data Acquisition ist eine mögliche Eigenschaft von DataSources, die über Web Service, über das BW Service API (SAPI) oder über das Operational-Provisioning-Framework (ODP) Daten bereitstellen. In der DataSource-Pflege zeigt die Registerkarte Extraktion unter Real-Time diese Eigenschaft an.

  DataSources, die über das SAPI oder über ODP mit ODP-Kontext SAPI Daten bereitstellen, können unter folgenden Voraussetzungen für Real-Time Data Acquisition verwendet werden:
  • BI-Content-DataSources müssen mit der Eigenschaft, Real-Time Data Acquisition zu unterstützen,  ausgeliefert sein.
  • Generische DataSources müssen in den Einstellungen zum generischen Delta das Kennzeichen Real-Time-fähig gesetzt haben (sieheDeltaübertragung ins BW).

  Für andere ODP-Kontexte wird Real-Time Data Acquisition auf bereits auf Kontext-Ebene unterstützt und nicht auf DataSource-Ebene: Die ODP-Kontexte HANA, BYD und BW unterstützen Real-Time Data Acquisition nicht. Der Kontext SLT~<Queue-Alias> unterstützt Real-Time Data Acquisition, d.h. in der DataSource-Pflege wird die Eigenschaft entsprechend angezeigt.

  Hinweis

  • Real-Time Data Acquisition als Eigenschaft von DataSources, die Daten über das BW Service API bereitstellen, ist technisch grundsätzlich nur unter folgenden Voraussetzungen möglich: Im Quellsystem hat das BW Service API mindestens den Releasestand Plug-In-Basis 2005.1 bzw. für 4.6C-Quellsysteme Plug-In 2004.1 SP10.

  • Voraussetzung für Real-Time Data Acquisition bei der Datenübertragung über ODP ist im Quellsystem:
    • Plug-In Basis (PI_BASIS) Releasestand SAP NetWeaver 7.3 SPS 08 oder höher und SAP Hinweis 1931427
    • Plug-In Basis (PI_BASIS) Releasestand SAP NetWeaver 7.31 SPS 05 oder höher und SAP Hinweis 1931427
    • Plug-In Basis (PI_BASIS) Releasestand SAP NetWeaver 7.4 SPS 02 oder höher und SAP Hinweis 1931427

  • Für Real-Time Data Acquisition können nur solche Web-Service-DataSources verwendet werden können, die Sie über die DataSource-Pflege im BW (Transaktion RSDS) definiert haben.

• Wenn Sie in ein DataStore-Objekt laden, müssen Sie den Datenfluss mit Transformation zwischen DataSource und DataStore-Objekt modellieren. Ein Datenfluss mit 3.x-Objekten unterstützt Real-Time Data Acquisition nicht.

Die Daten sollen in regelmäßigen, kurzen Abständen ins BW geladen werden und in die für das operationale Reporting verfügbaren InfoProvider verbucht werden.

Neben DataStore-Objekten (Standard- und schreiboptimierte DataStore-Objekte) können auch HybridProvider über Real-Time Data Acquisition mit Daten versorgt werden. Ein HybridProvider besteht sowohl aus einem DataStore-Objekt als auch aus einem InfoCube. Die eigentliche Real-Time-Fortschreibung erfolgt in das DataStore-Objekt des HybridProviders. Der InfoCube spielt die Rolle eines Aggregates für das DataStore-Objekt. Er wird durch einen mit dem HybridProvider generierten Standard-DTP beladen, der erfolgreiche, geschlossene RDA-Requests fortschreibt. Eine auf dem HybridProvider definierte Query bezieht ihre Daten aus dem InfoCube (Historie) und aus dem Change Log des DataStore-Objektes (aktuelle Daten). Diese Architektur des HybridProviders ermöglicht einen performanten Zugriff auf die Daten bei Analyse und Reporting. Weitere Informationen finden Sie unterHybridProvider anlegen.

DataStore-Objekte, die Bestandteil eines HybridProviders sind, können unabhängig vom HybridProvider nicht verwendet werden. Ein DataStore-Objekt kann daher entweder ausschließlich das Ziel in einem RDA-Datenmodell sein oder Bestandteil eines HybridProviders in einem RDA-Datenmodell, aber nicht beides gleichzeitig.

Um die Synchronisation von Bewegungsdaten und Stammdaten zu gewährleisten, können Daten mit Real-Time Data Acquisition auch in InfoObjects als InfoProvider übertragen werden. Unterstützt wird dabei die Real-Time-Übertragung von Attributen und Texten.

Im Folgenden wird der Begriff InfoProvider verwendet, wenn sich Informationen sowohl auf HybridProvider, auf unabhängige DataStore-Objekte als auch auf InfoObjects beziehen.

Für Real-Time Data Acquisition werden spezielle InfoPackages und Datentransferprozesse für die Datenübertragung verwendet. Ebenso gibt es spezielle Hintergrundprozesse, so genannte RDA-Jobs, die die Datenübertragung mit Real-Time Data Acquisition steuern und überwachen. Für Web Service und BW Service API heißen diese Jobs Dämonen, für ODP heißen die Jobs Datenpaketjobs. Wenn die Daten erfolgreich in den Stammdatentabellen verbucht sind bzw. im DataStore-Objekt (des HybridProviders) verbucht und aktiviert sind, stehen sie für Analyse und Reporting zur Verfügung. Ein Auffrischen der Queryanzeige genügt, um die aktuellen Daten anzuzeigen. Die Query zeigt den Zeitpunkt der letzten Aktualisierung durch einen Dämonlauf an - auch wenn keine neuen Daten verbucht worden sind.

Für Web Service und BW Service API heißt der RDA-Job, der die Datenübertragung steuert und überwacht, Dämon. Die Daten werden in diesem Fall zuerst in die Persistent Staging Area (PSA) des BW übertragen. Hierfür wird ein InfoPackage benötigt. Vom PSA werden die Daten über einen Datentransferprozess in den InfoProvider fortgeschrieben. Der Ablauf bei der Datenübertragung aus der Quelle ins PSA unterscheidet sich folgendermaßen:

• Über Web Service

  Die Daten der Quelle können durch die Nutzung des Web Service direkt in das PSA geschrieben werden, d.h. die Übertragung der Daten erfolgt von außen gesteuert ohne Anforderung aus dem BW. Ein InfoPackage ist in diesem Fall nur nötig, um bestimmte Parameter für Real-Time Data Acquisition festzulegen.

• Über Service API

  Die Daten des SAP Quellsystems können auf Anforderung aus der Delta-Queue des Quellsystems mit einem speziell dafür angelegten InfoPackage ins PSA geladen werden. Zuvor muss für die DataSource eine Initialisierung des Deltaverfahrens durchgeführt worden sein.

  Hierbei sind zwei Fälle zu unterscheiden:

  • Die Anwendung im Quellsystem schreibt die Daten in die Delta-Queue des BW Service API.

    Hier holt der Dämon die Daten ohne Extraktoraufruf ab.

  • Die Daten werden nicht automatisch von der Anwendung in die Delta-Queue geschrieben, sondern vom Extraktor auf Anforderung aus dem BW.

    Bei Extraktoren, die synchron auf Anforderung aus dem BW die Daten an das Service API übergeben, z.B. beim generischen Extraktor, ruft der Dämon den Extraktor auf, der dann die Daten in die Delta-Queue schreibt. Von dort werden sie dann direkt ins BW übertragen.

Für ODP heißt der RDA-Job, der die Datenübertragung steuert und überwacht, Datenpaketjob. Die Daten werden in diesem Fall nicht in die Persistent Staging Area (PSA) des BW, sondern über einen Datentransferprozess direkt in den InfoProvider übertragen. Das Quellsystem benachrichtigt das BW-System über neue bzw. geänderte Datensätze in der operationalen Delta-Queue des Operational-Data-Provisioning-Frameworks. Daraufhin startet im BW-System ein Datenpaketjob, um die Daten aus der Delta-Queue zu holen und ins BW zu übertragen.

• Sie können mit Real-Time Data Acquisition HybridProvider, vom HybridProvider unabhängige DataStore-Objekte sowie InfoObjects (Attribute, Texte) versorgen. Unterstützt wird dabei die zweistufige Datenübertragung, zuerst ins PSA und danach in den InfoProvider. Das DataStore-Objekt kann nicht als Quelle für eine weitere Real-Time Datenübertragung in einen weiteren InfoProvider genutzt werden, d.h. eine mehrstufige Datenübertragung mit Real-Time Data Acquisition ist nicht möglich.
• Für die Übertragung über das BW Service API gilt: DataSources, die für Real-Time Data Acquisition verwendet werden, können für die Standard-Extraktion und -Übertragung (Einplanung mit Standard-InfoPackages) im Deltaverfahren nicht gleichzeitig verwendet werden. Für eine DataSource sind die Datenübertragung mit RDA und die eingeplante Datenübertragung im Deltaverfahren gleichzeitig nicht möglich, da pro DataSource und Zielsystem nur ein Eintrag in der Delta Queue existieren kann.

  Für Daten, die per Real-Time Data Acquisition ins PSA übertragen wurden, ist neben der reinen RDA-Fortschreibung und neben der reinen Standard-Fortschreibung folgendes Fortschreibungsverfahren denkbar, bei dem beide Übertragungsmechanismen parallel verwendet werden:

  Die Daten werden aus dem PSA per DTP für Real-Time Data Acquisition in einen InfoProvider fortgeschrieben und per Standard-DTP in einen anderen InfoProvider. Die folgende Abbildung veranschaulicht dieses Verfahren:

  

• Wenn Sie über Real-Time Data Acquisition Daten in ein Standard-DataStore-Objekt (auch als Bestandteil eines HybridProviders) laden, können Sie nicht gleichzeitig über einen weiteren DTP in dieses DataStore-Objekt Daten laden. Dies liegt daran, dass es in einem DataStore-Objekt immer nur einen offenen Aktivierungs-Request geben kann. Diese Einschränkung gilt nicht für schreiboptimierte DataStore-Objekte und auch nicht für InfoObjects.

  Real-Time Data Acquisition hält parallel zu jedem DTP-Request einen Aktivierungs-Request offen. In einem DTP-Request für RDA können über einen gewissen Zeitraum verteilt mehrere Datenpakete geladen werden. Jedes Datenpaket wird direkt nach seiner Übertragung im DataStore-Objekt aktiviert. Solange ein Aktivierungs-Request offen ist, kann kein weiterer Datentransferprozess in dasselbe Standard-DataStore-Objekt laden. Verwenden Sie daher bei der Modellierung Ihres Datenflusses Real-Time Data Acquisition nicht, um in ein Standard-DataStore-Objekt zu schreiben, in das sie gleichzeitig noch mit einem weiteren Datentransferprozess Daten laden müssen.

  Je nach Anfoderung können Sie dennoch die Daten, die Sie über Real-Time Data Acquisition laden, in einem InfoProvider mit weiteren Datenquellen zusammenführen:

  • Sie können anstelle eines Standard-DataStore-Objekts ein schreiboptimiertes DataStore-Objekt verwenden.

    Weitere Informationen:Schreiboptimiertes DataStore-Objekt

  • Sie können das DataStore-Objekt, in das Sie über Real-Time Data Acquisition Daten laden, mit einem weiteren DataStore-Objekt in einem CompositeProvider, einem MultiProvider oder einem InfoSet verwenden.
  • Sie können über eine Prozesskette den Zeitraum, in dem Sie über Real-Time Data Acquisition Daten in das DataStore-Objekt laden, beschränken. In der restlichen Zeit können Sie über einen anderen Datentransferprozess Daten in dasselbe DataStore-Objekt laden.

    Weitere Informationen:

    Real-Time Data Acquisition über Prozessketten steuern

    Request-Konzept

Wenn die Datenübertragung von Daten mit Real-Time Data Acquisition in einen existierenden Datenfluss integriert werden soll, so gibt es zwei Alternativen:

• Verwendung von zwei verschiedenen DataSources

  Eine DataSource führt die Standard-Datenübertragung durch, die zweite DataSource überträgt die Daten mit Real-Time Data Acquisition. In einem CompositeProvider werden die Daten anschließend zusammengeführt.

• Verwendung einer einzigen DataSource

  In diesem Fall muss die Standard-Datenübertragung komplett durch ein Real-Time Data Acquisition Szenario ersetzt werden.

Weitere Informationen finden Sie unterReal-Time Data Acquisition.