Passing structured data between ABAP sessions?

Question

It is generally known that ABAP memory (EXPORT/IMPORT) is used for passing data inside ABAP session across call stack, and SAP memory (SET/GET) is session independent and valid for all the ABAP sessions of user session.

The pitfall here is that SET PARAMETER supports only primitive flat types, otherwise it throws the error:

"LS_MARA" must be a character-type field (data type C, N, D or T). by

Global assignment like ASSIGN '(PrgmName)Globalvariable' TO FIELD-SYMBOLS(<lo_data>). is not always a way, for example if one wants to pass structure to some local method variable.

Creating SHMA shared memory objects seems like an overkill for simple testing tasks.

So far I found only this ancient thread were the issue was raised, but the solution from there is stupid and represents a perfect example of how you shouldn't write, a perfect anti-pattern.

What options (except DB) do we have if we want to pass structure or table to another ABAP session?

Answer 1

In the same application server, you may use EXPORT/IMPORT ... SHARED BUFFER/MEMORY ....

Probable statement for your requirement:

EXPORT mara = ls_mara TO SHARED BUFFER indx(zz) ID 'MARA'.

Between application servers, you may use ABAP Channels.

Answer 2

As usual Sandra has a good answer.

Export/Import To/From Shared buffer/Memory is very powerful. But use it wisely and make sure you understand that is is on 1 App server and is non persistent. You can use rfc to call the other app servers to get the buffer from other servers if necessary. CALL FUNCTION xyz DESTINATION ''

See function TH_SERVER_LIST . ie what you see in SM59 Internal Connection.

Clearly the lack of persistency of shared buffer/memory is of key consideration. But what is not immediately obvious until you read the docu carefully is how the shared buffer manager will abandon entries based on buffer size and avaliable memory. You can not assume shared buffer entry will be there when you go to access it. It most likely will be, but it can be "dropped", the server might be restarted etc. Use it as a performance helping tool but always assume the entry might not be there. Shared memory as opposed to shared buffer, suffers from the upper limit issue, requiring other entries to be discarded before more can be added. Both have pros and cons.

In St02 , look for red entries here, buffer limits reached. See the current parameters button that tells you which profile parameters need to be changed.

A great use of this language element is for logging or for high performance buffering of data that could be reconstructed . It is also ideal for scenarios in badis etc were you can not issue commits. You can "hold" info without issuing a commit or db commit. You can also update / store your log without even using locking. Using the simple principle the current workprocess no. is unique.

 CALL FUNCTION 'TH_GET_OWN_WP_NO'
  IMPORTING
    wp_index = wp_index.

Use the index no as part of the key to your data .

if your kernel is 7.40 or later see class CL_OBJECT_BUFFER otherwise see function SBUF_OBJ_SHOW_OBJECT

Have fun with Shared Buffers/Memory. One major advantage of share buffers over share memory objects is the ABAP Garbage Collector. SAPSYS Garbage collection can bite you!