Varad
Alright. Although the title may seem like clickbait, ABAP developers actually have the ability to end a SAP session. 😛 I can now proudly display my ABAP team member power thanks to this paper.
You have consistently denigrated an ABAPer’s service. They have been utilized by you for SAP housekeeping duties. But the core of every SAP project is its ABAP team. Thus, never undervalue the potent ABAPer. 😛
My base colleague provided me with assistance in learning about the server details, directory construction, etc. It was time to make amends. I was a little nervous about what assistance I would have to offer, but my coworker is a straightforward man. All he needed was assistance with a bothersome daily task; nothing more. Fewww! 😉
It was now my turn to use my ABAP expertise to thank him.
The Basis team has one job scheduled to update some master data, he casually mentioned to me over a tea break. They plan the work for after business hours within the lean window, but they frequently discover that some users have locked the transaction that the base team has to change. Additionally, if any user is seated in that content.
Elevated Solution Framework
Determine the number of users who have locked the Material Master transaction.
Send such users a pop-up warning message instructing them to end their transaction and save their session within five minutes.
Check once more to see whether someone is still locking the transaction after five minutes (the time should be customizable rather than hardcoded). Give them one more and last chance to save their work in five minutes.
The material master transaction that the user is locking will be released or closed in five more minutes. Every other transaction and session that doesn’t affect the task at hand is left unaltered.
Step 1: Determine Users
The details of locks are provided by the function module ENQUEUE_READ.
Given that I intend to test this object and do not wish to end other people’s sessions, I will supply sy-uname = my name in this instance.
I’ll erase my name with a ‘*’ after thorough testing is complete to reach all users.
*** FM to obtain all MARA table lock data (e.g., SM12).
CALL FUNCTION 'ENQUEUE_READ'
EXPORTING
gname = 'MARA'
guname = '$SBHANDARE'
TABLES
enq = gt_lock_details
EXCEPTIONS
communication_failure = 1
system_failure = 2
OTHERS = 3.
IF sy-subrc <> 0.
EXIT.
ENDIF. Get lively sessions:
Finding out how many sessions are open in each user’s system is necessary once we have identified which users are locking our transaction.
We may obtain all the information about active sessions using the standard ABAP class SERVER_INFO.
*** Get all user sessions
CREATE OBJECT server_info.
gt_session_list = server_info->get_session_list( with_application_info = 1 ).Now we need to filter out the sessions which belong to our users with client details.
*** Filter user sessions on the basis of username and client.
gt_session_list_user = VALUE #( FOR ls_lock_details IN gt_lock_details
FOR ls_session_list IN gt_session_list
WHERE ( user_name = ls_lock_details-guname
AND tenant = sy-mandt )
( ls_session_list ) ).We currently only hold open sessions with our target users.
It’s time to notify and issue warnings to these uncooperative users. Might be diligent users.
FM “POPUP_TO_CONFIRM” is what we utilize for pop-up messages. There’s a catch, though. POPUP_TO_CONFRIM will send a message to the user of the program or report.If we use this FM, the user who opened the screen in change mode won’t receive a notification.What then is the substitute?
Engage in SAP chat. You read correctly. Anybody connected to your office’s SAP network can get anonymous pop-up messages.The good news is that it will be difficult for them to determine the sender’s identity.I hope my thoughts are not the same as yours.
We can send pop-up messages to every user in the network system with the aid of FM “TH_POPUP.” Functions flawlessly in our situation.
DATA(gv_msg) = |You are locking Transaction { gv_tcode }. Please save and leave the transaction within 5 Secs!!!|.
DATA gv_message TYPE sm04dic-popupmsg.
gv_message = gv_msg.
LOOP AT gt_lock_details INTO gs_lock_details.
CALL FUNCTION 'TH_POPUP'
EXPORTING
client = sy-mandt
user = gs_lock_details-guname
message = gv_message
EXCEPTIONS
user_not_found = 1
OTHERS = 2.
ENDLOOP.We can notify every user who locks our transaction by iteratively going over the users table.
Let’s give users five minutes to save their info and end the session.
AVOID UP TO THREE MINUTES.
The SAP Workflow ABAP Wait statement almost caused my SAP Production system to crash. I’ll tell you that fascinating story another time. Even the article’s headline, “Wait Wait.. do NOT use me,” is in my head.
Check for the list of users who are waiting on our transaction once more after five minutes. This unfortunate person would only get five minutes if a fresh user locked the transaction in between. They wouldn’t receive the first list and the second warning.
gv_msg = |grrr..You are still locking Transaction { gv_tcode }. Your session will be killed soon!!!|.
gv_message = gv_msg.
LOOP AT gt_lock_details ASSIGNING <fs_lock_details>.
CALL FUNCTION 'TH_POPUP'
EXPORTING
client = sy-mandt
user = <fs_lock_details>-guname
message = gv_message
EXCEPTIONS
user_not_found = 1
OTHERS = 2.
ENDLOOP.Give consumers one last chance to save their data and end the session by waiting the final five minutes.
AVOID UP TO THREE MINUTES.
Get a list of the users who are still locked the transaction after the tenth minute. These are the guys who are on their way out of town or who have been on the phone for longer than ten minutes. Who would they chat to at these late hours, by the way?
It’s time to act.
Similar to t-code SM04, we will use a system kernel call to obtain all active session data.
"get technical info for the user
CALL 'ThUsrInfo' ID 'OPCODE' FIELD opcode_usr_info
ID 'TID' FIELD <fs_session_list>-logon_hdl
ID 'WITH_APPL_INFO' FIELD with_appl_info
ID 'TABLE' FIELD gt_usr_info[].For every session number (0–6) that the user has opened, we will receive a massive list with numerous rows here. Every login made by a user is given a distinct login ID, which is created depending on the client number, system, and language that you enter while logging in. The format of this session ID is TXX_UXXXXX, where X can be any number between 0 and 9.
After that, each session gets a session ID, which is made up of the login ID as previously mentioned plus an additional _MX, where X stands for the session number, in this case 0–6 (session 1–7). Therefore, the.session value of this technical list is of importance to us:
This is for session 1’s modelinfo[0]. In a similar vein, sessions two and three would correspond to [1] and [2].
modeinfo [1].T51_U11407_M1 is the session.
Modeinfo[2] would be present in Session 3.T51_U11407_M2 is the session.
In order to obtain the precise session that the user was using, we must now use the “/UPD” variable in the technical data. You guessed correctly. Update Mode requires UPD.
CONCATENATE <fs_lock_details>-gusrvb '/UPD' INTO DATA(gv_value).
READ TABLE gt_usr_info ASSIGNING FIELD-SYMBOL(<fs_usr_info>)
WITH KEY value = gv_value.
IF sy-subrc IS INITIAL.
"The key for the value is 'modeinfo[X].enq_info'.... we need just the X
gv_modus_index = <fs_usr_info>-field+9(1).
ELSE.
CONTINUE.
ENDIF.Using the procedure described above, we will now create a list of the users who have necessary sessions that we must terminate or shut.
After compiling the final user list, I made an initial unsuccessful attempt to figure out how to end the user’s session.
I attempted to record the SM12 BDC using the erase feature, but it was unsuccessful. I’m not sure; maybe I didn’t have the proper permission. I didn’t delve very far, though.
I then looked up t-code SM04. I sent the user session number to end that session and completed the BDC recording of it.
" call transaction SM04, sync (S), no screens
CALL TRANSACTION 'SM04'
USING bdcdata
MODE 'N'
UPDATE 'S'.
" Now use bdc to end the session with that session id
CLEAR bdcdata[].
PERFORM bdcdaten USING:
'X' 'SAPMSSY0' '0120',
' ' 'BDC_CURSOR' '04/03',
' ' 'BDC_OKCODE' '=&OL0'.
PERFORM bdcdaten USING:
'X' 'SAPLSKBH' '0800',
' ' 'BDC_CURSOR' 'GT_FIELD_LIST-SELTEXT(01)',
' ' 'BDC_OKCODE' '=WLSE',
' ' 'GT_FIELD_LIST-MARK(01)' 'X',
' ' 'BDC_SUBSCR' 'SAPLSKBH 0810SUB810'.
PERFORM bdcdaten USING:
'X' 'SAPLSKBH' '0800',
' ' 'BDC_CURSOR' 'GT_FIELD_LIST-SELTEXT(01)',
' ' 'BDC_OKCODE' '=CONT',
' ' 'BDC_SUBSCR' 'SAPLSKBH 0810SUB810'.
PERFORM bdcdaten USING:
'X' 'SAPMSSY0' '0120',
' ' 'BDC_CURSOR' '04/03',
' ' 'BDC_OKCODE' '=PS 63'.
PERFORM bdcdaten USING:
'X' 'SAPMSSY0' '0120',
' ' 'BDC_CURSOR' '02/76',
' ' 'BDC_OKCODE' '=&IC1'.
PERFORM bdcdaten USING:
'X' 'SAPMSSY0' '0120',
' ' 'BDC_CURSOR' '02/76',
' ' 'BDC_OKCODE' '=&ILT'.
PERFORM bdcdaten USING:
'X' 'SAPLSSEL' '1104',
' ' 'BDC_OKCODE' '=CRET',
' ' 'BDC_SUBSCR' 'SAPLSSEL 1105%_SUBSCREEN_FREESEL',
' ' 'BDC_CURSOR' '%%DYN001-LOW',
' ' '%%DYN001-LOW' gv_ssi_session_id.
PERFORM bdcdaten USING:
'X' 'SAPMSSY0' '0120',
' ' 'BDC_CURSOR' '04/15',
' ' 'BDC_OKCODE' '=&IC1'.
PERFORM bdcdaten USING:
'X' 'RSM04000_ALV_NEW' '2000',
' ' 'BDC_CURSOR' gv_modus_string,
' ' 'BDC_OKCODE' '=DEL'.
PERFORM bdcdaten USING:
'X' 'SAPMSSY0' '0120',
' ' 'BDC_CURSOR' '04/15',
' ' 'BDC_OKCODE' '=&F15'.
" call transaction SM04, sync (S), no screens
CALL TRANSACTION 'SM04'
USING bdcdata
MODE 'P'
UPDATE 'N'. Let’s finally take the session (or sessions) down by going in for the kill. To ensure that no one can subsequently accuse us of foul play, we then log the specific session, user, and transaction combination that we removed to the spool. People, we gave you ample time!
Don’t feel bad about ending the meetings. The users have received two warnings and have been given ten minutes to save the item, but they are still preventing our transaction. We had to go through with the attack.
We have to be tough sometimes. Excluding people from the system guarantees that the entire system is in sync with the most recent master data.
you may be interested in this blog here :-
