This weblog was really sparked by a conversation that I had the other day. 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. Several of his comments revolved around the fact that ABAP Objects didn’t have persistent objects or an OO transactional system. Now I found this rather interesting considering that ABAP Objects does have 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 in SDN on the ABAP forum asking ABAP Developers to fill out /thread/21300 [original link is broken]. One of the questions is “What are the weak points for ABAP Objects”. The possible answer that struck me was – “No persistent objects or serializeable objects”. ABAP objects actually has both persistent and serializeable objects. 5 people out of 45 so far had given this option as a weak point for ABAP Objects. Therefore I dedicate this weblog to those 5 people and my Java friend.
In defense of those who answered that the lack of persistence and serializeable objects was a weakness, it is true that this functionality is not present before the 6.X releases of the WebAS. All the examples that I am going to share today were developed on a 620 WebAS. Before I jump into the heart of the weblog on Persistent Objects, I thought I might address serializeable objects once again real quick. 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!. The following is some sample ABAP code that I have to serialize a data object class and write it out to an XML file on the presentation server:
The resulting XML looks like this:
For this section on Persistent Objects I am going to take a chapter from a delta training course I wrote for in house development group. We are going to start off by creating a new persistent object for the SFLIGHT table. Then we will look at the Persistent Data Mapper. Finally I have three example exercise programs that I will share.
Creating the Persistent Object Class
We start off with the task of creating a Persistent Object Class. The process 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.
After the class creation, if you look at the Properties tab you should see something like the following:
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 update. That is because more than just this one class was created. You also have generated two additional classes. A ZCB_ class that is your Base Class and a ZCA_ class that is your Agent Class.
You will also see that your main class you just created now also has a Friends relationship to the Base class. The Base Class in turn is the Superclass for the Agent Class. Later when we get to the coding part of this exercise you will see that we always use the Agent class to create instances of our persistent class.
Right now our persistent class has just 5 methods that it has inherited from the IF_OS_STATE interface. You are not allowed to alter the GET or SET methods because the internal coding is generated. However according to the documentation you can change the default code in the HANDLE_EXCEPTION, INIT, and INVALIDATE methods. For the purposes of this exercise, we will just leave the default coding.
Persistent Data Mapper
Well we have a persistent object, but it doesn’t do much yet because we 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, we have an extra button when we are working with our persistent class. This button will navigate us to the Persistent Data Mapper.
When we first enter the Data Mapper we are asked to add a Table or Structure. For this example we will enter SFLIGHT (Please note that to get all of my screen shots I had to create my Persistent class multiple times. That is why in some of the screen shots you might see a slightly different class name).
Now at the top of the screen you see an area with your persistent class and all of its attributes (there are none yet). At the bottom of the screen you see all the possible fields exposed by the data object we selected.
If you double click on a field from the Table/Field View, it will be loaded into the middle part of the editor. From this area you can change the attribute name, description, visibility (Public, Protected, Private), and read only flag. Once you are complete you can press the arrow button to the left of the attribute name to add or update this attribute in our persistent class.
You can then repeat this task for each field we want to expose as an attribute in our Persistent Class. You also have a context menu that can be used to alter the attribute once it has been added to the persistent class.
When we save and exit from the Data Mapper, you should see many new SET_ and GET_ methods that have been generated in your Persistent Class.
Coding Examples using our Persistent Class
We have our Persistent Class and all the data fields mapped and exposed. All that is left now is to start writing some code to use our persistent class. For our first example, we will start simple and just read some data from out persistent class. You can see that we use the Agent class to create the instance of our persistent class. You can also see how you can use the get methods in calculations instead of the actual attributes. Finally we will book an additional person and increase our seats occupied. We then refresh our persistent object to prove that we have updated the database.
For the second example, we are going to get a little fancier. We are going to get an internal table full of instances of our persistent class. My internal table isflight contains just our data keys, along with the persistent class instance (my_flight) which contains the rest of our data. We then write out a simple report:
The final example is very similar to the first one. The only difference now is that we are going to use transactional object services to commit our changes through our persistent class. As you can see you can write an event handler for the completion of the update. It is in this event handler that we will reread the data to prove that the update was successful.
Admittedly these have been rather simplistic examples. Hopefully thought, they give people a chance to see that persistent objects do exist and give some simple steps to get started using them. These examples do not really show off the power and benefits of using persistent classes. Once you have down the basics of creating and working with persistent objects, you will be ready to explore their greater possibilities.