SAP ABAP Advanced Cookbook: Featuring over 80 sophisticated recipes, this is a superb tutorial for ABAP developers and consultants. It teaches you advanced SAP programming using the high level language through diagrams, step-by-step instructions, and real-time examples.

Prior to writing the code for storing objects in shared memory, an area root class must be created and a shared memory area be defined using transaction SHMA.

The steps required for creating a root class are:

For creating the set of code that writes object's contents to the shared memory, follow these steps:

In the shared memory-writing program, the statements collectively make the writing of object in the shared memory. Let us see how the program code works.

An area instance version needs to be created before any data may be written in the shared memory on the application server. The attach_for_write static method is used for this purpose and returns a handle to the area instance created in the application server memory. This imposes write lock on the version.

The CREATE OBJECT statement is then called with the name of the created handle. This creates a root object in the area instance of the shared memory. The link between the area instance and the root class is created using the set_root method. The set_data method is then called for the root reference my_root and supplied with the name and number of the employee, which are then stored in the shared area. Finally, the detach_commit method is called and the write lock is released.

Once the program has run successfully, you may see the created object in the shared memory using the shared memory transaction SHMM. This will appear as your area class name ZCL_MY_EMP_AREA. Refer to the following screenshot:

Double-click on the name of area to view the details, as shown in the following screenshot:

The read program is somewhat similar. However, instead of the attach_for_write method used earlier, we will use attach_for_read. The same instance name is passed and the handle is received. The method imposes a read lock on the area instance. Then, the get_data method of the root object is called using the area handle, my_handle. This returns the employee name and number stored earlier into the variables name and number respectively.

Finally, the detach method is called and the read lock is released.

While creating the shared memory area, if we select the Transactional Area checkbox, the area becomes transactional. In this case, the modifications to the area instance versions are not active immediately after the call of detach_commit method. Rather, they become active when the next database commit is executed.

Prior to storing objects in the database, a suitable database table with the name ZEMP_TABLE is created to store the values of the objects' attributes. Two fields are defined, NUMBER1 and NAME (the field name NUMBER was not allowed, so NUMBER1 has been used as the field name). Refer to the following screenshot:

Once the database table is defined, a persistence class must be defined. In order to define persistent classes, follow these steps:

During the generation of the persistent class zcl_my_persist, two additional classes are generated. These are the actor (agent) and the base agent classes having the names zca_my_persist and zcb_my_persist respectively. The base agent class is generated as abstract (that is, no instance can be constructed from it), and cannot be modified. It is created in a separate pool class from zcl_my_persist. The agent class zca_my_persist may be extended, as well as the loading and saving methods may be modified.

The instantiation mode of the persistence class may be set as abstract or protected. In our recipe, we have chosen the instantiation mode as protected (which means that only instances may be created from within the class or its subclasses). However, making the instantiation mode of a persistent class as protected makes the generated base agent class a friend of the persistent class (in the world of ABAP objects, a friend or its subclasses may create instances of the class in question).

The coding for this recipe declares two references, emp and agent, to the persistent class zcl_my_persist and the agent class zca_my_persist, respectively. Next, the static factory method agent is called for the class zca_my_persist (agent class). The reference returned is stored in the variable agent.

The agent class contains the method create_persistent required for storing the data into the database (this is analogous to the concept of insertion in database table).

The most important part is the calling of the create_persistent method that is passed the number and name that is to be stored. The employee with the number 00000017 and name John Reed is created and reference is returned in emp. Finally, the COMMIT WORK method stores the data of the emp object into the table created earlier in this recipe. One row with the number and a name is added to the table ZEMP_TABLE.

For reading the stored value related to the employee number 00000017, a number variable is declared and assigned the value 00000017. The static method agent of the zca_my_persist class is called in order to get a reference to the agent. The get_persistent method is then called and the number (in our case, 00000017) is passed. This method returns the entire object emp pertaining to the employee number. You may then call the get_name method of the zcl_my_persist class for the emp object in order to retrieve the employee name.

For the sake of this recipe and the ones that follow, we will focus on an employee and name example. The class will encapsulate an eight-character number (in numeric form) for the employee number 00000014 and a 30-character field for the employee name. For example, there can be an employee John Reed with number. This will be stored in the private attributes of the class as Name and Number.

For creating a class as a factory method design, follow these steps:

When the program calls the static factory method, the code within the factory method is called for each of the two objects emp1 and emp2. The factory method triggers CREATE OBJECT statement, which creates a new object and calls the constructor.

The constructor is called twice, once for each of the two instantiated objects emp1 and emp2. This prints the message successful creation for emp1 and emp2.

We will use the same class created in the last recipe of factory method. We will make few changes to the class so that we can prevent the creation of multiple instances of the class. We will make a copy of the class (program) shown in the previous recipe and modify it. The name of the copy is singleton_class.

For creating a singleton class, follow these steps:

Similar to the previous recipe, we try to instantiate two objects emp1 and emp2, having number 0000012 and 00000014 respectively. However, in our singleton class, we have added an attribute number_of_instances, which keeps track of the number of class instances that already exist. Upon creation of the first object, the factory method increments this static attribute to 1. On the second object creation attempt, the IF statement does not allow the CREATE OBJECT statement to be called a second time. The result is that the second object is not created. No further attempts of object creation will be allowed. Rather, a message saying that only one object instantiation is allowed is outputted for the second object creation attempt.

In order to demonstrate the adapter, we need two classes (input class and output class). The input class will be the fac_meth_class created earlier. For the output, we will create another class fac_meth_class2. This will serve as the class, into the format of which the input object will be converted.

It is without a factory method for sake of simplicity. It contains employee number and employee name but the format of these two is different from the classes shown in the previous recipes. The employee name of this class is based on data element emnam, whereas the number is a character without zeros having length as eight. The name is of the form (firstname lastname), meaning John Reed will be stored as John Reed and not Reed John as in the previous recipes. The constructor outputs the message, Converted employee created.

We will use the same class used previously as the input object for the adapter method.

For creating a singleton class, follow these steps:

When the program calls the static method adapter of the class adapter_meth_class , the code in the adapter method is executed. The adapter method calls the necessary code for converting the number into the character format and any zeros are removed from the number. In addition, the SPLIT statement is called for converting name of the employee in the (first name last name) format such as converting Reed John into John Reed. Finally the CREATE OBJECT is called in order to create the object in the converted class format . This triggers the constructor for the converted class fac_meth_class2 that outputs the message "Converted: Employee Created having number 1234" and name John Reed. Since we called the factory method of the original fac_meth_class before the adapter method call, the original constructor was also called and message printed also.