Skip to Content

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.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Durairaj Athavan Raja
    Hi Anand,

    Welcome to the SDN blogging community. I have seen your replies to the ABAP forum and it were really quality ones. And you started of with a very intersting topic.

    Hope to see many more from you.

    Regards
    Raja

    (0) 
    1. Anonymous
      Hi Raja,

      Very pleased to know that you have found my posts on ABAP forum to be of [i]quality[/i]. Hope you’ll like the future weblogs as well.

      Regards,
      Anand Mandalika.

      (0) 
  2. Hasnain jaffery
    Hello,
    I don’t know how much you are familiar with FI-CA. It offers a standard frame work (mass activity) for parallel job. This is usually used by service industries as they run high volume of data processing every night. It is very easy to use and configure.
    Hasnain
    (0) 
  3. Horst Keller
    Hint 1:

    As of Release 6.20, the addition PERFORMING subr ON END OF TASK should be replaced by CALLING meth ON END OF TASK. In new projects, you should rather work with methods than with subroutines.

    Hint 2:

    For real parallel processing purposes, you should use the addition DESTINATION IN GROUP {group|DEFAULT} together with STARTING NEW TASK. With this you can execute several function modules in parallel on a predefined group of application servers of the current SAP system.
    The parallel processing of function modules with addition IN GROUP optimally uses the available resources and should be preferred to a self-programmed parallel processing with explicitly specified destinations.

    Hint 3:

    As of Release 7.0 (SAP NetWeaver 2004s), there is a new way to call transactional or queued RFC: CALL FUNCTION func IN BACKGROUND UNIT oref. An object referenced by oref contains the destination and whether to execute a tRFC or a qRFC. Multiple objects can be used in parallel in one internal session, which enables parallel processing of tRFC/qRFC.

    (0) 
    1. Anonymous
      Thanks very much Horst. That was very informative. I shall use these hints in my future posts/weblogs.

      Regards
      Anand Mandalika.

      (0) 

Leave a Reply