| Author |
Message
|
| Vibor |
 Posted: Tue Mar 03, 2015 5:03 am Post subject: Timing out any flow |
 |
|
Newbie
Joined: 02 Mar 2015
Posts: 7
Location: Zagreb, Croatia
|
Is there a way (configuration or design) to timeout (terminate) any flow which is taking to long to complete?
Is there any way (if done by design) to take appropriate action (like send message to back-out queue)? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Mar 03, 2015 5:18 am Post subject: Re: Timing out any flow |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Vibor wrote: |
Is there a way (configuration or design) to timeout (terminate) any flow which is taking to long to complete?
Is there any way (if done by design) to take appropriate action (like send message to back-out queue)? |
See here 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vibor |
| Posted: Tue Mar 03, 2015 5:39 am Post subject: |
|
|
Newbie
Joined: 02 Mar 2015
Posts: 7
Location: Zagreb, Croatia
|
Thank you. 
So there isn't any design I can use... that's sad.
Only thing useful I have found is:
| Quote: |
Two message flow properties are provided which can be set within the BAR file and the workload management policy:
processingTimeoutSec – maximum time a message flow can process a message before taking an action.
processingTimeoutAction – the action to take. Currently, this is restricted to none or restartExecutionGroup. |
Which is also sad, because I have to have to configure bar file instead of flow file. Which means if bar file is deleted (like, automatically when flow from integration project is deployed), setting is lost. |
|
| Back to top |
|
|
| adubya |
| Posted: Tue Mar 03, 2015 6:08 am Post subject: |
|
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
| Vibor wrote: |
Which is also sad, because I have to have to configure bar file instead of flow file. Which means if bar file is deleted (like, automatically when flow from integration project is deployed), setting is lost. |
This is incorrect. Setting the property in the bar file is just a means of expressing the value you want to be applied to the flow at deploy time. Once deployed then the flow is no longer dependent upon the bar file and the property will continue to be active. |
|
| Back to top |
|
|
| Vibor |
| Posted: Tue Mar 03, 2015 6:17 am Post subject: |
|
|
Newbie
Joined: 02 Mar 2015
Posts: 7
Location: Zagreb, Croatia
|
| adubya wrote: |
| This is incorrect. Setting the property in the bar file is just a means of expressing the value you want to be applied to the flow at deploy time. Once deployed then the flow is no longer dependent upon the bar file and the property will continue to be active. |
But I've searched through flow properties and I haven't found "Processing Timeout" parameter. I've also opened flow as text file and searched for "timeout". No results were found.
How can I configure flow itself? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 03, 2015 6:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vibor wrote: |
| How can I configure flow itself? |
You configure the properties of the bar file. You then deploy the bar file - and LO the properties of the flow itself are configured.
Or you use the Admin API to adjust the properties of deployed objects. |
|
| Back to top |
|
|
| Vibor |
| Posted: Tue Mar 03, 2015 6:28 am Post subject: |
|
|
Newbie
Joined: 02 Mar 2015
Posts: 7
Location: Zagreb, Croatia
|
I think you misunderstood me or I did not express myself correctly. I know this:
| mqjeff wrote: |
| You configure the properties of the bar file. |
I (now, after reading Vitor's post and finding quoted text in my post) know how to configure specific flow by configuring bar file.
I was only complaining that I can't configure flow file itself, which means when bar file is deleted changes are also deleted. And this happens every time I want to deploy flow from integration project after changes in that flow have occurred.
Thank you all for your contribution.
EDIT: Just a warring for everyone reading this topic.
Even if you set "Processing Timeout (Second)" parameter, in debug mode this will not work. Terminating debugger doesn't save you either.
So, if you happen to have this code for testing flow termination:
WHILE TRUE DO
DECLARE debugger INTEGER 0;
END WHILE;
do not test in debug mode.
Last edited by Vibor on Tue Mar 03, 2015 7:01 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 03, 2015 6:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Vibor wrote: |
| I was only complaining that I can't configure flow file itself, which means when bar file is deleted changes are also deleted. And this happens every time I want to deploy flow from integration project after changes in that flow have occurred. |
a) If you're building your bar file with an automated tool (ant or similar) as is a good practice, it's very easy to reapply the changes.
b) If you set a policy rather than configure it in the bar file, the policy survives the redeploy of the bar file.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Tue Mar 03, 2015 7:18 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| Vibor wrote: |
| I was only complaining that I can't configure flow file itself, which means when bar file is deleted changes are also deleted. And this happens every time I want to deploy flow from integration project after changes in that flow have occurred. |
So you have it as a bar file override for when you are building the bar file. The change is documented there then. |
|
| Back to top |
|
|
| Vibor |
| Posted: Tue Mar 03, 2015 7:23 am Post subject: |
|
|
Newbie
Joined: 02 Mar 2015
Posts: 7
Location: Zagreb, Croatia
|
I'm using IBM Integration Toolikt to deploy flows. All flows dependencies are automatically put to a bar file and deployed. The only thing I have to do is drag and drop the wanted flow.
I'm not using automated build. I'm not rebuilding bar file and deploying it. This is all done automatically by IBM Integration Toolkit.
Also, I'm not sharing bar files. I'm sharing zip file with code by using "Project Interchange". All my code is checked and build elsewhere. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 03, 2015 7:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Vibor wrote: |
| I'm using IBM Integration Toolikt to deploy flows. All flows dependencies are automatically put to a bar file and deployed. The only thing I have to do is drag and drop the wanted flow. |
Great for development, not so great for later environments where more control & audit is typically required, and the ability to kill unresponsive flows is typically needed. As it is in your environment.....
| Vibor wrote: |
| I'm not using automated build. I'm not rebuilding bar file and deploying it. This is all done automatically by IBM Integration Toolkit. |
My comments above apply.
| Vibor wrote: |
| Also, I'm not sharing bar files. I'm sharing zip file with code by using "Project Interchange". All my code is checked and build elsewhere. |
My comments above apply, as do all the earlier comments about the automated build process reapplying the needed attributes. I will bet good money that the "elsewhere" isn't manually pulling the PI files into Toolkit & building the bar files by hand.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| adubya |
| Posted: Tue Mar 03, 2015 7:58 am Post subject: |
|
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
As above, drag and drop deployment is great in development but that's where it should stop IMO.
And as Vitor mentioned above, setting the timeout property in the bar file is one way of doing it, the other approach is to use mqsichangepolicy. The latter method will survive a drag/drop bar file deploy. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Tue Mar 03, 2015 10:46 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| adubya wrote: |
| As above, drag and drop deployment is great in development but that's where it should stop IMO. |
Everything should be scriptable. This means things are self documented via the scripts themselves. This allows you to hand things off to other people quickly and with confidence. |
|
| Back to top |
|
|
|
|
