Show TOC Start of Content Area

Process documentation Real-time Data Acquisition  Locate the document in its SAP Library structure

Purpose

SAP BW supports operational reporting on the data retrieval side by providing the option of loading data from the source system in near real time using a daemon. The real-time data acquisition process allows you to supply ODS objects from the ODS layer in SAP BW with this data for operational reporting purposes.

Prerequisites

Before you can load real-time data into SAP BW, you need to enter the source system and DataSource of the data into table RSCRT_DTA_DS_LG, along with the name of the ODS object to which it is to be loaded.

Process Flow

The data that is to be loaded into SAP BW at regular, short intervals is collected in the sources system in the delta queue of the Service API. You need to initialize the delta process beforehand.  As in a normal update, the data can then be loaded into SAP BW by executing an InfoPackage specially created for this purpose. A daemon that controls the regular execution of the InfoPackage is assigned to the InfoPackage at this time.

Data transfer begins for a DataSource from an InfoPackage for real-time data acquisition. The daemon then performs three steps for the InfoPackage assigned to it.

...

       1.      In the first step, the daemon calls the Service API in the source system. The Service API transfers the data records into SAP BW and then to the daemon. The data is updated in the PSA table.

       2.      If the data has been successfully updated to the PSA table, in the second step, the daemon confirms the transfer and the Service API changes the status of the records in the delta queue. Once the request has been successfully closed, the records are deleted from the delta queue. This occurs, as with a “normal” delta, with the next delta transfer.

       3.             3.      In a third step, the data is updated synchronously from the PSA table to the ODS objects. The changes to the A table of the ODS objects are then logged in the associated change log requests. The request that transfers the data to the PSA table (PSA request) and the change log request for each ODS object have a 1:1 relation. The data is written directly to the A table and the change log. An additional activation step for the data in the ODS object is thus not required. No data is written to the activation queue of the ODS objects since the data is activated immediately.

The requests are closed when size or time limits are exceeded. Then new requests are opened automatically to continue with real-time data transfer.

Restrictions

·        With SAP BW 3.5, real-time data acquisition functions are only available for selected scenarios.

·        You can only use real-time data acquisition to supply ODS objects as data targets.

·         A “normal” delta update and a real-time update cannot take place simultaneously for one DataSource and/or an ODS object.

If, for example, an ODS object is supplied using a real-time data acquisition daemon, data cannot be activated in the ODS object in the "normal" way before all real-time updates in this ODS object are complete or the daemon is stopped. Also, real-time data transfer cannot be started using a daemon if there are still requests in the ODS object that have not been activated. The activation queue has to be empty before a real-time update can begin.

·        An ODS object must always be supplied by the same daemon. Different InfoPackages for different DataSource/source system combinations can supply an ODS object with real-time data. However, they have to all be assigned to the same daemon.

·        For data targets that subsequently store the real-time supplied ODS objects, real-time data transfer cannot be used. The automatisms then continue to be active, that means, each ended, closed request starts the automatism for automatic further updating from the ODS object in the underlying data targets if you have activated this automatism for the ODS object. InfoPackages for real-time data acquisition may neither be used in InfoPackage Groups or in process chains.

 

 

End of Content Area