Real Time Data Acquisition

Definition
Definition: Real-time data acquisition supports operational reporting and analysis by allowing the user to send data to the delta queue or PSA table in real-time and to pass this data to InfoProviders in the operational DataStore layer at regular short intervals using a daemon.
The data is stored in the BI system persistently.
Purpose
Real-time data acquisition supports tactical decision-making.
It also supports operational reporting by allowing you to send data to the delta queue or PSA table in real-time.
Use Daemon to transfer Datastore objects to the operational datastore layer at frequent regular intervals.
Prerequisites
1: The Datasource has to support real-time data acquisition.
1:1 BI Content DataSources have to be delivered with the property for supporting real-time data acquisition.
1:2 The real time enabler/indicator has to be set in the generic delta settings for generic datasources.
Process Flow
1. Data is loaded into BI at frequent, regular intervals
1:1 then posted to the DataStore objects that are available for operational reporting.
1:2 Data is available for reporting as soon as it has been successfully posted to the datastore obtject and activated.
Web Service
A: you use this service to write the data from the source into the PSA.
B: Only an infopackage (full upload) is required to determine specific parameters for real-time data acquisition.
Using Service API
A: Data from the SAP source system can be loaded into the PSA using an Infopackage created specifically for this purpose.
B: You have to simulate the initialization of the delta process for the datasource beforehand.
Challenges
1.
1: You can only use real-time data acquisition to fill DataStore objects.
1.1. Data is first transferred into the PSA and then into the DataStore object.\
1.2. The DataStore object cannot be used as the source for a further real-time data transfer to another DataStore object.
1.3. Master Data cannot be transferred to the BI System with Real-Time data acquisition
1.4. Navigation attributes of the characteristics could no longer be used in aggregates.
aggregates cannot react to real-time updates since the change run in the RDA process cannot be triggered automatically for the loaded data.
2. Datasources that are used for real-time data acquisition cannot be used in the delta process for standard data transfer.
2:1 A data transfer with RDA and a scheduled data transfer cannot be executed simultaneously in the Delta process for a DataSource because there may be only one entry in the delta queue for each datasource and target system.
2:2 A data is updated from the PSA to a DataStore object a DTP for Real-time data acquisition, and to another datastore object with a standard DTP.
3. If you load data into a datastore object with real time data acquisition, you cannot load data into this datastore object simultaneously with an additional DTP.
1a: This is because there can only be one open activation request in a datastore object.
1b: Real-time data acquisition keeps an activation request open parallel to each DTP request.
1c: A further data transfer process cannot load into the same datastore object as long as an activation request is open.
4. Depending on requirements you can nevertheless merge the data that you load with a real-time data acquisition in an infoprovider with additional datasources.
4:1 The datastore object in which you load data with real time data acquisition can be used in a multiprovider or infoset.
4:2 Using a process chain you can restrict the time in which you load data into the datastore object with real time data acquisition. You can load into the same datastore object with a different data transfer process during the remainder of the time.

Daemon
Definition: Background process that processes the infopackages and data transfer processes assigned to it at regular intervals.
Use: The Daemon controls and monitors the transfer process for real time data acquisition.
1. If you are transferring data from an SAP source system, the Daemon starts the transfer of data into the PSA using an infopackage.
2. It controls the status of the data transfer.
3. It starts the further processing of data into the datastore object using a data transfer process.
4. It closes and opens requests when threshold values are reached.
5. It triggers the subsequent process chains.

Function: When you extract data the daemon works on the basis of the list of Datasources assigned to it in the infopackage.
1. extracts the data from the source systems
2. transfers it to the PSA tables and datastore objects.
3. It informs the service API in the source system when the data for the target system has been successfully updated.
4. When the PSA request has been successfully closed and a new delta request has been opened, the updated data is deleted from the delta queue of the source system.
1. When you further update data from the PSA to the Datasource objects, the daemon works on the basis of the list of sources (datasources) and targets (DataStore objects) assigned to it in the data transfer processes.
1:1 It transfers data to the datastore object.
1:2 The data is directly activated in standard datastore objects and written to the change log.

Operating Mode
1. 1: The daemon runs in a permanent background job and switches to idle mode, during which the background job continues execution, between extraction processes.
a. If you are using API to transfer data, the RFC connection to the source system remains open.
i. This implies that a permanent RFC connection is required between each source system and BI for real time data acquisition using the service API.
b. To prevent the system from using too much main memory and to avoid keeping the RFC connection open for too long, the daemon stops independently on a regular basis and reschedules itself.
i. As a result the main memory can be released and a new RFC connection is opened.
A: This happens without having to close the request for real-time data acquisition.

Error Handling
1: The daemon writes each successfully executed step to a control table.
a. : If the extraction or update is terminated the daemon restarts itself and continues the process from the point at which it was terminated.
i. : It repeats the entire substep with the granularity of a data package.
(IE) If execution of the DTP is terminated the daemon gets the new data from the source and loads, it into the infoprovider together with the data packages that terminated previously.

DTP Process
1: The system synchronizes infopackage requests ( PSA request), data transfer process requests (DTP) and change log requests in the standard datastore object and these requests remain open across several load processes.
a. When a daemon is started, it opens a PSA request in the first load process.
b. The system opens a DTP request and change log request when the PSA request contains data. c. The daemon uses the threshold values defined in the infopackage to determine when to close a request.
i. The data transfer process copies these settings from the infopackage.
ii. When a PSA request is closed, the related DTP and change log requests in the same load process are closed too.

d. D: When the requests are closed, new requests are opened automatically the next time daemon accesses data and the data transfer for real time data acquisition continues with these new requests.
e. E: If you are transferring data from an SAP source system, data is automatically deleted from the delta queue when the new PSA request is opened.
i. You can only update data from the datastore object to further infoprovider (an infocube), for example, if the DTP and change loge, request is closed.
f. In the monitor for real time data acquisition you can close PSA and DTP requests manually.