In system integration development, you make a Remote Function Call (RFC) to a generic function module of another system, execute some functions, and then possibly get the results back to the calling system. If the result is a generic type, such as a string or a table of strings, you can just pass the data with the mutually agreed-upon, mutually understood data type of a string or a table of strings between the calling system and callee system without a problem.

Figure 1 shows the result, which is a table of customized structure made of generic data types.

It is easy to build the same data structure definition statically in the calling system to receive the data. However, what if you have tens of thousands of different data structures, such as the structure shown in Figure 1, to be used in data transfer? You end up creating tens of thousands of different data structures one by one. That’s tedious.

I describe a composite data structure and show you how to recreate in a generic method the data structure based on a definition that you can apply to many different data structures. Simple data type means one flat composite structure of generic data types, not a nested structure that includes another structure or another table. This article is about a generic approach to create a data structure in the calling system.

Let me make an analogy: if you want to receive mail from the post office, you need to think about the incoming mail size and the quantity. Then you carry that information (definition of the data structure) home to build a mailbox (data structure) at home. Once this customized mailbox is built, you can receive mail from the post office. This article is about this first step, a generic way to build the mailbox. I do not cover the second step, which is to receive actual postal mail, because that’s easy since the mailbox is ready. Figure 2

The process of data transfer with a defined structure is as follows:

• The called system gets the definition of the structure
• The called system populates the definition in structure DFIES
• The called system -> calling system: sends the definition in DFIES to the calling system
• The calling system creates components one by one based on the definition in DFIES
• The calling system creates a structure based on the components from the previous step

This code snippet in Figure 3 dynamically interprets the data carried in a flat structure such as <ls_data> into a list of data components that includes definitions and saves the components in lt_meta. Lt_meta is in a data type of DFIES, which is universally available in any SAP system.

Step 1. Assume you have data such as lt_sample. You don’t know the exact data types and how many components lt_sample has. You can assume, for example, there are four components, each with its own data type, as shown in Figure 4. This is the data definition of one line of lt_sample.

Step 2. Loop through these four components to get the field name, internal type, length, and decimal places into internal table lt_meta of the type DFIES (the loop in Figure 3).

Step 3. The RFC call function module is initiated from the calling system to the callee. The called system responds with steps 1 and 2, sending the data definition in type DFIES to the calling system. My article “Get Data From Any Table in Another SAP System: A Generic Way in ABAP” in SAP Professional Journal and BI Expert covered a lot of detail about this RFC call, so here I skip the details. [7/2/2015]

Step 4. In the calling system, by receiving the data definition of type DFIES in lt_meta, you need to recreate the data types one by one and group them together with the data definition. In Figure 5, given the data type definition, you can recreate the data structure by creating each component of the structure one by one.

This sample code, which is based on an internal type, provides an example of type P for packed number and type C for character only. You could add more scenarios on how to handle a string, integer, or date.

For each scenario, I get the formal parameter name, parameter type (called “kind” in Figure 5, referred to as ls_parameter-kind), and the value into the format of abap_parmbind_tab and make it a table of abap_parmbind_tab.

Then in the next step I can call the method dynamically with generic parameter parameter-table to create each component (Figure 6).

This way, I have efficient coding to get a list of components created in table lt_comp.

Step 5. With this list of components in definition table lt_comp, I can create in the calling system the structure in Figure 7. In Figure 7 you create a structure definition in lr_struct based on the components defined in lt_comp. With this definition of lr_struct, you can create structure <ls_data>. This is identical to the structure of the source system. All you are doing here is understanding the data definition of the data structure of the source system and carrying the definition in a generic way so that the calling system can interpret it and use it to recreate the same structure. Thus, the calling system is ready for receiving data because the data structure is created.

Now I can replicate the structure in the calling system, and it is ready for incoming data of that type of structure.