RFC groups - RZ12

As I know - to balance traffic for asyc rfcs we need to add our servers in RZ12 as parallel_generators(as described ).Is these RFC's execute by first hitting load balancing groups (SMLG) or from RZ12.
Not clear at all.
Can any one let me know what exactly RZ12 and why we use that!.
I have a newly added app server and have not assigned it to any erver group.Is this means this newly added server will not be used by any parallel RFC processing?Please let me knoe
Thanks to make me clear on this confusion!
Thank you
Srikanth.M

Hi Srikanth,
You can go through this link
[http://help.sap.com/saphelp_470/helpdata/en/fa/096e92543b11d1898e0000e8322d00/content.htm]
Mainly RZ12 is used to view and maintain RFC server groups.
Thanks,
Sudheer.

Similar Messages

RFC Groups - Where Used?

Hi,
I currently have the standard generated 'parallel_generators' RFC Groups in my system but also have 2 others, for which I do not know why they were created or what uses them.
I have used RPR_ABAP_SOURCE_SCAN to try and find any hard coded usage with no results found and also struggled to 'decode' the variants tables VARI etc to find usage in Variants.
But what I actually want is a 'Where Used' for RFC Groups.
Does anyone know a comprehensive solution to this or alternative analysis method?
Thanks and Regards
Ash

Hi Ash,
Same with the "Where used list" (I mean, it will be tedious to go to each program and identify).
Basically, the logon group info is stored on the RZLLITAB table. What distinguishes it if it's a dialog or an RFC type is the field group type (that is, if it's 'S' then it's an RFC group). There are several function modules and programs that uses this info. One of the common ones that SAP is using is the function module SMLG_GET_DEFINED_GROUPS (or SPBT_INITIALIZE). This function module determine if it's an RFC or dialog. As you've might have seen, there are several functions / programs that uses this (and they use the info returned by this function module to load balance either dialog and RFC processes).
Basically, to somewhat answer your query: There's no absolute "Where used list" since a developer can hardcode the query to the database for this table (and not have it part of the variants or other tables). Looking particularly for the server groupname (that shows up on the RZ12 transaction) on the ABAP codes is tedious. Not to mention the fact that a developer can also hardcode the server groupname on an external program that does an RFC (thus you will not see this in the SAP/ABAP system even if it has the "Where used list").
Thanks,
Allaine
Edited by: Allaine Tabilin on Mar 6, 2009 8:56 PM

In ECC application server getting hang becase of RFC's calls

When ever BOP jobs running on SCM system it is doing no of rfc calls from ECC system, almost all the workprocess is occupying and it is causing application server to be hang. We have created RFC logon Groups (RZ12) parallel_generators, the we assign these groups in SMQS, SMQR. Even though we are still facing the same issue.
Can you explain how logon groups use SMQS, SMQR and Could you please suggest how we can restrict the RFC calls?
Thanks
Mani

Hi Mani,
I try to explain to you as simple as I can.
1) In your source system (APO/SCM), BOP batch program generate tRFCs/qRFCs and store them into outbound queue.
2) In your source system (APO/SCM), qRFC outbound scheduler send the data to target system (ECC) through RFC group (rfc resource management parameters works here), and maximum number of connection per destination (SMQS) can be defined to limited the connection to target system
3) These RFC connections logons to target system (ECC) through the RFC definition which you can use LB, i.e. logon group (SMLG).
4) Same number of work processes (as number of activated connecions) will be activated (running), these processes write the data into inbound queue of your target ECC system.
5) target system (ECC) inbound queue scheduler, pick up the data (trfc/qrfc) in the queue, and send to work process of RFC group(RZ12), these work processes execute the inbound processing application.
6) inbound processing appliation might generate outbound tRFC/qRFC, trigger above processing again (target and source system exchanged)
i would recommend you increase parameter rdisp/rfc_min_wait_dia_wp in your ECC system for now, and also decrease the "Max.Conn." of the ECC destination in your APO/SCM sytem for immdiate remedy.
You need review your system resource ad configuration, business scenarios etc in detail and then optimize your qRFC and RFC resource configuration.
You should be able to find a lots of oss note by searching use key words "RFC" and "resource"
Good luck!
Denny

Error during this APL startup period - PI 7.0 SPS13

When we need to perform some maintenance in an application Server, we are stop this APL. During these steps, no problem in the XI System.
We have the same procedure to startup and we only put APL again, the central instance is not affect and all XI components will be running well, but during the APL startup, in the SMGW transaction we can see the ID AI_RUNTIME_XP0 for this APL, before all XI components will be available.
This situation is causing a lot of problems in the interfaces. During
this startup period, we can see this error messages
Received XI System Error in Integration Engine. ErrorCode:
JCO_SYSTEM_FAILURE ErrorText:
ErrorStack: "SYSTEM FAILURE" during JCo call. Bean
SMPP_CALL_JAVA_RUNTIME3not found on host apl54, ProgId
=AI_RUNTIME_XP0: P
(In this example, the APL was apl54).
Is there a special procedure to boot the APL ?

Marco
If I understand your question right, you want to know if there is a best practice to stop and restart an application server which is a part of your XI landscape? If my assumptions are right, for the fact that you are trying to bring down an application server means you have more than one app server and they are in a load balanced mode. If yes, you might want to first remove the application server from the RFC group (RZ12) which will prevent any new messages hitting this server. Then, once all the messages that are still under processing in this app server are completed, you can bring the server down, do the maintainance and bring it up. Once up, add it to the RFC group again. Same procedure applies for the java server nodes on this app server as well.
Hope this helps. I should say you haven't been very clear with your questions and hence no reply from other members. We understand your anxiety in not receiving any answers but with a global community like SDN, you might have to give as much information as possible to compensate for language barriers.
Thanks
KK

Load balancing by RZ12 Serger Groups

Hi.
I'm trying to get some knowledge about this subject for my prod. BI system. Maybe some of you, almighty masters of SAP administration (standard flattering), could give me a hand
Here's the situation: We've a BI system (NW 7.0 ehp1) with 4 servers ( CI + 3 appl.serv). We've defined both a server group (RZ12) and a logon group (SMLG), with the same name, for bw load purposes. That means mostly background and dialog processes, with less number of end-user logons, so I'm focusing in the Server Group configuration.
Now, the problem: Basically, the number of processes are not properly balanced. Servers 1 and 2 get about the 80% of the work, while other two, 3 and 4 just the other 20%.
I've been reading and investigating but most of the documentation refeers to the logon group load balancing algorithms in SMLG, by the setting of group-dependnet atribute "Ext. RFC-enabled", with it's corresponding "Fab.Typ" algorithm
What i want to know if it's there's a way to know that balancing algorithm/method it's being used in RZ12 rfc server groups, and how can I verify and even modify that behaviour.
I've been checking this notes:
Note 593058 - New RFC load balancing procedure
Note 1508504 - Load balancing in background processing
Also:
http://help.sap.com/saphelp_nw70ehp1/helpdata/en/a4/db833d4c47ea4ea1a9b7af3c535ff2/content.htm
Any suggestion or informacion will be gladly wellcomed. Dont hesitate in requesting me more detailed information.
Thanks in advance and regards.
Armando.

Hi,
Are you using load balancing in RFC connections as well ?
Thanks
Sunny

Load balancing algorithm for groups in RZ12

Hello,
I would like to know the load balancing algorithm for groups defined in RZ12.
I know that log on groups for external connections are administered via SMLG and table RZLLICLASS.
I also know that RFC resources can be managed for RFC logon groups via RZ12.
Kind regards,
Peter
<removed_by_moderator>
Point awarding is at your discretion, but read and follow the "Rules of Engagement"
Edited by: Juan Reyes on Dec 3, 2010 10:21 AM

Hello!
Found this post while searching information about RFC and Logon Groups...
I have some mess in my head with SMLG functionality and RZ12. As I know SMLG we can use to distribute users to application server instances, it gives us good achievement in performance. With RZ12 we can distribute RFC connection of particular job for parallel execution on predefined application server. With SMQS and SMQR transaction we can set "Name of AS Group" to route RFC-execution on certain server or servers. But I have troubles with understanding. Imagine, we set up group 1 with 2 servers (name it RFC_GR1), and group 2 with another 2 servers (name it RFC_GR2). How could qRFC scheduler decide on which RFC server group (RFC_GR1 or RFC_GR2) distribute RFC-execution? How to interact "Name of AS Group" with RFC groups if we can set only one group? How could we distribute RFC-execution depending on our logon groups (smlg)? We would like to distribute RFC depending on SAP logon groups. Is it possible? Or do I compare apple and orange?
Regards,
Artem Ivashkin

Startrfc & RFC Server Groups

Good day.
I was curious if there was a command line tool, similar to startrfc, that would leverage the RFC Server Groups (RZ12) as opposed to the Logon Groups (SMLG).
We currently have 2000 iDocs to post at once and are bombarding a single APP server since the logon load balancing algorithm is not rapid enough. Since the RFC Server Groups are designed for this exact purpose, I find it silly that startrfc would not leverage them.
Any help or ideas would be greatly appreciated.
Thank you,
Charles
DBA & BASIS Admin

Hi Charles,
We are developing an interface between SAP and an external system.
Estimated load for inbound documents is about 5000 iDocs per hour.
We plan to use "startrfc" command to load IDocs to SAP.
We are also interested in using RFC Server Groups (RZ12).
Have you found a WorkAround ?
Best regards
Jean Christophe

RFC Server Groups affecting RFC performance

Hi SDN performance experts
I am investigating an issue with RFC performance within our ECC5 system. ST03N shows an average total RFC response time across all instances has grown from a monthly average of 352ms in March to 1500ms in October. However, CPU and Database times have not risen very much during this time, indicating that we are 'losing' time elsewhere.
I broke down my investigation to look at each instance in turn and what I found was that half the instances had an average monthly RFC time that had been stable since March, whilst the remaining instances showed times that had increased greatly in May and June. Two of these instances had shown an increase from 0.5secs to nearly 20secs in three months!!
I dug a little deeper and found that a RFC server group (RZ12) had been created for the instances that are showing poor performance around May or June. The instances NOT included in this RFC server group are the ones that continue to perform well. I therefore assume that the problems are caused by this RFC server group.
The group has the following attributes (within RZ12):
Activated - 1
Max requests in queue - 5
Max no of logons - 90
Max disp of own logon - 25
Max no of WPs used - 75
Min no of free WPs - 1
Max no of comm entries - 90
Max wait time - 15
Can anyone help me solve this problem by advising how the RFC group should be set up to improve performance.
Many thanks,
Arwel Owen,
SAP BASIS Manager,
Princes Ltd,
Liverpool, UK.

Hi Nuno,
We configured RFCs to use application instances instead of the central instance because we too had problems with RFCs locking up the central instance many years ago. We took the decision then not to run RFC-based interfaces from the central instance, but to balance them across the application instances instead.
Each application instance has 15 DIA processes and the system barely ever reaches any near full capacity (where all DIA processes are in use), so I think we have enough processes configured.
We are not experiencing many buffer swaps. The Export/Import buffer has very similar number of swaps across all instances - it does not show more swaps for instance 01 over instance 00 (see my previous post for more information on how our instances are configured).
Can you please explain what you mean by configuring SMLG instead of RZ12 for RFCs?
Many thanks,
Arwel.

What could mean "server group"

What could mean server group. I have to specify when running a program in background(probably this is not a group in "smlg"as this partains to dialog processing

I think you're refering to SAP RFC server group
Similar to load distribution of user logins with logon groups, there is a mechanism for load distribution of RFCs
This is needed to achieve parallelization to achieve higher performance
To avoid overloading a dialog instance with too many simultaneous RFCs, it uses the resources of all existing dialog instances optimally. Hence you refine RFC server groups.
Use RZ12 to maintain RFC groups.
Create a group & assign single/multiple instances to this group
Regards
Puneeth

No IDocs could be sent to BI using RFC.

We are experiencing this error while loading data from R/3 to BI 7.0. The exact problem is that these Idocs eventually get transferred to BI but at a very very slow rate:
For a job that takes 10secs to load, you can have it running for 4hours.
How can we resolve fast pls?
Note there have been steps taken by our basis team all to no avail.
SM58 on BI doesnt throw up any hanging Idocs
=============================================
Errors while sending packages from OLTP to BI
Diagnosis
No IDocs could be sent to BI using RFC.
System Response
There are IDocs in the source system ALE outbox that did not arrive in the ALE inbox of BI.
Further analysis:
Check the TRFC log.
You can access this log using the wizard or the menu path "Environment -> Transact. RFC -> In source system".
Error handling:
If the TRFC is incorrect, check whether the source system is fully connected to BI. In particular, check the authorizations of the background user in the source system.
============================================
regards,
Nneka

Hi
I think that you should perform with your basis some checks in your R3 environment.
First go to we20 / we21 and check if you have the RS* message configured in the LSR3SID system.
Also ask to your technical team if they saw some RFC response time issue in the environment. Sometimes you have a large wait time and you can set a RFC groups in order to avoid that.
Be sure that the user used in the RFC connections are correct and if the roles assigned are the necesary.
If all of this points are correct you can try to reduce the amount of records and the size in every InfoPackage .
hope this help you

S_RFC Function Groups

Hello experts:
I am currently using S_RFC with full authorization ( * ) for RFC users in satellite systems. Can anyone clarify what this implies in terms of security? Can I restrict the "Name of RFC to be protected" field only to the function groups requiered for each user?
Particulary, I am using an RFC connection for the test workbench through SolMan using trx STWB_WORK? Do the function groups requiered depend on the transaction or program I am testing through my assigned test package? If so, how can I find out which function groups a particular transaction or program requieres? If not, does it depend on the program or transaction from which I am making the RFC connection, in this case STWB_WORK?
Can someone shed some light on how to determine the strictly necessary function groups to be assigned in S_RFC?
Thank you all,
Henry

Hello Henry,
While we wait for somebody more knowledgable than myself to answer, some comments from me:
My understanding is that this tool uses eCATT (to retrieve the results of test cases) from remote systems.
Always usefull => Activate the security audit log (transaction SM19) using the dynamic tab to log all successfull RFC calls to find out which calls are made in those systems, and in your SolMan.
Also take a look at the function groups of transaction SECATT in transaction SU24 which might have a "Proposal" (previously "Check/Maintain" value), as they may appear in the audit log in your remote systems... (I am not sure what the default values are).
There is also a SAP note "Minimum authorizations for Workplace users" (Note 215927) which might be usefull for you.
I also think the access required (not only S_RFC) will be dependent on your test cases (begging the question: How can SAP deliver a correct default or role...). You can also mitigate this risk by not saving the logon data permanently in the connections...
Of course, the application authorizations (e.g. S_DEVELOP, S_USER_GRP, and many others...) are also important for security, and the user type for the connection (type SYSTEM is the recommended type, if the logon data is going to be saved) as well. You might also want the user to logon when the connection is opened, if they are running the test themselves..?
Another aspect is how your target system is setup? If an invoced RFC call leaves it's RFC group (and is able to!), do you want to be able determine which RFC_NAME groups it can call? Or do you want to prevent it using client settings (see tha CATT / eCATT restrictions in SCC4 for your release) and system settings for the RFC check?
Some alternate strategies are to accept the risk, use dedicated user IDs for the test cases and secure the access to this transaction (not only limited to STWB_WORK) in the source system (your SolMan). Though some security folks I know prefer securing the target, as a general security principle, you can make a "quick-win" by securing your SolMan security...
Tricky topic. Good question!
Cheers,
Julius

RFC for Availbility check.

Hi all,
I am working for a Retail project. there is a requirement like...
Whenever POS (point of sales - Store) doing the billing for an article one request should go SAP to check the availbility of the product and get the status of the same.. is there any standard RFC for the req... pls do the needful...
it is some thing like online availability check...
Thanks in advance...
subbu..

hi
Synchronous RFC (CALL FUNCTION-DESTINATION)
Syntax
CALL FUNCTION func DESTINATION dest parameter list.
Effect
Synchronous call of a remote-capable function module specified in func using the RFC interface. With the addition DESTINATION, the destination is specified in dest. Character-type data objects are expected for func and dest. The calling program is continued using the statement CALL FUNCTION, if the remotely called function has finished.
CALL FUNCTION - DESTINATION parameter list
Syntax
... http://EXPORTING p1 = a1 ... pn = an
http://IMPORTING p1 = a1 p2 = a2 ...
http://CHANGING p1 = a1 p2 = a2 ...
http://TABLES t1 = itab1 t2 = itab2 ...
[EXCEPTIONS exc1 = n1 exc2 = n2 ... MESSAGE mess
OTHERS = n_others].
Effect
These additions are used to assign actual parameters to the formal parameters of the function module, and return values to exceptions that are not class-based. The additions have the same meanings as for the general function module call, the only differences being that, with the addition TABLES, only tables with flat character types can be transferred, and that if a header line exists, it is not transferred. The additions EXPORTING, IMPORTING and CHANGING allow you to transfer tables that have deep character types, deep structures, and strings.
For EXCEPTIONS, you can also specify an optional addition MESSAGE for the special exceptions SYSTEM_FAILURE and COMMUNICATION_FAILURE. If one of these exceptions occurs, the first line of the corresponding short dump is entered in the field mess, which must be flat and of character-type.
Transferring tables using the addition TABLES is considerably faster than using the other additions, since a binary format is used internally instead of an XML format.
Parallel Processing with Asynchronous RFC
To achieve a balanced distribution of the system load, you can use destination additions to execute function modules in parallel tasks in any application server or in a predefined application server group of an SAP system.
Parallel-processing is implemented with a special variant of asynchonous RFC. Its important that you use only the correct variant for your own parallel processing applications: the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword. Using other variants of asynchronous RFC circumvents the built-in safeguards in the correct keyword, and can bring your system to its knees
Details are discussed in the following subsections:
· Prerequisites for Parallel Processing
· Function Modules and ABAP Keywords for Parallel Processing
· Managing Resources in Parallel Processing
Prerequisites for Parallel Processing
Before you implement parallel processing, make sure that your application and your SAP system meet these requirements:
· Logically-independent units of work:
The data processing task that is to be carried out in parallel must be logically independent of other instances of the task. That is, the task can be carried out without reference to other records from the same data set that are also being processed in parallel, and the task is not dependent upon the results of others of the parallel operations. For example, parallel processing is not suitable for data that must be sequentially processed or in which the processing of one data item is dependent upon the processing of another item of the data.
By definition, there is no guarantee that data will be processed in a particular order in parallel processing or that a particular result will be available at a given point in processing.
· ABAP requirements:
¡ The function module that you call must be marked as externally callable. This attribute is specified in the Remote function call supported field in the function module definition (transaction SE37).
¡ The called function module may not include a function call to the destination BACK.
¡ The calling program should not change to a new internal session after making an asynchronous RFC call. That is, you should not use SUBMIT or CALL TRANSACTION in such a report after using CALL FUNCTION STARTING NEW TASK.
¡ You cannot use the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP keyword to start external programs.
· System resources:
In order to process tasks from parallel jobs, a server in your SAP system must have at least 3 dialog work processes. It must also meet the workload criteria of the parallel processing system: Dispatcher queue less than 10% full, at least one dialog work process free for processing tasks from the parallel job.
Function Modules and ABAP Keywords for Parallel Processing
You can implement parallel processing in your applications by using the following function modules and ABAP keywords:
· SPBT_INITIALIZE: Optional function module.
Use to determine the availability of resources for parallel processing.
You can do the following:
¡ check that the parallel processing group that you have specified is correct.
¡ find out how many work processes are available so that you can more efficiently size the packets of data that are to be processed in your data.
· CALL FUNCTION Remotefunction STARTING NEW TASK Taskname DESTINATION IN GROUP:
With this ABAP statement, you are telling the SAP system to process function module calls in parallel. Typically, youll place this keyword in a loop in which you divide up the data that is to be processed into work packets. You can pass the data that is to be processed in the form of an internal table (EXPORT, TABLE arguments). The keyword implements parallel processing by dispatching asynchronous RFC calls to the servers that are available in the RFC server group specified for the processing.
Note that your RFC calls with CALL FUNCTION are processed in work processes of type DIALOG. The DIALOG limit on processing of one dialog step (by default 300 seconds, system profile parameter rdisp/max_wprun_time) applies to these RFC calls. Keep this limit in mind when you divide up data for parallel processing calls.
· SPBT_GET_PP_DESTINATION: Optional function module.
Call immediately after the CALL FUNCTION keyword to get the name of the server on which the parallel processing task will be run.
· SPBT_DO_NOT_USE_SERVER: Optional function module.
Excludes a particular server from further use for processing parallel processing tasks. Use in conjunction with SPBT_GET_PP_DESTINATION if you determine that a particular server is not available for parallel processing (for example, COMMUNICATION FAILURE exception if a server becomes unavailable).
· WAIT: ABAP keyword
WAIT UNTIL
Required if you wish to wait for all of the asynchronous parallel tasks created with CALL FUNCTION to return. This is normally a requirement for orderly background processing. May be used only if the CALL FUNCTION includes the PERFORMING ON RETURN addition.
· RECEIVE: ABAP keyword
RECEIVE RESULTS FROM FUNCTION Remotefunction
Required if you wish to receive the results of the processing of an asynchronous RFC. RECEIVE retrieves IMPORT and TABLE parameters as well as messages and return codes.
Managing Resources in Parallel Processing
You use the following destination additions to perform parallel execution of function modules (asynchronous calls) in the SAP system:
In a predefined group of application servers:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION IN GROUP Groupname
In all currently available and active application servers:
CALL FUNCTION Remotefunction STARTING NEW TASK Taskname
DESTINATION IN GROUP DEFAULT
The addition first determines the amount of resources (work processes) currently available (i.e. in all servers or in a group of application servers, comparable with login servers). The resources available for executing asynchronous calls on each application server depends on the current system load.
The applications developer is responsible for the availability of RFC groups in the production system (i.e. the customer's system). For details on how to maintain the RFC groups, see Maintaining Group Destinations For Load Distribution.
After determining the available resources, the asynchronous call is executed in an available application server. 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.
The process for determining available resources in an RFC group is as follows:
First, the system determines the length of the dispatcher queue for the relevant application server. If it is greater than 10% of the overall length, the server makes no resources available. If it is smaller, the system makes available the current number of free dialog processes minus 2 (as a reserve instance for other purposes, e.g. for logon to the system or administration programs). Thus, one application server must have at least 3 dialog processes if RFC parallel processing is taken into account.
§ At present, only one RFC group per program environment is supported for parallel execution of asynchronous calls. Using both additions (DESTINATION IN GROUP Groupname and DESTINATION IN GROUP DEFAULT) in one program is not allowed.
§ The exception routine RESOURCE_FAILURE is only triggered in connection with asynchronous RFCs with the additions DESTINATION IN GROUP Groupname and DESTINATION IN GROUP DEFAULT.
You are recommended (for performance and other reasons) to use an RFC group with sufficient resources for parallel processing of asynchronous calls
Continue with the following section:
CALL FUNCTION - STARTING NEW TASK
regards
satish

About types of rfcs

dear all,
this is jyothi. can u please explain the different rfcs and waht is the difference between those types.

HI,
SYNCHRONOUS R F C:
With synchronous RFC, processing stops in the calling program until the called remote function is processed and its output is returned. Then in the calling program, the processing continues after the call.
The statement CALL FUNCTION ... DESTINATION enables you to call remote ABAP function modules or C routines in external server programs.
When you call a function in this way, always include handling for the standard exceptions COMMUNICATION_FAILURE and SYSTEM_FAILURE.
The exception COMMUNICATION_FAILURE is resolved by the system if the specified destination in the sideinfo table RFCDES is not maintained, or if the connection to the remote system cannot be established.
The exception SYSTEM_FAILURE is resolved if the function module or C routine that you want to start in the remote system is not available.
The connection to a remote destination remains intact for as long as the context of the calling program remains active. The function groups addressed in the remote destination remain active for as long as the calling program itself remains active (this is the same as with local calls). This means that if you call two function modules from the same function group one after the other, they can both access the same global data of the function group.
Each function module called using synchronous RFC forms its own logical unit of work (LUW) (exception:
You can debug function modules called remotely in R/3 - R/3 connections.
If a remotely-called function module uses dialogs (for example, CALL SCREEN,
CALL TRANSACTION or lists), they are executed in the session of the caller (and are fully functional).
Note that RFC dialogs in background processing lead to a program termination with the exception SYSTEM_FAILURE (but you can use RFC within background processing).
ASYNCHRONOUS RFC :
In an asynchronous Remote Function Call, the called remote function is started and then continues processing on its own immediately in the calling program. Remote function processing is separate from the calling program. The function output can be received later in the program.
Asynchronous RFC is intended for parallel processing of processes.
With the addition STARTING NEW TASK you can call a remote function module asynchronously. You can use any task name.
The function module that you call is executed in its own work process.
You can also use aRFC in background processing. Note, however, that even here, each aRFC call occupies a dialog work process.
In the sideinfo table RFCDES, you can set the number of aRFC calls for each destination using the aRFC options. After these aRFC calls an automatic load check is performed on the target server. If resource bottlenecks are detected, the system waits for a short time for the next aRFC call,
meant for the same remote system, and the client program is rolled out of its work process. It can then receive results from previous aRFC calls.
During the call, you may not specify an IMPORTING addition since the call does not wait for the end of the function module. Here, you can only handle the two system exceptions, COMMUNICATION_FAILURE and SYSTEM_FAILURE for the same reason. The function module output must be received and the function module-specific exceptions must be handled later on in a different place. (See following slides)
Receiving the function module output and handling the function module-specific exceptions are optional, however.
A program can receive output (parameters and exceptions) from a function module that is running asynchronously.
To implement this, when you call use the addition "PERFORMING ON END OF TASK", where the specified subroutine must exist in your program, and through which the output of the function module is received using command "RECEIVE RESULTS FROM FUNCTION . .". When the function module ends, the subroutine is called automatically.
The subroutine must also have a formal parameter with any name you choose. When the subroutine is called, it receives the accompanying task name. This parameter lets you see which aRFC call just ended, and you can receive the relevant
output using the RECEIVE RESULTS FROM FUNCTION command.
The subroutine may not contain any statements that interrupt the program execution (such as CALL SCREEN, SUBMIT, COMMIT WORK, WAIT, RFCs, W or I messages). WRITE statements in this subroutine specially defined for aRFC have no effect.
The subroutine can only be executed automatically if the calling program is in rollout status. -> "WAIT UNTIL" statements (see next slide).
The addition KEEPING TASK with the RECEIVE statement causes the function group context that was loaded remotely to wait until the calling program has ended. This lets you use the old remote context with later aRFC calls with the same task name.
The language element WAIT UNTIL with the addition PERFORMING is only useful with aRFC, and otherwise has no effects.
When the WAIT UNTIL statement is executed, the conditions specified are checked.
If it is fulfilled, the program processing continues directly after the WAIT UNTIL statement.
Otherwise the system waits in rollout status for the output from the aRFCs. If the aRFC output is now returned, the form routine specified during the call is executed and is sent back to the WAIT UNTIL statement.
This check/wait procedure repeats until the WAIT conditions are fulfilled, or until there are no more open RFC calls.
Note that the WAIT UNTIL statement sets the SY-SUBRC. Therefore, store the SY-SUBRC value (set in the form routine by exceptions-handling in RECEIVE RESULTS) in its own global variable before leaving the form routine, if you need this value again later (after WAIT UNTIL).
aRFC is particularly suited for implementing parallel processing in several R/3 Systems.
You can also use aRFC within the same SAP R/3 System, for example, to move some of the processing load to an application server specially used for this.
Enter the RFC destination that refers to the corresponding application server. (You can find this under Internal connections in Transaction SM59.)
You can also use aRFC locally within the same application server to implement parallel processing in several work processes.
Here you do not need to specify a destination.
Note, however, that several work processes will be occupied by your program at the same time.
LOAD BALANCING USING RFC GROUPS:
You can divided the application servers for an SAP R/3 System into different RFC groups using Transaction SM59.
When calling a function module within this R/3 System, you can specify one of the defined RFC groups using the addition DESTINATION IN GROUP , which selects the server that has the lowest load in order to execute the function module.
Instead of specifying a specific RFC group, you can also enter the word DEFAULT. The server is selected from all the application servers of the R/3 System.
If all the servers of the specified group are overloaded (see next slide), the exception RESOURCE_FAILURE is triggered.
Note that:
- You have to specify the addition DESTINATION IN GROUP after STARTING NEW TASK as opposed to the DESTINATION addition.
- You can only use this addition within the current SAP R/3 System (you cannot have additional DESTINATION entries).
For each server in the specified RFC group, the system checks if the application server has:
- a dispatcher queue load of <> No IMPORTING . . . / PERFORMING . . . ON END OF TASK when calling;
-> No RECEIVE RESULTS FROM FUNCTION . . .
In the source system, you can use the administration transaction SM58 that lets you display and modify tRFC-LUWs.
EXECUTION:
tRFC calls are first stored in the local tRFC tables ARFCSSTATE and ARFCSDATA. The execution status of the LUWs is logged in table ARFCSSTATE, while ARFCSDATA contains the input data for the tRFCs.
If you do not want to execute a remote LUW immediately, rather trigger it at a later time, call the function module START_OF_BACKGROUNDTASK before the COMMIT WORK statement locally. Here, you must enter the date and time of execution.
The COMMIT WORK statement automatically schedules an immediate job or a job set for a later start time to remotely call the LUW. In the job execution, the relevant data is read from the tRFC tables, and the corresponding tRFCs are transmitted. If the remote LUW is executed successfully, the accompanying entries are deleted from the tRFC tables. If an error occurs, an automatic repeat mechanism, or rollback mechanism is activated (see next slide).
If the update is triggered locally because of the COMMIT WORK statement, the tRFCs are only executed when the local update is successfully completed.
WHEN ERROR COMES:
If a connection cannot be made to the partner, this is logged in the tRFC status table ARFCSSTATE (which you can see by using Transaction SM58), and the job is rescheduled. You can set in the destination the number of times the system repeats the effort to connect, and the time intervals, by using the tRFC options. The default is a maximum 30 times with a 15 minute interval.
If, after a tRFC-LUW is successfully executed in the partner system in one of the function modules, the program terminates with an A/X-message (MESSAGE A/X...) or triggers an exception (RAISE...),
- all the changes made in the current LUW are automatically rolled back in the remote system, and
- the remote program termination is logged in the tRFC status table ARFCSSTATE (viewable using SM58) in the source system.
The entries relevant to the LUW remain in the tRFC tables and the execution job is not rescheduled. In this case, you can find the remote error using Transaction SM58, and you have to correct the problem in the remote system. Afterward you must trigger the remote execution again also in Transaction SM58.
If you want to cancel and roll back this remote execution from a remote function module of a tRFC-LUW, but you also want to reschedule the job in the source system (for example, because a master record that is to be processed is locked and the LUW must be executed again), call the function module RESTART_OF_BACKGROUNDTASK in the remote function module instead of MESSAGE A... or RAISE...
LUW BUILDING:
If tRFCs are transmitted with different destinations before the COMMIT WORK, they are grouped into different LUWs according to their destination.
A tRFC call with the addition AS SEPARATE UNIT is always processed as a separate LUW independently of the other tRFCs.
Each tRFC-LUW is assigned a unique transaction ID (viewable with Transaction SM58).
The function module ID_OF_BACKGROUNDTASK (which is called before the COMMIT WORK) returns this ID.
You can determine the LUW execution status using the function module STATUS_OF_BACKGROUNDTASK under the transaction ID (which is called after the COMMIT WORK).
If you also called the update function modules locally before the COMMIT WORK, tRFC calls are only processed when the local update function modules have been processed successfully.
You can also call transactional C functions. However, you must use the rollback mechanism in the external server program .

Parallel processing in background

Hi All,
I am processing 1 million of records in background, which takes approximately around 10 hrs. I wanted to reduce the time to less than 1 hr and tried using parallel processing. But the tasks run in Dialog workprocesses and giving abap short dumps due to time out.
Is there any other solutions using that i can reduce total processing time.
Please note that i cannot split. I am getting 1 million records from a select query and after processing all those records in SAP, I am sending to XI and XI will post in legacy system.
Please note that all other performance tunings done.
Thanks,
Rajesh.

Hi Rajesh,
Refer sample code for Parallel Processing:
By doing this your processing time will be highly optimized.
Go thru the description given in the code at each level.
This code Checks available WORK PROCESSes and assigns data in packets for processing. This way you save a lot of time esp when data is in Millions.
Hope it helps.
REPORT PARAJOB.
Data declarations
DATA: GROUP LIKE RZLLITAB-CLASSNAME VALUE ' ',
"Parallel processing group.
"SPACE = group default (all
"servers)
WP_AVAILABLE TYPE I, "Number of dialog work processes
"available for parallel processing
"(free work processes)
WP_TOTAL TYPE I, "Total number of dialog work
"processes in the group
MSG(80) VALUE SPACE, "Container for error message in
"case of remote RFC exception.
INFO LIKE RFCSI, C, "Message text
JOBS TYPE I VALUE 10, "Number of parallel jobs
SND_JOBS TYPE I VALUE 1, "Work packets sent for processing
RCV_JOBS TYPE I VALUE 1, "Work packet replies received
EXCP_FLAG(1) TYPE C, "Number of RESOURCE_FAILUREs
TASKNAME(4) TYPE N VALUE '0001', "Task name (name of
"parallel processing work unit)
BEGIN OF TASKLIST OCCURS 10, "Task administration
TASKNAME(4) TYPE C,
RFCDEST LIKE RFCSI-RFCDEST,
RFCHOST LIKE RFCSI-RFCHOST,
END OF TASKLIST.
Optional call to SBPT_INITIALIZE to check the
group in which parallel processing is to take place.
Could be used to optimize sizing of work packets
work / WP_AVAILABLE).
CALL FUNCTION 'SPBT_INITIALIZE'
EXPORTING
GROUP_NAME = GROUP
"Name of group to check
IMPORTING
MAX_PBT_WPS = WP_TOTAL
"Total number of dialog work
"processes available in group
"for parallel processing
FREE_PBT_WPS = WP_AVAILABLE
"Number of work processes
"available in group for
"parallel processing at this
"moment
EXCEPTIONS
INVALID_GROUP_NAME = 1
"Incorrect group name; RFC
"group not defined. See
"transaction RZ12
INTERNAL_ERROR = 2
"R/3 System error; see the
"system log (transaction
"SM21) for diagnostic info
PBT_ENV_ALREADY_INITIALIZED = 3
"Function module may be
"called only once; is called
"automatically by R/3 if you
"do not call before starting
"parallel processing
CURRENTLY_NO_RESOURCES_AVAIL = 4
"No dialog work processes
"in the group are available;
"they are busy or server load
"is too high
NO_PBT_RESOURCES_FOUND = 5
"No servers in the group
"met the criteria of >
"two work processes
"defined.
CANT_INIT_DIFFERENT_PBT_GROUPS = 6
"You have already initialized
"one group and have now tried
"initialize a different group.
OTHERS = 7..
CASE SY-SUBRC.
WHEN 0.
"Everythings ok. Optionally set up for optimizing size of
"work packets.
WHEN 1.
"Non-existent group name. Stop report.
MESSAGE E836. "Group not defined.
WHEN 2.
"System error. Stop and check system log for error
"analysis.
WHEN 3.
"Programming error. Stop and correct program.
MESSAGE E833. "PBT environment was already initialized.
WHEN 4.
"No resources: this may be a temporary problem. You
"may wish to pause briefly and repeat the call. Otherwise
"check your RFC group administration: Group defined
"in accordance with your requirements?
MESSAGE E837. "All servers currently busy.
WHEN 5.
"Check your servers, network, operation modes.
WHEN 6.
Do parallel processing. Use CALL FUNCTION STARTING NEW TASK
DESTINATION IN GROUP to call the function module that does the
work. Make a call for each record that is to be processed, or
divide the records into work packets. In each case, provide the
set of records as an internal table in the CALL FUNCTION
keyword (EXPORT, TABLES arguments).
DO.
CALL FUNCTION 'RFC_SYSTEM_INFO' "Function module to perform
"in parallel
STARTING NEW TASK TASKNAME "Name for identifying this
"RFC call
DESTINATION IN GROUP group "Name of group of servers to
"use for parallel processing.
"Enter group name exactly
"as it appears in transaction
"RZ12 (all caps). You may
"use only one group name in a
"particular ABAP program.
PERFORMING RETURN_INFO ON END OF TASK
"This form is called when the
"RFC call completes. It can
"collect IMPORT and TABLES
"parameters from the called
"function with RECEIVE.
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE msg
"Destination server not
"reached or communication
"interrupted. MESSAGE msg
"captures any message
"returned with this
"exception (E or A messages
"from the called FM, for
"example. After exception
"1 or 2, instead of aborting
"your program, you could use
"SPBT_GET_PP_DESTINATION and
"SPBT_DO_NOT_USE_SERVER to
"exclude this server from
"further parallel processing.
"You could then re-try this
"call using a different
"server.
SYSTEM_FAILURE = 2 MESSAGE msg
"Program or other internal
"R/3 error. MESSAGE msg
"captures any message
"returned with this
"exception.
RESOURCE_FAILURE = 3. "No work processes are
"currently available. Your
"program MUST handle this
"exception.
YOUR_EXCEPTIONS = X. "Add exceptions generated by
"the called function module
"here. Exceptions are
"returned to you and you can
"respond to them here.
CASE SY-SUBRC.
WHEN 0.
"Administration of asynchronous RFC tasks
"Save name of task...
TASKLIST-TASKNAME = TASKNAME.
"... and get server that is performing RFC call.
CALL FUNCTION 'SPBT_GET_PP_DESTINATION'
EXPORTING
RFCDEST = TASKLIST-RFCDEST
EXCEPTIONS
OTHERS = 1.
APPEND TASKLIST.
WRITE: / 'Started task: ', TASKLIST-TASKNAME COLOR 2.
TASKNAME = TASKNAME + 1.
SND_JOBS = SND_JOBS + 1.
"Mechanism for determining when to leave the loop. Here, a
"simple counter of the number of parallel processing tasks.
"In production use, you would end the loop when you have
"finished dispatching the data that is to be processed.
JOBS = JOBS - 1. "Number of existing jobs
IF JOBS = 0.
EXIT. "Job processing finished
ENDIF.
WHEN 1 OR 2.
"Handle communication and system failure. Your program must
"catch these exceptions and arrange for a recoverable
"termination of the background processing job.
"Recommendation: Log the data that has been processed when
"an RFC task is started and when it returns, so that the
"job can be restarted with unprocessed data.
WRITE msg.
"Remove server from further consideration for
"parallel processing tasks in this program.
"Get name of server just called...
CALL FUNCTION 'SPBT_GET_PP_DESTINATION'
EXPORTING
RFCDEST = TASKLIST-RFCDEST
EXCEPTIONS
OTHERS = 1.
"Then remove from list of available servers.
CALL FUNCTION 'SPBT_DO_NOT_USE_SERVER'
IMPORTING
SERVERNAME = TASKLIST-RFCDEST
EXCEPTIONS
INVALID_SERVER_NAME = 1
NO_MORE_RESOURCES_LEFT = 2
"No servers left in group.
PBT_ENV_NOT_INITIALIZED_YET = 3
OTHERS = 4.
WHEN 3.
"No resources (dialog work processes) available at
"present. You need to handle this exception, waiting
"and repeating the CALL FUNCTION until processing
"can continue or it is apparent that there is a
"problem that prevents continuation.
MESSAGE I837. "All servers currently busy.
"Wait for replies to asynchronous RFC calls. Each
"reply should make a dialog work process available again.
IF EXCP_FLAG = SPACE.
EXCP_FLAG = 'X'.
"First attempt at RESOURCE_FAILURE handling. Wait
"until all RFC calls have returned or up to 1 second.
"Then repeat CALL FUNCTION.
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '1' SECONDS.
ELSE.
"Second attempt at RESOURCE_FAILURE handling
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '5' SECONDS.
"SY-SUBRC 0 from WAIT shows that replies have returned.
"The resource problem was therefore probably temporary
"and due to the workload. A non-zero RC suggests that
"no RFC calls have been completed, and there may be
"problems.
IF SY-SUBRC = 0.
CLEAR EXCP_FLAG.
ELSE. "No replies
"Endless loop handling
ENDIF.
ENDIF.
ENDCASE.
ENDDO.
Wait for end of job: replies from all RFC tasks.
Receive remaining asynchronous replies
WAIT UNTIL RCV_JOBS >= SND_JOBS.
LOOP AT TASKLIST.
WRITE:/ 'Received task:', TASKLIST-TASKNAME COLOR 1,
30 'Destination: ', TASKLIST-RFCDEST COLOR 1.
ENDLOOP.
This routine is triggered when an RFC call completes and
returns. The routine uses RECEIVE to collect IMPORT and TABLE
data from the RFC function module.
Note that the WRITE keyword is not supported in asynchronous
RFC. If you need to generate a list, then your RFC function
module should return the list data in an internal table. You
can then collect this data and output the list at the conclusion
of processing.
FORM RETURN_INFO USING TASKNAME.
DATA: INFO_RFCDEST LIKE TASKLIST-RFCDEST.
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.
Handle communication and system failure
ELSE.
READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME.
IF SY-SUBRC = 0. "Register data
TASKLIST-RFCHOST = INFO_RFCHOST.
MODIFY TASKLIST INDEX SY-TABIX.
ENDIF.
ENDIF.
ENDFORM
Reward points if that helps.
Manish
Message was edited by:
Manish Kumar

Table in function

Hi all,
I would like to use the content of tables LQUA and LAGP and some other SAP tables in a own function.
I don't want much data transfer on the system, but these tables are very big.
How do I reach the data in the tables?
Do I have to supply the records through the tables section of the function?
And if so how do I do that with minimal data transfer?
gteetings Fred

hi
see this sample
REPORT PARAJOB.
Data declarations
DATA: GROUP LIKE RZLLITAB-CLASSNAME VALUE ' ',
"Parallel processing group.
"SPACE = group default (all
"servers)
WP_AVAILABLE TYPE I, "Number of dialog work processes
"available for parallel processing
"(free work processes)
WP_TOTAL TYPE I, "Total number of dialog work
"processes in the group
MSG(80) VALUE SPACE, "Container for error message in
"case of remote RFC exception.
INFO LIKE RFCSI, C, "Message text
JOBS TYPE I VALUE 10, "Number of parallel jobs
SND_JOBS TYPE I VALUE 1, "Work packets sent for processing
RCV_JOBS TYPE I VALUE 1, "Work packet replies received
EXCP_FLAG(1) TYPE C, "Number of RESOURCE_FAILUREs
TASKNAME(4) TYPE N VALUE '0001', "Task name (name of
"parallel processing work unit)
BEGIN OF TASKLIST OCCURS 10, "Task administration
TASKNAME(4) TYPE C,
RFCDEST LIKE RFCSI-RFCDEST,
RFCHOST LIKE RFCSI-RFCHOST,
END OF TASKLIST.
Optional call to SBPT_INITIALIZE to check the
group in which parallel processing is to take place.
Could be used to optimize sizing of work packets
work / WP_AVAILABLE).
CALL FUNCTION 'SPBT_INITIALIZE'
EXPORTING
GROUP_NAME = GROUP
"Name of group to check
IMPORTING
MAX_PBT_WPS = WP_TOTAL
"Total number of dialog work
"processes available in group
"for parallel processing
FREE_PBT_WPS = WP_AVAILABLE
"Number of work processes
"available in group for
"parallel processing at this
"moment
EXCEPTIONS
INVALID_GROUP_NAME = 1
"Incorrect group name; RFC
"group not defined. See
"transaction RZ12
INTERNAL_ERROR = 2
"R/3 System error; see the
"system log (transaction
"SM21) for diagnostic info
PBT_ENV_ALREADY_INITIALIZED = 3
"Function module may be
"called only once; is called
"automatically by R/3 if you
"do not call before starting
"parallel processing
CURRENTLY_NO_RESOURCES_AVAIL = 4
"No dialog work processes
"in the group are available;
"they are busy or server load
"is too high
NO_PBT_RESOURCES_FOUND = 5
"No servers in the group
"met the criteria of >
"two work processes
"defined.
CANT_INIT_DIFFERENT_PBT_GROUPS = 6
"You have already initialized
"one group and have now tried
"initialize a different group.
OTHERS = 7..
CASE SY-SUBRC.
WHEN 0.
"Everythings ok. Optionally set up for optimizing size of
"work packets.
WHEN 1.
"Non-existent group name. Stop report.
MESSAGE E836. "Group not defined.
WHEN 2.
"System error. Stop and check system log for error
"analysis.
WHEN 3.
"Programming error. Stop and correct program.
MESSAGE E833. "PBT environment was already initialized.
WHEN 4.
"No resources: this may be a temporary problem. You
"may wish to pause briefly and repeat the call. Otherwise
"check your RFC group administration: Group defined
"in accordance with your requirements?
MESSAGE E837. "All servers currently busy.
WHEN 5.
"Check your servers, network, operation modes.
WHEN 6.
Do parallel processing. Use CALL FUNCTION STARTING NEW TASK
DESTINATION IN GROUP to call the function module that does the
work. Make a call for each record that is to be processed, or
divide the records into work packets. In each case, provide the
set of records as an internal table in the CALL FUNCTION
keyword (EXPORT, TABLES arguments).
DO.
CALL FUNCTION 'RFC_SYSTEM_INFO' "Function module to perform
"in parallel
STARTING NEW TASK TASKNAME "Name for identifying this
"RFC call
DESTINATION IN GROUP group "Name of group of servers to
"use for parallel processing.
"Enter group name exactly
"as it appears in transaction
"RZ12 (all caps). You may
"use only one group name in a
"particular ABAP program.
PERFORMING RETURN_INFO ON END OF TASK
"This form is called when the
"RFC call completes. It can
"collect IMPORT and TABLES
"parameters from the called
"function with RECEIVE.
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE msg
"Destination server not
"reached or communication
"interrupted. MESSAGE msg
"captures any message
"returned with this
"exception (E or A messages
"from the called FM, for
"example. After exception
"1 or 2, instead of aborting
"your program, you could use
"SPBT_GET_PP_DESTINATION and
"SPBT_DO_NOT_USE_SERVER to
"exclude this server from
"further parallel processing.
"You could then re-try this
"call using a different
"server.
SYSTEM_FAILURE = 2 MESSAGE msg
"Program or other internal
"R/3 error. MESSAGE msg
"captures any message
"returned with this
"exception.
RESOURCE_FAILURE = 3. "No work processes are
"currently available. Your
"program MUST handle this
"exception.
YOUR_EXCEPTIONS = X. "Add exceptions generated by
"the called function module
"here. Exceptions are
"returned to you and you can
"respond to them here.
CASE SY-SUBRC.
WHEN 0.
"Administration of asynchronous RFC tasks
"Save name of task...
TASKLIST-TASKNAME = TASKNAME.
"... and get server that is performing RFC call.
CALL FUNCTION 'SPBT_GET_PP_DESTINATION'
EXPORTING
RFCDEST = TASKLIST-RFCDEST
EXCEPTIONS
OTHERS = 1.
APPEND TASKLIST.
WRITE: / 'Started task: ', TASKLIST-TASKNAME COLOR 2.
TASKNAME = TASKNAME + 1.
SND_JOBS = SND_JOBS + 1.
"Mechanism for determining when to leave the loop. Here, a
"simple counter of the number of parallel processing tasks.
"In production use, you would end the loop when you have
"finished dispatching the data that is to be processed.
JOBS = JOBS - 1. "Number of existing jobs
IF JOBS = 0.
EXIT. "Job processing finished
ENDIF.
WHEN 1 OR 2.
"Handle communication and system failure. Your program must
"catch these exceptions and arrange for a recoverable
"termination of the background processing job.
"Recommendation: Log the data that has been processed when
"an RFC task is started and when it returns, so that the
"job can be restarted with unprocessed data.
WRITE msg.
"Remove server from further consideration for
"parallel processing tasks in this program.
"Get name of server just called...
CALL FUNCTION 'SPBT_GET_PP_DESTINATION'
EXPORTING
RFCDEST = TASKLIST-RFCDEST
EXCEPTIONS
OTHERS = 1.
"Then remove from list of available servers.
CALL FUNCTION 'SPBT_DO_NOT_USE_SERVER'
IMPORTING
SERVERNAME = TASKLIST-RFCDEST
EXCEPTIONS
INVALID_SERVER_NAME = 1
NO_MORE_RESOURCES_LEFT = 2
"No servers left in group.
PBT_ENV_NOT_INITIALIZED_YET = 3
OTHERS = 4.
WHEN 3.
"No resources (dialog work processes) available at
"present. You need to handle this exception, waiting
"and repeating the CALL FUNCTION until processing
"can continue or it is apparent that there is a
"problem that prevents continuation.
MESSAGE I837. "All servers currently busy.
"Wait for replies to asynchronous RFC calls. Each
"reply should make a dialog work process available again.
IF EXCP_FLAG = SPACE.
EXCP_FLAG = 'X'.
"First attempt at RESOURCE_FAILURE handling. Wait
"until all RFC calls have returned or up to 1 second.
"Then repeat CALL FUNCTION.
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '1' SECONDS.
ELSE.
"Second attempt at RESOURCE_FAILURE handling
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '5' SECONDS.
"SY-SUBRC 0 from WAIT shows that replies have returned.
"The resource problem was therefore probably temporary
"and due to the workload. A non-zero RC suggests that
"no RFC calls have been completed, and there may be
"problems.
IF SY-SUBRC = 0.
CLEAR EXCP_FLAG.
ELSE. "No replies
"Endless loop handling
ENDIF.
ENDIF.
ENDCASE.
ENDDO.
Wait for end of job: replies from all RFC tasks.
Receive remaining asynchronous replies
WAIT UNTIL RCV_JOBS >= SND_JOBS.
LOOP AT TASKLIST.
WRITE:/ 'Received task:', TASKLIST-TASKNAME COLOR 1,
30 'Destination: ', TASKLIST-RFCDEST COLOR 1.
ENDLOOP.
This routine is triggered when an RFC call completes and
returns. The routine uses RECEIVE to collect IMPORT and TABLE
data from the RFC function module.
Note that the WRITE keyword is not supported in asynchronous
RFC. If you need to generate a list, then your RFC function
module should return the list data in an internal table. You
can then collect this data and output the list at the conclusion
of processing.
FORM RETURN_INFO USING TASKNAME.
DATA: INFO_RFCDEST LIKE TASKLIST-RFCDEST.
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.
Handle communication and system failure
ELSE.
READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME.
IF SY-SUBRC = 0. "Register data
TASKLIST-RFCHOST = INFO_RFCHOST.
MODIFY TASKLIST INDEX SY-TABIX.
ENDIF.
ENDIF.
ENDFORM
regards
Arun

RFC groups - RZ12

Similar Messages

Maybe you are looking for