Expand +



Simple Data Type Transfer through RFC

by George Chen

December 1, 2017

Before sending data across systems you need to ensure both systems are on the same page regarding the data type. If it is a unique composite data type from the called system, then you first need to send the definition of this data type to the calling system and have it recreated. Then when you send the data over, there is no surprise or dump.

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. 

Figure 1
An example of a simple flat structure definition with 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.

(Note: A large percentage of data transfers in an SAP system is done with an RFC-enabled ABAP call. That’s why a generic data transfer is so important and widely used. A generic approach of data type or data structure definition is the core of data transfer.)

You need to send the definition of this customized structure to the calling system before you send the data back to the calling system. First, you employ the generic data type DFIES (Figure 2) to carry this definition of a customized structure to the calling system. This data types DFIES is available in the Data Dictionary (DDIC) in any SAP system. Second, you send the data of such a structure to the calling system, which as I mentioned is not in scope for this article.

Figure 2
DDIC definition of structure DFIES

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.

Figure 3
Get the data component definition into a table of the type DFIES

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.

Figure 4
Data types (or components) included in lt_comp

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.

Figure 5
Create components one by one from the data definition of DFIES

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).

Figure 6
Dynamic call of a method with dynamic parameters

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.

Figure 7
Create a structure from its component definition in lt_comp

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

An email has been sent to:


George Chen

George Chen is the owner of Lynk, Inc. An SAP consultant, he has worked on SAP Netweaver ABAP/HANA/BPC/BW/IP/TPM/CRM for the past 17 years. He specializes in process integration, performance tuning, and introducing advanced ABAP design patterns in development. He has worked with SAP America many times to conduct ABAP performance tuning and troubleshooting. His focuses are ABAP for HANA and ABAP OO in SAP NetWeaver.


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!