Buffering Contexts (SAP Library - ABAP Programming (BC-ABA))

Buffering Contexts

The principal aim of contexts is to avoid the repeated calculation of frequently-used data which is derived from other key data. This is achieved by storing the derived data in the context buffer. Data for each module is stored separately in the buffer.

The main difference between the context buffer and the database buffers in the database interface or the SAP table buffer is that it is only periodically refreshed (every hour on the hour).The system makes no attempt to update it synchronously, or even nearly synchronously. For this reason, you cannot use the buffer for every context, or for every module within a context. Rather, you should only use it for data which does not often change.

In the Buffer type column of the Modules table, you can set the type of buffer you want to use. This can be the context buffer itself (P), a temporary buffer (T), or no buffer at all (N).

The Individual Buffering Types

Permanent (P)

This is the default buffer setting, in which the cross-transaction application buffer is used. For more information about this buffer, see the keyword documentation for EXPORT/IMPORT TO/FROM SHARED BUFFER. The cross-transaction application buffer can contain up to 128 context entries. These entries are structured using a process similar to LRU (Least Recently Used).

To display the contents of the context buffer on the current application server, choose Goto ® Display buffer in the Context Builder. The buffer is reset every hour on the hour. You can also reset it manually in the Context Builder by choosing Edit ® Reset buffer. This resets the buffer on all application servers.

Temporary (T)

If you choose this buffer type, the derived data is only buffered within a transaction. Within a transaction the buffer can contain up to 1024 entries. These entries are exported in bundles into the cross-transaction application buffer. The results of the various instances of a context are stored in the same buffer within the program.

No buffer (N)

If you choose No buffer, the derived data is not buffered. If you use this buffering type for all modules in a context, using the context will not improve system performance, but is merely a way of re-using program logic.

Permanent buffering can lead to problems when you are testing your Customizing settings. The Context Builder therefore allows you to de-activate the context buffer (buffering type P) during the current terminal session. To do this, choose Settings ® Buffering. The system displays a dialog box. Select Inactive, and choose Continue. You can activate or de-activate the context buffer for a particular user by setting the user parameter BUF to Y or SPACE (default) or N using the Maintain users transaction (SU01).

Construction of the Buffer

The context buffer contains two buffer tables for each module:

The I buffer (internal buffer), which saves each combination of module input parameters queried during the lifetime of the buffer, along with their derived values.
The E buffer (external buffer), which assigns the derived values in the module to the key values in the context. The E buffer is filled each time a query is made. The first time a query is made using a particular combination of module input parameters, the results are written to the I buffer without any reference to the key values for the context. If, however, the same combination of module input parameters is queried more than once (so that the combination already exists in the I buffer), the system writes the results to the E buffer along with the context key values). It is therefore possible for the results of a particular combination of module input parameters to appear more than once in the E buffer, since different combinations of key fields can lead to the same set of module input parameters.

The various modules within a context are linked by the derivation schema. The input parameters of a module are either key fields or output parameters of another module. The entries in the E buffer for modules which depend on other, previous modules are the same as the I buffer entries for those previous modules. The buffering type of the E buffer for the dependent module is the same as the lowest buffering type of any of the modules on which it depends. Thus, if one of the previous modules has buffering type N, the system will not store any entries in the E buffer of the dependent module.

When you access the context buffer, either during testing or using the DEMAND statement, the system first searches in the E buffer of each module, followed by the I buffer. Access to the E buffer is more direct, and quicker than using the I buffer, which usually needs to be accessed more often.

The inclusion of entries in the E buffer which have been queried more than once is an acceptance of data redundancy as the price for quicker access. The I buffer is a filter for the E buffer, only allowing redundant data when absolutely necessary. Together, the I and E buffers provide a balance of quick access time and high probability of finding an appropriate entry.

Note

When you create your own contexts, you should bear in mind the advantages of this buffering concept. Try to include as many relationships between data objects in a single context for each program, rather than using several contexts in the same program. You can also combine a group of contexts as modules of a single, larger context. Within a context, the system buffers all intermediate results in an optimal form. If you are using separate contexts, there is no link between any of the individual buffers.

Deleting a Buffer

You can delete the contents of a context buffer as follows:

in the Context Builder (Transaction SE33), choose Edit ® Delete buffer ® Local server to delete the buffer contents for a context on the current application server, or Edit ® Delete buffer ® All servers to delete the buffer contents for a context on all application servers.

You can use these functions when testing or buffering contexts.

in ABAP programs, you can use the function modules CONTEXT_BUFFER_DELETE_LOCAL and CONTEXT_BUFFER_DELETE to delete the buffer contents for a context on the local server or all servers respectively.

You can use these function modules in conjunction with changes to database contents to ensure that the contents of the context buffer are always current.

Example

The following is an example which you could use in asynchronous update:

DATA CONTEXT_NAME LIKE RS33F-FRMID.

CONTEXT_NAME = 'DOCU_TEST1'.

...

CALL FUNCTION 'CONTEXT_BUFFER_DELETE' IN UPDATE TASK
     EXPORTING
          CONTEXT_ID = CONTEXT_NAME
     EXCEPTIONS
          OTHERS     = 0.

....

COMMIT WORK.

In the example, the system calls CONTEXT_BUFFER_DELETE as an update module. You could use it as the last update call following the database changes before the COMMIT WORK statement. For more information about asynchronous update, see Programming Database Updates