OK. So, maybe the title is a little misleading and before I continue, I should qualify it. You can’t access any memory in ABAP. This tip can only access the current internal session, and it can only access data that is declared globally in the programs currently loaded in the internal session. Fortunately in most programs, those memory locations have a lot of data declarations.
[UPDATE] The ABAP statement variants used in this tip are marked for internal use only by SAP. Therefore, the use of these programming statements should be done at your own risk.
But what is an internal session? Without going into too much detail, an internal session (sometimes called the roll area) is the main memory area of a ABAP program. The internal session contains data and objects of all ABAP programs since the start of a program and remains in memory for the entire duration of the program. The following graphic partially shows how SAP memory is partitioned. In this example, the purple box of the internal session has two main programs (red boxes) loaded in memory. In this example, the red main program groups can either be SAP programs, Function Group, or Class Implementations.
ABAP syntax does not allow for the direct access of memory between SAP programs, but it is possible for code in one main program group to access any globally defined variable in another main program group as long as the program you are accessing has already been loaded in the internal session. In order to access the data across main program group boundaries, we will be using field-symbols. ABAP field-symbols are a powerful coding construct that “points” to a memory area. Field-symbols are assigned to memory locations during program runtime. For a full introduction to field-symbols, please visit SAP help.
In order to use a field-symbol, it first must be assigned to memory by using the ASSIGN statement. The memory of other main programs can be accessed by using the following access syntax in the assignment:
ASSIGN ('(MAIN_PROGRAM)VARIABLE[]') TO <FIELD-SYMBOL>.
I recently implemented a BADI that was triggered on the AT_SAVE event of BADI of IF_EX_WORKORDER_UPDATE. The logic I was implementing required data from the reservations associated with the production order. Lucky for me, the data I needed was declared globally in the top include of function group COBT. That means that it is available to any code that follows it.
In this example, field symbol <TAB> is defined as being able to point to anything. The ASSIGN statement sets <TAB> to point to the entire table RESB_BT in program SAPLCOBT. Once field-symbol <TAB> is pointing to internal table RESB_BT, we can manipulate the table like it is defined in the local scope.
DATA: LT_RESBB TYPE STANDARD TABLE OF RESBB, L_TABLE_NAME(20) TYPE C VALUE '(SAPLCOBT)RESB_BT[]'. FIELD-SYMBOLS: <TAB> TYPE ANY, <WA> TYPE RESBB. ASSIGN (L_TABLE_NAME) TO <TAB>. LT_RESBB = <TAB>. LOOP AT LT_RESBB ASSIGNING <WA>. ... ENDLOOP.
The following graphic illustrates how my BADI code (implemented in a private method) accesses data declared in the top include for function group COBT (main program SAPLCOBT).
I will stress here that in this example, field symbol <TAB> points to RESB_BT in main program SAPLCOBT. Therefore local variable LT_RESBB also points to the RESB_BT in main program SAPLCOBT. Any changes made to LT_RESBB will be reflected in RESB_BT in main program SAPLCOBT, so please be careful when implementing this logic as to not inadvertently introduce data inconsistencies in your SAP system.
Field-symbols are a very powerful coding construct in ABAP. If you have any other cool field-symbol tips or tricks, please share them in the comments.
The tip you describe here is documented in the ABAP syntax help (under Alternative 1 of ASSIGN – dynamic_dobj). What you failed to mention is that this variant of the syntax using (PROG)DOBJ is marked as internal use only. This means that SAP doesn’t support the use of this variant by customers or partners. It also means that SAP can remove the statement or alter the way it works in future releases.
Originally this concept was needed by the ABAP debugger. The classic debugger ran in the same session as the program being debugged and needed a way to inspect the memory values of the debuggee. However when SAP rewrote the ABAP debugger in 6.40 we split it into a separate session. The Debugger now remotely attaches to the running session and uses special kernel methods to inspect the memory of the debuggee. At some point SAP might remove the classic debugger completely and with it, this syntax variant.
Using this approach to access out of scope variables within BADIs is not necessarily a good idea – particularly if you use this approach to change data. The flow of the data into and out of the BADI is designed based upon the logic surrounding the BADI. If you alter data within the BADI that wasn’t expected, it could be too late to process the correct validation or other important triggering logic.
Dangerous but very useful.
Thanks to both Craig and Thomas for their great tips!