Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Data processing via model objects ofers great benefits like loose decoupling from frontend compared to function modules. There are a few things though thatwe cannot do with methods. The first is that a method cannot be remote enabled. The other thing is that a method cannot be flagged as 'Update module' eg, cannot run via the update task to have delayed LUW update.

I'll show you how you can set up Model based data processing combined with LUW  via Update task/module,

This demo is based  on the demo I’ve shown in :

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/400a0e2f-4a09-2f10-6caf-eed13053d4eb

In the setup there is an additional interface/class created: ZIF_RF_TRANSACTION_HANDLER, the controller will have a reference to this object,  and basically this object is holding references to all changed model objects. And there is an Update Module: Z_RF_SAVE_MODELS

There are a few hurdles we have to take:  an Update function Module won’t accept reference parameters.  I’ve overcome this to develop code that stores an instance of a model object in XML  string, and code that Re-instantiates an object model out of an XML string, the transaction handler translates the model references to an internal table with no references (attribs in XML string), call the update module(pass the internal table with the XML/model info), this update module will get its own transaction handler, and will transfer the internal table with XML to this (new)transaction handler, this transaction handler rebuild its list with object references to changed models, and then will perform the actual Save(s)! in a logical unit of work.

 

Demo script:

When the user changes the contents of the Price field on the screen and hits ‘Trigger PAI/PBO’ the screen structure is being copied to the model  (by the controller). The model  notifies that one of the attributes is changed, changes its attribute MV_MODEL_STATE  in CO_STATE_CHANGED  and raise the event  EV_SINGLE_ENTITY_MODEL_CHANGED. This event is handled by the transaction handler object, which will store the reference in its table with references to model objects that are changed.

When the Save button (of the SAPGUI program) on  the toolbar  is clicked, the Controller will call the SAVE_CHANGES  method of the transaction handler object. This method is building an internal table with all the information needed to recreate / Re-instantiate the model  object,  this table is transferred to an Update Function Model.  In this Module another transaction handler object is obtained via the factory (another instance because the update will run in a different session ) , the table with the info & XML representation of the instance attributes will be transferred to the transaction handler. The transaction handler will rebuild the table with objects references, with help of the factory. Than this table will be processed, of each model the SAVE method is called, if this method returns an error object, an Abend message will be issued, causing the bundled update to  fail, and to rollback previous changes. A notifying message will be delivered in via the Business Workplace.

 

I have been struggling with all kind of recordings/pictures, in the end I’ve got the idea to make a runtime analysis, that will give you an idea of the code flow: http://tinyurl.com/6o8g88e

I also made a screen capture recording of the user interface, you can watch that here: http://www.youtube.com/watch?v=TwvzFBspibg&context=C3c6f131ADOEgsToPDskJftLNRKik7O2Gdoh4mmpbN

 

Code is available in the Code Exchange section: https://cw.sdn.sap.com/cw/groups/abap-oo-model-processing,  

Feel  free to contact me! 

Regards and thanks for reading ..