<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
confusing.</p>
<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>
<p class=MsoNormal>
+"InternalTableX" is not
an internal table - the "OCCURS n" specification is +<i> mso-bidi-
missing.</i></p>
<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>
<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
somlreci1-rec_type,+</p>
<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
ts_reclist.+</p>
<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
InternalTables</p>
<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>
<p>
data: t_reclist type tt_reclist.</p>
<p>and creating the structure based upon the structure
definiton:</p>
<p>
<![if !supportEmptyParas]>
<![endif]>
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>
<p class=MsoNormal>
+s_reclist-receiver = 'user@company.com'.
"<-- 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
'SO_NEW_DOCUMENT_SEND_API1'
EXPORTING
style='mso-tab-count:2'>
document_data = docdata
style='mso-tab-count:2'>
DOCUMENT_TYPE = 'RAW'
style='mso-tab-count:2'>
PUT_IN_OUTBOX = 'X'
style='mso-tab-count:2'>
COMMIT_WORK = 'X' "used from
rel.6.10
TABLES</b></p>
<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]>
<![endif]></p>
<p class=MsoNormal><![if !supportEmptyParas]>F
inally, a comment from Thomas Jung, </p>
<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>
<p>
<![if !supportEmptyParas]>
Good luck with your Internal Tables in BPS’s,</p>
<p>
<![if !supportEmptyParas]>
Tomas.
