| Author |
Message
|
| hellobond070 |
 Posted: Tue Feb 16, 2010 4:50 am Post subject: Sap Adapter : Retry option |
 |
|
Centurion
Joined: 18 Nov 2009
Posts: 118
|
hi all,
I need to know if there is any retry mechanism for SAP request node to push IDOCs to SAP.
Suppose there is an error while connecting the SAP system so I want a retry to happen without the flow throwing any error.
Is this possible. If yes where in the wizard do I need to mention this. |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Tue Feb 16, 2010 7:59 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
how best is your Error handling scenario here.
second how best is your SAP Server supporting to this scenario here.
say if your sap server is down, how many times will you be trying it.
you can do this retry part by using try catch node and put it in a loop for some finite number of times.
what will happen if it couldnt able to establish the connection after finite number of tries.
SAP Adapter in MB V6.1 will establish an adapter connection or listener kind of stub. that will be inactive when the SAP Server goes down.
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| hellobond070 |
| Posted: Tue Feb 16, 2010 8:31 am Post subject: |
|
|
Centurion
Joined: 18 Nov 2009
Posts: 118
|
Hello Gayathri,
We have a problem in production.
When the SAP gets restarted the first message after that posted by our flow using a SAP request node to SAP system fails.
After that it works fine. This might be because it goes for the same old connection handle.
Now I want the flow to try again before throwing an error with a new handle and hence I want to know if there is any option while running the wizard for SAP adapter creation. This can resolve our problem.
Something like in File Nodes provided in version 6.1. We have a retry option before the file is archived or deleted.
Please advise. |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Tue Feb 16, 2010 8:45 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
|
| Back to top |
|
|
| napier |
| Posted: Tue Feb 16, 2010 9:02 am Post subject: |
|
|
Apprentice
Joined: 09 Oct 2007
Posts: 48
Location: USA
|
| Quote: |
| Suppose there is an error while connecting the SAP system so I want a retry to happen without the flow throwing any error. |
Yes you can set this in SAP Outbound Resource Adapter
under Advanced->Advanced connection configuration->maximum no of retries in case of system connection failure. |
|
| Back to top |
|
|
| hellobond070 |
| Posted: Sat Feb 20, 2010 2:02 am Post subject: |
|
|
Centurion
Joined: 18 Nov 2009
Posts: 118
|
|
| Back to top |
|
|
| jpunathil |
| Posted: Fri Apr 30, 2010 1:53 pm Post subject: Help needed in setting the retry property |
|
|
Newbie
Joined: 30 Apr 2010
Posts: 8
|
Napier,
Could you please help me understand the property configuration mentioned by you:
under Advanced->Advanced connection configuration->maximum no of retries in case of system connection failure.
I couldnt find this feature at all.. I am using Broker toolkit version 6.1.0.5
Please advise.
Thanks in advance,
Jobin |
|
| Back to top |
|
|
| tatyeong |
| Posted: Thu Mar 03, 2011 6:21 am Post subject: |
|
|
Acolyte
Joined: 16 Apr 2010
Posts: 52
|
Hi,
Did anyone manage to find out if there is a retry count property which can be set on the SAPRequest node, to handle scenario such as temporary drop in network connectivity so that the message does not get thrown to the catch / failure flow.
In the reverse direction where a message is sent from SAP to WMB, I am able to configure on SAP end the retry count and interval that SAP attempts to send IDoc to WMB |
|
| Back to top |
|
|
| jhosie |
| Posted: Thu Mar 03, 2011 7:44 am Post subject: |
|
|
Apprentice
Joined: 12 May 2005
Posts: 28
|
For your specific case (the server is back up but the connection pool has a stale connection) you only really need to retry once straight away. If the re-connect fails then you have another problem that might take more time and/or human intervention to solve so you should throw an exception and rollback the current transaction in that case.
In fact the SAPRequest node will do this by default. This fix was added under APAR IC62731 http://www-01.ibm.com/support/docview.wss?uid=swg1IC62731
With this fix, if the node fails to communicate with SAP on the current connection, it will drop that connection and then try to establish a new connection. If it fails to establish a new connection, it will throw an exception.
So all you need to do is apply that fix (or move to 6.1.0.8 ) |
|
| Back to top |
|
|
| tatyeong |
| Posted: Thu Mar 03, 2011 6:10 pm Post subject: |
|
|
Acolyte
Joined: 16 Apr 2010
Posts: 52
|
Hi Jhosie,
I am aware of the fix and already applied that in my environment.
Where I am coming from is more of when SAP is actually down when the SAPRequest node tries to send the message, does it just attempt once before throwing exception? or does it attempt a few times And this property is configurable if there's one? |
|
| Back to top |
|
|
| jhosie |
| Posted: Fri Mar 04, 2011 2:37 am Post subject: |
|
|
Apprentice
Joined: 12 May 2005
Posts: 28
|
Hi Tatyeong
The general approach in WMB for dealing with transient errors is to rollback the current transaction and retry the whole flow. That way, you don't hold open any syncpoint logs, DB locks and don't prevent the broker from being responsive to configuration changes.
The input nodes in your flow typically control this retry algorithm. For example,
- the MQInputNode uses the backoutThreashold defined on the Q
- The file input node ( and many others tcp-) have a retry panel where you configure thresholds and sleep time
- SAP Input relies on SAP resending (as you observed)
- SOAP Input relies on the WS Client resending
If you really want to hold open the current transaction until the error resolves itself(maybe you know that you are not holding any locks and you can live with the broker being unresponsive) then your best bet is to code a try, catch and retry loop e.g. using a ESQL or Java Compute node before the SAP node.
I would urge caution if you take this approach however and make sure that you are only retrying in the case of transient errors and that you have a reasonable exit condition for the loop to avoid holding onto other resources for too long.
Hope this helps |
|
| Back to top |
|
|
|
|
