| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Changing properties through scripting |
« View previous topic :: View next topic » |
| Author |
Message
|
| x061294 |
 Posted: Wed Jan 04, 2006 10:27 am Post subject: Changing properties through scripting |
 |
|
Acolyte
Joined: 05 Apr 2005
Posts: 62
|
Running wbimb ver 6 on Windows
On a "normal" release process, one would use the toolkit to create a bar file, add in message flow's, configure any necessary properties, save it and deploy it. That bar file could then be moved to another machine, imported into the toolkit, have the properties changed and deployed on a new broker. However, this obviously introduces someone having to type the changes in the toolkit. I was hoping to work around that and script the whole deploy process.
With the mqsicreatebar command, one can create a bar file. However, if in the bar file there are configurable properties, as best I can tell, you can't tell the command in any way to change these properties. So I was taking it to the next level, by taking the bar file, unzipping it, running it through say an XSLT parser and changing the properties in the actual cmf file, sving the changes and then rezipping it all back together. In theory then I would have a bar file all set up for deploying onto the broker via the mqsideploy command.
I was testing this out by creating the bar, unzipping it, and manually editing the cmf file. I did this, saved it back and rezipped it. I then brought it into the toolkit to see if it could recognize the changed property. And, when opening the configure tab of the bar file I receive an error
| Quote: |
| Problems occurred when invoking code from plug-in: "org.eclipse.core.runtime". |
The zip file that is recreted after my editing is a few K different in size than the original (192K original bar, 188K modified bar), which may point to something. While the bar file after modifying certainly looks fine, and imports fine, and can be viewed in the toolkit, the properties can't be viewed, and while I didn't try deploying it, I'm guessing that even if it does deploy it won't be right.
Has anyone else either encountered this and worked around it, or, come up with some other scripted way to deploy bar files with parameters that need to be configured in each processing level (development / test / user acceptance / prod) |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jan 04, 2006 10:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Did you consider looking at the Config Mgr Proxy API?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| x061294 |
| Posted: Wed Jan 04, 2006 11:20 am Post subject: |
|
|
Acolyte
Joined: 05 Apr 2005
Posts: 62
|
| I had considered it, and am looking into it, however, I'm not sure that I have that level of control through the proxy API. (ability to change properties) I can deploy a BAR certainly, but I don't know that I can change the properties in the BAR. Have you tried it and know that it is possible? |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Jan 04, 2006 11:24 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
CMP == Configuration Manager Proxy ..... why would that allow you to edit a bar file?
EDIT: actually, I've considered doing something like that (command line BAR file property editor), but never got around to it... I'm motivated now to give it a try .... 
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 04, 2006 11:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I wouldn't think it would let you "edit a bar".
I thought it might let you specify override properties for the deployment descriptor, though.
But it doesn't seem to. That's what I get for not checking before I post.
I think you don't want to be editing the cmf file - that's the compiled message flow.
You want to edit the broker.xml file. This is what contains the overrides for promoted properties.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| x061294 |
| Posted: Wed Jan 04, 2006 11:54 am Post subject: |
|
|
Acolyte
Joined: 05 Apr 2005
Posts: 62
|
While the broker .xml file contains the properties that can be overridden, the values appear to be in the .cmf file (which while compiled is still readable, but, maybe not editable  ) which is why I was going after the cmf file - i.e. changing the datasource from one db to a different db. But, since it is "compiled" that might be the problem.
Wayne, if you have some thought's/idea's/prototype's, etc., I'm all for hearing/trying/testing them. Appreciate anything you can come up with. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 04, 2006 12:06 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yeah, I don't think the cmf is actually editable... if it was, there wouldn't be a need for the deployment descripter. Among other things, changing the length of strings inside it could throw off internal byte counts - generally a bad idea.
The broker.xml file is the file to edit.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| x061294 |
| Posted: Wed Jan 04, 2006 12:12 pm Post subject: |
|
|
Acolyte
Joined: 05 Apr 2005
Posts: 62
|
That was my concern as well, and, so far as I can tell, it isn't all that editable.
However the xml file doesn't have the actual values, just the properties that can be changed.
| Code: |
<?xml version="1.0" encoding="UTF-8"?>
<Broker>
<CompiledMessageFlow name="D">
<ConfigurableProperty uri="D#additionalInstances"/>
<ConfigurableProperty uri="D#commitCount"/>
<ConfigurableProperty uri="D#commitInterval"/>
<ConfigurableProperty uri="D#coordinatedTransaction"/>
<ConfigurableProperty uri="D#MQOutput.queueName"/>
<ConfigurableProperty uri="D#MQOutput.queueManagerName"/>
<ConfigurableProperty uri="D#MQInput.validateMaster"/>
<ConfigurableProperty uri="D#MQOutput.replyToQMgr"/>
<ConfigurableProperty uri="D#MQInput.topicProperty"/>
<ConfigurableProperty uri="D#MQInput.queueName"/>
<ConfigurableProperty uri="D#MQOutput.replyToQ"/>
<ConfigurableProperty uri="D#MQOutput.validateMaster"/>
<ConfigurableProperty uri="D#MQInput.serializationToken"/>
</CompiledMessageFlow>
</Broker> |
So editing it doesn't appear to add any value because I need to put the actual data values somewhere, and this doesn't help me. But I'm open to ideas. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Jan 04, 2006 12:17 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
but ConfigurableProperty allows for an "override" attribute, which can be changed .....
EDIT: you see this attribute in broker.xml if you use the bar editor 'configure' page to override a value. 
_________________
-wayne
Last edited by wschutz on Wed Jan 04, 2006 12:19 pm; edited 2 times in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 04, 2006 12:17 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Try entering an override value in the BAR file using the toolkit and then see if the broker.xml file contains values...
I would expect that the value would be the value of the element with the correct uri name... All the ones you show are terminated elements.
Or the values might go into a different attribute.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| x061294 |
| Posted: Wed Jan 04, 2006 12:27 pm Post subject: |
|
|
Acolyte
Joined: 05 Apr 2005
Posts: 62
|
You would be correct. If I change the additional instances, there is the override value
| Code: |
<?xml version="1.0" encoding="UTF-8" ?>
- <Broker>
- <CompiledMessageFlow name="D">
<ConfigurableProperty override="9" uri="D#additionalInstances" />
<ConfigurableProperty uri="D#commitCount" />
<ConfigurableProperty uri="D#commitInterval" />
<ConfigurableProperty uri="D#coordinatedTransaction" />
<ConfigurableProperty uri="D#MQOutput.queueName" />
<ConfigurableProperty uri="D#MQOutput.queueManagerName" />
<ConfigurableProperty uri="D#MQInput.validateMaster" />
<ConfigurableProperty uri="D#MQOutput.replyToQMgr" />
<ConfigurableProperty uri="D#MQInput.topicProperty" />
<ConfigurableProperty uri="D#MQInput.queueName" />
<ConfigurableProperty uri="D#MQOutput.replyToQ" />
<ConfigurableProperty uri="D#MQOutput.validateMaster" />
<ConfigurableProperty uri="D#MQInput.serializationToken" />
</CompiledMessageFlow>
</Broker> |
I will have to look into this more. Thanks for the pointers to direction. However, Wayne, still interested in working with you on an editor |
|
| Back to top |
|
|
| mqmatt |
| Posted: Thu Jan 05, 2006 3:28 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
As you've seen, the CMP API doesn't create or modify BAR files - it takes the BAR file as input to the deploy method. In fact, the BAR file is treated as a raw byte stream until it is unpacked by the Config Manager.
Programmatic manipulation of BAR files (and deployment descriptors) is something the product lacks at the moment, but is an area being looked at.
Any comments would be appreciated... and timely  |
|
| Back to top |
|
|
| x061294 |
| Posted: Thu Jan 05, 2006 8:51 am Post subject: |
|
|
Acolyte
Joined: 05 Apr 2005
Posts: 62
|
This is a very important piece of the puzzle to get away from a manual deployment effort. We have different instance counts, different database sources, different queue names, etc for our different processing levels (dev, qa, prod) As I mentioned in previous post, we currently do a manual process where a person sign's onto the box, brings up a toolkit, imports the bar, modifies the properties, then deploy's it. Painful, but necessary since we have these properties that are different. We've looked into trying to get away from needing to change these properties as much as possible, but we can't get away from them entirely.
The movement to the CMP is a good step, however, as noted, technically it doesn't solve this problem at all. So until we can solve this problem, the CMP doesn't help us.
We're going down the path of rolling our own, but we're going to have to write an XSLT transformation to search for the correct flow within the .xml file, find the right property and change the override. Far from a clean solution, and, one we'll have to modify every time we have a new flow/bar. But at least if we do this we can do this at development time rather than manually typing it at production time.
So having the CMP, or something like it, available to modify the deployment descriptors would mean that I wouldn't have to code up an XSLT (or substitute in your favorite file manipulator) each time I go to do a release. And would certainly give the release process a much cleaner process, reducing the likelyhood of errors.
Trust me, having people have to sign onto production brokers to do releases has raised more than a few eyebrow's in our audit areas. We tell them that we don't have any product supported options and they've allowed us to skate so far, but, they aren't happy. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 05, 2006 9:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You shouldn't need to log into a production box, per se. I'd expect you to have a management/administration console machine for different things, on which you'd install the Toolkit.
Or you could have a Toolkit that is completely unconnected to anything other than, perhaps, CVS or similar. Then you could import a BAR file, edit the properties, save it again, and then move it to, say, the configmgr machine and kick of a script using mqsideploy or the CMP. Or you could have a scheduled task that would run on the production box, go out to the network and fetch the bar file from a predetermined place and then do the deployment.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jamest_ibm |
| Posted: Tue Jan 10, 2006 7:43 am Post subject: |
|
|
Newbie
Joined: 13 Dec 2004
Posts: 9
Location: Winchester, UK
|
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
