| Author |
Message
|
| ramas_settiv |
 Posted: Thu Oct 20, 2011 2:16 am Post subject: WMB Retry mechanism and sequential exec of messages to SAP |
 |
|
Newbie
Joined: 20 Oct 2011
Posts: 2
|
We are working on a new module where WMB integrates with SAP system.
We need inputs on retry mechanism and sequential execution of messages to SAP (when SAP is down).
We are yet to set up the SAP environment and dwell into integration but the thing is we will receive the messages and we have to pass the messages in the same order only, even if we provide persistence can we be sure that messages received in particular order will pass the same way?
Like
Msg1
Msg2
Msg3
Msg4
Msg5 are received and the SAP restart has occurred if we use persistence can we be sure that after restart the messages will go in the same 1,2,3,4,5 order? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Oct 20, 2011 2:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
What does the documentation say about order of messages?
What does the documentation say about persistence?
What does your own testing show? |
|
| Back to top |
|
|
| ramas_settiv |
| Posted: Thu Oct 20, 2011 2:38 am Post subject: WMB Retry mechanism and sequential exec of messages to SAP |
|
|
Newbie
Joined: 20 Oct 2011
Posts: 2
|
We are yet to set up the environment for testing.
Persistance with respect to MQ we are not sure how once msgs are pilled up with be consumed.
There is a concept of retry in SAP input node but there is no mention of priority while passing messages.
Any links on documentation will also be helpful.
PS: I am novice to WMB |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Oct 20, 2011 4:21 am Post subject: Re: WMB Retry mechanism and sequential exec of messages to S |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 20, 2011 4:42 am Post subject: Re: WMB Retry mechanism and sequential exec of messages to S |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ramas_settiv wrote: |
| Persistance with respect to MQ we are not sure how once msgs are pilled up with be consumed. |
How messages are consumed is nothing to do with their persistence.
| ramas_settiv wrote: |
| Any links on documentation will also be helpful. |
Look in the WMQ (not the WMB) documentation for message ordering, grouping & persistence.
| ramas_settiv wrote: |
| PS: I am novice to WMB |
It sounds like you're a novice to WMQ as well given some of this. I urge you to seek training and/or mentoring; you seem to be straight in the deep end here.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Oct 20, 2011 11:58 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
Vitor
you seem to be straight in the deep end here
|
Properly interfacing with SAP is an art form in its own right.
Basically, SAP Lies in its return codes.
If you call a BAPI to pass some data into SAP table, you might get an OK reply. BUT at that moment, the data may well have not been written to the table. That process may in itself happem sometime later. If it throws an error, the error may get passed back to Broker in another call.
Confused?
Our SAP guys just shrung their shoulders.
This 'feature' makes finding the root cause of the problem very difficult.
Then there is the 'I'm busy processing that record, please try later' situation.
If you are updating every line in a big order once again, SAP will return an OK to broker but the update has not completed. So if you then try to update that Order again, SAP might say I can't update that order. It also creates a whole raft of idocs internally (at least one for every order line) and can bring a whole SAP instance to its knees.
We have had to introduce a whole load of delays in the bulk load flows because of this 'feature'
Working with SAP is not the easiest bit of broker to get right.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 20, 2011 12:07 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| Quote: |
Vitor
you seem to be straight in the deep end here
|
Properly interfacing with SAP is an art form in its own right.
Basically, SAP Lies in its return codes.
If you call a BAPI to pass some data into SAP table, you might get an OK reply. BUT at that moment, the data may well have not been written to the table. That process may in itself happem sometime later. If it throws an error, the error may get passed back to Broker in another call.
Confused?
Our SAP guys just shrung their shoulders.
This 'feature' makes finding the root cause of the problem very difficult.
Then there is the 'I'm busy processing that record, please try later' situation.
If you are updating every line in a big order once again, SAP will return an OK to broker but the update has not completed. So if you then try to update that Order again, SAP might say I can't update that order. It also creates a whole raft of idocs internally (at least one for every order line) and can bring a whole SAP instance to its knees.
We have had to introduce a whole load of delays in the bulk load flows because of this 'feature'
Working with SAP is not the easiest bit of broker to get right. |
But feel "deep end" was more compact.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 20, 2011 1:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The other thing with SAP, is that if you have IDOCs of different types that need to be processed in a certain order, you can make some configuration in SAP so that it will always process any IDOCs from type A before processing IDOCs from type B.
Talk to your SAP people.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
