How to stop parallel processing Programatically

[Former Member]

Hello Techies,

We know that using Asynchronous rfc implements the parallel processing by using the syntax,

CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword):

Let us say , i have one API name 'TEST_API'  in 4 different systems and also i do have a central system from where  i shall start the parallel processing by calling the API 'TEST_API' using rfc destinations.

i do as below

do 4 times.

CALL FUNCTION 'TEST_API'
   STARTING NEW TASK name

Destination in GROUP 'my_group'
     PERFORMING get_details ON END OF TASK
   EXCEPTIONS
   system_failure = 1 MESSAGE mess
   communication_failure = 2 MESSAGE mess
   resource_failure = 3.

enddo.

Question is now after two process has started one each in separate system, i have decided to stop the parallel processing in between.

How do you stop the parallel processing programatically ?

[matt]

Why have you asked almost exactly the same questions as here: ?

Are you and working on the same homework question, or same issue at work?

[Former Member]

No, we are working on different scenarios.

My requirement is to stop the workprocess in between.

[matt]

Are you working for the same company though? It just seems odd that two questions on parallel processing should appear in the same timeframe.

[Former Member]

Hi Matthew,

I don't know about the other person  who he is and where does he work, it is just a coincidence.

Better  if you know the answer can you reply.

Regards,

Ravi

[matt]

I accept your explanation.

I'm a moderator. It's part of my role to challenge suspicious behaviour, so don't get annoyed when that happens.

[Former Member]

Ravi,

If you are still developing the parallel processing program:

You can define a TVARV variable. Check that variable within the parent program to see if parallel processing is enabled or disabled. If enabled, launch parallel job. If not, launch a serial job (preferably in background.)

If the program is already in production:

Have basis reduce the number of processes in the server group to just 1. You can't do that if your server group is shared by multiple programs. Depending on why you want to stop parallel processing, this may not solve the problem. For example, if each process is taking too long and basis doesn't want you to run dialog jobs running for long times, this will not help because the single thread will still be a dialog job.

[ravikiran_kongati]

Hi Sudhi Karkada,

I am aware how to implement parallel processing. Also i am having my own group which is not shared as public to all to consume work process.

My question is once i start parallel process in other system how do i stop that?

[matt]

Ravi Kiran Kongati wrote:

.

Question is now after two process has started one each in separate system, i have decided to stop the parallel processing in between.
How do you stop the parallel processing programatically ?

I don't really follow what you mean by "decide to stop". I also can't think of a scenario where you'd want to interrupt processing.

Perhaps you can explain the process more clear. For example, is it something like this?

LOOP.

     Launch thread

     IF <condition> is TRUE.

          Kill running threads

          Leave loop

     ENDIF.

ENDLOOP.

Also, explain why you need to stop the running threads.

[Former Member]

Let me drill down even more for understanding.

I have user interface in central system where user selects the multiple systems and click on execute.

When execute is clicked, from the central system i call Asynchronous RFC in each system launching a new task.

Suddenly user wants to stop the execution, we have provided a STOP/CANCEL button in the userinterface, in such a case already if a process is started how to kil the process.

[Former Member]

I think it could be possible to use fm TH_GET_WPINFO to get information about the running work processes. As that function module is not RFC-enabled, I would write a wrapper RFC module with the task of identifying the running processes and terminate them.

[Former Member]

You have to stop the corresponding work process. FM TH_STOP_WP will do the job. To get the PID of your aRFC task you could use FM TH_WPINFO. Just have a look at function group THFB.

[matt]

Ok, so it's not really parallism - it's executing programs remotely.

I suggest then, that the remote jobs are executed as background batch jobs (i.e. your remote function modules create background jobs that do the actual work - and return the information concerning them), scheduled to run immediately on the remote systems. Then you can use one of the function modules listed here: how to cancell background active job | SCN to cancel the job, if the user needs to do that.

[Former Member]

He is using aRFC. That is something completely different from background jobs.

Edit: Have a look at Implementing Parallel Processing - Background Processing - SAP Library

[Former Member]

Andre SchüßlerHi Matthew,

I am calling RFC in each system and not waiting for  the already started taks to complete, thus it is a parallel processing.

Please see the reply from Andre.

[matt]

It doesn't matter. I'm suggesting an alternative approach to the overall problem.

[Former Member]

Ravi Kiran Kongati wrote:


Suddenly user wants to stop the execution....

This is an ad-hoc request, you can cancel processes in sm50.

For designed and worked as intentioned parallel processes where it is normal that sometimes a process gets canceled you're better of designing it from scratch using sap workflow parallel processes with a wait for an event to cancel the whole process.

Kind regards, Rob Dielemans

[Tomas_Buryanek]

Hello,

have you tried asynchronous RFC control statement:

WAIT UNTIL logical_expression

?

[Former Member]

Wait UNTIL logical_expression is to wait until the expression statement is true.

My requirement is not to wait i want to cancel already started parallel process.

[Former Member]

Please use following logic and let us know your feedback.

   CALL FUNCTION 'CACS_DATE_GET_TIMESTAMP'

      IMPORTING

        e_timestamp              = name

      EXCEPTIONS

        date_not_filled_but_time = 1

        date_has_no_valid_format = 2

        OTHERS                   = 3.

    IF sy-subrc <> 0.

* Implement suitable error handling here

    ENDIF.

CALL FUNCTION 'TEST_API'

   STARTING NEW TASK name

Destination in GROUP 'my_group'

     PERFORMING get_details ON END OF TASK

   EXCEPTIONS

   system_failure = 1 MESSAGE mess

   communication_failure = 2 MESSAGE mess

   resource_failure = 3.

  WAIT UNTIL gv_functioncall = gv_done.

FORM get_details USING name.

  RECEIVE RESULTS FROM FUNCTION 'TEST_API'

        TABLES

  gv_functioncall = gv_done.

ENDFORM.

[Former Member]

Why should he do that? To kill a work process that was started via aRFC you can use the FMs I provided in my first post.

Edit: You can also take a look at the functionalities of tcode SM50/SM66 to get a deeper understanding on how to stop a work process.

[Former Member]

I dont want to wait until the process gets completed. I want to kill already started process.

[Sandra_Rossi]

As you have a program which waits for RFCs, and as an RFC process should execute a small unit of work, i.e. one unit should not last very long, so you could define a maximum number of work processes running at the same time, and test whether someone has requested a stop, which would be checked each time one RFC has finished.

PS: if an RFC is running a "too much long time", then it's bad design, probably you should use a background job instead.

[Former Member]

They are using async RFC, so they are not waiting for RFC (if I understand correctly)

[Sandra_Rossi]

In the code of your initial post, you have mentioned "PERFORMING get_details ON END OF TASK", which means there should be a WAIT. If there is no WAIT, the PERFORMING is useless.

[Former Member]

The answer to the question is already given in my first post.

The function modul TH_WP_STOP kills the work process (without core dump).

This is what you want.

If you need to kill the work process in a remote System, function modul STUM_WP_TERMINATE is the way to go (can also kill with core dump).

Both function modules do only need the PID of the work process. You can get this PID on various ways. For example through calling function module TH_WPINFO (or EW_TH_WPINFO if you want to call it in remote system).

Please note the following.

Every time you call a function module via aRFC a new dialog work process is started. The function modules are executed independently in these work processes.  If you kill one of these work processes you kill the execution of the function module that is assigned to it (that is what you want).

If you start your function module via aRFC in 4 different systems, you get 4 unique dialog work processes. Kill all 4 of them and you are done.

[Former Member]

Hi Andre,

what i understood is  For example

Central System       ------>  connection 3 systems ( system id's : A, B, & C )

I am calling RFC's say 'API_TEST' in system A, system B and System C.

Now let us say i have called all the 3 systems via RFC and now i want to kill system B workprocess, for that what i need to do is to kill the work process remotely from Central system.

To kill the work process in system B again i should i have one more RFC say 'KILL_PROCESS' in system B which intrun kills the workprocesses, question here is will it kill its  new workprocess as well ( i.e.work process which was newly started when we called KILL_PROCESS' ) and will it have a dump here ?

[Former Member]

Ravi Kiran Kongati wrote:

Hi Andre,

what i understood is  For example

Central System       ------>  connection 3 systems ( system id's : A, B, & C )

I am calling RFC's say 'API_TEST' in system A, system B and System C.

Now let us say i have called all the 3 systems via RFC and now i want to kill system B workprocess, for that what i need to do is to kill the work process remotely from Central system.

Thats correct.

Ravi Kiran Kongati wrote:


To kill the work process in system B again i should i have one more RFC say 'KILL_PROCESS' in system B which intrun kills the workprocesses, question here is will it kill its  new workprocess as well ( i.e.work process which was newly started when we called KILL_PROCESS' ) and will it have a dump here ?

You can use RFC function module STUM_WP_TERMINATE. You don't need to create your own function module. You have to call it as a synchronous RFC and supply it with the PID of the process you want to kill.

Okay lets say you want to kill the execution of 'TEST_API' in system B.

Than you do just the following:

CALL FUNCTION 'STUM_WP_TERMINATE'

     DESTINATION system_b_destination

     EXPORTING

          pid = the_pid_of_the_wp_to_kill

     EXCEPTIONS

          ...

With this call the process gets killed.

Of Course you have to get the PID of the process first. You can do this by calling function module EW_TH_WPINFO.

ps. No short dump is generated. But you have the option to get a core dump.

[Former Member]

Hi Andre,

What do you mean by Core dump.

Couple of questions here :

1. when i am using RFC EW_TH_WPINFO in central system with destination mentioned as system B the importing parameter of FM EW_TH_WPINFO is giving result as Central system id. is this behavior correct.

2. Now we have situation like multiple users run this RFC's in multiple systems with same RFC user name, we can't change RFC user  here becuase you have to create RFC's for all users otherwise, in such a case killing process related to RFC user will kill other users workprocess as well.

Do you have any solution for this ?

[Former Member]

AFAIK: A core dump is a dump of the kernel. A short dump is a dump of an ABAP program.

You don't need a dump at all in your case. So forget about it. Just kill the processes with the option "without core dump" (if available).

1: Forget about the importing Parameter of EW_TH_WPINFO. Just call it in the following way and it will work:

CALL FUNCTION 'EW_TH_WPINFO'

   DESTINATION system_b_destination

   EXPORTING

     with_cpu       = '00'

   TABLES

     wplist         = wp_overview

   EXCEPTIONS

     ...

2: Well,I don't have a solution for this. Maybe there is some RFC State table where the connection between taskname and PID is stored. But I don't know.

If you cant identitfy your processes you might be lost

[Former Member]

Hi Andre,

1. While killing the work process of remote system i am facing message popup workprocess killed.

   
I am not expecting this because this might be irrelevant for user. Can we ignore this message, we need to simply kill process and come out.

2. When multiple users are running the parallel process in remote systems with same RFC name, we are not able to track the process related to users. This is  a challenge. probably i need to wait for some replies.