Sunday, March 14, 2010

BizTalk Adapter Pack – SAP Binding ReceiveTimeout

 

One of the most important configurations to make inside a SAP Receive location is the “receiveTimeout” property.  The documentation describes this property as:

“Specifies the WCF message receive timeout. Essentially, this means the maximum amount of time the adapter waits for an inbound message. The default is 10 minutes.

Cc185372.Important(en-US,BTS.10).gifImportant

For inbound operations such as receiving IDOCs, we recommend setting the timeout to the maximum possible value, which is 24.20:31:23.6470000 (24 days). When using the adapter with BizTalk Server, setting the timeout to a large value does not impact the functionality of the adapter.”

The default value(10 minutes), is too short of a period for BizTalk to stop listening for messages from SAP.  For instance, if your organization has a weekly back up scheduled for SAP, it will likely take longer than 10 minutes.  The documentation indicates that there is no impact to using a large number so I am not sure why the default is only 10 minutes.

 

image

 

Just to give a practical example of what you can expect when SAP goes down (either planned or unplanned) from a BizTalk perspective.

SAP going down

Event Type:        Warning

Event Source:    BizTalk Server 2009

Event Category:                (1)

Event ID:              5740

Date:                     3/13/2XXX

Time:                     10:01:31 PM

User:                     N/A

Computer:          SERVER

Description:

The adapter "WCF-Custom" raised an error message. Details "The WCF service host at address sap://CLIENT=XXX;LANG=EN;@a/SAPServer/00?ListenerGwServ=SAPGateWay00&ListenerGwHost=SAPServer&ListenerProgramId=IDOC&RfcSdkTrace=False&AbapDebug=False has faulted and as a result no more messages can be received on the corresponding receive location. To fix the issue, BizTalk Server will automatically attempt to restart the service host.".

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type:        Warning

Event Source:    BizTalk Server 2009

Event Category:                (1)

Event ID:              5740

Date:                     3/13/2XXX

Time:                     10:01:31 PM

User:                     N/A

Computer:          SERVER

Description:

The adapter "WCF-Custom" raised an error message. Details "Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_FAILURE. AdapterErrorMessage=An exception has occurred on the listener while executing RfcWaitForRequest..

   at Microsoft.ServiceModel.Channels.Common.Design.AdapterAsyncResult.End()

   at Microsoft.ServiceModel.Channels.Common.Channels.AdapterReplyChannel.EndTryReceiveRequest(IAsyncResult result, RequestContext& requestContext)

   at Microsoft.Adapters.Internal.LayeredChannelBindingElement.LayeredInboundChannel`1.System.ServiceModel.Channels.IReplyChannel.EndTryReceiveRequest(IAsyncResult result, RequestContext& context)

   at System.ServiceModel.Dispatcher.ReplyChannelBinder.EndTryReceive(IAsyncResult result, RequestContext& requestContext)

   at System.ServiceModel.Dispatcher.ErrorHandlingReceiver.EndTryReceive(IAsyncResult result, RequestContext& requestContext)".

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

 

Event Type:        Warning

Event Source:    BizTalk Server 2009

Event Category:                (1)

Event ID:              5740

Date:                     3/13/2XXX

Time:                     10:01:32 PM

User:                     N/A

Computer:          SERVER

Description:

The adapter "WCF-Custom" raised an error message. Details "The faulted WCF service host at address sap://CLIENT=XXX;LANG=EN;@a/SAPServer/00?ListenerGwServ=SAPGateWay00&ListenerGwHost=SAPServer&ListenerProgramId=IDOC&RfcSdkTrace=False&AbapDebug=False could not be restarted, and as a result no messages can be received on the corresponding receive location. BizTalk Server will continue trying to start the service host until it succeeds or the receive location is disabled.

To fix the problem, you may choose to:

1. Use the error information given to fix the problem.

2. Restart the receive location.

3. Keep waiting for BizTalk to recycle the service host. Another event will notify if the service host is successfully started.

SAP coming back up

Event Type:        Information

Event Source:    BizTalk Server 2009

Event Category:                (1)

Event ID:              8112

Date:                     3/13/2XXX

Time:                     11:03:13 PM

User:                     N/A

Computer:          SERVER

Description:

The WCF service host at address sap://CLIENT=XXX;LANG=EN;@a/SAPServer/00?ListenerGwServ=SAPGateWay00&ListenerGwHost=SAPServer&ListenerProgramId=IDOC&RfcSdkTrace=False&AbapDebug=False was successfully restarted, therefore the associated receive location can now receive messages.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

 

You are now able to receive messages from SAP without any intervention.  Had we not set an appropriate ReceiveTimeout, the receive location would have still be down when SAP tried to push this IDoc to our system.

image

 

You never want your middleware to be the cause of an outage so it is important to understand when your dependant servers/services have scheduled maintenance so that you can ensure that your application can sustain this downtime.  Configuring the ReceiveTimeout to an appropriate value will reduce the chance that BizTalk will be down due to someone else's maintenance window.

6 comments:

hxbergen said...

Are you using Adapter Pack 1.0? Because the timeout issue is fixed for 2.0.
Another Question. Why do you not use the WCF-SAP Adapter instead of WCF-Custom Adapter. It is quite the same, but with a better comfort to define the connection uri.

Kent Weare said...

Nope, this is BizTalk 2009 - BizTalk Adapter Pack 2.0.

My perferance is to use the WCF-SAP adapter, but the developer who deployed this app used the WCF-Custom adapter probably due to the fact that when you generate schemas, the adapter that is used in the generated binding file is WCF-Custom

hxbergen said...

OK I have misunderstood your your comment. We had another Problem with BizTalk Adapter Pack 1.0.

(P.S. We are using BizTalk 2006 R2 and Adapter Pack 2.0)

Enrico Zerilli said...

Hi
i have the same problem, i have set the property receiveTimeout = 24.20:31:23.6470000 but the problem some time appeare. My architecture is BizTalk Server 2006 R2 with Microsoft BizTalk Adapter v2.0 for mySAP Business Suite Service Pack 1. I have planning to upgrade BizTalk Server 2009 with Microsoft BizTalk Adapter v2.0 for mySAP for BizTalk Server 2009. This upgrade will solve the problem? How can i do for solve this situation without upgrade? Thanks in advance.
Enrico

Enrico Zerilli said...

Hi
i have the same problem, i have set the property receiveTimeout = 24.20:31:23.6470000 but the problem some time appeare. My architecture is BizTalk Server 2006 R2 with Microsoft BizTalk Adapter v2.0 for mySAP Business Suite Service Pack 1. I have planning to upgrade BizTalk Server 2009 with Microsoft BizTalk Adapter v2.0 for mySAP for BizTalk Server 2009. This upgrade will solve the problem? How can i do for solve this situation without upgrade? Thanks in advance.
Enrico

Kent Weare said...

Enrico,

Are you referring to the SAP adapter that leverages the .Net Connector?

With BizTalk 2006 and this Adapter(.Net Connector) I never saw this issue in over 3 years. Strangely enough I have seen this with BizTalk 2009(and this .net connector adapter) and a host instance restart after the issue occurs will resolve the problem.

When using the BizTalk Adapter pack and this property, I find that BizTalk recovers correctly and does not require any host instance restarts.