topic Transactional BGRFC Delay Method in Application Development and Automation Discussions

Transactional BGRFC Delay Method

former_member202335 — Tue, 09 Jun 2020 11:44:26 GMT

Hello All,

I work as an ABAPer but don't have a lot of experience with BGRFCs.

Requirement : -

The user makes amendments in a document called 'Trading Contract' and clicks on the 'Save' button to save them.
When the save button is clicked, a BGRFC is executed to transition (via a BAPI) the contract from its existing status to a new status ('Awaiting Amendment Approval'). A BGRFC is being used because this can't be done in the same LUW because of technical reasons.

Program snippet: -

....
lv_dest_name = '/ACCGO/AMEND'.
lo_destination = cl_bgrfc_destination_inbound=>create( lv_dest_name ).
lo_unit = lo_destination->create_trfc_unit( ).

CALL FUNCTION '/ACCGO/CTR_TC_STATUS_CHANGE' IN BACKGROUND UNIT lo_unit
EXPORTING
iv_tkonn = iv_contract_num
iv_btbsta = lv_unapp_amend_status.

CALL METHOD lo_unit=>delay(5).
....
....
COMMIT statement is somewhere later in the code.

Issue: -

After the COMMIT, it sometimes takes some time for the lock on the trading contract to get released. If the BGRFC gets immediately executed (after execution of the COMMIT), and if the lock is not released, the BGRFC will not be able to do its job. I introduced the DELAY statement above hoping that it will reduce the chances of this happening. But, as a result of the DELAY, it seems that the unit simply does not get executed...it remains locked (as seen in SBGRFCMON) even after the 5 seconds are over. Could anyone help me out here?

Re: Transactional BGRFC Delay Method

Sandra_Rossi — Tue, 09 Jun 2020 12:45:53 GMT

Why don't you start your RFC function at the end of the update task to minimize the chance of being locked? (you do this by creating an update function module, and running it after all other update function modules, and your update function module starts the RFC).

Re: Transactional BGRFC Delay Method

ldaunys — Mon, 10 May 2021 08:05:51 GMT

I had exact same problem and realized there's no way to ensure data is unlocked, so what I did is try to acquire the lock for 200 seconds (that is enough for my project) and if that fails I crash the unit with an error (just throw an exception). This allows a human being to look at it and restart it in SBGRFCMON. Units can also be restarted through code (like dedicated programs).

This code is written within a bgRFC function. I launch the unit and let it wait for locks with some delays.

while lo_obj->is_locked = abap_false         <br>   and lv_lock_attempts < 100. "Limit attempts count to prevent lockups
  try.
      add 1 to lv_lock_attempts.
      lo_obj->lock( ). "Throws exception if lock fails
    catch zcx_lock.
        call function 'ENQUE_SLEEP' 
           exporting
             seconds = 2.
  endtry.
endwhile.
...
if lo_obj->is_locked = abap_false.
  raise object_locked. "Crashes the unit
endif.

Note: I also call this unit within the same LUW where unlock is supposed to happen to minimize the time window that people have to manually lock the data. You might also want to use unit->delay( ) if you know for a fact that data will stay locked for at least a specific amount of time.