Skip to Content
Author's profile photo Former Member

Kill delayed work processses automatically

Kill delayed work processses automatically through batch

Generally we use TCode SM50 to view running processes and delete the long running processes manually. This is an attempt to make this manual process into automated process.


SAP has given a function module TH_SERVER_LIST’ which gives all the details of the SAP Application Servers on the network.


SAP has given a function module  ‘TH_SYSTEMWIDE_WPINFO’ which gives all the details of work processes on given SAP Application Server.


We can filter the details by which type of work processes shall be stopped based on the time it has taken.


We have to take those process identifications (PID) and SAP Application Server and call the function ThWpInfo’ to stop the process permanently.


This report could be scheduled so that it runs on its own and stop the long running processes automatically.


It is to be noted that this Program uses unreleased function modules and kernel calls, and so is to be used at your own risk.

Complete source is as follows:


I do hope it helps.


I thank Mr. Matthew Billingham for his valuable suggestions and guidance.


REPORT  ZR_KILL_PROCESS.

DATA: itab LIKE STANDARD TABLE OF WPINFO,
      wa
LIKE WPINFO,
      delay_seconds
TYPE i VALUE 900.

DATA: BEGIN OF TY
 
INCLUDE STRUCTURE MSXXLIST_V6.
DATA: END OF TY.

DATA: itab_as LIKE STANDARD TABLE OF TY,
      wa_as
LIKE TY.

CONSTANTS: opcode_wp_stop TYPE x VALUE 2.

CALL FUNCTION ‘TH_SERVER_LIST’
TABLES
LIST          
= itab_as
EXCEPTIONS
NO_SERVER_LIST
= 1
OTHERS         = 2.

LOOP AT itab_as INTO wa_as.

  CALL FUNCTION ‘TH_WPINFO’
  
EXPORTING
   SRVNAME       
= wa_asname
  
TABLES
   WPLIST        
= itab
  
EXCEPTIONS
  
OTHERS = 1.

 
LOOP AT ITAB INTO WA.

   IF WAWP_TYP = ‘DIA’ AND WAWP_STATUS = ‘Running’ AND WAWP_ELTIME GT delay_seconds.

    CALL ‘ThWpInfo’
   
ID ‘OPCODE’ FIELD opcode_wp_stop
   
ID ‘SERVER’ FIELD wa_asname
   
ID ‘PID’ FIELD wawp_pid.

   ENDIF.
 
ENDLOOP.

ENDLOOP.

Assigned Tags

      9 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hi,

      I wonder what is the practical use for such report.

      May you explain about the business requirement?

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      If any user has run a report giving inappropriate parameters then it leads work process landing into a loop taking huge time and impacting performance of the SAP system. For such cases we can use this program to stop those processes.

      Author's profile photo Otto Gold
      Otto Gold

      How can the program decide if this is a problematic work process or a legitimate one? You certainly don't want to kill long running jobs that must complete etc. I would take care of such processes ad hoc and not kill them with the carpet bombing 🙂

      cheers Otto

      Author's profile photo Rainer Hübenthal
      Rainer Hübenthal

      Hi Otto,

      hi is killing only dialog processes.

      //Rainer

      Author's profile photo Rainer Hübenthal
      Rainer Hübenthal

      Well, what is the advantage of your report instead of just setting the parameter rdisp/max_wprun_time in RZ11?

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      There are some limitations as per the SAP Note 25528.

      Therefore we can use this program to overcome those limitations if the business requirements comes up.

      Author's profile photo Former Member
      Former Member

      I've read the note.

      What are the limitations you need to overcome?

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      As per the note:

      If any long query is running then ABAP/4 command would be waiting it to finish.

      Also you cannot issue next command therefore work process will continue to work.

      Author's profile photo Former Member
      Former Member

      Will direct call to ThWpInfo solve this issue?

      (If I had to guess, I would say that this limitation results from system design and not due to timeout mechanism implementation)