Parallel Processing – An Introduction

Lemme start off with a question. When you are looking at a screen in SAP, what is it that’s required for you to go ahead ?

A user action on the screen, some would say. But just think again. You go to the initial screen of SE38 and in another session, have the initial screen of SE11. Just try changing the radio-buttons on these two screens. Do you notice something? That proves rather conclusively that not all user-actions will trigger processing. Doesn’t it?

The user-action will trigger further processing (called PAI) only if the screen-element has some function-code associated with it. Now can you trigger a function code without a user action? No…? Well, here’s something for you.

REPORT ZAUTOREFRESH_SCREEN. SELECTION-SCREEN BEGIN OF BLOCK AUTOREFRESH WITH FRAME. PARAMETERS CHKBOX AS CHECKBOX. SELECTION-SCREEN END OF BLOCK AUTOREFRESH. AT SELECTION-SCREEN. IF SY-UCOMM EQ 'ANY_OK_CODE'. WAIT UP TO 2 SECONDS. IF CHKBOX EQ 'X'. CLEAR CHKBOX. ELSE. CHKBOX = 'X'. ENDIF. ENDIF. CALL FUNCTION 'RFC_PING' STARTING NEW TASK 'WAITING' PERFORMING RETURN_FROM_WAIT ON END OF TASK. FORM RETURN_FROM_WAIT USING TASKNAME. SET USER-COMMAND 'ANY_OK_CODE'. ENDFORM.

Execute the above piece of code and on the selection screen just hit enter.

Need less to say, this thing works for a normal screen as well.

Apparently, things are a wee bit different in case of a list. Unlike in case of a screen, if the values of the variables displayed on the list have to be altered, you’ve got to do it yourself. The system doesn’t automatically do it for you.

REPORT ZAUTOREFRESH_LIST. DATA w_time_elapsed TYPE i VALUE -2. START-OF-SELECTION. WRITE : 'The time elapsed is :', w_time_elapsed, 'seconds'. SET USER-COMMAND 'ANY_OK_CODE'. AT USER-COMMAND. IF sy-ucomm EQ 'ANY_OK_CODE'. WAIT UP TO 2 SECONDS. ADD 2 TO w_time_elapsed. DO. READ LINE sy-index. IF sy-subrc NE 0. EXIT. ENDIF. MODIFY LINE sy-index FIELD VALUE w_time_elapsed. ENDDO. CALL FUNCTION 'RFC_PING' STARTING NEW TASK 'WAITING' PERFORMING return_from_wait ON END OF TASK. ENDIF. FORM return_from_wait USING taskname. SET USER-COMMAND 'ANY_OK_CODE'. ENDFORM.

Now let’s pull up our sleeves and see how it works….
The CALL FUNCTION…STARTING NEW TASK starts the execution of the function module in a new dialog work process. The processing is asynchronous, which means that the calling program does not wait till the function module completes execution. The PERFORMING …ON END OF TASK addition ensures that when the system detects the completion of the execution of the Function Module, it executes the corresponding subroutine.

So in case of the selection-screen, when the user hits enter, the Function Module gets called and the program continues with it’s execution – there’s no more code to be executed in the PAI and there’s no PBO either (AT SELECTION-SCREEN OUTPUT). So the screen is displayed, instantaneously.

Now this Function Module gets completed and the subroutine RETURN_FROM_WAIT gets executed. Since this subroutine sets a user-command, the PAI gets executed again and the checkbox is changed. The Function Module gets called again and the system displays the screen immediately, with the checkbox changed.

Theoretically, this can go on indefinitely. There wouldn’t be any problems of TIME OUT, since the program is in a constant state of activity.

The auto-refresh functionality essentially means that we would have to employ some kind of parallel processing. Because, there’s always a period of time during which the user does not do any activity on the screen. And certainly, we cannot expect the dialog work-process to be reserved for just one application. So we need a mechanism where the program can be triggerred to life periodically. And this weblog shows you how to do just that.