Doubt in call function

[Former Member]

Hi,

Call Function 'FM' starting new task task-name

Exporting

.

.

.

.

What does this statement does.

[Former Member]

Hi mukesh,

1. When we use normal call function 'XYZ'

then,

we have to WAIT until the FM gets completely

executed.

(synchronous)

2. However, if we do not want to wait

(asynchronous)

we use this addtion STARTING NEW TASK

3. In this case, the program execution

continues

and parallely a new TASK / PROCESS

is created

which indepenedently executes the FM.

4. Also see F1 help on it.

regards,

amit m.

[Former Member]

Hi Amit,

You want to say that parallely the FM is executed twice one on its own and the other the newly created task will execute it.

I could not get anything in F1 help.Help is on call function in 'update task' not on start a new task.

[Former Member]

Hi again,

1. the FM is executed twice one on its own and the other the newly created task will execute it.

NO. The FM is executed ONLY ONCE.

But it is executed, in a separate process.

2. call function 'abc' <b>starting new task</b>

(keep your cursor on STARTING

and press F1)

3. From Help :

4.

Syntax

CALL FUNCTION func STARTING NEW TASK task

[DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]

parameter_list

[{PERFORMING subr}|{CALLING meth} ON END OF TASK].

Extras:

1. ... DESTINATION IN GROUP {group|DEFAULT}

2. ... {PERFORMING subr}|{CALLING meth} ON END OF TASK

Effect

Asynchronous call of a remote-enabled function module specified in func using the RFC interface. Use addition DESTINATION to specify a single destination in dest or use IN GROUP to specify a group of application servers. The latter supports parallel processing of several function modules. The calling program is continued after the CALL FUNCTION statement as soon as the remotely called function has been started in the target system, without waiting for its processing to be completed. Use PERFORMING and CALLING to specify callback routines for the takeover of events when the remotely called function is terminated. For func and dest, character-type data objects are destexpected.

If no destination is specified, the destination "NONE" is used implicitly. When using destination "NONE", a new main mode is opened for the current user session. The asynchronous RFC does not support communication with external systems or programs in other programming languages.

For task, you must specify a character-type data object, which contains a task identifier for the called remote function module, which can be up to eight characters long and chosen at will. This task ID should be unique for each call; it is passed to the callback routines to identify the function. Every task ID defines its own RFC connection with its own context, so that for repeated calls of function modules of the same task ID, the global data of the respective function group can be accessed, provided that the connection still stands.

Note

Note that you cannot exceed the maximum number of six main modes in dialog processing. Otherwise, an error message is triggered.

Addition 1

... DESTINATION IN GROUP {group|DEFAULT}

Effect

If ypu specify IN GROUP as the destination, you can execute several function modules in parallel on a predefined group of application servers of the current SAP system.

For group, you must specify a data object of type RZLLI_APCL from the ABAP Dictionary, which contains either the name of an RFC server group created in transaction RZ12 or is initial. When specifying DEFAULT or if group is initial, all currently available application servers of the current SAP system are used as the group. Within a program, you are only allowed to use one single RFC server group. At the first asynchronous RFC with the addition IN GROUP, the specified RFC server group is initialized. At each asynchronous RFC with the group specified, the best suited application server is automatically determined and the called function module is executed on this server.

If the function module cannot be executed on any of the application servers, because not enough resources are available at present, a predefined exception RESOURCE_FAILURE is triggered, to which, in addition to the other RFC exceptions, a return value can be assigned. With this exception, the addition MESSAGE is not allowed.

Notes

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.

An application server, which is used as part of an RFC server group for parallel processing, must have at least three dialog work processes, of which one is currently free. Other resources such as requests in the queue, number of system messages etc. are considered as well and must not exceed certain threshold values.

To guarantee that only application servers with sufficient resources are accessed, we recommend that you use the addition DEFAULT with explicitly defined RFC server groups.

The function modules of function group SPBT provide service functions for parallel processing, for example, initialization of RFC server groups, determination of the used destination or temporary removal of an application server from an RFC group.

Addition 2

... {PERFORMING subr}|{CALLING meth} ON END OF TASK

Effect

Use this addition to specify either a subroutine subr or, as of release 6.20, a method meth as the callback routine, which is executed after terminating the asynchronously called function module. For subr, you must directly specify a subroutine of the same program. For meth, you can enter the same specifications as for the general method call.

The specified subroutine subr can have exactly one USING parameter of type clike. meth must be public and can have only one non-optional input parameter p_task of type clike. At the call, the RFC interface fills this parameter with the task ID of the remotely called function, which was specified at the call in task. In the subroutine subr or in the method meth , you can use the statement RECEIVE to receive the results of the remote function. In the callback routine, you are not allowed to execute statements that interrupt the program execution or terminate a SAP LUW. Statements for list output are not executed.

Prerequisite for the execution of the callback routine is that the calling program still exists in its internal mode when the remote function is terminated. It is then executed at the next change of the work process . If the program was terminated or lies on the stack as part of a call sequence , the callback routine is not executed. Use the statement WAIT to stop the program execution until certain or all callback routines have been executed.

regards,

amit m.

[Former Member]

It will be executed only once in the new process. the current process will skip it and conitnue.

Regards,

Ravi

[Former Member]

It will spawn a new thread (process) and excute the function, while continuining the execution of the program that called the function.

Regards,

Ravi

Note :Please mark the helpful answers

[Former Member]

Hi mukesh,

CALL FUNCTION function STARTING NEW TASK task_name

[DESTINATION [dest | IN GROUP [Group_name | DEFAULT ]]]

[PERFORMING subroutine ON END OF TASK ]

[EXPORTING { parameter = value } ]

[TABLES { parameter = itab } ]

[EXCEPTIONS exception = value [MESSAGE field ]].

Runs the function function module asynchronously, in a new mode (or, if defined with DESTINATION, in another system identified by dest). The calling program starts without waiting for the called function module to end. As a result, it is not possible for the called function module to use its parameters to return values and exceptions. However, if required, you can use PERFORMING to name a subroutine. The only exception is errors that may occur when a connection is being set up to a remote system. You must use EXCEPTIONS to intercept them. You can use the MESSAGE addition to name a field in which the system places an explanatory text if an system error occurs. For this kind of call, all systems involved must have at least R/3 Release 3.0. When you create a call with DESTINATION, you can also use IN GROUP to name a group of application servers, on which the function module can undergo parallel processing.

Award if it helps.

regards,

keerthi.

[Former Member]

Hi,

the FM will run as new task , with out disturbing the other process.

Regards

vijay

[Former Member]

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