Übertragung von Daten über Web Service

Verwendung

In der Regel erfolgt die Übertragung von Daten ins BW über eine Datenanforderung, die aus dem BW an das Quellsystem abgesetzt wird (Pull aus dem Scheduler). Sie können die Daten aber auch über Web Services von außen gesteuert die Eingangsschicht des BW, in die Persistent Staging Area (PSA) schicken. Man spricht dann von einem Push der Daten ins BW.

Wenn Sie Web Services zur Übertragung von Daten ins BW verwenden, können Sie Real-Time Data Acquisition verwenden, um die Daten im BW weiter fortzuschreiben, oder Sie können die Fortschreibung mit einem Standard-Datentransferprozess durchführen:

Wenn Sie häufig auf die Daten zugreifen möchten und die Daten eine Aktualität von einer Stunde bis zu einer Minute haben sollten, verwenden Sie Real-Time Data Acquisition. Die Daten werden dabei zuerst in das PSA des BW geschrieben. Von dort werden sie in regelmäßigen, kurzen Abständen, durch einen Hintergrundprozess, einen so genannten Dämon gesteuert, in ein DataStore-Objekt fortgeschrieben und stehen dann direkt für das operationale Reporting zur Verfügung.
Wenn die Daten im BW nicht stündlich aktualisiert vorliegen müssen, sondern eine Aktualisierung in größeren Zeitabständen für Analyse und Reporting ausreicht, verwenden Sie die Standard-Fortschreibung. Auch hier werden die Daten zuerst in das PSA des BW geschrieben. Die Fortschreibung und Weiterverarbeitung der Daten wird über eine Prozesskette gesteuert.

In SAP NetWeaver 7.0 erzeugen Sie Web Services zum Datenladen mit der Aktivierung einer im BW definierten DataSource. Die Web Services liefern Ihnen WSDL-Beschreibungen, die technologieunabhängig dazu genutzt werden können, Daten ins zu schicken.

Die SOAP-Schnittstelle des BW-Servers kann so genannte guaranteed delivery gewährleisten, da sowohl im Erfolgs- als auch im Fehlerfall eine XML-Nachricht an den Client zurückgesendet wird. Wenn der Client einen Fehler oder keine Nachricht (z.B. Verbindungsabbruch beim Versenden einer Erfolgsmeldung) erhält, kann er die Daten erneut verschicken.

Es kann aber derzeit keine guaranteed delivery only once gewährleistet werden, da es keine Abstimmung auf der Ebene einer Transaktions-ID gibt, anhand der festgestellt werden könnte, dass ein Datenpaket 'irrtümlich' noch einmal gesendet wurde und nicht mehr gebucht werden darf. Die Fortschreibung in ein DataStore-Objekt kann, wenn die Deltas mit After-Images (Deltaverfahren AIM) gebildet werden, jedoch mit solchen zuviel versendeten Daten konsistent umgehen, solange die Serialisierung sichergestellt ist. Die Serialisierung ist dann Aufgabe des Clients.

Voraussetzungen

Sie sind mit den Web-Service-Standards und -Techniken vertraut.

Siehe auch:

Web Services

Prozess

Designtime

Sie definieren im BW die Web-Service-DataSource. Beim Aktivieren der DataSource wird für die Datenübertragung ein rfc-fähiger Funktionsbaustein generiert sowie eine Web-Service-Definition, aus der Sie in einem externen System einen Client-Proxy generieren können. Beispielsweise sind in SAP-Systemen Implementierungen des WebServices in ABAP möglich.
Je nachdem, in welchem Verfahren Sie die Daten im BW weiter fortschreiben wollen, fahren Sie folgendermaßen fort:
- Sie legen den Datenfluss für Real-Time Data Acquisition fest:
  1. Nach der Definition eines DataStore-Objekts legen Sie eine Transformation mit der DataSource als Quelle und dem DataStore-Objekt als Ziel an sowie den zugehörigen Datentransferprozess für Real-Time Data Acquisition.
    
    Eine weitere Fortschreibung der Daten in nachfolgende InfoProvider ist nur mit Standard-Datentransferprozessen möglich.
  2. In einem InfoPackage für Real-Time Data Acquisition legen Sie für die Verarbeitung der gesendeten Daten Schwellenwerte für die Größe der Datenpakete und der Requests fest.
  3. Im Monitor für Real-Time Data Acquisition definieren Sie einen Hintergrundprozess (Dämon), und ordnen diesem die DataSource (mit InfoPackage) sowie den Datentransferprozess zu.
    
    Weitere Informationen finden Sie unter Bewegungsdaten über Web Service übertragen (RDA).
- Sie legen den Datenfluss für die Standard-Fortschreibung fest:
  1. Nach der Definition eines InfoProviders legen Sie eine Transformation mit der DataSource als Quelle und dem InfoProvider als Ziel an sowie den zugehörigen (Standard-)Datentransferprozess. Ggf. legen Sie nachfolgende InfoProvider, Transformationen und Datentransferprozesse fest.
  2. In einem InfoPackage legen Sie für die Verarbeitung der gesendeten Daten Schwellenwerte für die Größe der Datenpakete und der Requests fest.
    
    Weil die Festlegung der Schwellenwerte nur in einem InfoPackage für Real-Time Data Acquisition möglich ist, wird ein solches InfoPackage auch bei der Standard-Fortschreibung verwendet.
    
    Wie bei Real-Time Data Acquisition bleibt auch hier der PSA-Request über mehrere Ladevorgänge hinweg offen. Ein PSA-Request wird automatisch vom System geschlossen, wenn ein im InfoPackage festgelegter Schwellenwert erreicht wird. Um eine Fortschreibung der Daten mit einem Standard-Datentransferprozess zu ermöglichen, muss der PSA-Request auch unabhängig vom Erreichen eines Schwellenwertes geschlossen werden können. Dies wird über den Prozesstyp Request eines Real-Time-InfoPackages schließen in einer Prozesskette gesteuert.
  3. Sie legen eine Prozesskette an, welche die Datenverarbeitung im BW steuert.
    
    Diese Prozesskette startet mit dem Prozess Request eines Real-Time-InfoPackages schließen, an den sich die Fortschreibungs- und Weiterverarbeitungsprozesse anschließen.
    
    Weitere Informationen finden Sie unter Bewegungsdaten über Web Service übertragen (Standard).

Laufzeit

Sie verwenden den Web Service, um Daten in das PSA des BW zu schicken.

Eine WSDL-Beschreibung des Web Service sowie eine Testfunktion zum Aufruf des Web Service steht Ihnen in der Administration für die SOAP Runtime (Transaktion WSADMIN) zur Verfügung.

Wenn Sie Real-Time Data Acquisition verwenden, und der Dämon läuft, steuert dieser die regelmäßige Fortschreibung der Daten aus dem PSA in das DataStore-Objekt. Die Daten werden automatisch aktiviert und stehen für Analyse und Reporting direkt zur Verfügung.

Wenn Sie die Standard-Fortschreibung verwenden, und die Prozesskette läuft, steuert diese, wann ein PSA-Request geschlossen wird und somit die Fortschreibungs- und Weiterverarbeitungsprozesse angestoßen werden.