Per IBM advice http://www-01.ibm.com/support/docview.wss?rs=0&q1=%2bsap+%2bbroker&uid=swg21423320&loc=en_US&cs=utf-8&cc=us&lang=all I have ticked the
"ensure once only delivery" in the SAP Inbound Adapter.
However what I observe is; whenever there is a failure in the flow, an exception is raised , and SAP is informed that the transaction has failed.
One can see that in SAP trx SM58, a record is shown for the failed idoc. This is expected behaviour.
If the flow is fixed, redeployed and then in SM58 one executes 'Execute LUW' (a regular procedure within SAP) then the transaction message just disappears. It is not handled by the flow anymore. The message is lost. This is for me not expected behaviour.
Service Trace shows event status = 1 (and not -1 in case of fully new message) and hence does not pass on.
Probably due the fact that the event is retained in MB, due to the "ensure once only delivery" setting.
1) is this expected behaviour ?
2) if so, should I in my error flow handling explicitly get rid of this stored event to allow Re-execute from SAP. How do I get rid of this stored event ?
BTW for the time being I have switched off "ensure once only delivery". Now when I redeploy after failure and subsequent SM58 execute LUW, the message is not lost and handled by the flow as expected.
This topic has been locked.
Pinned topic SAP SM58 vs "ensure once only delivery" in WMB V7 Inbound SAP adapter
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
SystemAdmin 110000D4XK67 Posts
Re: SAP SM58 vs "ensure once only delivery" in WMB V7 Inbound SAP adapter2010-09-09T17:33:00ZThis is the accepted answer. This is the accepted answer.Hello Bart,
When encountering the issues with 'ensure once only delivery' did you happen to gather any WMB service traces? If so, please review them for any signs of a NullPointerExeption (NPE). There was a defect found on WMB v7 and the JCA SAP Adapter that caused some events to be delivered into the WMB eventstore with an XID == NULL. This then bubbled up the stack and caused messages to fail and never be delivered to the endpoint.
Please open a PMR with IBM WebSphere Adapter Support if you would like to follow up on this issue and receive any possible fixes.