Skip to end of metadata
Go to start of metadata

Hello All,

 Every new challenge is the path to learn new concepts. I find it happening every time. Even having not-so ideal design can force us to think out of box and in turn learn new things.

Credits: Chris Paine, Thomas Jung

To fulfill a requirement where an ABAP screen will call a Web Dynpro Screen and inturn pass values to the screen, I stumbled upon the concept of Shared Memory. In this WIKI I would liek to share the short sample which helped me realise the potential of shared memory.

The sample scenario: Two reports. One report shall set the value in shared memory and another shall read the same and display.

Firstly, we would have to create the Shared memory area class. The steps are as follows:

     a. Create a Shared Area(T/n : SHMA)
     b. Create a Root class


     c. Enable the shared memory option in the class properties


     d. Create attributes and Getter & Setter methods to set and get the values of the attributes. These attributes shall be the values you wish to pass from ABAP to WD app.

In our scenario, we have an attribute named UNAME of type String. We also have two methods: SET_UNAME & GET_UNAME with parameters UNAME_IMP and UNAME_EXP respectively.    

In the method SET_UNAME, write the following code:  UNAME = UNAME_IMP. Here we are setting the class atribute by importing parameter

In the method GET_UNAME, write the following code:  UNAME_RET = UNAME. Here we are setting the exporting parameter with class attribute
To complete the scenario, we have created two reports.

First report: ZRP_SHAR_OBJ_SAMP.

The code in the report is as follows:


DATA: username type String.
shar_handle = ZCL_SHAR_AREA_SAMP=>attach_for_write( ).
CREATE OBJECT shar_root AREA HANDLE shar_handle.
shar_handle->set_root( shar_root ).
shar_root->set_uname( exporting uname_imp = 'Sharath').
write 'value is set'.
shar_handle->detach_commit( ).

Report 1 Output:
Second report: ZRP_SHAR_OBJ_SAMP_1.

 The code in the report is as follows:


DATA: username type String.

shar_handle = ZCL_SHAR_AREA_SAMP=>attach_for_read( ).
shar_handle->root->get_uname( importing uname_ret = username ).
shar_handle->detach( ).
write username.

The report displays the name set in first report.
Potential Usages: When you would need to pass values, Set the values in shared memory and read the same from the assistance class of the Web Dynpro application and vice versa.

Thank you.




  1. Unknown User (gavi44y)

    Hi Sharath,

    Nice WIKI, easy to follow and good learning point for me.


  2. Unknown User (alezd8o)

    Hi Sharath,

    Thanks for this entry. I think it can be useful in many scenarios.

    On the other hand, I am afraid that this is a very powerfull tool that could be, let say, 'over-used' taking into account that other more appropiate methods to share/pass data are usually avaible in many situations. I mean that Shared Memory Objects could be used as 'last-minute trick' to solve some situations that could be solved in a better way by using a particular data exchange method. Hence I guess that sometimes it can be difficult to know whether using SMO is the most appropiate way to be followed.

    Finally, as far as I know, EXPORT/IMPORT MEMORY sentences should be avoid as much as possible. Should we consider that SMO is a better way of doing that?

    Many thanks again for your input :)


  3. Thanks Sharat, learnt new thing wiht SHMA, apart from EXPORT/IMPORT memory



  4. This approach is actually not that reliable. In post production servers you have more than one application server. When the WDA application opens, due to load balancing there is no guarantee that the user session for the WDA application will be on the same application server as the originating SAPGUI screen (or whatever your original process was).

    Share memory objects exist in the global memory of the application server. They do not cross application servers. Unless you use some RFC based tricks to propigate your shared memory objects across all application servers, you will likely find that this approach fails some times in production systems with multiple application servers.

    I would instead suggest passing small amounts of information via URL parameters. For larger amounts or data types that can't easily be converted to strings, you should consider writting the data into the database temporarily (perhaps as a server cookie). This is the only way to ensure persistence in a multiple application server environment.

  5. Thank you All for your comments.

    @ Thomas: Thank you for your feedback. The take away from your feedback is, It's vital for architects and developers to consider the deployment scenario in production and not be constrained to development environment.