Browse DevX
Sign up for e-mail newsletters from DevX


Debunking a Persistent Myth in ABAP Objects : Page 2

That SAP's ABAP Objects language lacks support for serializeable and persistent objects is such an enduring myth, we decided to lay it forever to rest with a host of simple examples of how to persist objects from a class.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

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.

Thomas Jung is an application developer for Kimball Electronics Group (www.kegroup.com) and a huge fan of ABAP.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date