Collector for Cross-system RFC Locks
The technical name of the Collector for Cross-system RFC Locks is /DVD/MON_CL_COL_RFC_LOCKS.
In a scenario where business processes are handled by multiple applications and are accessing the same data, there needs to be a precaution that restricts applications from accessing data that is currently being processed by another application in a business process chain. This is what cross-systems locks (CSL) are for. CSL is based on the token concept: Application programs that need to access the same data compete for a token that is assigned to this data. The program that owns the token can access the data. For more information about CSL, see the chapter SAP Cross System Lock in the SAP Help Portal.
This collector collects information about cross-system RFC locks. It extracts information the same way as transaction SMCL. It can be parametrized and uses an input table that has the same select options as transaction SMCL. In addition, the collector has an enhancement spot implemented, which you can use to automatically release these locks.
If CSL is active on the monitored system, but no token is found for the used token manager, the warning message No entry found in table ‘CSL_MTLK’ for CSL token manager ‘<TOKEN_MANAGER>’ is raised. Otherwise, if CSL is not active on the monitored system, no message is raised.
In version 2211 and lower, if no token manager is found, the error message CSL: No hit in token manager <TOKEN_MANAGER> is raised. This occurs regardless of whether CSL is active or not. To resolve this error, we recommend upgrading to the latest available version.
Default KPIs Delivered with This Collector
The following default KPIs are delivered with this collector:
KPI name |
Description |
Unit |
Detail table |
---|---|---|---|
RFC_LOCK_ALL |
All cross-system RFC locks |
Count |
Yes |
RFC_LOCK_LONG |
Number of long-running cross-system RFC locks |
Count |
Yes |
Input Table
The collector uses the input table /DVD/MON_LCK_RFC, where you can specify what details will be extracted into the detail table /DVD/MON_S_RFC_LOCKS.
The input table /DVD/MON_LCK_RFC supports wildcards for the following fields:
-
TOKEN_HOME_SYSTEM
-
OBJECT_TYPE
-
USERNAME
These fields reflect the same function for defining inputs as transaction SMCL.
The fields MSY and MNU must be fully specified.
Field name | Description |
---|---|
MSY |
Remote system of the token manager |
MNU |
Number of the token manager |
TOKEN_HOME_SYSTEM |
Home system of the token manager |
OBJECT_TYPE |
Key for the lock object type |
USERNAME |
User who initiated the token lock |
Parameters
The following parameters are used for this collector:
Parameter name |
Description |
---|---|
RFC_LOCK_LONG_THRESHOLD |
Used for the KPI RFC_LOCK_LONG. Specifies how many seconds the lock must exist to be reported as long-running. Default value: 300 seconds |
RFC_LOCK_DAY_THRESHOLD |
Specifies how many days the collector looks back to collect lock details. By default, when the collector runs for the first time or the last run timestamp is not defined, this threshold is used. Otherwise, all locks are collected since the last run. |
Detail Table
The collector provides the detail table RFC cross-system lock details. The technical name of the detail table is /DVD/MON_S_RFC_LOCKS.
The detail table RFC cross-system lock details reports all cross-system RFC locks that are currently in place and were created in the last 24 hours. It contains the following fields:
Technical name |
Description |
---|---|
TOKEN |
Token |
TOKEN_MANAGER |
System of the token manager |
TOKEN_MANAGER_NUM |
Number of the token manager |
STATUS |
Status of assignment of the token manager to the token |
USERNAME |
User who initiated the token lock |
LAST_TIME_ACCESS |
Last access timestamp for the RFC lock formatted |
AGE |
Number of minutes during which the lock was not accessed |
EVENT_TIMESTAMP |
Same as the field LAST_TIME_ACCESS. It is only used for overriding the AppDynamics analytics timestamp |
Enhancement Spot
You can use a collector run to automatically release all locks that have been collected over the past 24 hours. There is an enhancement spot with the BAdI /DVD/MON_BAD_RFC_LOCKS and with an interface that contains the method RELEASE_LOCKS.
In the created implementation, call the function module CSLAR_TKCHANGE with the parameters already provided through the interface:
Function module parameter |
Variable |
---|---|
PCOMM_ROUTING_INFO |
IS_ROUTING_INFO |
BNAME |
SY_UNAME (The locks that are held under this username are released) |
PUCOMM |
‘DELE’ |
PCOMM_CALLED_CPPS |
IT_CALLED_CPPS |
TO_CHANGE_TOKEN |
IT_TOKENS |
This function module will automatically release all RFC locks collected by the collector. If you want, you can also add an additional function to this implementation, for example logging or another action that needs to be performed after releasing the lock.
Example code for releasing all collected locks:
CALL FUNCTION 'CSLAR_TKCHANGE'
EXPORTING
pcomm_routing_info = is_routing_info
bname = sy-uname
pucomm = 'DELE'
TABLES
pcomm_called_cpps = it_called_cpps
to_change_token = it_tokens
EXCEPTIONS
no_connection = 1
no_alobject = 2
internal_error = 3
OTHERS = 4.
IF sy-subrc <> 0.
/dvd/cx_mon_exception=>raise_from_system_message( ).
ENDIF.