Singleton Design Pattern is most heavily used in OO based developments. Lets see an usage of Singleton Design pattern.
Long time back, I wrote an article about Singleton Design Patterns. In fact that was the first article in Design Patterns space. The example, I have used in the earlier post, is just for a demo purpose. So, I got quite a few request over the time on how to use the Singleton Pattern in real time.
As part of this article, I would first recap on how to setup your class to achieve Singleton design pattern. After that, we jump on to a simple example using the Singleton in Sales Order processing. Before we start, take a look at how the sequence UML would look like:
Set up for Singleton
Create a Global class in SE24. When you create the class, select the Private as Instantiation. This control how object is instantiated. In other words this controls where CREATE OBJECT statement for this object can be written. Since for Singleton you want to get the same object back if it was already created earlier, you need to control how the object is setup. Thus, you would need to select Private as Instantiation.
Next you need to create an attribute which would hold the reference of the object. This needs to be Static as it needs to hold the object reference throughout the Session or Transaction.
Now create a method to streamline the object creation. Since we already declared the object instantiation as Private, we need to instantiate the object within the class itself. This method would be responsible to do exactly that. You would need to add a return parameter to this message so object can be passed back to the client. I always prefer to call this method as GET_OBJECT. So, whenever I see GET_OBJECT, I know that this is Singleton – at least in my development.
In implementation of the method GET_OBJECT, we check if the object already BOUND, use that otherwise create a new one.
GET_OBJECT method implementation
method GET_OBJECT. " returning value(RO_OBJECT) type ref to ZCL_SO_ADD_DETAILS . * if zcl_so_add_details=>o_singleton is not bound. create object zcl_so_add_details=>o_singleton. endif. * ro_object = zcl_so_add_details=>o_singleton . endmethod.
I also prefer to create CLEAR_OBJECT in the class. The purpose this method to clear the object. So, when next time client class GET_OBJECT, it would generate a new object. Ideally, this method wont be needed as we don’t want to clear the objects in the session. Whenever the Session gets expired or completed, it would also lose the object. But, the way majority of Standard SAP transactions are designed, it would be problem if we rely on session to clear the Objects. As Many times, SAP will start over the next Transaction – means allow you to create a new document – without actually closing that particular session.
This method also allows you to effectively get rid of the object within ABAP unit.
Usage of Singleton in Sales Order Processing
Sales Order user exits might be the most widely used User Exits in SAP. Lets assume the requirement is to Populate few custom fields & at Sales Order header & Item level and save them into a separate table. So, to achieve this using Singleton, you would set up your class as we described above. Create new instance methods SET_HEADER_FIELDS, SET_ITEM_FIELDS and SAVE_DATA in the same singleton class ZCL_SO_ADD_DETAILS.
You would need to implement the User Exits to call the respective methods. So, your method calls within userexit would be similar to this:
Userexit accessing the Singleton object
* FORM userexit_move_field_to_vbak. DATA: lo_add_data TYPE REF TO zcl_so_add_details. lo_add_data = zcl_so_add_details=>get_object( ). lo_add_data->set_header_fields( vbak ). ENDFORM. "userexit_move_field_to_vbak * FORM userexit_move_field_to_vbap. DATA: lo_add_data TYPE REF TO zcl_so_add_details. lo_add_data = zcl_so_add_details=>get_object( ). lo_add_data->set_item_fields( vbap ). ENDFORM. "userexit_move_field_to_vbap * FORM userexit_save_document. DATA: lo_add_data TYPE REF TO zcl_so_add_details. lo_add_data = zcl_so_add_details=>get_object( ). lo_add_data->save_data( ). ENDFORM. "userexit_save_document *
One more userexit to implement to clear the object
Userexit to clear object
* FORM userexit_refersh_document. zcl_so_add_details=>clear_object( ). ENDFORM. "userexit_refersh_document
As shown in the UML sequence diagram (figure 1), object would be instantiated when first time GET_OBJECT method gets called. It would be live until the CLEAR_OBJECT gets called.
How do you use Singleton
Share your thoughts and usage practice on how you are using Singleton Design Pattern.