What is BOXED Components in ABAP? Let me try to explain you.

In Release 7.0 EhP2, SAP has introduced a BOXED component. When you open any structure in SE11, you would notice drop down box for TYPE selection. There are 3 options available to choose from:

• Type
• Type ref to
• Type … BOXED

I recollect from one of the SAP TechED presentations that there would be a new addition to TYPES called BOXED. So, I began exploring it. I read and re-read the online help but couldn’t understand how it would be beneficial to the Application development. Finally, I wrote a small program and was able to see how LESS memory is consumed when BOXED component is used.

What is Static Box?

Currently, a BOXED component can only be Static BOX. When you defined a type as a BOXED, SAP doesn’t allocate any memory. It would rather assign an initial memory for one structure and have an “internal” memory management to point it to that memory. This is referred as Initial Value Sharing. All occurrences of any data defined with this type would point to a single initial memory.

This would be highly beneficial when you know that quite a few variables or attributes are not going to be used in your program execution path. Your complex application could have many more execution based on user action or database action or some other action. So, you would need to have those variables defined to overcome the compile time errors. These variables, without having declared as BOXED, would require its own memory. Thus increasing the memory requirement to execute your application.

How BOXED is different?

Let me show you the basic differences:

• How it is different than normal TYPE – For data declaration using TYPE, system would assign initial memory. Even if all data decoration is same and have initial value it would still have its own memory.
• How it is different object reference – For TYPE REF TO there isn’t any memory assigned. As soon as you assign some value or instantiate the object, all variables point to this one reference would be sharing same memory.

Whenever you define a BOXED component, it is would make the TYPE as deep structure. You can say, From memory consumption perspective the boxed falls in between TYPE and TYPE REF TO.

Simple Example

When you define any TYPE, you can add addition BOXED at end to define it as the BOXED components.

In this example, I have declared three set of variables – one defined with TYPE, one defined with TYPE.. BOXED and the last defined with TYPE REF TO. You can see the Memory Analysis for any variable in the New Debugger, Memory Analysis tab.

Code lines

Simple example to show memory consumption when using TYPE, TYPE REF TO and TYPE BOXED.

 
REPORT  ztest_np_simple_boxed.
*&---------------------------------------------------------------------*
*& Purpose : Simple Demo for BOXED TYPE
*& Author  : Naimesh Patel
*& URL     : http://zevolving.com/?p=1813
*&---------------------------------------------------------------------*
 
 
*---- Normal TYPE
TYPES:
  BEGIN OF lty_adrc,
    adrc TYPE adrc,
  END   OF lty_adrc.
TYPES:
  BEGIN OF lty_kunnr,
    kunnr TYPE kna1-kunnr,
    adress TYPE lty_adrc,
  END OF lty_kunnr.
*
*---- boxed TYPE
TYPES:
  BEGIN OF lty_adrc_b,
    adrc TYPE adrc BOXED,
  END OF   lty_adrc_b.
* TYPE with deep BOXED TYPE
TYPES:
  BEGIN OF lty_kunnr_b,
    kunnr TYPE kna1-kunnr,
    adress TYPE lty_adrc_b,
  END OF lty_kunnr_b.
 
* Data with Simple TYPE
DATA: ls_kunnr1 TYPE lty_kunnr.
DATA: ls_kunnr2 TYPE lty_kunnr.
DATA: ls_kunnr3 TYPE lty_kunnr.
 
* Data with BOXED TYPE
DATA: ls_kunnr_b_1 TYPE lty_kunnr_b.
DATA: ls_kunnr_b_2 TYPE lty_kunnr_b.
DATA: ls_kunnr_b_3 TYPE lty_kunnr_b.
 
* Data with Reference TYPE
DATA: ls_kunnr_o_1 TYPE REF TO lty_adrc.
DATA: ls_kunnr_o_2 TYPE REF TO lty_adrc.
DATA: ls_kunnr_o_3 TYPE REF TO lty_adrc.
 
*-------
* NO data assignment here
* Check how Memory is consumed in Memory Analysis Tab.
*-------
BREAK-POINT.
WRITE: 'done'.
 

Memory Overview

When you check the Memory Analysis, you would see something similar to this:

As you notice here, TYPE occupies full memory of what is needs. TYPE.. BOXED needs some partial memory. This memory is due to the fact that it has to keep track of the initial value sharing variables. TYPE REF TO doesn’t have any bound memory at all as nothing is yet assigned to it.

When does BOXED component gets its own Memory?

Whenever there is a possibility of losing the initial value sharing of the BOXED Component, System revokes the Initial Value Sharing and assign a separate memory to that particular variable. From the SAP’s documentation on Initial value sharing:

• Write Access to the variable
• When Variable is assigned to a Field-Symbol
• When Variable is passed as a parameter to any subroutine
• Accessing Variable using the Data reference

Memory Consumption of BOXED component in an Internal Table

With using this example, you would notice memory consumption more clearly when TYPE.. BOXED is used in the Internal table component. Since it is only allowed to add BOXED to the TYPE, I created a local TYPE with BOXED addition. I used this BOXED TYPE as a component in my TYPE for ITAB.

Code lines

ITAB Memory analysis when using BOXED components

 
REPORT ztest_np_boxed_itab.
*&---------------------------------------------------------------------*
*& Purpose : Demo of Memory Consumption of ITAB with BOXED Type
*& Author  : Naimesh Patel
*& URL     : http://zevolving.com/?p=1813
*&---------------------------------------------------------------------*
 
*---- ITAB declared with NORMAL Type
TYPES:
  BEGIN OF lty_pox,
    pox TYPE mepoitem_datax,
  END   OF lty_pox.
TYPES:
  BEGIN OF lty_po,
    po TYPE ekko-ebeln,
    pox TYPE lty_pox,
  END   OF lty_po.
*
DATA: lt_po TYPE STANDARD TABLE OF lty_po.
DATA: ls_po LIKE LINE OF lt_po.
*
*---- ITAB Declared with BOXED TYPE
TYPES:
  BEGIN OF lty_pox_b,
    pox TYPE mepoitem_datax BOXED,    "<<
  END   OF lty_pox_b.
TYPES:
  BEGIN OF lty_po_b,
    po TYPE ekko-ebeln,
    pox TYPE lty_pox_b,
  END   OF lty_po_b.
*
DATA: lt_po_b TYPE STANDARD TABLE OF lty_po_b.
DATA: ls_po_b LIKE LINE OF lt_po_b.
*
*
DATA: ls_pox TYPE lty_pox.
 
*-----
* Initial values in both Tables
*-----
DO 100 TIMES.
  ls_po-po = sy-tabix.
  APPEND ls_po TO lt_po.
ENDDO.
DO 100 TIMES.
  ls_po_b-po = sy-tabix.
  APPEND ls_po_b TO lt_po_b.
ENDDO.
BREAK-POINT.
*
*-----
* Update alternate 50 records
*-----
FIELD-SYMBOLS: <lfs_po_b> LIKE LINE OF lt_po_b.
DATA: lv_flag TYPE flag.
LOOP AT lt_po_b ASSIGNING <lfs_po_b>.
  IF lv_flag = 'X'.
    <lfs_po_b>-pox-pox-loekz = 'X'.
    CLEAR lv_flag.
  ELSE.
    lv_flag = 'X'.
  ENDIF.
ENDLOOP.
BREAK-POINT.
*
*----
* rest 50 = total 100
*----
lv_flag = 'X'.
LOOP AT lt_po_b ASSIGNING <lfs_po_b>.
  IF lv_flag = 'X'.
    <lfs_po_b>-pox-pox-loekz = 'X'.
    CLEAR lv_flag.
  ELSE.
    lv_flag = 'X'.
  ENDIF.
ENDLOOP.
*------
* Check how Memory is consumed in Memory Analysis Tab.
*------
BREAK-POINT.
WRITE: 'done'.
 

Output

You can see that initial memory requirement for the LT_PO_B is very less as it contains the BOXED component which is using the Initial Value sharing. Due to this fact, there is only the memory for “pointers” to keep track of what is using initial value.

As you keep on updating the rows in the table LT_PO_B, you would notice that the Bound Used Memory and Bound Allocated memory would increase. Like after 50 rows updates:

After all 100 rows updates with a value, would assign its own memory space:

Conclusion

When you are dealing with lot of Variables which may not be assigned in the application execution based on various different execution paths, it would be better to use BOXED TYPE. This would definitely save quite a few memory on Application Servers.

Have you tried the TYPE…BOXED yet? If yes, share your experience.