Skip to main content

Chapter 6: Master Data Caching

In the last chapter, we saw the Document Posting Engine perform the final, critical step of creating an SAP document. But let's rewind a bit. Back in the Frontend Data Validation chapter, the program checked thousands of rows of data for errors.

Have you wondered how it does this so quickly? If it had to ask the SAP database, "Is this Company Code valid?" for every single row, the program would be painfully slow. The secret to its speed is a powerful performance technique called Master Data Caching.

The Open-Book Exam Strategy​

Imagine you're about to take an open-book exam. The "exam" is validating your 1,000-row spreadsheet. The "reference books" are the huge master data tables in the SAP database.

You have two strategies:

  1. The Slow Strategy: For every question (every row), you run to the library (the SAP database), find the right book, look up the answer, and run back to your desk. This would take forever.

  2. The Smart Strategy: Before the exam starts, you go to the library once. You identify the key reference books you'll need (like the list of all valid Company Codes and GL Accounts) and make photocopies. Now, during the exam, all the answers are in a small, fast-to-access stack of papers right on your desk.

Master Data Caching is the program's "smart strategy." It makes a photocopy of the necessary reference data so that the validation step can be incredibly fast.

How It Works: Fetch Once, Check Many Times​

The caching process happens at the very beginning of the validation step. It's a simple, two-phase approach that dramatically reduces the time spent talking to the database.

Let's look at the code that makes this happen.

1. Defining the Cache: The Temporary Tables​

First, the program declares a few empty internal tables to act as our "cache" or our stack of photocopies. Each table is designed to hold a specific type of master data.

For example, t_bukrs will hold Company Codes, and t_kostl will hold Cost Centers.

* These tables will act as our in-memory cache
DATA : BEGIN OF t_bukrs OCCURS 0, " For Company Codes
         bukrs TYPE bukrs,
       END OF t_bukrs.

DATA : BEGIN OF t_kostl OCCURS 0, " For Cost Centers
         kostl TYPE kostl,
         prctr TYPE prctr,
       END OF t_kostl.

" ... other cache tables for accounts, document types, etc.

These are defined at the top of the program (YFIC_004.abap), ready to be filled.

2. Filling the Cache: The FOR ALL ENTRIES Trick​

Next, inside the validations routine, the program performs a few, large SELECT queries to fill these cache tables. It uses a very efficient ABAP statement called FOR ALL ENTRIES.

This statement tells the database: "Here is a list of all the Company Codes from my file. Please check all of them at once and give me back only the ones that actually exist in your master data table (t001)."

* Inside FORM validations

* Go to the database ONCE to get all valid Company Codes
SELECT bukrs FROM t001
  INTO TABLE t_bukrs  " Put the results into our cache table
  FOR ALL ENTRIES IN itab1
  WHERE bukrs = itab1-company_code.

* Go to the database ONCE to get all valid Cost Centers
SELECT kostl, prctr FROM csks
  INTO TABLE t_kostl  " Put the results into our cache table
  FOR ALL ENTRIES IN itab1
  WHERE kostl = itab1-cost_center.

After these statements run, our cache tables (t_bukrs, t_kostl, etc.) are filled with all the valid master data we need. We've made our photocopies.

3. Using the Cache: The READ TABLE Check​

Now, the program can loop through the uploaded data in itab1 and perform its checks. But instead of using a slow SELECT to the database inside the loop, it uses a lightning-fast READ TABLE on our in-memory cache.

* Loop through every row of uploaded data
LOOP AT itab1.

  * Check Company Code against our fast, in-memory cache
  READ TABLE t_bukrs WITH KEY bukrs = itab1-company_code.
  
  * If the READ fails (sy-subrc is not 0), it's an error!
  IF sy-subrc NE 0.
    itab1-flag = 'X'.
    itab1-message_err = 'Company Code is not valid!!!'.
    MODIFY itab1.
  ENDIF.
  
  " ... other checks for different fields using their cache tables ...
ENDLOOP.

Reading from an internal table in memory is thousands of times faster than querying a database table. By doing the heavy lifting just once at the beginning, the program ensures that the validation process is responsive and efficient, giving you instant feedback on the Interactive ALV Workbench.

Conclusion​

Master Data Caching is a classic performance-tuning pattern that is key to the MassUpload tool's success. By replacing thousands of slow, individual database queries with a handful of bulk queries and fast in-memory lookups, it makes the entire validation process fast and efficient. This ensures a smooth user experience, where errors are highlighted almost instantly, no matter the size of your upload file.

You have now completed the entire tutorial! You've journeyed from the friendly Interactive ALV Workbench, through Data Ingestion and lightning-fast Frontend Data Validation, understood the central Financial Document Line Item (itab1) structure, and seen how the reliable Document Posting Engine makes the final post.

Congratulations! You now have a complete picture of how MassUpload works, from file selection to a successfully posted SAP document.