I read somewhere
Walking on water and building code for requirements is very easy... As long as they are frozen .
We started with a requirement which needed a user to be able change the data in one of the custom tables .
Everything was tested and finalized for production when just a days from the Go live the business comes back and saying they need multiple users in in the TMG Transaction at the same time working on different sets of data.
We did not have the time to redesign the whole thing using editable ALV's.
Also I did not really want to go the ALV way as TMG has a more complete experience.
So that's when I decided to look into trying to make it lock at a record level instead of locking the complete table , with some help from the various other articles here's how we achieved it. ( thought it would be nice to document it for future use) .
- Create the table and a Lock object , (this one had a big primary key) .
- Create the TMG for it .
- Make a note of the Function group used and the Screen number.
- Navigate to the FG in SE80 .
- Open the Screen and add a new Module( ZCUSTOM_ENQUE) in the PBO section .
- Put in the following code ( I prefer to create a new include to store custom modules )
MODULE zcustom_enque OUTPUT. *Call the function module corresponding to the lock object we created CALL FUNCTION 'ENQUEUE_EZXXXXXXXXX' EXPORTING mode_ztpp_XXXXXX = 'E' mandt = sy-mandt arbpl = ztpp_xxxxxx-arbpl matnr = ztpp_xxxxxx-matnr dtvon = ztpp_xxxxxx-dtvon werks = ztpp_xxxxxx-werks mdv01 = ztpp_xxxxxx-mdv01 srno = ztpp_xxxxxx-srno x_arbpl = ' ' x_matnr = ' ' x_dtvon = ' ' x_werks = ' ' x_mdv01 = ' ' x_srno = ' ' _scope = '2' _wait = ' ' _collect = ' ' EXCEPTIONS foreign_lock = 1 system_failure = 2 OTHERS = 3. IF sy-subrc <> 0. * MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO * WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. * row is locked..hence gray.. LOOP AT SCREEN. screen-input = 0. MODIFY SCREEN. ENDLOOP. ENDIF. ENDMODULE. " ZCUSTOM_ENQUE OUTPUT
- Create a report program in SE38 ( this will be the entry point for the user )
- The below Report ensures there are no locks at the table level when the TMG is called and should be the only call method for a TMG . ( assign a Tcode to this report ) .
REPORT zpp_XXXXXXXXXXXXXXXX_tmg. **Selection range for view maintenance DATA: BEGIN OF selekttab OCCURS 1. INCLUDE STRUCTURE vimsellist. DATA: END OF selekttab, **Table of inactive CUA functions for view maintenance BEGIN OF excl_cua_funct OCCURS 1. INCLUDE STRUCTURE vimexclfun. DATA: END OF excl_cua_funct. DATA: lt_enq_del TYPE STANDARD TABLE OF seqg3, lt_enq_read TYPE STANDARD TABLE OF seqg7, lw_enq_read TYPE seqg7, lw_enq_del TYPE seqg3, lv_subrc TYPE sy-subrc. *Read all the lock details in system CALL FUNCTION 'ENQUE_READ2' EXPORTING gclient = sy-mandt gname = ' ' guname = '*' TABLES enq = lt_enq_read. *We will search entry for table level lock for our table LOOP AT lt_enq_read INTO lw_enq_read WHERE gname EQ 'RSTABLE' AND garg CS 'ZTXXXXXX' . " table name MOVE-CORRESPONDING lw_enq_read TO lw_enq_del. APPEND lw_enq_del TO lt_enq_del. ENDLOOP. *Delete table level lock entry for our table CALL FUNCTION 'ENQUE_DELETE' EXPORTING check_upd_requests = 1 IMPORTING subrc = lv_subrc TABLES enq = lt_enq_del. *Now call the table maintenace generator. CALL FUNCTION 'VIEW_MAINTENANCE_CALL' EXPORTING action = 'U' view_name = 'ZTXXXXXXXX' " TMG name show_selection_popup = space TABLES dba_sellist = selekttab excl_cua_funct = excl_cua_funct.
Hope this helps someone.
Amarpreet.