Mass table updates using Transaction object services(OS)

[SuhaSaha]

Hello SDNers,

I have a requirement where i have two tables ZTABLE(holds current data) & ZTABLEH(holds history data) - similar to MARD & MARDH tables.

When the update program will run:

1. ZTABLE contents will be moved to ZTABLEH.
2. ZTABLE contents to be deleted.
3. ZTABLE to be updated with the new data.

I can do this by implementing all the DB changes in an update module(CALL FUNCTION IN UPDATE TASK). I am curious to know if i can use the Transaction OS to achieve this?

My gut feeling is that Transaction OS is not for mass changes, wanted to know what fellow ABAPers think about it?

BR,

Suhas

[naimesh_patel]

Hello Suhas,

I wont suggest to use Transaction OS for mass updates. Persistent objects treat each and every row as objects with fields as attributes. You would need to use SET_ method for each field to set the  field value to the attribute.

Based on your requirement, you can simply COPY the data from ZTAB to ZTABH as I believe the table type would be compatible, when not using Persistent Objects. If you would need to do this by Persistent objects, you would need to call GET_ for each object (row) of ZTABH and move the data to object of ZTAB. I think this would be add more runtime.

I remember that one of my client faced issue of Resource bottleneck as they used persistent objects to load one of their custom table. I believe Resource bottleneck was be because of the Often COMMIT WORK to save the data into DB but not necessarily because of the Persistent objects.

Persistent objects could be a choice when you want to do it with a "Single" LUW.

Thanks,
Naimesh Patel

[SuhaSaha]

Hello Naimesh,

The reasons you have stated are exactly the ones for which i was apprehensive about using Persistent classes.

I remember that one of my client faced issue of Resource bottleneck as they used persistent objects to load one of their custom table. I believe Resource bottleneck was be because of the Often COMMIT WORK to save the data into DB but not necessarily because of the Persistent objects.

I think in addition to the multiple COMMITs, imo it'll take considerable memory to maintain the huge no. of objects(1 row = 1 object). Correct me if i am wrong!

Persistent objects could be a choice when you want to do it with a "Single" LUW.

I don't quite follow you. In my case i want to bundle the DB changes for the current & history tables in a "single" LUW as well, hence the use of Update module

Imho transaction OS can be used when someone is developing a custom transaction(viz., ZME21n) & wants to use OO transaction instead of the classical one. Watsay?

BR,

Suhas

[Former Member]

Hello ,

In my opinion I have used transaction services for mass updates and have had no issues ( my Mass update was 100 Transactions ).The Transaction service could also be used with Classical updates and hence I am not aware of any issues with transaction service and Mass changes using classical updates. The transaction service is simply a wrapper and offers the developer more granularized transaction control.

However, With persistent objects, there could be an issue with the Update processes being overloaded when a mass update happens, as there is an update FM linked to every Persistent object - which makes perfect sense . However I would like to add that , my mass update was with persistent objects and I did not face any resource bottleneck issues. You could overcome the bottleneck by setting the update as synchronous, but that would make the updates a tad  slow.

The ability to create dependecies and bunding  in transactions is always a big highlight for me in using transaction services.

Do correct me if I am missing anything here.

Thanks,

Venkat

Message was edited by: Venkat Gowrishankar- Made some assumptions in the Original post and hence a revision to the OP.

[SuhaSaha]

Hello Venkat,

My # of records are in the range of 10k. Since OS visualise each record as an object, so we've x10k objects to maintain and this i think might cause resource bottleneck

Hence the reluctance to use T-OS

BR,

Suhas

[Former Member]

Hello Suhas,

Since OS visualise each record as an object

The is not the case especially when using non persistent objects.

This is where the real power of Transaction services come in. It gives us the granularity to have a single transaction object which may have 1000 Db updates or 100 Objects with 10 DB updates or 1000 Objects with 1000 DB updates.

We could do the same using classical approaches too, but the ease and flexibility of the transaction service is always a highlight.

However with persistent objects, I guess you have no choices left. . You are spot on that persistent objects and Mass processing never go hand in hand. Infact,  I once used them as an experiment in a  certain enhancement and regretted using them. This was in Mass conversion of Planned orders .

But , As you might already know, a persistent obejct is never stored in the DB, it is made persistent by the ABAP persistence service. The DB has it as a data record only and a mass migration by using SQL commands would not harm the persistent representation of the object. 

I have used Persistent objects and the persistence service to a large extent and I really enjoy working with them, especially handling data changes and Object states.

As always, happy to recieve your inputs.

Thanks,

Venkat.

[SuhaSaha]

Thanks for the reply Venkat!

The is not the case especially when using non persistent objects.
This is where the real power of Transaction services come in. It gives us the granularity to have a single transaction object which may have 1000 Db updates or 100 Objects with 10 DB updates or 1000 Objects with 1000 DB updates.

How to bundle 1000 DB updates in a single transaction object (some sample code, maybe )? I was under the impression that T-OS always worked with Persistence classes.

I have used Persistent objects and the persistence service to a large extent and I really enjoy working with them, especially handling data changes and Object states

As much as i would love to use Persistence classes, i am still not convinced over their utility May be you can blog about your experiences & highlight their use-case. I'm pretty sure that'll make a few non-believers convert

BR,

Suhas

[Former Member]

Hello Suhas,

Here is an example below, where I call a BAPI and also update a Z test table ( the table has only field - counter ). The Update module updates 5 records at a time. In the below example, we create a transaction, which invovles calling a BAPI and a sub transaction which updates 5 table entries.

When the Parent transaction is complete, both the BAPI as well as the Table updates are completed. This is just a basic scenario, there could be other complicated scenario's too.

I had written a response some time back for selective transaction control.However, I had tried with persistent objects back then.

http://scn.sap.com/thread/3317699

Similarly we could create as many dependencies and as many transaction objects as we wish. That's why  I had mentioned that the transaction service is just a "wrapper", which gives a lot of

flexibility.

Hope this helps . Here is the code snippet.

TYPE-POOLS  : oscon.
DATA : lr_tr_mgr TYPE REF TO if_os_transaction_manager,
       lr_trans  TYPE REF TO if_os_transaction,
       lr_trans_sub  TYPE REF TO if_os_transaction,
       l_tabix   TYPE sy-tabix,
       lt_table TYPE STANDARD TABLE OF ztest_table,
        lr_excpn  TYPE REF TO cx_os_transaction.
FIELD-SYMBOLS : <fs_table> TYPE ztest_table.
DATA: w_header  TYPE bapi2017_gm_head_01,
      w_code    TYPE bapi2017_gm_code,
      it_item   TYPE TABLE OF bapi2017_gm_item_create,
      wa_item   TYPE bapi2017_gm_item_create,
      it_return TYPE TABLE OF bapiret2,
      wa_return TYPE bapiret2,
      w_head    TYPE bapi2017_gm_head_ret,
      w_matdoc  TYPE bapi2017_gm_head_ret-mat_doc,
      w_matyear TYPE bapi2017_gm_head_ret-doc_year.

INITIALIZATION.
  cl_os_system=>init_and_set_modes( i_external_commit = oscon_false " No Explicit Commit work, End method triggers it.
                                    i_update_mode     = oscon_dmode_update_task )." oscon_dmode_update_task_sync -->COMMIT WORK AND WAIT
  "OSCON_DMODE_UPDATE_TASK  - > in update task.
START-OF-SELECTION.
  lr_tr_mgr = cl_os_system=>get_transaction_manager( ).
  TRY.
*Parent transaction.
      lr_trans = lr_tr_mgr->create_transaction( ).
      lr_trans->start( ).
      l_tabix = sy-tabix.
*        l_create = 'X'.
      REFRESH  it_item.
      w_code = '03'.
      w_header-pstng_date     = w_header-doc_date = sy-datum.
      w_header-pr_uname       = sy-uname.
      w_header-ver_gr_gi_slip = '3'.
      wa_item-material       = XXXX.
      wa_item-plant          = 'XXXX.
      wa_item-stge_loc       = 'XXXX'.
      wa_item-move_type      = 'XXXX'.
      wa_item-entry_qnt      = '1.00'.
      wa_item-entry_uom      = 'EA'.
      wa_item-costcenter     = 'XXXX'.

      wa_item-gr_rcpt        = '1XXXX'..
      APPEND wa_item TO it_item.
      CALL FUNCTION 'BAPI_GOODSMVT_CREATE'
        EXPORTING
          goodsmvt_header  = w_header
          goodsmvt_code    = w_code
        IMPORTING
          goodsmvt_headret = w_head
          materialdocument = w_matdoc
          matdocumentyear  = w_matyear
        TABLES
          goodsmvt_item    = it_item
          return           = it_return.
      lr_trans_sub = lr_tr_mgr->create_transaction( ).
      lr_trans_sub->start( ).
      DO 5 TIMES.
        APPEND INITIAL LINE TO lt_table ASSIGNING <fs_table>.
        <fs_table>-counter = sy-index  + 70. " some random value.
        IF sy-index EQ '5'.
          CALL FUNCTION 'ZTEST_TABLE_UPDATE' IN UPDATE TASK
            TABLES
              it_table = lt_table.
          lr_trans_sub->end( ).
        ENDIF.
      ENDDO.
      lr_trans->end( ).
    CATCH cx_os_transaction INTO lr_excpn .
*Error handling...
      WRITE: 'Error Occured in transaction processing'.
  ENDTRY.

Thanks,

Venkat.

[SuhaSaha]

I had written a response some time back for selective transaction control.However, I had tried with persistent objects back then.
http://scn.sap.com/thread/3317699

Why the hell did i not try it out before asking this question? I will pass the blame to your post (partly) & SAP documentation (mostly), they never state that one can use T-OS with non-persistent objects

Anyway thanks for your response, i have tried it out & it works OK!

The Transaction Service of the Object Services is also based on SAP LUWs and not on a new transaction concept. However, it does the bundling before the programmer, so that he or she does not have to explicitly create and register procedures that change the database. Internally, the Transaction Service still works with the classic update function modules.

I think the above statement is true for Persistence objects, correct? The agent class of a persistence class has the method SAVE_IN_UPDATE_TASK which is wrapped by the update module OS_UPDATE_CLASS.

I was wondering if we write direct DB updates (INSERT, DELETE etc) instead of wrapping them in Update FMs how will T-OS react? If T-OS does the bundling for us, then we don't need to code the Update modules

BR,

Suhas

Message was edited by: Suhas Saha

[Former Member]

Hello Suhas,

I will pass the blame to your post (partly) & SAP documentation (mostly),

Let's set a trial date with SAP . I too have some documentation issues to sort out .

I think the above statement is true for Persistence objects, correct? 
The agent class of a persistence class has the method SAVE_IN_UPDATE_TASK which is wrapped by the update module OS_UPDATE_CLASS. 

Yes, you are correct.

Surprisingly, If you observe the coding, it collects all the Updates , Delete's and Inserts into one Update Module. So if we are updating  5 persistent objects, all of them get updated in the DB in one shot -> which means persistent objects too get updated en masse and not singular as I had mentioned..

Thanks to You, i was thinking that every persistent object would have its own update module, now looking at the code, it seems the agent  bundles all changes in one update. Usually you do not have a scenario where would have multiple persistent objects( you could , no stopping! ), so the chaces of a mass update are slim, maybe thats why i had assumed it .

So, persistent objects too in a mass update should not have an issue, unless you have a save at every object change, but if you bundle them,from the looks of it , it should be fine. Thanks for providing the Bulb flash moment .

Regards,
Venkat.