Purpose
The Persistent Staging Area (PSA) is the inbound storage area in BI for data from the source systems. The requested data is saved, unchanged from the source system.
Request data is stored in the transfer structure format in transparent, relational database tables in BI. The data format remains unchanged, meaning that no summarization or transformations take place, as is the case with InfoCubes.
When loading flat files, the data does not remain completely unchanged, since it is adjusted by conversion routines, where necessary (for example, the date format 31.21.1999 is converted to 19991231 in order to ensure uniformity of data).
You determine the PSA transfer method in transfer rule maintenance.
If you set the PSA when you are extracting data, you get improved performance if you use TRFCs for loading the data. The temporary storage facility in the PSA also allows you to check and change the data before the update into data targets. Coupling the load process for further processing in BI also contributes to an improved load performance. In contrast to a data request with IDocs, a data request in the PSA also gives you variousoptions for further updating data to the data targets. Coupling the load process for further processing in BI also contributes to an improved loading performance. If errors occur when data is processed further, the operative system is not affected.
The PSA delivers the backup status for the ODS (until the total staging process is confirmed). The duration of the data storage in the PSA is medium-term, since the data can still be used for reorganization. However, for updates to ODS objects, data is stored only for the short-term.
In the PSA tree of the Administrator Workbench, a PSA is displayed for every InfoSource. You get to the PSA tree in the Administrator Workbench using either Modeling or Monitoring. The requested data records appear, divided according to request, under the source system they belong to for an InfoSource in the PSA tree.
Features
The data records in BI are transferred to the transfer structure when you load data with the transfer method PSA. One TRFC is performed for each data package. Data is written to the PSA table from the transfer structure, and stored there. A transparent PSA table is created for each transfer structure that is activated. The PSA tables each have the same structure as their respective transfer structures. They are also flagged with key fields for the request ID, the data package number, and the data record number.
Since the requested data is stored unchanged in the PSA, it may contain errors if it contained errors in the source system. If the requested data records have been written to the PSA table, you can check the data for the request and change incorrect data records.
Depending on the type of update, data is transferred from the PSA table into the communication structure using the transfer rules. From the communication structure, the data is updated to the corresponding data target.
Using partitioning, you can separate the dataset of a PSA table into several smaller, physically independent, and redundancy-free units. This separation can mean improved performance when you update data from the PSA. In the BW Customizing Implementation Guide, under Business Information Warehouse ® Connections to Other Systems ® Maintain Control Parameters for Data Transfer,you determine the number of data records from which you want to create a partition. Only data records from a complete request are stored in a partition. The specified value is a threshold value.
As of SAP BW 3.0, you can use the PSA to load hierarchies from the DataSources released for this purpose. The corresponding DataSources will be delivered with Plug-In (-A) 2001.2, at the earliest. You can also use a PSA to load hierarchies from files.
Constraints
The number of fields is limited to a maximum of 255 when using TRFCs to transfer data. The length of the data record is limited to 1962 bytes when you use TRFCs.
Data transfer with IDocs cannot be used in connection with the PSA.