Learn how to easily find the specific Persistent Staging Area (PSA) entry you’re looking for with these simple steps.
Key Concept
A BW system stores raw source system data in Persistent Staging Area (PSA). Behind the scenes, PSA is simply a transparent table that has the same fields as the source system’s transfer structure. When you load data from the source system and store it in PSA, the system writes it to this transparent table in BW. The system stores all PSA data from the same DataSource together in the same transparent table. The system-generated request identifier, which uniquely identifies each data load to BW, is a key for this table to keep each load’s data separate.
Understanding how BW stores Persistent Staging Area (PSA) data so that you can locate specific PSA records is helpful when you are debugging sophisticated transfer rules or update rules using simulation. It’s also useful when you are verifying InfoCube data against the original source system data that PSA stores.
You might need to examine PSA data during your BW development. Debugging update rules using simulation or verifying the raw data received from your source systems are two situations in which you might work directly with PSA data. You can see this PSA data using Administrator Workbench Monitor, shown in Figure 1.

Figure 1
View PSA data from Administrator Workbench Monitor
Unfortunately you can only see PSA data in packet-sized chunks; you can’t search for a specific record in PSA. Looking for a single record inside a large request reminds me of a small needle in a very large haystack. However, there is a way to easily locate specific records in PSA.
As mentioned earlier, BW stores PSA data in transparent tables. The trick is finding the name of the transparent table for a given PSA. You have several ways to find the PSA table associated with a DataSource, but by far the easiest is the RSTSODSPART table. This table cross-references PSA tables and their database partitions to request identifiers. Follow these four steps.
Step 1. Find a request identifier. The system assigns a request identifier to each BW data load. BW uses this system-generated identifier to identify that particular data load. The easiest way to find the request identifier is using the Administrator Workbench Monitor screen. The request identifier is the long identifier (that usually starts with REQU_) in the Header tab (Figure 1).
Step 2. Find the PSA table. Given a request identifier, use transaction SE16 to search through table RSTSODSPART (Figure 2). Paste your request identifier into the REQUEST field (Figure 3) and click on the execute icon or press F8. Figure 4 shows the resulting data records.

Figure 2
Use table RSTSODSPART to cross-reference PSA tables

Figure 3
Enter your request identifier

Figure 4
The system shows the details
This tells you that the transparent table /BIC/B0001627000 contains request REQU_3YIJF922MKDM3678AIEEJ1MVU. This is the PSA’s transparent table.
Step 3. View the PSA table. Copy the ODSNAME_TE value (/BIC/B0001627000 in Figure 4) to the clipboard. Execute transaction /nSE16 to get back to the start of the SE16 transaction. This time, paste the PSA table name into the Table Name field of SE16 and press Enter (Figure 5).

Figure 5
Enter the Table Name
The system may prompt you to select the fields to use as search criteria. If so, make sure you check the REQUEST field. Now you can perform searches of PSA table data. If you’re searching for records in a specific request, include that request identifier (REQU_3YIJF922MKDM36 78AIEEJ1MVU in this example) in the REQUEST field. If you don’t specify a request, then you see all PSA entries for all requests. Along with the REQUEST identifier you can also choose other selections. Suppose you want to see all PSA data where sold-to customer 1902 placed an order for material CN00S1. Choose the request identifier, the sold-to customer, the material, and the document class.
When you search PSA, you must specify values in the system format without any conversion exits. If you have a doubt about a field’s system format, execute the SE16 search without any selections and you can see some examples. Figure 6 shows an SE16 search with only the REQUEST selection.

Figure 6
SE16 with the REQUEST selection
You can see from this data that your customer number is 10 characters front-padded with zeros, your material has no padding (because it’s not all numeric), and your document class is a single character. Knowing this, you can choose the green arrow to go back and choose your selections, as shown in Figure 7.

Figure 7
Modify your selections to conform to the style
The results show all raw source records for orders by sold-to customer 1902 for material CN00S1 (Figure 8).

Figure 8
All raw source material for orders for customer 1902
Note
When you look at the PSA table, you see the raw data from the source system. Any conversion exits your BW InfoObjects perform do not apply to PSA data. For example, your 0MATERIAL may have a MATN1 conversion exit. When you look at a numeric material number (like 1001234) in B, it displays with no leading zeros. However, the PSA table stores itin raw format with leading zeros (000000000001001234). Another important example is fiscal period. BW stores it internally as YYYYPPP (2005011).
Step 4. Simulate an update. One of the most useful applications of this tip is for testing complex transfer rules or update rules using the “simulate update” functionality. Suppose you’ve created custom ABAP update rules that look at the first two characters of your material number and perform custom logic based on the values. During the development of these update rules, you might want to test with a specific material number. However, your data load contains several thousand materials. How do you debug using a specific material number?
First you use the tip to locate a good candidate for testing in your PSA data. Once you’ve found the data in the PSA table, you can use the DATAPAKID and RECORD fields to find that same record during a “simulate update.” The DATAPAKID field contains the packet number that holds the PSA record. The RECORD is the record number within that data packet. Figure 9 shows that a PSA record containing material CN00S1 is in data package 10, record 941. You can use this information to test using this record in the “simulate update” process.

Figure 9
Numbers in DATAPAKID and RECORD fields
Open your data load in the Administrator Workbench Monitor screen. Choose the Details tab. Open the Processing section of the request details. Since the PSA record that you want to use for debugging is in data package 10, right-click on that data package and choose Simulate Update to begin your simulation (Figure 10).

Figure 10
Select Data Package 10 for simulation
Data Package 10 contains 1,000 records, but you only want to test using one of those records (record 941). Choose the Select Simulation Records option shown in Figure 11. Once you click on the Perform Simulation button, the system asks you to choose which records from Data Package 10 you want to use in the simulation. Enter record number 941
(Figure 12). Finally, confirm the record that you’re going to use in your simulation and click on the Transfer button to begin the simulation using your selected PSA record for material CN00S1 (Figure 13).

Figure 11
Select a specific record for the simulation

Figure 12
Select record 941

Figure 13
Click on the Transfer button
David Eady
David Eady is the reporting team lead of the SI Corporation MIS team headquartered in Chattanooga, TN. The reporting team is responsible for all aspects of SAP information delivery. David has been with SI Corporation for six years and has been involved with BW for the last four years. He has a BS degree in industrial engineering from Mercer University and lives with his wife and two daughters in the foothills of northwest Georgia.
You may contact the author at eadydd@comcast.net.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.