Page tree
Skip to end of metadata
Go to start of metadata


The Persistent Staging Area (PSA) is the inbound storage area for data from the source systems in the SAP Business Information Warehouse.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 the Business Information Warehouse. 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 if necessary (for example, the date format 31.21.1999 is converted to 19991231 in order to ensure uniformity of data).




The design of the PSA table was previously oriented towards transfer structure. The PSA table is generated for an active transfer structure in this case. The PSA as a standalone application is managed in an object tree of the Administrator Workbench. You can still use this technology when your data model is based on the previously available objects and rules (DataSource 3.x, transfer rule 3.x, update rule 3.x). However, it is  recommend to use  the concepts for DataSources and transformations available after SAP NetWeaver 7.X, which includes using the new technology of the PSA.


In the 3.x dataflow, if you activate  datasources or  transfer rules, the PSA table will be created in 3.x dataflow.

If you change a datasource in the sourcesystem and replicate the changes into BW system or perform changes directly in RSDS a new version of the PSA table can be created. It depends wether the old version of the datasource contains data or not. In case there are no data available in the PSA table no new version will be created. If there a data available and the structure or datatype has been changed in a way that is not compatible with the database (abbreviated or type changed, for NUMC also made longer) or a field has been deleted, a new PSA version will be created with the new format. The old data remains in the old PSA table but ca no longer be extracted using standard methods. Therefore make sure that there is no data remaining in the PSA table of the datasource that has not yet been uploaded to the infoprovider. If a new version has been created an addtionally entry will be created in table RSTSODS.

e.g. /BIC/B0020971000 --> first version which is 0
/BIC/B0020971001 --> 2 entries availalbe in RSTSODS

      /BIC/B0020971001 --> newest version

Examples with data records in the PSA table

New PSA version
 CHAR (5)CHAR (10)No
 CHAR (5) CHAR (3) Yes
 Adding a field - No
 Remove a field - Yes


Technical name of the PSA table

The techncial name of the PSA/Changelog table starts with: /BIC/B..... and will be generated by the system, the technical name has to be checked in each system as the name will be different.

Options for 7.x datasources:

  • transaction RSDS --> menu GoTo


  • table RSTSODS

Insert appropriate datasource in field USEROBJ + * (* --> important as this field also includes the source system)stands for the appropriate source system)


PSA - Data Update

In general if you are using 7.X dataflow the data are loaded first into PSA via infopackage and afterwards via DTP into the datatarget. 

In case you are still using the 3.x dataflow you have the following options in the the infopackage:

PSA and Data Targets/InfoObjects in Parallel (By Package)

PSA and Then into Data Target/InfoObject (by Package)

Only PSA

Deleting Requests from the PSA/Changelog table

In order to avoid a grow up to an unlimited size, it is recommended to delete unneeded PSA and changelog requests. Deleting requests can improve the performance of dataloading, decrease downtime of maintenance task and costs of data retention.

How to delete and what is should be considered is available here:

Important tables and Technical Information

Which tables and which classes are important in the area PSA are available here.




Related Content