Skip to Content

SDN-BLOG How to do internal Tables in BSP

<p>This blog is an accumulation of a discussion in the BSP
Forum on the SDN)</p>

<p class=MsoBodyText>People who have worked with ABAP for a while sometimes
forget that the internal table concept is rather different than what exists in
most programming languages. It is very powerful, but at the same time can be

<p class=MsoNormal>In SAP it is possible to have a table which is the rows and
a headerline which is the working area or structure which can then be commited
to the table.</p>

<p class=MsoNormal>With a BSP, if we try to create an internal table within the
BSP event or layout we will get the following error: mso-bidi-

<p class=MsoNormal>            
            +”InternalTableX” is not
an internal table – the “OCCURS n” specification is +<i> mso-bidi-


<p> class=”MsoNormal”><![if !supportEmptyParas]>The problem we are seeing as an inconsistency has to do with
the difference between classic ABAP and ABAP Objects. When SAP introduced ABAP
Objects they decided to clean up some of the legacy syntax and create stricter
rules. However they didn’t want to break the millions of line of code that
already existed, so they only implemented these stricter checks when OO is
being used. Therefore you can declare a table with a header line in a regular
ABAP program or Function Module but you can’t have one with a header line in
OO. </p>
<p>Because everything in BSP generates ABAP OO classes behind
    the scenes, you get these same stricter syntax checks. My suggestion is that
    you have a look in the on-line help at the section on ABAP Objects and always
  follow the newer syntax rules even when writing classic ABAP programs.</p>
<p>In a BSP when we need to work with a table we must always do
  the following:</p>
<p>1, in the Types definitions create a structure:</p>

            types : begin of ts_reclist,</p>
<p class=MsoNormal>+ mso-bidi-
style=’mso-tab-count:2′>                             receiver
type somlreci1-receiver,+</p>

<p class=MsoNormal>+ mso-bidi-
style=’mso-tab-count:2′>                  style=’mso-tab-count:
1′>              rec_type type

<p class=MsoNormal>+ mso-bidi-
style=’mso-tab-count:2′>                             end
of ts_reclist.+</p>

<p class=MsoNormal>+ mso-bidi-
<![if !supportEmptyParas]> <![endif]>+</p>
<p>but we must remember this is only a structure definition and
  we cannot store anything in it, although we can use it elsewhere as a
definition for Structures(WorkAreas)</p>
<p>2, in our Types definitions (this is the best place for this
one as we can then access it from many areas without having to create it
locally) so in the Types definitions we must create a TableType:</p>

<p>  class=”MsoNormal”>                         +types : tt_reclist type table of

<p> class=”MsoNormal”><![if !supportEmptyParas]> <![endif]>
this TableType is our table definition and again we cannot
store anything in it, but we can use it elsewhere as a definition for

<p>3, now that you have laid the foundations you can build and in the event handler, it is now simply a case of
creating the InternalTable based upon the Table definition:</p>

            data: t_reclist type tt_reclist.</p>
<p>and creating the structure based upon the structure

  <![if !supportEmptyParas]>


            data: s_reclist type ts_reclist.</p>

<p>as described above, the structure becomes the work area and
this is where you assign new values for elements of the table eg:<![endif]>

<p class=MsoNormal>            
            +s_reclist-receiver = ‘’.
  “<– change address+</p>

<p class=MsoNormal>+ mso-bidi-
<![if !supportEmptyParas]> <![endif]>+</p>

<p class=MsoNormal>+ mso-bidi-
            s_reclist-rec_type = ‘U’.+</p>

<p>and then once the data is in the elements of the structure,
the structure can be appended to the internal table as follows: class=”MsoNormal”></p>

<p class=MsoNormal>            

            append s_reclist to t_reclist.</p>

<p class=MsoNormal><![if !supportEmptyParas]> <![endif]></p>

<p class=MsoNormal >the internal table will then be readable for the ABAP
function and can be applied for example as follows:  class=”style1″>          
style=’mso-tab-count:1; font-family: “Courier New”, Courier, mono;’>           </p>


class=”style1″>CALL FUNCTION


            document_data = docdata

            DOCUMENT_TYPE = ‘RAW’

            PUT_IN_OUTBOX = ‘X’

            COMMIT_WORK = ‘X’ “used from



<p class=MsoNormal style1>+ mso-bidi-font-size: style=’mso-tab-count:2′>                       
            <b><u>receivers = t_reclist</u></b>+</p>

<p class=MsoNormal> class=”style1″>
  <![if !supportEmptyParas]>

<p class=MsoNormal><![if !supportEmptyParas]>F
  inally, a comment from Thomas Jung, </p>

  <![if !supportEmptyParas]>
“when defining my work area for an internal table I like to
use the like line of statement. That way if I change the structure of my table
type, I know that my work area will still be OK. Second, your types and table
types don’t have to just be declared in your code. You can create a table type
in the data dictionary and use it across multiple programs(also great for
method and function parameters). I really push hard for the other developers at
my company to use the Data Dictionary Types more and more.”</p>

  <![if !supportEmptyParas]>
Good luck with your Internal Tables in BPS’s,</p>

  <![if !supportEmptyParas]>


You must be Logged on to comment or reply to a post.
  • People reading this that aren't familiar with BSP should understand that none of the processing in here is really specific to BSP.  These discussions really just involved syntax changes due to ABAP Object.  These stricter rules for Tables with header lines can be applied to many of the new ABAP technology areas.
    • Hi Eddy,

      you are correct, this could perhaps become the sequel to this blog.

      The main point of this blog was to explain to BSP'ers who were not familiar with the ABAP Internal Table with Header Line principle, how to get over this in a BSP, because if you simply try to create an ITAB on the fly in a BSP you'll get:

      "InternalTableX" is not an internal table - the "OCCURS n" specification is missing.

      But, you are indeed correct on the reusability side.


    • Hi Tomas,

      Have to agree good blog, but just that little teaser at the bottom about the Dictionary Objects was not enough you should really go into that and push that over the coding in the BSP.