Author |
Message
|
koko |
Posted: Mon Jan 30, 2006 10:14 am Post subject: Message persistence in EXEXMLINPUTQ |
|
|
 Master
Joined: 26 Sep 2003 Posts: 206
|
We have a system that instantiates workflows by putting msgs into EXEXMLQ. It makes a sync call and wait for some time to see if the order is really acquired by workflow. This is leading us to some problems where even though WF acquired it ( but taking longer time than the sync call is waiting for ) it is assuming that the order is not acquired by workflow leading to duplicate orders in WF.
I would like them to make their call Async so the moment they can put a msg into EXEXMLQ they can be guaranteed the WF will pick up and process their stuff though it might be litlle sluggish.
Is this a good approach? to use async mecanism to rely on assured delivery. Do I need to make any changes to the WF/MQ to gurantee assured delivery of msgs coming into EXEXMLQ? _________________ Thanks
Koko |
|
Back to top |
|
 |
vennela |
Posted: Mon Jan 30, 2006 11:31 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
Quote: |
Is this a good approach? |
I don't see any reason why you shouldn't do this.
Quote: |
Do I need to make any changes to the WF/MQ to gurantee assured delivery of msgs coming into EXEXMLQ? |
If you want to make the message persistent, change the PMO options. That's all you need to do. |
|
Back to top |
|
 |
fidelio |
Posted: Tue Jan 31, 2006 8:15 am Post subject: |
|
|
Apprentice
Joined: 14 Sep 2005 Posts: 45 Location: AttainBPM
|
If you use the ProcessCreateAndStartInstance command, set ResponseRequired=Yes, and specify a reply queue in the MQMD, the WF server will send a response message when the process is started containing either an error message with a reason why the process wasn't started or the process instance data if it was started successfully. You can use the receipt of the reply message to determine that the process was started.
The ProcessCreateAndStartInstance command differs from the ProcessTemplateExecute in that the former sends a response when the process is stared, the latter when the process instance completes. |
|
Back to top |
|
 |
koko |
Posted: Tue Jan 31, 2006 5:28 pm Post subject: |
|
|
 Master
Joined: 26 Sep 2003 Posts: 206
|
Quote: |
If you use the ProcessCreateAndStartInstance command, set ResponseRequired=Yes and specify a reply queue in the MQMD, the WF server will send a response message when the process is started containing either an error message with a reason why the process wasn't started or the process instance data if it was started successfully. |
Thats EXACTLY the problem. If the system is waiting for say 20 secs, and WF does not ackowledge the message within that time, the sending system is assuming that msg is lost ( though it is not ).
I guess instead of speculating a reasonable value for the valid response window, I would rather user the underlying MQs assured delivery. _________________ Thanks
Koko |
|
Back to top |
|
 |
jmac |
Posted: Tue Jan 31, 2006 6:22 pm Post subject: |
|
|
 Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
[quote="koko"]
Quote: |
I guess instead of speculating a reasonable value for the valid response window, I would rather user the underlying MQs assured delivery. |
I assume you choose not to wait indefinitely for the message. _________________ John McDonald
RETIRED |
|
Back to top |
|
 |
koko |
Posted: Tue Jan 31, 2006 6:50 pm Post subject: |
|
|
 Master
Joined: 26 Sep 2003 Posts: 206
|
Jmac Wrote
Quote: |
I assume you choose not to wait indefinitely for the message. |
LOL. No sir. I want to make the WF instantiation an async call. The moment it puts a msg into EXEXMLQ, it becomes a trust worthy handoff to WF through MQ. _________________ Thanks
Koko |
|
Back to top |
|
 |
hos |
Posted: Wed Feb 01, 2006 12:13 am Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002 Posts: 470
|
Actuallly the synchronus CreateAndStart call uses MQ assured delivery, too.
It just combines asynchronous MQPut and MQGet calls to a single synchronous method. If your Put fails, the synchronous call will fail immediately.
But I agree that for book keeping purposes the asynchronous approach might be the better one. As fidelio proposed, let MQWF asynchronously reply and analyze these responses. If there is an error you can restart your order. Actually you can configure MQWF to response erronous requests only.
But I am uncertain whether this will improve your current situation. Do you have reason to believe, that XML requests 'get lost', i.e. that MQWF will never answer and you don't know whether the system got the request or not??!!
If this is the case, your situation will not improve with the asynchronous approach. It is a misconception to believe that asynchronous requests make use of MQ assured delivery and synchonous don't. |
|
Back to top |
|
 |
koko |
Posted: Wed Feb 01, 2006 3:40 am Post subject: |
|
|
 Master
Joined: 26 Sep 2003 Posts: 206
|
hos wrote
Quote: |
As fidelio proposed, let MQWF asynchronously reply and analyze these responses.
|
I am not sure I follow you. Are you saying that my source system can work in async mode by doing a PUT into the Q and WF would put a response message when the instance started. I guess the source system should use a ResponseRequired = NO when it makes an async call. In this case why would WF bother to reply to the REPLYQ?
On the other hand if you want my source system to use ResponseRequired = YES, it is a sync call and it would wait for "some time" before giving up on WF. This "some time" is the whole problem in my scenario. Yes. I agree that sync vs async mechanisms have nothing to do with "loosing" messages. Its just that the source system, with a lack of proper confidence in WF that the msg has been acquired by it, is assuming that msg may not have been acquired by WF
Quote: |
If there is an error you can restart your order. |
I guess, I must have a program listening on to the REPLYQ and as and when msgs arrive on it, have a mecanism to try to instantiate the flows again.
Quote: |
Actually you can configure MQWF to response erronous requests only. |
May I know how to do this? Is this something I need to do on the WF side or the source system side? _________________ Thanks
Koko |
|
Back to top |
|
 |
jmac |
Posted: Wed Feb 01, 2006 6:29 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
ResponseRequired of IFERROR will only post a response if MQWF fails to start an instance.
If you code NO, then your messages are guaranteed to MQWF, but they are not guaranteed to start an instance. _________________ John McDonald
RETIRED |
|
Back to top |
|
 |
hos |
Posted: Wed Feb 01, 2006 6:35 am Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002 Posts: 470
|
Quote: |
On the other hand if you want my source system to use ResponseRequired = YES, it is a sync call and it would wait for "some time" before giving up on WF. This "some time" is the whole problem in my scenario. |
Even if you use ResponseRequired=YES you can use the MQWF XML interface asynchronously. You just set up a different thread that would permanently listen to the reply queue and do some repair action in case of errors.
Quote: |
May I know how to do this? Is this something I need to do on the WF side or the source system side? |
Just use
Code: |
<ResponseRequired>IfError</ResponseRequired> |
in your request. |
|
Back to top |
|
 |
fidelio |
Posted: Wed Feb 01, 2006 8:37 am Post subject: |
|
|
Apprentice
Joined: 14 Sep 2005 Posts: 45 Location: AttainBPM
|
I see the confusion... I am thinking of a multi-threaded solution where your application puts the start message on the queue and assumes delivery and a successful start with a different thread watching the REPLY queue for responses, and your program is putting a message and waiting for a response in the same thread. Is there a requirement for a single-threaded app? Is there some action you need to take in your app after a successful start, or do you just need to know if a process didn't start? |
|
Back to top |
|
 |
koko |
Posted: Wed Feb 01, 2006 8:46 am Post subject: |
|
|
 Master
Joined: 26 Sep 2003 Posts: 206
|
Quote: |
Is there some action you need to take in your app after a successful start, or do you just need to know if a process didn't start? |
The system that I am referring to is a middleman. It needs to acknowlege the possession of the order to it's source system. So unless my middleman is damn sure that the msg is or will be taken care by WF it cannot guarantee its source system. _________________ Thanks
Koko |
|
Back to top |
|
 |
jmac |
Posted: Wed Feb 01, 2006 11:59 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
koko wrote: |
The system that I am referring to is a middleman. It needs to acknowlege the possession of the order to it's source system. So unless my middleman is damn sure that the msg is or will be taken care by WF it cannot guarantee its source system. |
Well IMHO, you are never sure that WF will take care of the message, that is unless you are 100% sure that you have a valid ProcessTemplateCreateAndStartInstance message for the Process Template you are starting. _________________ John McDonald
RETIRED |
|
Back to top |
|
 |
|