CALL FUNCTION - STARTING NEW TASK
Short Reference
ABAP Syntax CALL FUNCTION func STARTING NEW TASK task
[DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]
[{CALLING meth}|{PERFORMING subr} ON END OF TASK]
parameter_list
.
ABAP_ADDITIONS:
1 ... DESTINATION IN GROUP {group|DEFAULT}
2 ... {CALLING meth}|{PERFORMING subr} ON END OF TASK
What does it do? Asynchronous call ( aRFC ) 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
multiple function modules. The calling program is continued using the
statement CALL FUNCTION , as soon as the remotely called function
has been started in the target system, without having to wait for its
processing to be finished. Use CALLING and PERFORMING to
specify callback routines for the takeover of events when the remotely
called function is terminated. func and dest expect
character-like data objects.
If the destination is not specified and also not defined using the
addition KEEPING TASK of the statement
RECEIVE , then the destination "NONE" is used implicitly. The
asynchronous RFC does not support communication with external systems or
programs written in other programming languages.
A character-like data object must be specified for task . This
object must contain a freely definable task ID with a maximum of eight
digits for the remotely called function module. This task ID must be
unique for each call, and is handed to the callback routines for
identifying 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 and with the same destination,
the global data of the associated function group can be accessed if the
connection is still available. (This is the case, for example, if the
PERFORMING or CALLING addition is used. For asynchronous
RFC without a response (without the PERFORMING or CALLING
addition), the RFC connection is closed immediately after the call.)
More Information
For more information on aRFC , see
Asynchronous RFC ( aRFC )
in the SAP Library.
Latest notes: When screens are called during aRFC processing,
additional main sessions are opened in the RFC client. Note that the
maximum number of six main sessions cannot be exceeded; if there are
more, an error message is displayed.
Asynchronous RFC triggers a database
commit in the calling program. An sRFC during the
update is an exception to this.
If multiple asynchronous RFCs with various destinations are removed in
succession in a calling program, this automatically leads to the
parallel processing of the function modules called. Since the relevant
management can lead to resource bottlenecks on both the client and the
server, this kind of parallel processing is only recommended using the
DESTINATION IN GROUP addition.
ABAP_ADDITION_1 ... DESTINATION IN GROUP {group|DEFAULT}
What does it do? If IN GROUP is specified as the
destination , this supports parallel
execution of multiple function modules on a predefined group of
application servers of the current AS
ABAP . This variant of aRFC is also known as parallel
remote function call ( pRFC ).
group expects a data object of the type RZLLI_APCL from
ABAP Dictionary, either an initial data object or one that includes the
name of an RFC server group created in transaction
RZ12 . If DEFAULT is specified or if group is
initial, all currently available application servers of the current
AS ABAP are used as the group. Only one RFC server group may be used
within a program. During the first asynchronous RFC using the addition
IN GROUP , the specified RFC server group is initialized. For
each asynchronous RFC where the group is specified, the most suitable
application server is determined automatically, and the called function
module is executed on this.
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 raised, to which, in
addition to the other RFC exceptions , a return
code can be assigned. For this exception, the addition MESSAGE
is not permitted.
Latest notes: The parallel processing of function modules with the
addition IN GROUP makes optimal use of the available resources
and is preferable to self-programmed parallel processing with explicitly
specified destinations.
An application server that 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, the number of system messages and so on, are also respected and
must not exceed certain threshold values
.
To ensure that only those application servers that have enough
resources are accessed, we recommend working with explicitly defined RFC
server groups instead of working with the addition DEFAULT .
The function modules of the function group SPBT provide service
functions for parallel processing, for example, initialization of RFC
server groups, determining the used destination, or temporarily removing
an application server from an RFC server group.
ABAP_ADDITION_2 ... {CALLING meth}|{PERFORMING subr} ON END OF
TASK
What does it do? Use this addition to specify either a method meth
or a subroutine subr as the callback routine executed after
terminating the asynchronously called function module. For meth ,
the same information can be specified as for
method call , in particular the dynamic information. subr
expects a subroutine of the same program to be specified statically.
The method meth must be public , and
can have only one non-optional input parameter p_task of type
clike . The specified subroutine subr can
have exactly one USING parameter of the type clike . In the
call, the RFC interface fills this parameter with the task ID of the
remotely called function specified in the call in task . In the
method meth or in the subroutine subr , the statement
RECEIVE can be used to receive the results of
the remote function. In the callback routine, no statements can be
executed that interrupt the routine or that trigger an implicit
database commit . Class-based
exceptions must be handled within the callback routine. Statements for
list output are not executed.
A 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 is located on the stack as
part of a call sequence , the callback
routine is not executed. Use the statement WAIT
UNTIL to stop the program execution until certain callback
routines or all callback routines have been executed.
Latest notes: If no RECEIVE statement is executed in the callback
routine to receive the result of the remote function, the connection
remains intact and implicitly behaves like the
RECEIVE statement with the KEEPING TASK addition. This
implicit behavior is generally not desired.
We recommend that the time of execution of the callback routine is
programmed using WAIT UNTIL . This
statement leads to an explicitly requested change in the work process
and offers further control options. Only in exceptional cases should
callback routines be executed for implicit changes to the work process,
for example at the end of a dialog step .
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved