During business logic design, we face different problems related to data processing. One of these problems, probably the most frequent one, is exhaustive database access. Imagine you have an application that queries the database for existing products and different programs require this information. It would be a waste of time especially when products attributes are not changing frequently. So why not load it only once and serve everybody?
Shared memory objects could easily solve this problem. They are ABAP Object Instances which are stored in SAP Memory on an application server. They can be accessed and updated by all users and sessions created on the same application server.
Before the SAP ERP 6.0, SAP shared memory was accessed by the EXPORT/IMPORT statements in order to save unstructured data. However shared objects offer the possibility to store tables and complex ABAP structures processed by business logic.
SAP memory objects are used to minimize database access. Instead of retrieving the required data from the database, data is retrieved once and saved in the shared memory, accessed and/or updated, then committed to the database. This concept provides faster data processing: highly recommended in case of data read.
Shared memory objects generation consists on creating a class whose attributes represent stored objects in the shared memory. A getter and setter should be implemented to access and update them from the calling program. Every instance of this class is stored in the shared memory as an independent area.
The shared area is monitored by an SAP tool (transaction SHMM) that allows managing objects in the shared memory in addition to lock management: There are three types of lock in the SAP memory objects: Read, Write and Update. Write and Update are exclusive; however, read access allows many users and sessions to read simultaneously the same data from shared memory. The tool allows also deleting the shared memory instance and refreshing it in case of errors and dumps.
Author- Khaled Boukari