I was
wondering quite long how my blog should touch the topic I want to discuss.
Should I start from the basics and introduce the developer step by step to data
types or maybe go straight for more advanced topics. Finally I decided that all
the basics most of us already know and I add no value to the current contents
of SAP documentation which cover elementaries quite well. It also mentions a
bit about the complex typing but there is no real example which would
truly convince me for using it neither showing the power which sits behind the
scenes. This is what I will try to feed the developer with. So please a have a
comfortable sit and be prepared to start using this technique after reading the
below.
*Nested, deep and flat*
This term usually
goes with structures and tables. Nested structure have other structure as a component. We
define such structure like
Here the address
component is a structure itself. So the +gs_user
+structure looks like:
The basic
rule for addressing the components of gs_address is
<structure_name>-<substructure_name>-<component>. It
therefore adds another level of addressing the actual components. What we gain
in exchange is now we can address whole address
at once as a whole substructure. We will focus on that later.
Before I go
further I want you to be aware that *deep*
structure is just the one whose any component (even this nested one) have
dynamic type (string, xstring, table type, reference type). In contrary any
structure which doesn't fulfill this requirement is a *flat *structure. So the structure can be flat yet nested. In our example gs_user is such structure. If we change component street or +name +to be of type string
it would be then a deep nested structure. I hope you get the difference.
*Same level grouping
*
Apart from
including whole structures as the components we can use +include to group our components under one name.+
We will use
same structure +gs_address +which
definition we already have above. Now we will use this structure to include its
definition within components of +gs_user.+
By doing so,
we no longer have +nested+ structure.
All the components are now on the same depth level. To prove that go to
debugger and see its definition:
* 1) For every month
DO 12 TIMES.
*-- first determine month bounds
g_month_start = '2008'.
g_month_start+4(2) = g_month = sy-index.
g_month_start+6(2) = '01'.
CALL FUNCTION 'RP_LAST_DAY_OF_MONTHS'
EXPORTING
day_in = g_month_start
IMPORTING
last_day_of_month = g_month_end.
- 2) Select distinct organizational assignment for employee within the month
- (might have several records so choose only one)
INTO (g_pernr,gs_year_data-orgeh)
WHERE begda <= g_month_end
AND endda >= g_month_start.
- 3) Get components of gs_year_data only for this month
CONCATENATE 'PER' g_month INTO g_comp_name. "PER01, PER02, PER03...
*-- get PERXX component
ASSIGN COMPONENT g_comp_name OF STRUCTURE gs_year_data TO .
- 5) Collect all data under one organizational key
ENDSELECT.
ENDDO.
----
FORM calculate_capacity USING i_month_start TYPE d
i_month_end TYPE d
i_pernr TYPE persno
CHANGING cs_perxx_data TYPE ts_data.
DATA l_capacity TYPE bsgrd.
- 4) Select distinct capacity for the employee
- (might have several records so choose only one)
WHERE pernr = i_pernr
AND begda +and cx_perrxx_data I was able to address the components with their old names (headcount, capacity), not the new ones (headcount_01, capacity_12 etc). It gave me the opportunity to "hide" the caller's original type and
pass only relevant part to the procedure. If I passed whole line of +gt_year_data +I would receive every time
bunch of data which I am not interested in within certain context. i.e. I don't
need to pass fields for March if I am doing calculation for February. Also the
key fields are irrelevant here.
Another
advantage is that typing formal parameter cs_perxx_data
like that, I make my subroutine more "open" to external calls. I am no
longer worried whether the actual parameter passed to subroutine is part of
larger structure or not, neither if it has the correct key fields. I am
therefore not tight to pass only specific type of structure so I make my
subroutine more "generic" in terms of the reusability.
Substitutor
The interesting thing is that I could make my ts_year_data definition like
. +At the same time I am able to address "groups" of components using gs_year_data-perXX. So nothing really changes in terms of addressing components compared to non-nested grouped structure.The only change is that in this case +perXX +means a substructure and in the previous one a group. Therefore I am still able to use the same calcuation procedure and +COLLECT +statement as the components are flat and all non-key fields are numeric.
One step further in grouping
Just before
final conclusion comes I want to show one you one more thing. I if need another
"layer" of grouping i.e. to calculate mean values for all the months
for each of the basic fields i.e
Mean for March for headcount = ( January headcount +
February headcount + March headcount ) / 3 etc
Mean for February for capacity= ( January capacity +
February capacity ) / 2
Mean for March for capacity = ( January capacity +
February capacity + March capacity ) / 3 etc
I would
therefore only change my original definition to:
...and would
receive another level of grouping. First one would be DATA or MEAN, then would
go PERXX, then components themselves HEADCOUNT and CAPACITY. This little change in definition still allows me to use calculate_capacity subroutine. I would
only have to change this line to address DATA
or +MEAN +grouping
Meanwhile I
can write some procedure which still would accept two structures namely +IS_DATA +(only for evaluation) and CS_MEAN (for real calculation) both of
type +ts_data. +This way we keep
working only on the basic structures and don't have to worry whether it is a
part of something bigger or not.
Note!
For some standard tables SAP is using something similar called repetitive structures i.e for table
PA0008. These is just a bunch of components with same subsequent suffixes
LGAXX, BETXX, ANZXX, EINXX, OPKXX where XX is b/w 01-40, but there is no usage
of INCLUDE STRUCTURE there. So in fact we are not able to work with these
components as a group, rather they have to be treated individually. For this
purpose we have to use ASSIGN COMPONENT or ASSIGN...INCREMENT in conjunction
with DO loop or just using DO...VARYING. This is however not so convenient way
of working with whole structure. If you are interested more on these kind of
structures please refer SAP documentation.
Conclusion
Summing up
our deliberations there is a huge advantage of grouping repetitive components
within structure. Not only they become more reusable but also they give us the
feeling that our final structure consists of smaller elements logically grouped
rather than loosely defined non-connected components. If you mastered in
include structures you can create highly reusable procedures not only intended
for usage of one program still providing highly specialized service. So next
time before you start developing your report stop for a moment and think over
if this concept can be somehow implemented in it. I am sure you will benefit from
using it soon.
Didn't feed you hunger?
Want to see
how to implement this concept in ABAP Dictionary or how to create such things dynamically? If so, stay tuned for
next knowledge release.
12 Comments
