2024 May 06 8:38 AM
In the world of ABAP development, we often encounter the need to pass data between programs. Recently, I faced a requirement to transfer an internal table from one report program to another. After extensive research, I realized there wasn’t a straightforward method available online. Therefore, I devised a solution that involves converting the table data into JSON format and passing it as a string parameter to the called program, which then converts it back into a table. I believe this approach could be beneficial to others, and here’s how I implemented it:
In the Caller Program:
Convert the Internal Table to JSON:
DATA(lv_json) TYPE string. lv_json = /ui2/cl_json=>serialize( data = lt_data ).
Pass the JSON Data to the Called Program:
SUBMIT z_submit WITH p_data = lv_json AND RETURN.
In the Called Program (z_submit):
Create a Report with a String Parameter:
REPORT z_submit. PARAMETERS: p_data TYPE string.
Define the Table Type: (Here, you would define the structure of your internal table/ Deep Structure that matches the JSON data structure.)
Convert JSON Data (String Parameter) Back to Internal Table:
DATA: lt_data TYPE <your_table_type>. /ui2/cl_json=>deserialize( EXPORTING json = p_data CHANGING data = lt_data ).
This method is particularly useful when dealing with large datasets that need to be passed between programs without the use of global variables or database persistence. It’s a clean and efficient way to serialize and deserialize data.
I hope this technique proves to be useful. If you have any insights or know of a more straightforward method, please feel free to share your thoughts!
#abap
2024 May 06 9:15 AM
That is a nice trick indeed. However I think that if you need to use it, the design of the report being submitted is flawed.
Selection parameters are meant to be filled by end users and no end user is able to enter a JSON string manually.
A simpler approach would be to use EXPORT TO MEMORY ID / IMPORT FROM MEMORY ID statements.
2024 May 06 10:33 AM - edited 2024 May 06 10:35 AM
This trick is not needed anymore, you can pass any kind of data object (*) if you indicate "NO-DISPLAY".
Example:
REPORT.
PARAMETERS itab TYPE string_table NO-DISPLAY.
START-OF-SELECTION.
IF itab IS INITIAL.
itab = VALUE #( ( `Hello world` ) ).
SUBMIT zzsro_pass_any_itab_via_submit WITH itab = itab AND RETURN.
ELSE.
WRITE itab[ 1 ].
ENDIF.
(*) To be precise (ABAP Keyword Documentation (sap.com)😞
"If the addition NO-DISPLAY is specified, a selection parameter can have any data types except for reference types. These selection parameters can only be filled using the WITH addition of the SUBMIT statement. In this case, unlike the general conversion rule for deep types, the same rules apply as when importing data from a data cluster."
2024 May 06 7:57 PM
Typically you need this kind of solution if the report already exists and you are not the owner. In this case you have rarely a string parameter. But if you own the report you better use a class or fm in order to code the logic.
2024 Jul 30 2:58 PM - edited 2024 Jul 30 5:03 PM
This is a really good solution for I was searching for days now.
Beside the programs you may also use it in function modules to pass table content without exporting it to a file before.
However, it might be slow depending on the amount of data. "deserialize" will take a while with a large amount of data.
But beside that, this is the best, easiest and simplest solution I found.
Many thanks for sharing it.
2024 Jul 30 3:18 PM
Can't you declare the parameter directly as type internal table NO-DISPLAY instead of string + serialization? (you declare the type of the internal table in a class or interface)
2024 Jul 30 5:16 PM
Dear Sandra,
in my case no.
I was searching for a way to pass unspecified table data through an function module, in my case an RFC function module. Here the possibilities are limited. No references, pass by value and so on.
There are ways to transfer tables to text files or to XML files. But files are no Option.
I found a way to create an XML string, but converting this back to the original table data in the receiving SAP System was complicated.
That JSON makes things a lot more comfortable and with lesser Coding lines.
Well, the success of RFC still needs to be proved but a small test snippet in a local program looks promising.
KR
Markus
2024 Jul 31 8:29 AM
Passing parameters by RFC is a different question than passing by SUBMIT (the topic of the blog post). RFC-enabled function modules may receive parameters of any table type or deep structure provided that the type is defined in the ABAP Dictionary, it's discouraging to create manually many types in case of a deep type; to avoid this the workaround is to use XML, JSON or whatever format. But for SUBMIT, it's the wrong solution because you don't need to define the type in the ABAP Dictionary, the best solution is to declare the parameter via PARAMETERS NO-DISPLAY and its type in a class or interface (convenient to declare via TYPES).