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 » WebSphere Message Broker (ACE) Support » Best way to delay message?

Post new topic  Reply to topic
 Best way to delay message? « View previous topic :: View next topic » 
Author Message
frankie72
PostPosted: Mon Dec 05, 2011 2:21 am    Post subject: Best way to delay message? Reply with quote

Newbie

Joined: 05 Oct 2011
Posts: 5

Hi! I have some attachements/files that are sent via a custom application to a share on destination.

My flow sends a message that contains a reference to the file(s) like filename etc. Problem is. If my message arrives before the attachments/files have arrived I get error.

Thus I need to delay the message until I know that the files should be in place physically on the destination.

Any ideas?

Just implementing some kind of brute delay in the flow should probably solve it (adds extra time though for entire message throughput) but it would be more elegant to have some kind of correlation. But I do not want to build a lot of extra logic around this. Less is more. So I am looking for a simple but effective way.

Open for suggestions

Thanks
Back to top
View user's profile Send private message
zpat
PostPosted: Mon Dec 05, 2011 3:28 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5866
Location: UK

Use the WMB fileread node perhaps to check for the file and ESQL sleep for a while if not there?
Back to top
View user's profile Send private message
frankie72
PostPosted: Mon Dec 05, 2011 10:24 am    Post subject: Reply with quote

Newbie

Joined: 05 Oct 2011
Posts: 5

zpat wrote:
Use the WMB fileread node perhaps to check for the file and ESQL sleep for a while if not there?


Yes that might work. Need to check the docs for that node. I guess it needs to returns some kind of boolean true/false then if file present or not (and that I can specify filename dynamically using/populating local env settings somewhere before that node in my flow)

Thanks.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Dec 05, 2011 10:31 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

frankie72 wrote:
I guess it needs to returns some kind of boolean true/false then if file present or not


Almost - it route to the Out or the NoMatch terminals depending on if it finds the files or not. You can easily code a boolean based on that.

Note that like anything that reads a file, there's no check to see if the file is complete. So if you're got large file attachments, the node might be able to find the file before the full contents are available.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Mon Dec 05, 2011 10:35 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

The general case of the problem of "Is a file ready to be processed" is formally unsolvable. It's a restatement of the Halting Problem, as there is some program that has the responsibility of writing the file. So you can't know that the file is ready to be processed until you know that the program writing the file has halted.
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Dec 05, 2011 10:42 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

mqjeff wrote:
The general case of the problem of "Is a file ready to be processed" is formally unsolvable.




This is exactly the point I was driving at, but expressed much better.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
inMo
PostPosted: Mon Dec 05, 2011 12:02 pm    Post subject: Reply with quote

Master

Joined: 27 Jun 2009
Posts: 216
Location: NY

Perhaps it would be worth asking for more information on the 'Custom Application' that is 'sending' the files in question? What is causing the custom application to send the file(s)? How are you aware that the app is sending the files (are you triggering the custom app?)
Back to top
View user's profile Send private message
mqjeff
PostPosted: Mon Dec 05, 2011 12:23 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

It is always better in this kind of situation to get the sending application to clearly indicate that files are ready for processing. For example by writing a trigger file, or by moving files from a temporary location to a final location or etc.

It is always better in this kind of situation for the receiving applications to also code defensively.
Back to top
View user's profile Send private message
frankie72
PostPosted: Tue Dec 06, 2011 4:59 am    Post subject: Reply with quote

Newbie

Joined: 05 Oct 2011
Posts: 5

Thanks all.

I have decided to actually try to get receving application to deal with this. Not something the integration platform should handle. It is a error that arsies there and should be fixed there.

I can see the happy faces on the application side already =) last.word.not.said
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Best way to delay message?
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.