ecently, I was talking with a Java developer who was fairly new to the SAP world but claimed to already be an ABAP expert. He was commenting on the ABAP programming language. In several of his comments he remarked that ABAP Objects didn’t have persistent objects or an OO transactional system. I found this rather interesting considering that ABAP Objects has both of those things.
On the same day that I had the opportunity to set this poor misguided soul straight, I ran into another instance of persistence ignorance. There was a posting on the SAP Developer Network’s (SDN) ABAP forum asking ABAP developers to fill out a survey for someone’s master theses. One of the questions: “What are the weak points for ABAP Objects?” Among the choices given by the survey to answer the question: “No persistent objects or serializeable objects.” ABAP Objects has both persistent and serializeable objects.
Five people out of 45 had selected this option as a weak point for ABAP Objects. I dedicate this solution to those five people and my Java friend.
A common misconception these days is that ABAP Objects has no support for serializeable and persistent objects. But it does.
Follow along to learn step-by-step how to create a serializeable data object class, a persistent object, and to use the Persistent Data Mapper.
Serializeable Objects
In defense of those who might have agreed with the statement that lack of persistence and serializeable objects in ABAP Objects is a weakness, it is true that this functionality is not present before the 6.X releases of SAP’s WebAS. All the examples that I am going to share today were developed on a 620 WebAS.
In a moment I’ll jump into the heart of persistent objects, but first I’ll address serializeable objects. If you want an ABAP Object class to be serializeable, all you have to do is add the IF_SERIALIZABLE_OBJECT interface. That’s it?pretty simple! Listing 1 is some sample ABAP code from which I have to serialize a data object class and write it out to an XML file on the presentation server:
The XML output looks like this:
xmlns:cls="http://www.sap.com/abapxml/classes/global" xmlns:dic="http://www.sap.com/abapxml/types/dictionary"> 0000000001 00000 LSCHEU LSCHEU 2000-11-01 00003 00050 2000-11-02 | Editor’s Note: This content was originally published on the SAP Developer Network. Reprinted with permission. |
Persistent Objects
For this section on persistent objects I am going to take a chapter from a Delta training course I wrote for an in-house development group. I’ll begin by showing you how to create a new persistent object for the SFLIGHT table. From there, I’ll look at the Persistent Data Mapper. Finally, I’ll share three example exercise programs.
Creating the Persistent Object Class
The process of creating a persistent object class is very similar to creating any other type of global class in ABAP Objects. From the create class dialog, you simply choose persistent class for the Class Type (see Figure 1).
Figure 1.
After the class creation, your Properties tab should look like Figure 2.
Figure 2.
You will notice that even though I choose Public as my instantiation type in the create dialog, SAP has forced this to Protected and locked the field against updates. That is because more than just this one class was created. I’ve also generated two additional classes. A ZCB_ class that is my Base class and a ZCA_ class that is my Agent class (see Figure 3).
Figure 3.
You will also see that the main class I just created also has a Friends relationship to the Base class (see Figure 4). The Base class in turn is the Superclass for the Agent class. Later when I get to the coding part of this exercise, you will see that I always use the Agent class to create instances of my persistent class.
Figure 4.
Right now my persistent class has just five methods that it has inherited from the IF_OS_STATE interface. I am not allowed to alter the GET or SET methods because the internal coding is generated. However, according to the documentation, I can change the default code in the HANDLE_EXCEPTION, INIT, and INVALIDATE methods. For the purposes of this exercise, I will just leave the default coding (see Figure 5).
Figure 5.
Persistent Data Mapper
Well I have a persistent object, but it doesn’t do much yet because I haven’t mapped any data objects to the class. This is where the Persistent Data Mapper comes into play. On the Main menu bar in the class builder, I have an extra button when I am working with my persistent class. This button navigates to the Persistent Data Mapper (see Figure 6).
Figure 6.
When I first enter the Data Mapper I am asked to add a Table or Structure. For this example I will enter SFLIGHT (see Figure 7).
| Author’s Note: Class names in the screen shots may vary slightly. |
Figure 7.
Now at the top of the screen I see an area with my persistent class and all of its attributes (of which there are none yet). At the bottom of the screen I see all the possible fields exposed by the data object I selected (see Figure 8).
Figure 8.
If I double-click on a field from the Table/Field View, it will be loaded into the middle part of the editor. From this area I can change the attribute name, description, visibility (Public, Protected, Private), and read-only flag. Once I am complete, I can press the arrow button to the left of the attribute name to add or update that attribute in my persistent class (see Figure 9).
Figure 9.
I can repeat this task for each field I want to expose as an attribute in my persistent class. I also have a context menu that can be used to alter the attribute once it has been added to the persistent class (see Figure 10).
Figure 10.
When I save and exit from the Data Mapper, I can see the many new SET_ and GET_ methods that have been generated in my persistent class (see Figure 11).
Figure 11.
Coding Examples Using a Persistent Class
Now I have my persistent class and all my data fields mapped and exposed. All that is left now is to start writing some code to use my persistent class. The first example (Listing 2) is simple; it reads some data from the persistent class. You can see that I use the Agent class to create the instance of my persistent class. You can also see how I can use the get methods in calculations instead of the actual attributes. Finally, I will book an additional person and increase the seats occupied. Then I’ll refresh my persistent object to prove that I have updated the database. The code is shown in Listing 2.
For the second example (Listing 3), I’m going to get a little fancier. I’m going to get an internal table full of instances of my persistent class. My internal table, isflight, contains just my data keys, along with the persistent class instance (my_flight), which contains the rest of my data. I’ll then write out a simple report. The code is shown in Listing 3.
The final example (Listing 4) is very similar to the first one. The only difference now is that I am going to use transactional object services to commit my changes through my persistent class. As you can see, I can write an event handler for the completion of the update. It is in this event handler that I will reread the data to prove that the update was successful. The code is shown in Listing 4.
Admittedly these have been rather simplistic examples. Hopefully, they will give you a chance to see that persistent objects do exist and give you some simple guidance to get started using them. These examples do not really show off the power and benefits of using persistent classes. But once you have the basics of creating and working with persistent objects down, you will be ready to explore their greater possibilities.
