ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Workflow Engines - IBM MQ Workflow & Business Process Choreographer » Message persistence in EXEXMLINPUTQ

Post new topic  Reply to topic
 Message persistence in EXEXMLINPUTQ « View previous topic :: View next topic » 
Author Message
koko
PostPosted: Mon Jan 30, 2006 10:14 am    Post subject: Message persistence in EXEXMLINPUTQ Reply with quote

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
View user's profile Send private message
vennela
PostPosted: Mon Jan 30, 2006 11:31 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
fidelio
PostPosted: Tue Jan 31, 2006 8:15 am    Post subject: Reply with quote

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
View user's profile Send private message
koko
PostPosted: Tue Jan 31, 2006 5:28 pm    Post subject: Reply with quote

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
View user's profile Send private message
jmac
PostPosted: Tue Jan 31, 2006 6:22 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
koko
PostPosted: Tue Jan 31, 2006 6:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
hos
PostPosted: Wed Feb 01, 2006 12:13 am    Post subject: Reply with quote

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
View user's profile Send private message
koko
PostPosted: Wed Feb 01, 2006 3:40 am    Post subject: Reply with quote

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
View user's profile Send private message
jmac
PostPosted: Wed Feb 01, 2006 6:29 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
hos
PostPosted: Wed Feb 01, 2006 6:35 am    Post subject: Reply with quote

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
View user's profile Send private message
fidelio
PostPosted: Wed Feb 01, 2006 8:37 am    Post subject: Reply with quote

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
View user's profile Send private message
koko
PostPosted: Wed Feb 01, 2006 8:46 am    Post subject: Reply with quote

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
View user's profile Send private message
jmac
PostPosted: Wed Feb 01, 2006 11:59 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Workflow Engines - IBM MQ Workflow & Business Process Choreographer » Message persistence in EXEXMLINPUTQ
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.