‎2009 Mar 19 6:10 AM
Hi OO master:
I have been using structured program all my life and am planning to use Classes for one of my new development. My requirement is to
1) Get data from a table (KNA1)
2) depending on the this table get data from one more table (KNVP)
3) get data from the 3rd table VBAK.
4) do some more processing on the VBAK data and update in a Z table..
I was planning to create 4 method for each task listed above and 1 more method which calls all of them.. Is this the correct approach, or should I call the the 4 methods in a FM?
Also if the inserts to the Z table are happening in a Class-method, does the Rollback work, is it still considered a single LUW..
Hope someone can help me on this.
SG.
‎2009 Mar 19 6:44 AM
Hello
If you start programming in (ABAP-)OO then you should always think in terms of responsibilities. Looking at your requirements I see at least four classes:
1) Get data from a table (KNA1) " <<< customer class
2) depending on the this table get data from one more table (KNVP) " <<< customer class, too
3) get data from the 3rd table VBAK. " <<< sales order class
4) do some more processing on the VBAK data and update in a Z table..
" <<< perhaps own z-table class
Where is the fourth class? It is a "model" class consisting of all the other classes (=> composition ).
The model class would create a single instance of the customer class.
The model class has an itab holding references of sales order instances (which you create depending on some selection criteria).
If the Z-table is tightly linked to the sales orders (VBAK) then it might be part of the sales order class.
The model instance is responsible to orchestrate all these different instances in a proper way.
Regards
Uwe
‎2009 Mar 19 6:33 AM
You can call the individual methods in the report as well instead of a new method for calling all methods
I hope for a class method, it is still considered a single LUW..
‎2009 Mar 19 6:44 AM
Hello
If you start programming in (ABAP-)OO then you should always think in terms of responsibilities. Looking at your requirements I see at least four classes:
1) Get data from a table (KNA1) " <<< customer class
2) depending on the this table get data from one more table (KNVP) " <<< customer class, too
3) get data from the 3rd table VBAK. " <<< sales order class
4) do some more processing on the VBAK data and update in a Z table..
" <<< perhaps own z-table class
Where is the fourth class? It is a "model" class consisting of all the other classes (=> composition ).
The model class would create a single instance of the customer class.
The model class has an itab holding references of sales order instances (which you create depending on some selection criteria).
If the Z-table is tightly linked to the sales orders (VBAK) then it might be part of the sales order class.
The model instance is responsible to orchestrate all these different instances in a proper way.
Regards
Uwe
‎2009 Mar 19 2:37 PM
As you suggested I will be calling the Z-table class to update the Z-table. But this class will be called in a loop on the itab. So, will all the calls to this class be in a single LUW... I might need to Rollback everything depending on some logic which would be added at the end.. Is this possible when i have the logic to insert a record in a class...
Thanks for ur earlier response
‎2009 Mar 19 9:16 PM
Hello
I assume you you have a 1:n relationship between a sales order (VBAK) and your Z-table.
Your model class contains a single instance of your customer class (KNA1) multiple instance of your sales order class (VBAK) which may include an itab for Z-table records related to the sales order.
One possible approach would be that you define an event (e.g. UPDATE_DB) in your model class and an event handler method (e.g. HANDLE_UPDATE_DB) within your sales order class. When you create the sales order instances you register this event handler method, e.g.:
LOOP AT me->mt_orders INTO ls_order.
CREATE OBJECT lo_order
EXPORTING
id_order_number = ls_order-vbeln.
SET HANDLER: lo_order->handle_update_db FOR me.
APPEND lo_order TO me->mto_orders. " itab for collecting sales order instances
ENDLOOP.
When the user pushes the SAVE button your model class (or better a controller class which takes care of the interaction between user and model class -> MVC paradigm) you may call a method
go_model->save_data( ).A possible approach to handle the DB update is shown in the following sample class ZCL_ALV_TEST. This class contains an event USER_COMMAND which take a reference of IF_RECA_MESSAGE_LIST as input.
For the sake of simplicity I have defined the event handler method HANDLE_USER_COMMAND within the same class:
METHOD constructor.
" create message handler
me->mo_msg_list ?= cf_reca_message_list=>create( ).
" set event handler
SET HANDLER: me->handle_user_command FOR me.
ENDMETHOD.
METHOD save_data.
* define local data
DATA: lx_error_exists TYPE c.
me->save_data_internal( ).
CALL METHOD me->mo_msg_list->has_messages_of_msgty
EXPORTING
id_msgty = 'E'
* if_or_higher = ABAP_TRUE
RECEIVING
rf_exists = lx_error_exists.
IF ( lx_error_exists = space ).
COMMIT WORK.
ELSE.
ROLLBACK WORK.
ENDIF.
me->mo_msg_list->clear( ).
ENDMETHOD.
When the event is raised all registered event handler methods will be called:
method SAVE_DATA_INTERNAL.
raise event user_command
exporting
io_msg_list = me->mo_msg_list.
endmethod.
If something goes astray during updating your Z-table then you just add an E-message to the message collector. This message collector is finally evaluated in the SAVE_DATA method where it causes either the COMMIT WORK or the ROLLBACK WORK.
METHOD handle_user_command.
IF ( 1 = 2 ).
" Condition failed
ELSE.
CALL METHOD io_msg_list->add
EXPORTING
* is_message =
id_msgty = 'E'
* id_msgid =
* id_msgno =
* id_msgv1 =
* id_msgv2 =
* id_msgv3 =
* id_msgv4 =
* id_msgd1 =
* id_msgd2 =
* id_msgd3 =
* id_msgd4 =
* id_detlevel =
* if_cumulate =
* id_probclass =
* id_tabname =
* id_fieldname =
* id_value =
* id_index =
* id_intreno =
* id_custact =
* id_sublog =
* id_context =
* IMPORTING
* es_message =
.
ENDIF.
ENDMETHOD.
I hope I could give you some ideas for your project.
Regards
Uwe