Community
Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Read only

RFC Getting Timed out.

Former Member

‎2010 Jun 23 12:39 PM

0 Likes
1,549

Hi Experts,

I have a RFC in CRM system to update address attributes for a BP.

When the informatica calls this RFC with limited number of records say for eg with 7000 records the RFC works fine & updates.

But when called with more records eg. 11000 or more there is a TIMEOUT error

The maximum runtime of a program is limited by the system profile

parameter "rdisp/max_wprun_time". The current setting is 600 seconds. If this

time limit is

exceeded, the system attempts to cancel any running SQL statement or

signals the ABAP processor to stop the running program. Then the system

waits another 60 seconds maximum. If the program is then still active,

the work process is restarted.

The user that is used to execute this RFC is created as background user only & not as a dialogue user.

Any inputs to overcome this issue will be appreciated.

regards,

Kevin

Hi Experts,

I have a RFC in CRM system to update address attributes for a BP.

When the informatica calls this RFC with limited number of records say for eg with 7000 records the RFC works fine & updates.

But when called with more records eg. 11000 or more there is a TIMEOUT error

The maximum runtime of a program is limited by the system profile

parameter "rdisp/max_wprun_time". The current setting is 600 seconds. If this

time limit is

exceeded, the system attempts to cancel any running SQL statement or

signals the ABAP processor to stop the running program. Then the system

waits another 60 seconds maximum. If the program is then still active,

the work process is restarted.

The user that is used to execute this RFC is created as background user only & not as a dialogue user.

Any inputs to overcome this issue will be appreciated.

regards,

Kevin

Reply
3 REPLIES 3
Read only

Former Member

‎2010 Jun 23 1:18 PM

0 Likes
1,147

All RFC calls are executed in dialog work processes (the type of user is irrelevant) and thus are subject to the same runtime limits as any dialog user. The profile parameter rdisp/max_wprun_time governs what the default time out is (default 300s, see for example [here|http://help.sap.com/saphelp_nw70/Helpdata/en/22/0425c6488911d189490000e829fbbd/frameset.htm]).

As you don't want to change this limit (affects all users) you really should process the data in smaller packages, i.e. call the RFC more often.

Cheers, harald

Read only

Former Member
In response to Former Member

‎2010 Jun 23 1:32 PM

0 Likes
1,147

Hi Harald,

Thanks for your suggestion.

This is what i have asked the informatica team to do as a temporary solution.

But i thought there would be a better way to hande this ... meaning somehow make this RFC to work for all the records using Some options. ( Wonder what options! )

The one i was thinking is to call this RFC inside another RFC & call the original RFC in update task....

But here the problem is that the RFC has to return messages to informatica that too for each record being passed.!!!

Wondering how to solve this problem.

regards,

Kevin.

Read only

Former Member
In response to Former Member

‎2010 Jun 24 8:01 AM

0 Likes
1,147 
But i thought there would be a better way to handle this ... meaning somehow make this RFC to work for all the records using Some options. ( Wonder what options! )

Well, there's always other options and workarounds, but they are not necessarily better. I actually think it's better to process data in reasonable chunks and so far I haven't encountered the need for long running RFC's. Especially since I like to see progress/status on the client side, which requires feedback from the RFC server from time to time (and long running synchronous RFC calls usually don't do this - unless somebody coded some special logic with destination 'BACK' or something similar).

Anyhow, if for some (strange?) reason you're convinced that you want to have really long running RFC's you could for example check if you can divide your RFC function into smaller units. I.e. if you don't have a single statement that runs forever I think you should be able to reset the timer by executing a COMMIT WORK.

Another option might be to switch to an asynchronous interface, where you submit initially the data to be processed via RFC, schedule a job for it and have some logic that provides feedback via call backs. The main issue with such a solution is that all of a sudden your RFC client also needs RFC server functionality for processing the callbacks.

As I don't know the background for your requirement I'm tempted to re-label your temporary solution as a very good, scalable solution (e.g. think parallel processing of smaller chunks), which provides much more freedom. Though of course in your specific case maybe there is a good reason why you want to do it that way...