This blog will be the shortest of previous lengthy ones, but not less useful I hope:
So far we have said that we can work with nested structures as independent units. This could be used as a replacement for what SAP delivers by standard – repetitive structures, but also can be handful for custom made reports. I hope you have already tried that at least just for sport.
Local vs Global
Today I am going to focus on how to implement this concept in DDIC objects, namely including structure definition within another. What we already did was using include concept only for local data objects. This worked pretty fine for local subroutines etc. But the real advantage comes with going beyond program bounds.
I didn’t spot it
You might think so, if you look that this technique is more or less used across SAP standard tables and structures which you work every day with.
The above screenshot is nothing but PA0001 (Organization Assignment) table structure, which is basic table for Employee Master Data. If you look closer you shall see that in fact the definition looks like
Do you already get why I did that? We can now clearly see that table definition is nothing but a bunch of includes. I am not going to discuss the meaning of each structure. The important is that this table definition carries only one field MANDT and the rest is just a composition of all the other, standard structures.
Furthermore, one structure PAKEY is marked as KEY one, which makes all the fields the structure comprises of, the key fields of the table. For me this means that:
- we can use this structure across all Infotype tables as a primary key -> this makes the key uniform for all of these tables
- in program we can pass only the key (structure) for any Infotype we want, no matter which we are currently working with -> this makes our programs more generic as we might be interested only in this part to determine record uniqueness
- any change to KEY part will reflect all the Infotype tables -> this makes me sleep well as I don’t bother it will affect any of my live-running programs
How that maps to our example we are persistently working on? I believe couple screenshots below will give you fair understanding of that.
You may like it or not, but I like my original example, so I keep working on it. All in all it is the matter of understanding what I want to say by writing this blog. I am sure later you will find it useful in much more sophisticated examples.
Just for reminder and people who might have missed our previous classes. The definition we want to achieve looks like
So first goes our basic data structure. The definition is quite obvious.
The next step is simply creating another structure ZSTR_PER_DATA including ZSTR_DATA definition twice – one for DATA, one for MEAN. We therefore select appropriate option from menu…
…and give structure name we want to include in the definition.
We repeat it for MEAN
The Group field is arbitrary and we can live without it, but filling this field in will allow us to address whole substructure as one entity in the program.
Eventually we end up with such definition
We do the same to create top level structure but this time we just include structure ZSTR_PER_DATA.
After a moment of clicking and typing we should have the following
We have two levels of nested structure here. Each of them can be addressed separately using its group name. So this structure is ready now to be used across all programs including the one discussed in the first blog.
As you can see there is no significant difference whether you are working with locally typed data objects or with globally typed ones. Still the concept of treating parts of structure as independent entities applies here. What is more, you gain the ability to type this way parameters of global objects like Function Modules, methods of global classes etc. This opens another door in the programming possibilities.
“Silence is the virtue of fools” – FrancisBacon
I am not going to be silent, as there is much more to say about typing. So get prepared.