| Author |
Message
|
| abd.wsu |
 Posted: Wed Jan 25, 2017 10:18 am Post subject: Additional instances of message flow |
 |
|
Acolyte
Joined: 12 Sep 2012
Posts: 65
|
Is there a way to preserve additional instances of a message flow when a bar file is deployed? Here's the scenario.
A bar file is deployed with 0 additional instances. But later via the MB Explorer or the UI, the no. of additional instances is increased to 4.
However when a new bar file is deployed to the same flow, the additional instances is reverted back to 0.
Is there any way to preserve this at the admin level, so that the developers don't have to remember to set the instances before building the bar and deploying it. By doing that there is scope of human error. And would cause issues if a developer simply doesn't set this and deploys a new bar. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Jan 25, 2017 10:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
A deployed bar file is no longer a bar file. It doesn't exist.
A set of resources exist that were packaged in the bar file.
So, no, you can't do this.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 25, 2017 12:34 pm Post subject: Re: Additional instances of message flow |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| abd.wsu wrote: |
| A bar file is deployed with 0 additional instances. But later via the MB Explorer or the UI, the no. of additional instances is increased to 4. |
This is a great reason to script such changes.
| abd.wsu wrote: |
| However when a new bar file is deployed to the same flow, the additional instances is reverted back to 0. |
Only if the attribute is set to 0.
| abd.wsu wrote: |
| Is there any way to preserve this at the admin level, so that the developers don't have to remember to set the instances before building the bar and deploying it. |
Set the additional instances property using a file and the mqsiapplybarfileoverride command. You should be doing this anyway to ensure the deployed bar file is correct for the environment (e.g. web URLs points to the correct Prod endpoint rather than the QA endpoint).
This is simple if you're deploying with a script as you should be.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Thu Jan 26, 2017 8:40 am Post subject: Re: Additional instances of message flow |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 364
Location: Columbus, OH
|
| Vitor wrote: |
| This is simple if you're deploying with a script as you should be. |
As we are in the middle of migrating from v8 to IIB 10 we are also scripting all build and deploy processes.
I've had the fun of trolling through all the environments to see what Additional Instance values are for all flows as well as externalizing all references to URLs to property files that can be set via bar overrides.
But now that that work is done it is a trivial exercise to create a bar file for a specific environment and know that the values are set correctly. Or where they need to be updated if they need changing. In fact it is so simple that now we don't need a developer to handle that task, operations personal can now update a properties file and have the bar file deployed.
I will say I've developed a strong dislike (close to hatred) of the BrokerName variable. I saw more than enough code that was checking it to determine what environment (Dev, Test, Prod, etc) it was in so that it would know what URL to call to last me a lifetime. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 26, 2017 9:15 am Post subject: Re: Additional instances of message flow |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| joebuckeye wrote: |
| I will say I've developed a strong dislike (close to hatred) of the BrokerName variable. I saw more than enough code that was checking it to determine what environment (Dev, Test, Prod, etc) it was in so that it would know what URL to call to last me a lifetime. |
There's a specific place in Hell (or as we call it here, the Code Review Stage Gate) for developers that do that.
When we were developing naming standards for the new datacenters, we came that close (please visualize a thumb and forefinger very close together) to just numbering the Linux servers to defeat exactly that kind of coding practice. But senior management were worried how much code would break when we migrated it, and insisted we keep an environmental marker in the server name.
(Migrating code which has not been changed or edited is exempt from Stage Gates)
So we moved the marker from the 4th character of the name to the 5th. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 26, 2017 5:09 pm Post subject: Re: Additional instances of message flow |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| joebuckeye wrote: |
| I will say I've developed a strong dislike (close to hatred) of the BrokerName variable. I saw more than enough code that was checking it to determine what environment (Dev, Test, Prod, etc) it was in so that it would know what URL to call to last me a lifetime. |
Sincere question: What is wrong with a message flow that automatically recognizes the environment it finds itself running in and acts accordingly?
Is the preference to make the What-URL-Do-I-Call decision at deploy time via bar overrides? Is that because not only can you change the URL to call between DEV and QA and PROD by the bar override, but that you can also change the URL completely for each environment without touching the code, just bar overriding again?
What method are you using for migrating from 8 to 10, as we are currently weighing pros and cons from upgrade the whole Broker in one shot with the mqsi commands all the way to lets order those new servers now.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 26, 2017 9:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
When doing a migration like that I like to have the new broker version and the old broker version side by side. I can then decide (via the MQ cluster setup) which version gets to process the message and switch back and forth as I please. That gives time to test in dev / qa and work out the bugs.
I understand that this would probably be a bit more invasive for HTTP and the load balancer setup...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 27, 2017 5:42 am Post subject: Re: Additional instances of message flow |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| joebuckeye wrote: |
| I will say I've developed a strong dislike (close to hatred) of the BrokerName variable. I saw more than enough code that was checking it to determine what environment (Dev, Test, Prod, etc) it was in so that it would know what URL to call to last me a lifetime. |
Sincere question: What is wrong with a message flow that automatically recognizes the environment it finds itself running in and acts accordingly? |
It moves control of the environment from the administrators to the developers. Consider the scenario where an application is calling a web service. It needs to call as follows:
If the application is making this determination then any changes to the URL must be made by every application. It's also impossible for the administrators to determine how many applications are using that URL, which they could otherwise do by scanning the properties files in the source control.
Now someone's going to say:
[quote]
Well it's just a DNS record - if the name changes put in an alias so the old name resolves to the new name
[/quote
It's quite true - you can do that. If your network people are happy with that. Sooner or later they're going to clean up the DNS server (deliberately or accidentally) and every application that didn't make the change yet (which someone hasn't because there's no imperative to do it) will go boom.
Also this technique makes every environmental change (like a renamed DNS) a code change. Most sites allow a change to properties to go through with minimal review even though it includes a deploy. If the developer has to go in and change the code (even if he's just editing a URL) welcome to the full change control and regression testing cycle - enjoy your stay.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jan 28, 2017 4:48 am Post subject: Re: Additional instances of message flow |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| Vitor wrote: |
| PeterPotkay wrote: |
It moves control of the environment from the administrators to the developers. Consider the scenario where an application is calling a web service. |
|
I'm thinking coding it in the flow to use a specific URL based on runtime environment, or using bar file overrides are both in control of the developers.
| Vitor wrote: |
| PeterPotkay wrote: |
Also this technique makes every environmental change (like a renamed DNS) a code change. Most sites allow a change to properties to go through with minimal review even though it includes a deploy. If the developer has to go in and change the code (even if he's just editing a URL) welcome to the full change control and regression testing cycle - enjoy your stay. |
|
Yes, good point. A simpler change, less chance of altering another portion of the code accidentally. But a change nonetheless.
| Vitor wrote: |
| PeterPotkay wrote: |
| If the application is making this determination then any changes to the URL must be made by every application. It's also impossible for the administrators to determine how many applications are using that URL, which they could otherwise do by scanning the properties files in the source control. |
|
If its easier to scan properties files than esql files then this is another pro.
I guess I'm of the school of thought that the less times you touch something, the better. And altering the properties file is touching it. However, the code can be perfectly coded based on requirements:
If DEV, URLdev
If QA, URLqa
If PROD, URLprod
Else you are a lost, abort.
Five minutes after initially deploying to Prod, the requirements suddenly "change" to
If PROD, urlproduction
With the barfileoverrides method, not really a big deal. The other way? Change the code and back to DEV, then QA, then finally Prod. OK, I get it. I like it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Jan 28, 2017 7:07 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
This point has been discussed many times before here.
The only thing to come out of previous discussions is that there is no 'RIGHT' answer.
Do what works for you.
I've overcome the issue of different URL's by storing the properties of this and other params in a Database. Each flow has an entry in the DB. The table is read when the flow first runs and then every 24 hours. The data is stored in a Shared Variable.
This allows us to hold not only URL's but Username and passwords, logging controls and other items that we deemed to be configurable.
To change a param, update the DB and restart the flow. No barfile overrides or anything.
This also allows the same bar file to be deployed to DEV, TEST, PRE-Prod and Prod.
As I said, this worked for me at several different customers and installations all over the world. IT also allows the Ops people to see all the configurable params for each flow in one consistent place.
It may not work for you and that is ok.
Just my 2c worth.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Sat Jan 28, 2017 1:23 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
smdavies99,
Thanks for sharing your ideas. The Database concept is interesting as it makes it easy to see what all the setting are, and easy to make changes. Of course now you are dependent on that database on flow deploy or flow / EG / Broker restart time.
I've also heard of people using queues to hold these kind of details, the idea being change the message in the "config" queue if you want to change what the flow does.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Sat Jan 28, 2017 1:54 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
User Defined Configurable services can be used to store this information. Easy to view and update, no dependency on a database.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jan 28, 2017 8:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| zpat wrote: |
| User Defined Configurable services can be used to store this information. Easy to view and update, no dependency on a database. |
Doesn't the user defined configurable service force you to do an integration node (broker) restart in case you change the service? Would be easier if you could limit it to an application / flow restart, yes ?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Jan 28, 2017 10:49 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| PeterPotkay wrote: |
smdavies99,
Thanks for sharing your ideas. The Database concept is interesting as it makes it easy to see what all the setting are, and easy to make changes. Of course now you are dependent on that database on flow deploy or flow / EG / Broker restart time.
I've also heard of people using queues to hold these kind of details, the idea being change the message in the "config" queue if you want to change what the flow does. |
Some valid points Peter.
If the table (and it is not huge) is in a DB that your flows will use then it should be available when you do a broker start/failover etc.
The beauty is that a redeploy or a flow restart is all that is needed to get the data into the flow. no other flow or EG is affected.
As I said, there is no one perfect solution.
_________________
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 |
|
|
| zpat |
| Posted: Sun Jan 29, 2017 11:32 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
| fjb_saper wrote: |
| zpat wrote: |
| User Defined Configurable services can be used to store this information. Easy to view and update, no dependency on a database. |
Doesn't the user defined configurable service force you to do an integration node (broker) restart in case you change the service? Would be easier if you could limit it to an application / flow restart, yes ? |
UD Config Service updates are immediately available. Also there is no need to cache them in your own code, since they are held in memory anyway.
You might prefer to stop the flow (or app) whilst updating the CS, but you don't have to.
Incidentally you can now export them and import them as XML files which makes large ones a bit easier to administer.
No type of configurable service update requires a broker re-start. In most cases they don't require any sort of restart, even at flow or EG level (this has been an aim of IBM development for some time now).
In fact, I would actually prefer it if they did require an EG reload to refresh them - to give me more control over when they take effect, however the trend from IBM has been to make them immediately effective.
If you are restarting an entire broker - you can stop doing this as it's not been required since the dreadful v6 days when mqsisetdbparms didn't even run while the broker was up.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
