When moving to S/4 and with the corresponding classic release 9.5 the TM triggers, which are used for asynchronous updates and also for updates in case of locked documents, are using bgRFC as underlying technology.
Specifically in case of locked documents, the triggers are created with a certain delay (initially 30 seconds, then starting with 10 seconds and slowly getting slower for retries). What happens is that the triggers are created with a lock.
This looks in the bgRFCMON-transaction like this:
An important information about bgRFC is, that the frequence bgRFC checks for locked units which restart time has come is definable.
The note 1616303 describes the details, but basically the default is 5 minutes, but it can be adapted using transaction rz11 adapting the parameter rdisp/bgrfc_watchdog_time.
In case the processing of triggers which are based on locks takes too long, you can reduce the waiting time by changing this parameter.
When looking into bgRFC performance, this article might also be relevant to you.
Specifically in case of locked documents, the triggers are created with a certain delay (initially 30 seconds, then starting with 10 seconds and slowly getting slower for retries). What happens is that the triggers are created with a lock.
This looks in the bgRFCMON-transaction like this:
An important information about bgRFC is, that the frequence bgRFC checks for locked units which restart time has come is definable.
The note 1616303 describes the details, but basically the default is 5 minutes, but it can be adapted using transaction rz11 adapting the parameter rdisp/bgrfc_watchdog_time.
In case the processing of triggers which are based on locks takes too long, you can reduce the waiting time by changing this parameter.
When looking into bgRFC performance, this article might also be relevant to you.
- SAP Managed Tags:
| User | Count |
|---|---|
| 9 | |
| 8 | |
| 5 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 3 |
