| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Where am I? |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Wed Nov 12, 2014 4:24 pm Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| Vitor wrote: |
| PeterPotkay wrote: |
| If I had a suffix appending to the end of the execution group, the ESQL could identify what EG its running in and thus automagically understand what environment it was in. |
And if I had wheels, I'd be a wagon.
|
And if I won the lottery we wouldn't be talking about this.
| Vitor wrote: |
Also if a UDP changes the code, where do you stand on promotable properties? |
I never said it was a change to the code.
I think you'll agree is a good feature to be able to leave the Reply To QM field blank in the MQMD on the MQPUT of the request, knowing that the the correct name will be filled in based on the environment you are running in.
And that you can refer to the same DSN name in your ESQL, but the database you actually hit is different, with no changes to the code or to the bar file, based on the environment you are deployed to.
And by using Reply To Alias queues, the ESQL code can use the same queue name but produce a message with a different Reply To Q for each environment, but with the exact same code and bar file.
So I'm looking to see how we can use this concept for a couple of other things, like the URL you HTTP Request to, which needs to change based on environment. Would it not be useful to have some kind of DSN concept for URLs like we do for databases? Or instead of a new DSNforURL object, what if the ESQL code could simply query the environment its in, and set the correct URL?
99.94% of the code is going to be the same or is already going to be handled with features like Reply To QMs, Reply To Aliases, DSNs, etc. I'm looking to go the last 0.06%.
And no, its not audit related. Its related to minimizing / eliminating anything that needs to be done beyond deploy this exact bar file you signed off on in QA to PROD, with the only decision being date and time of deploy. All in the interest of minimizing / eliminating screw ups at deployment time.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed Nov 12, 2014 11:08 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
The business then says 90 days not 30 days - you need a code change! If the number of days was a UDP, it's just a redeploy.
|
And if a DB table is used, it us a simple update table and flow restart. No deploys needed. No regression testing etc etc etc.
All the options presented in this thread have their advantages and disadvantages. The correct one really depents upon the processes in place at your site.
For us where we don't control or even have direct access to our customers systems that are scattered around the world, the KISS principle rules OK.
We ship the SQL update command and instructions to restart the flow. There is one site where this is allowed. If we had to re-deploy, they'd insist on a two week UAT/Parallel running before it was allowed to be deployed to production. What price the timeliness of the business change then eh?
But to be honest, these values rarely change once the flow has been in use for a while.
_________________
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 |
|
|
| inMo |
| Posted: Thu Nov 13, 2014 5:47 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
My 2 cents ...
The general guidance is two part:
1) Identify the means by which you will identify what environment you are in. That is something that must be decided by the team on the project.
2) Once you have an acceptable means of identifying the environment, the code needs to look to an external, maintainable source for environment specific information. The available information should be consistent across environments. In the example where a rule is changed from 90 to 30 days: You are scr*wed if you have that as code. You are safe if the value of 90 is externalized, changeable and is used as part of a code decision.
A database is one way of externalizing the values. Just keep in mind that having a table structure ties you to that table structure. When you need to make changes, it can have unintended impacts on your code. It would be wise to design around the idea that you will regularly be adding new data to the external source and you encapsulate the flow's reading of that source to protect the rest of the flow code. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 13, 2014 6:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| So I'm looking to see how we can use this concept for a couple of other things, like the URL you HTTP Request to, which needs to change based on environment. Would it not be useful to have some kind of DSN concept for URLs like we do for databases? Or instead of a new DSNforURL object, what if the ESQL code could simply query the environment its in, and set the correct URL? |
Why not have Test, QA & Prod DNS servers? Then you could refer to the same URL and it would resolve to the correct end point in the same way a DSN resolves. Your network people might have a view....
In my world, my support people find it much more helpful to have a list of properties stored in the deploy system which a) they can review before we set it going and b) they can refer to later in the event of problems. I accept you can store them in a DB, and I accept your point you can code them into ESQL. My point about coding them in ESQL is that any changes to values require a redeploy, and a deploy typically requires change control.
Indeed, for "business" values a database is probably the best place. We don't allow a DB for things like queues and URLs because a) this allows the users to alter the table values without actually telling us and b) changing queues and databases should be included in the change control process like the deploy.
| PeterPotkay wrote: |
| 99.94% of the code is going to be the same or is already going to be handled with features like Reply To QMs, Reply To Aliases, DSNs, etc. I'm looking to go the last 0.06%. |
Humph - at least 60% of the flows in my care are web based. Queues are in the minority. I feel the envy flow through me.
| PeterPotkay wrote: |
| Its related to minimizing / eliminating anything that needs to be done beyond deploy this exact bar file you signed off on in QA to PROD, with the only decision being date and time of deploy. All in the interest of minimizing / eliminating screw ups at deployment time. |
Laudible, and the reason we have the bar files in a locked source code repository. The bar file we deploy to test is the same one we deploy to QA and the same one we deploy to Prod for all the reasons you have, and we can tell that not only because of the date & time but the eye catchers. The properties we apply on an environmental basis are in the same source code repository, are available for review and form an audit trail for the support use case I give above.
Clearly you need to do what's best for your site, and if 99.4% of the environmental changes are handled by the environment itself (identically named DSNs pointing to different databases) then maybe this is better for the 0.06% than externalising.
It's not for me though 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Nov 13, 2014 6:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So what if you need to deploy a bar file that was signed off in QA, but in production you need to alter the number of instances that the flow or a specific node uses?
An external properties system handles all of your user-defined properties, but not broker defined properties.
The only thing that mqsiapplybaroverrides changes is one single XML file within the BAR file. Every other part of it is left entirely untouched.
The XML file in question is not used at all by your code or your flow. It's only used during the actual deployment. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
