Skip to Content
Introduction
Where I live in the United States, it is nearly time for the Christmas Holidays. Any day now we will have the first snow of the season. People are busy putting up lights and Christmas trees. The shopping centers are full of eager shoppers. Given this is the season for sharing of gifts, what better time could there be for exploring the new ABAP Shared Memory functionality in WebAS 640.

Now you might be saying to yourself, that we already have access to shared memory areas via the import and export statements. What could be so special about this new functionality? Well first of all, this is read access to shared memory without the need to copy it into user session memory. Second the new shared memory is implemented through ABAP Objects. Therefore you are provided with robust tools to interact with shared memory through code. You also have good administrative tools to monitor and support these memory areas. This is what I want to focus on today. We will look at how to create a shared memory class, but I will really focus on what I have seen to be some of the major advantages to this new technology.

Creating our Root Class
All of the data we want to store or expose through the shared memory area has to be contained in a Root Class. Later when we work with our shared memory, you will see that all we are really doing is getting a pointer to an instance of this root class. We then access or manipulate the data through this class. We will start off quite simply by creating a normal ABAP Class from SE80. We will name it ZCL_SDN_SHARED_ROOT.

image

Now we have to define that this class will be a Shared Memory Class. To do that we just have to select Shared Memory-Enabled from the General Data area of our class properties.

image

That’s it. We now have a shared memory root class. For this class to be useful, it’s going to need to be able to supply some data. For that reason, let’s create a private attribute called message of type string.

image

Now we can create two public methods that will be used to access this message attribute(GET_MESSAGE and SET_MESSAGE). The GET_MESSAGE will have a string returning parameter and the SET_MESSAGE will have a string importing parameter. Right now all these methods are going to do is to read and write our private attribute. Of course I could have just exposed my message attribute as a public attribute. However I wanted to show that one of the advantages of the shared memory class is the ability to add logic on read and write. Later we will add just such logic.

image

Creating the Shared Memory Area
Next up we have to create a Shared Memory Area. This Area is another ABAP Class. It will become the information broker for your root classes. It will control access to the instances of the root class. That’s right, you might have multiple versions of the root class alive at once. Therefore the Area manages these versions. For instance you might have a reader working with the active version while a separate writer is building a new version. This ability to version, which comes from the Area object, is one of the other major advantages of the shared memory technology.

To create our Area we go to transaction SHMA. We are going to name our area class ZCL_SDN_SHARED_AREA.

image

From the top part of the following screen we fill in the Basic Properties. All we are going to do right now in here is assign our root class to the area. We also have the ability to set certain other parameters. The first makes the shared memory area Client Specific. If you are familiar with the basic SAP concept of Clients within a System Instance, this should be self explanatory. Next up is the Aut. AreaStrucuring. We will look at this option a little later in the weblog. Finally there is transaction area. This option allows you to tie your shared memory area to a data base object. This allows you to propagate shared memory values across multiple application servers. But proper Propagation, Invalidation, and Preloading of Shared memory areas across multiple Application Servers could probably be a weblog by itself. For today we will learn to walk before we run.

image

The bottom half of the screen has some additional attributes. For now we will leave all values at their default. Therefore we won’t have multiple versions. Nor will we have any type of Auto Start for our memory area. There also will not be any limits set.

image

If we return to SE80, we can now see that we have two classes that really make up our shared memory: the area class and the root class.

image

Our Area class is generated for us, but it still might be interesting to look at some of its Public methods. These are methods we are going to program against to read, write and update our shared memory.

image

Read Program
We are ready to write our first program. This program will get read access to our shared memory area. We can then access the GET_MESSAGE method of our root class to write out our message attribute.

Write Program
If you ran the read program you got a short dump, right. That’s because our shared memory area doesn’t exist yet. Later we will learn how we can turn on Auto Initialization so that on the first read request the memory area is created. For now let’s just write a program to do that. This program will create an instance of the root object. It will then write to the message attribute and set the root back into the area.

After you run this write program, you can go back to the first and now you should get results without the short dump.

image

Shared Memory Monitor
Before we move on to more advanced techniques, let’s take a minute to look at the monitoring and administration tools for shared memory. If you successfully ran the write and then the read program, you should be able to see your area and root instance in these tools. You start off by going to transaction SHMM. From the first screen of the monitoring tool, we can see all of shared memory areas. We can also see memory usage, number of instances, number of versions, and the status breakdown of the versions. As you can see our new little shared memory area isn’t taking up much space.

image

If we double click on the area, we can drill down farther and see all the instances of root classes within the area. We only have our once instance (the default instance). From these screens you delete either an instance or the whole memory area. You can also see the structure of the root class and the public attributes of the class. Overall the tools that you would need to keep track of where you shared memory is allocated are all here.

image

Auto Preloading
As you saw from the example earlier, we got a short dump when we tried to read from the unloaded memory area. Wouldn’t it be much nicer if the memory area could automatically preload itself on the first read attempt. Well that’s exactly what we are going to do now. To do this we are first going to have to add the interface, IF_SHM_BUILD_INSTANCE, to our root class.

image

This should add one new public static method to our root class called BUILD. This is where we are going to put the initialization code for our shared memory instance.

image

Basically we will copy in the code from our earlier write program into this BUILD method. We will just change the initial message, so that we can tell the difference.

Now we need to change that attributes of our area. Always remember to go to SHMM and delete any existing Shared Areas after you make changes here. First we will set the Aut. AreaStructuring in the basic properties of the shared area.

image

Now we also must supply the name of our constructor class. This is our root class where we just implemented the IF_SHM_BUILD_INSTANCE. This field entry will check and make sure that the class you supply has this interface. We also have to set if we want to Auto start on just the read request or also every invalidation.

image

Now we are ready for a new read program. This read program is only slightly different. When we issue the attach_for_read on an initial memory area, this should trigger our BUILD method. Now this build activity happens Asynchronously in another work processes. Unfortunately the attach_for_read doesn’t wait for this BUILD work to complete. Therefore we have to account for this and add a wait to our read program if the initial attach fails.

Updating Data in Shared Memory
We have looked at how to write initial data into our shared memory. But remember our write program created a new instance of the root class. We also need to be able to update the data in an existing instance. To do that we will use the attach_for_update. Because the update might trigger the BUILD method as well if the shared area is initial, we have to account for the Asynchronous activity again. Then we try to get a pointer to the existing root instance. If one doesn’t exist, we just create one.

Now while I was writing this weblog, I noticed some interesting attributes on the attach_for_update that aren’t there on the attach for read. They were attach_mode and wait_time. It looks as though maybe SAP plans to do the wait logic for us. I decided to give these new options a try:

All I got was this very interesting short dump. I guess I will just have to wait a little longer for this functionality. Maybe Support Stack 10 will have it.

image

OO Access
In this section I wanted to demonstrate the power of shared objects based upon their OO implementation. Instead of just accessing a memory area, you are accessing an ABAP class. That means that this shared memory area can also contain logic to manipulate the data as it is read. For this demonstration, I will append a random number between 1 and 100 to the end of the message in the GET_MESSAGE method. I have just been dying for an excuse to use the new Random Number classes in 640 anyway. The following is the code for the new GET_MESSAGE method.

The following are the new results:

image

OO Events
I was going to close out the weblog with an example of how I could use OO events in my shared memory class. I thought it would be really neat to have two consumers of a shared memory area. One would write and the other would register for an ON_Update event. When the first program wrote an update, the second program’s event handler would respond to this update and popup a message. Unfortunately I received the following message as soon as I added an event to the root class.

image

Now my German is a little rusty, but I get the feeling it is telling me I can’t use events in shared memory classes. I can understand that there would be serious technical problems to get a shared memory event to work right, but it sure would be nice! Perhaps we have something to look forward to in NetWeaver 05.

To report this post you need to login first.

15 Comments

You must be Logged on to comment or reply to a post.

  1. Peter Inotai
    Hi “Santa”,

    Thanks for this Xmas gift!

    It’s really incredible how to publish such great weblogs every day recently.

    Peter

    Ps: Did you also play around with the integrated ITS functionality?
    It wasn’t mentioned in your ‘first impression’ weblog, however it’s also a quite interesting topic, and I’m very interested in.

    (0) 
    1. Thomas Jung
      I have a long list of things I want to explore in my Netweaver Sandbox and the integrated ITS is definetely one of them.  I did try it out while working on my first impressions weblog.  I spent just a few mintues on it, but couldn’t get any pages to pull up.  I just haven’t had the time to make it back around and play with it. We start the upgrade of our full landscape in early January.  Once the development system is upgraded I will definetely be working with the integrated ITS.  I hope to share something after the holidays.
      (0) 
  2. Jayanta Narayan Choudhuri
    I tried one share memory class that works fine but another that takes substantial time to build never comes out of build and hangs.

    Both the classes menu “Check Consistency of Area(Ctrl&F2)” shows two major errors
    Area attribute Binding has an invalid value                                 109,200,001.
    Area attribute Synchronization has an invalid value 159,200,000.

    Despite these RED errors one class works fine.

    Please suggest workarounds.

    -jnc

    (0) 
    1. Thomas Jung Post author
      I wouldn’t worry about those two errors.  I get those as well on my objects that are working and in standard objects in our internal systems.  I have a felling that the errors are incorrectly reported based upon future features that are not yet implemented (see OSS note 911030).

      Now for your problem.  Is this class with the problem one you have created or an SAP delivered one?  Have you debugged inside the build method to see what is causing the long wait?  If it is taking a long time it could be reading in a lot of data and exhausting the amount of memory in the shared area. You can check total free memory in SHMM. 

      (0) 
  3. yann szwec
    Thanks for this demonstration, It is very interesting.
    Do you think I could use this way for a application log, with several chidl process?

    I think about
    – One father report, creating the abap shared memory, and giving to it the loghandle
    – each child report calling this shared memory to add their message into this application log.

    It seems a good idea. What do you think about?

    Anayway,

    thanks for this lesson

    BR

    Yann SZWEC
    http://www.sapetabap.com

    (0) 
    1. Thomas Jung Post author
      That seems reasonable.  Remember that each child object would have to lock the shared object to write their log entry.  This is a relatively small amount of time, so it probably wouldn’t effect the average application log writer – however it might become a problem if you had some sort of system logging to with thousands of entries per second from multiple sources.

      Also remember that shared memory objects are per application server.  Also if the application server shuts down unexpectedly, the state of the shared memory objects will be lost.  So if you need to also persist your log, you will need to plan for that as well.

      (0) 
  4. Jan Creemers
    Hi Thomas,

    I have read this book and it gave me a very good start in ABAP OO development.

    There is still a problem that I have with SHMO and it’s something where the book also ends …

    I have posted the question on SDN, but I also try it here, because I think it’s so close linked to the content of your book:

    Hi,

    I have shared memory objects, that are instantiated from the database.
    But I can not save their state back to the database.
    I always receive the exception CX_SHM_EXTERNAL_REFERENCE on the persistent objects.
    The persistency layer only works one way …
    I tried everything from the wonderfull book “Next Generation ABAP Development”.

    How can I solve this?
    Where can I find some good documentation on this subject?

    thanks,
    Jan

    (0) 
    1. Thomas Jung Post author
      From the error message, it would seem that you still have some instance that is attached for read or write to the shared memory object so it can be written into the database.  You would have to clear all instances first.
      (0) 
  5. Henryk Eimler
    Hi Thomas,

    thank you for this blog. It was a very good instruction for my tests. But now I am facing a big problem.
    I tried to give the values from shared memory from one application server to another, but it does not work… I cant find my Shared Memory Area on the second server. In your blog you mentioned, that this would be possible. Do you have an instruction how to achive this?

    Best regards
    Henryk 

    (0) 
    1. Thomas Jung Post author
      YOu have to buidl this propigation into your logic.  You generally create a remote enabled function module and call this FM via RFC point to a specific application server instance.  You will have to create the Shared Memory Area again on each Application Server. 
      (0) 
      1. Christiaan du Plessis
        Hi Thomas,

        I realise your reply was written 2+ years ago. Do you know whether this manual propagation is still required? In the documentation is seems like one of the principals behind the SMA is that it is accessibly from any application server.

        (0) 
  6. Kenneth Moore
    Hey Thomas,

    I’m playing around with this and I have multiple tables I would like to buffer for an application.  Should I create a shared memory class for each table?  Or can I use the same shared memory and just use multiple methods to load the different tables?

    Thanks – Kenneth

    (0) 
    1. Thomas Jung Post author
      Either approach is techincally possible.  I personally would follow the rule that if the tables are closely related there is no reason to not combine them.  Remember that you attach to the shared object for write and that “locks” the object for a very short amount of time.  Therefore you wouldn’t want to use one object for many unrelated tables used by disparent applications as this could lead to contention.  However related tables would be easier to manage and code against a single shared memory object.
      (0) 
  7. Bala Manchikalapat

    Hi Thomas,

    May be 10 Yrs back. Good one.

    But when I try to do the first session ( with Private Attribute ) and 2 Methods. and runing Prog1 and prog2.

    But Prog1 went good without dump. and prog2 is not giving any output with –> ‘This is the initialization of our Shared Memory!

    After successfully implementing , I want to proceed to next steps.

    Please suggest me where I am doing wrong.

    With Regards,

    Bala

    (0) 

Leave a Reply