Doubt in call function

Question

Hi,
Call Function 'FM' starting new task task-name
Exporting
What does this statement does.

Answer 1

Hi
chk this out
CALL FUNCTION STARTING NEW TASK
Variant 2
CALL FUNCTION func ...STARTING NEW TASK task name.
Extras:
1. ... DESTINATION dest
2. ... DESTINATION IN GROUP group name
3. ... DESTINATION IN GROUP DEFAULT
4. ... PERFORMING form ON END OF TASK
5. ... EXPORTING  p1 = f1    ... pn = fn
6. ... TABLES     p1 = itab1 ... pn = itabn
7. ... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
Starts the function module func asynchronously in a new session. In contrast to normal function module calls, the calling program resumes processing as soon as the function module is started in the target system. It does not wait until the function module has finished. Using CALL SCREEN, the called function module can, for example, display a screen and thus interact with the user. Note that taskname must be a valid string of at least 2 characters, preferably fewer than 8 characters. You cannot use either ' ' or SPACE as tasknames.
Notes
Note that under certain circumstances, an RFC may cause a database commit. For this reason, do not insert an RFC between two OpenSQL statements that open and close a database cursor (such as SELECT...ENDSELECT).
This variant applies only from R/3 Release 3.0, so both the client system and the server system must have Release 3.0 at least.
With this variant, the called function module must also be flagged in the Function Builder as externally callable, even if it is executed locally (without the addition Destination).
There can be no function call to the destination 'BACK' in the called function module (for more information about the destination 'BACK', see CALL FUNCTION func DESTINATION dest).
This variant does not allow you to execute external programs that you access from a TCP/IP-type detination asynchronously. (See the Transaction Tools -> Administration, Administration -> Network -> RFC destinations for maintaining destinations).
Neither does this variant allow you to display images such as lists or screens in a separate window during RFC communication using a SAProuter.
From Release 4.0 onwards, you can carry out a new, stricter system load check on RFC destinations. (In RFC destination maintenance of an R/3 connection, choose Destination -> ARFC-Optionen). Before the function module is executed, the system checks that the destination has sufficient resources available. If not, the system delays execution of the function module for a given period of time. The algorithm used to determine the system load on the target machine is the same as that used for an asynchronous RFC with the DESTINATION IN GROUP addition. Note that this option is only available for target systems from Release 3.1H onwards. This procedure is active as default.
In principle, parallel processing makes sense whenever application servers have the necessary resources. In this case, the application servers must be configured with at least 3 dialog work processes.
A program that is run in the background and uses RFC parallel processing requires at least 1 dialog work process per application server (because parallel processing takes place in a dialog work process).
If the instance profile parameter 'auth/rfc_authority_check' is set to 1, the system automatically performs an RFC authorization check. The authorization check refers to the relevant function group for the function module to be called. If no authorization is found, a runtime error occurs. You can check the authorization in advance with the function module AUTHORITY_CHECK_RFC. If the RFC communication takes places in one system and in the same user context (that is, the same client and User ID) the system does not perform an RFC authority check. For more information, see: RFC Authorization Concept.
When you are using asynchronous RFC to implement parallel windows, all these windows are closed if the caller session is the only session and terminates.
Note that asynchronous tasks that have been started are not necessarily closed when the calling program ends.
See also RFC Logons to the Target System (Remote Logon).
Addition 1
... DESTINATION dest
Effect
Executes the function module externally as a Remote Function Call (RFC); dest can be a literal or a variable. The R/3 System where the function module is executed depends on the specified destination. Externally callable function modules must be flagged as such in the Function Builder (of the target system).
Note
If the destination is not explicitly specified, the system uses the default destination 'NONE'.
Note
If, during a Remote Function Call, an error occurs in the target system, details of the error message are passed back to the calling system in the following system fields: SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1, SY-MSGV2, SY-MSGV3, and SY-MSGV4. These fields are initialized before every RFC. If a short dump or a type X message occurs, the short text of the dump is transferred to the caller, and the contents of SY-MSGID, SY-MSGTY, SY-MSGNO, and SY-MSGV1 assigned by the system.
In RFC-enabled function modules, no ABAP statements are allowed that would end the RFC connection (for example, either LEAVE or SUBMIT without the AND RETURN addition).
Note
Note that a database commit occurs at each Remote Function Call (RFC). Consequently, you cannot use Remote Function Calls between pairs of statements that open and close a database cursor (such as SELECT ... ENDSELECT).
Addition 2
... DESTINATION IN GROUP group name
Addition 3
... DESTINATION IN GROUP DEFAULT
Effect
You use this addition to perform parallel execution of function modules (asynchronous calls) on a predefined group of R/3 System application servers.
You use addition 2 (DESTINATION IN GROUP group name) to perform parallel execution of function modules on a predefined group of application servers. To maintain the RFC groups, choose Tools -> Administration -> Administration ->Network -> RFC destinations -> RFC -> RFC groups. The application programmer is responsible for the availability of RFC groups in the production system. In this case the group name variable must be of the type RZLLITAB-CLASSNAME
You use addition 3 (DESTINATION IN GROUP DEFAULT) to perform parallel execution of function modules (asynchronous calls) on all currently available R/3 System application servers. However, instead of this variant, you are recommended to use an RFC group with appropriate resources for parallel processing of asynchronous calls (at least for performance reasons). Please note that the addition DESTINATION IN GROUP ' ' has the same effect as the addition DESTINATION IN GROUP DEFAULT.
When you first call a function module with these additions, the system initializes the specified RFC group (unless the group has already been explicitly identified).
To obtain current information about resources (that is, the resources available to process function modules), you can also initialize the RFC group explicitly in the program using the function module SPBT_INITIALIZE. You must perform this action before the first function module call.
In both cases, the system first ascertains the currently available resources (work processes) on the available application servers (either a group of servers or all servers). By checking the current system load of each application server, the system determines how many work processes are available to execute asynchronous calls.
After ascertaining the available resources, the asynchronous call is executed to one of the
destinations. If no resources are available at that particular time, the system executes the
exception routine RESOURCE_FAILURE (see the addition EXCEPTIONS). In the case of
an asynchronous function module call, this exception must be handled by the application
program (see example).
No resources are made available by the system if resource availability limits are exceeded:
Notes
To be taken into consideration for RFC parallel processing, an application server must have at least 3 free dialog processes.
The system triggers the exception RESOURCE_FAILURE only for asynchronous RFCs with the additions DESTINATION IN GROUP group name and DESTINATION IN GROUP DEFAULT.
At present, only one RFC group per program environment is supported for parallel execution of asynchronous calls. Using both the additions DESTINATION IN GROUP group name and DESTINATION IN GROUP DEFAULT in a program is thus not allowed.
To find out which destination was automatically selected, call the function module SPBT_GET_PP_DESTINATION immediately after the function module call with the two additions. This returns the selected RFC destination.
If you want to delete an application server from the list of the configured RFC group at runtime (for example, when the application server is not accessible for technical reasons), use the function module SPBT_DO_NOT_USE_SERVER.
Addition 4
... PERFORMING form ON END OF TASK
While the parameters for receiving results (that is IMPORTING and TABLES parameters) are specified directly as additions in the case of "conventional" function modules (see variant 2), these are logged in the FORM routine form when making an asynchronous call (see RECEIVE).
Notes
If a function module returns no result, and you are not interested in error messages that arise when executing the function module, this addition (... PERFORMING form ON END OF TASK) can be omitted.
If you want to handle the error messages that arise when executing the asynchronous function module call, you must use this addition. Also, when receiving the results in the FORM routine (see RECEIVE), you must react accordingly to the system exceptions SYSTEM_FAILURE and COMMUNICATION_FAILURE.
With asynchronous RFC, the task name uniquely identifies the asynchronous connection and thus the context called.
If several asynchronous function modules are executed consecutively to the same destination, you must assign a different task name to each.
A calling program that starts an asynchronous RFC with the PERFORMING form ON END OF TASK addition cannot switch roll areas or change to an internal mode. This is because the asynchronous function module call reply cannot be passed on to the relevant program. You can perform a roll area switch with SUBMIT or CALL TRANSACTION.
If a calling program makes asynchronous calls, finishes, and then expects responses, it cannot receive these responses.
To wait for the reply to a started asynchronous function module, use the WAIT command with the addition PERFORMING form ON END OF TASK. Here, WAIT must be in the same program context (mode).
Note that executing asynchronous calls is subject to a roll area change.That is, subroutines performed to receive asynchronous calls can take place while other asynchronous calls are being made. Thus as a developer you must ensure that subroutines can be executed at any time. You must not make assumptions about the implicit processing sequence.
Addition 5
... EXPORTING p1 = f1 ... pn = fn
Effect
Passes values of fields and field strings from the calling program to the function module. In the function module, the formal parameters are defined as import parameters.
Addition 6
... TABLES p1 = itab1 ... pn = itabn
Effect
Passes references to internal tables.
Addition 7
... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
While any exceptions arising in the called function module are handled by the second
addition (see the FORM subroutine RETURN_INFO), this addition can handle two special
system exceptions, (as with function module calls with the DESTINATION addition):
SYSTEM_FAILURE
is triggered, if a system crash occurs on the receiving side.
COMMUNICATION_FAILURE
is triggered if there is a connection or communication problem.
In both cases, you can get a description of the error with the optional ... MESSAGE messaddition
Note
In principle, you should always react to these two system exceptions, whether you are making an asynchronous function module call or receiving results.
Examples
Calling a transaction in a seperate session.
DATA: MSG_TEXT(80) TYPE C. "Message text
Asynchronous call to Transaction SM59 -->
Create a new session
CALL FUNCTION 'ABAP4_CALL_TRANSACTION' STARTING NEW TASK 'TEST'
  DESTINATION 'NONE'
  EXPORTING
      TCODE = 'SM59'
  EXCEPTIONS
    COMMUNICATION_FAILURE = 1 MESSAGE MSG_TEXT
    SYSTEM_FAILURE        = 2 MESSAGE MSG_TEXT.
  IF SY-SUBRC NE 0.
    WRITE: MSG_TEXT.
  ELSE.
    WRITE: 'O.K.'.
  ENDIF.
Using RFC groups to parallelize function module calls(RFC parallel processing)
TYPES: BEGIN OF TASKLIST_TYPE,
         TASKNAME(4) TYPE C, "Verwaltung der Tasks
         RFCDEST     LIKE RFCSI-RFCDEST,
      END OF TASKLIST_TYPE.
DATA: INFO LIKE RFCSI, C,  "Message text
      JOBS TYPE I VALUE 10,  "Number of parallel jobs
      SND_JOBS TYPE I VALUE 1,  "Sent jobs
      RCV_JOBS TYPE I VALUE 1,  "Received replies
      EXCP_FLAG(1) TYPE C,  "Number of RESOURCE_FAILUREs
      TASKNAME(4) TYPE N VALUE '0001',  "Task name administration
      TASKLIST TYPE TABLE OF TASKLIST_TYPE,
      WA_TASKLIST TYPE TASKLIST_TYPE.
DO.
  CALL FUNCTION 'RFC_SYSTEM_INFO'
       STARTING NEW TASK TASKNAME DESTINATION IN GROUP DEFAULT
       PERFORMING RETURN_INFO ON END OF TASK
       EXCEPTIONS
         COMMUNICATION_FAILURE = 1
         SYSTEM_FAILURE        = 2
         RESOURCE_FAILURE      = 3.
  CASE SY-SUBRC.
    WHEN 0.
Administration of asynchronous tasks
        WA_TASKLIST-TASKNAME = TASKNAME.
        CLEAR WA_TASKLIST-RFCDEST.
        APPEND WA_TASKLIST TO TASKLIST.
        WRITE: /  'Started Task: ', WA_TASKLIST-TASKNAME COLOR 2.
      TASKNAME = TASKNAME + 1.
      SND_JOBS = SND_JOBS + 1.
      JOBS     = JOBS - 1.  "Number of existing jobs
      IF JOBS = 0.
        EXIT.  "Job processing finished
      ENDIF.
    WHEN 1 OR 2.
Handling of communication and system failure
    WHEN 3.  "No resources available at present
Receive reply to asynchronous RFC calls
      IF EXCP_FLAG = SPACE.
         EXCP_FLAG = 'X'.
First attempt for RESOURCE_FAILURE handling
         WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.01' SECONDS.
      ELSE.
Second attempt for RESOURCE_FAILURE handling
         WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.1' SECONDS.
      ENDIF.
      IF SY-SUBRC = 0.
        CLEAR EXCP_FLAG.  "Reset flag
      ELSE.  "No replies
        "Endless loop handling
      ENDIF.
    ENDCASE.
ENDDO.
Receive remaining asynchronous replies
WAIT UNTIL RCV_JOBS >= SND_JOBS.
LOOP AT TASKLIST INTO WA_TASKLIST.
    WRITE:/   'Received Task:', WA_TASKLIST-TASKNAME COLOR 1,
          30  'Destination: ', WA_TASKLIST-RFCDEST COLOR 1.
ENDLOOP.
FORM RETURN_INFO USING TASKNAME.
  RECEIVE RESULTS FROM FUNCTION 'RFC_SYSTEM_INFO'
    IMPORTING RFCSI_EXPORT = INFO
    EXCEPTIONS
      COMMUNICATION_FAILURE = 1
      SYSTEM_FAILURE        = 2.
  RCV_JOBS = RCV_JOBS + 1.  "Receiving data
    IF SY-SUBRC NE 0.
Handling communication and system failure
   ELSE.
     READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME
                INTO WA_TASKLIST.
     IF SY-SUBRC = 0. "Daten registrieren
       WA_TASKLIST-RFCDEST = INFO-RFCDEST.
       MODIFY TASKLIST INDEX SY-TABIX FROM WA_TASKLIST.
     ENDIF.
   ENDIF.
ENDFORM.
plz reward if useful