ABAP_to_the_Future

14
Shared Memory
The ability of a program to only talk to the shared memory root instance on the
current application server has led to shared memory being perceived to be impossible
to use. False! You can get around the problem.
First, create a method in your root class that takes in a material as the input and
then deletes that record from the buffer table. Naturally, that method only affects
the application server on which the program is runn ing. Then, wrap the code
inside a remote-enabled function module; the code looks like Listing 14.8.
FUNCTION zmm_shm_invalidate_material.
*"---------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" VALUE(ID_MATERIAL) TYPE MARA-MATNR
*"---------------------------------------------------------------
DATA: lo_material TYPE REF TO zcl_material_master_shmo.
DO 2 TIMES.
TRY.
"We only want one user updating the shared memory at once
"If two try at once, only let the first one do so
lo_material = zcl_material_master_shmo=>attach_for_update( ).
lo_material->root->delete_material( id_matnr = id_material ).
lo_material->detach_commit( ).
RETURN. "All done
CATCH cx_shm_inconsistent
cx_shm_no_active_version
cx_shm_exclusive_lock_active
cx_shm_version_limit_exceeded
cx_shm_change_lock_active "that is what I am looking for
cx_shm_parameter_error
cx_shm_pending_lock_removed.
WAIT UP TO 5 SECONDS.
CONTINUE. "Try Again - in case two users trying to
"update at same time
CATCH cx_shm_out_of_memory.
"We are in trouble. The only way to be sure the data is updated
"is to free up the entire material shared memory
zcl_material_master_shmo=>invalidate_area( ).
RETURN.
ENDTRY.
ENDDO.
* If we get here we could not delete the record that has been
650