Timeout for RFC Adapter

[Former Member]

Hello,

I have a HTTP --> RFC Synchronous scenario.

However I need to return timeout error in case RFC takes more than 30 secs as HTTP Response otherwise RFC Response will be sent as HTTP Response.

I tried using sync-async bridge in BPM and configured CHECK_FOR_ASYNC_RESPONSE_TIMEOUT = 30 sec.

I got a pipeline Timeout Error as a Response.

Can I catch this error as exception in BPM as I need to send Error Code for Timeout as Response in this case.

Or is there any other way I can set this timeout.

I dont want to apply this at Global level as for other interfaces it is 60 secs.

Is there any way to set the Timeout for particular interface?

Thanks in advance...

Thanks

Beena.

[former_member195313]

Hello All ,

For our PI system i have changed the following value and it worked..

Change the value of "Cluster Data –> Template –> Services –> com.sap.aii.adapter.xi.svc"

RFC Time Out Problem

[Former Member]

Beena,

I think that you have missed my point. If you do not want to set alerts or parameters at a global level, or they do not meet this specific interface requirement, then you can use the control step to manage your requirement from within the BPM

For instance the timeout control step can throw an exception then the exception branch can send SMTP, HTTP response or whatever.

This will occur as long as the timeout is set to trigger before any relevant global timeout parameter. Then you exit the BPM cleanly before the global sync send parameter has timed out

FYI - an alert can be set up with conditions for specific party, service, interface etc

I hope that this has helped you,

Mike

[Former Member]

Beena,

I posted this answer to a similar request a couple of weeks ago

I had a similar issue some time back and used the following three parameters

1. Visual Administrator

SAP XI Adapter: RFC parameter syncMessageDeliveryTimeoutMsec

This parameter is explained in SAP Note 730870 Q14 and SAP Note 791379

2. Alert Configuration

SA_COMM parameter CHECK_FOR_ASYNC_RESPONSE_TIMEOUT

This parameter specifies the maximum time in seconds that can pass between the arrival of the synchronous request message on the Integration Server and the asynchronous response message. If this time period is exceeded, a system error is returned to the caller.

The alert is set up with recipients, text etc via transaction ALRTCATDEF, also in RWB Alert Configuration. An email is sent when the alert is triggered

3. Integration Process TimeoutControlStep

My design is such that timeout parameter 3 which is set in the Integration Process will be triggered first. This will give me control to handle the timeout via my own tailored SMTP email (sent from within the BPM) prior to either of the other timeouts taking effect

Regards,

Mike

[Former Member]

Thanks Mike,

But these parameters will apply at global level and for all interfaces. I have another HTTP --> RFC scenarios where I dont want to apply these settings.

Beena.

[Former Member]

Beena,

You have posted a similar question to the forum titled Deadline in BPM on the 27th December

My reply remains as follows

As you will be aware the smallest time unit is one minute.

There are always tradeoffs. For example, consider the overhead of running the XI job that listen for alerts every 5 seconds or so. Likewise with the SMTP mail send process etc. In our environment, even at one minute, there is a lag between picking up an alert and the final execution and delivery of an alert email.

If seconds are really critical then can you redesign this scenario so that Web Application perform this task instead of XI.

I too will watch this thread for other suggestions

Regards,

Mike

[Former Member]

Thanks Mike,

I did posted similar question but that was related to deadline in specific and whether we can have less than one minute in deadline branch.

Now I was trying the parameter CHECK_FOR_ASYNC_RESPONSE_TIMEOUT in Integration engine configuration but don't know how to catch pipeline exception.

Please let me know if there are any other alternatives.

Thanks,

Beena.