| Author |
Message
|
| aerosoul |
 Posted: Mon Jan 03, 2011 7:47 am Post subject: Referencing message sets by their ID |
 |
|
Newbie
Joined: 03 Jan 2011
Posts: 8
|
Hello,
I'm using Broker v6.1.0.8, and I'm having an issue figuring out, how to reference message sets by their ID in MQInput node (or any node which uses messagesets).
In the Toolkit when i select the message set on the Input Message Parsing tab, i see the ID of it, but in the actual .msgflow file there is only its name referenced, which is kind of nonsense to me.
My goal would be to be able to rename MessageSets in the BAR, but right now as they are referenced by name it is not possible.
I would appreciate any help with this. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Jan 03, 2011 8:10 am Post subject: Re: Referencing message sets by their ID |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aerosoul wrote: |
| My goal would be to be able to rename MessageSets in the BAR, but right now as they are referenced by name it is not possible. |
I don't understand the question or the problem. The message flow contains the id of the message set as you correctly point out. The bar file contains only those items you're deploying (which could easily be a message flow but not it's associated message sets if they're unchanged).
If you change (by renaming) the message set you'd need to redeploy them anyway & could use a separate bar file to do this.
So what's the problem? I don't see what you're getting at. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| aerosoul |
| Posted: Mon Jan 03, 2011 10:12 am Post subject: Re: Referencing message sets by their ID |
|
|
Newbie
Joined: 03 Jan 2011
Posts: 8
|
The quoted part is just the greater theme for me.
The problem is that in my test environment msgflow source references the used messagesets by name, and I would like to know if there is a way to reference them by their ID (so that i could change message set names right before deploy in the BAR, and still preserve msgflow and message set corelation).
| Vitor wrote: |
| aerosoul wrote: |
| My goal would be to be able to rename MessageSets in the BAR, but right now as they are referenced by name it is not possible. |
I don't understand the question or the problem. The message flow contains the id of the message set as you correctly point out. The bar file contains only those items you're deploying (which could easily be a message flow but not it's associated message sets if they're unchanged).
If you change (by renaming) the message set you'd need to redeploy them anyway & could use a separate bar file to do this.
So what's the problem? I don't see what you're getting at. |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 03, 2011 10:23 am Post subject: Re: Referencing message sets by their ID |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aerosoul wrote: |
| The problem is that in a msgflow source the used messagesets are referenced by name, and I would like to know if there is a way to reference them by their ID |
As you've said the input nodes refer to the message set id, and code within the ESQL refers to the top level tag. Whilst it might have a reference to the name in the msgflow file I can't think of a good reason you should be looking in there.
| aerosoul wrote: |
| (so that i could change message set names right before deploy and still preserve msgflow and message set corelation). |
That's an odd thing to want to do. Why would you deploy a different named message set to the one you've (presumably) been using in development?
Perhaps if you gave a little more detail on what requirement you're trying to fulfill? There could be another way to achieve the same end.
Certainly if you're committed to using a different name you shouldn't be messing with the flow source; you should promote the properties & use bar file overrides.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 03, 2011 10:24 am Post subject: Re: Referencing message sets by their ID |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aerosoul wrote: |
| The quoted part is just the greater theme for me. |
Like I said, I think a little more information on your greater theme might yield some better advice here. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 03, 2011 11:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you are in any way shape or form trying to override the message set data on a SOAPInput node, and you are not at 7.0.0.2 and using Gateway mode, then you are flat out out of luck. This is set at design time and is not alterable at deploy or runtime.
If you are otherwise trying to do something on a node that is NOT SOAPInput like add a version identification string to the message set name so that you can see the deployed version information, then you should at least attempt to promote the properties as mentioned and use an override. |
|
| Back to top |
|
|
| aerosoul |
| Posted: Mon Jan 03, 2011 11:35 am Post subject: Re: Referencing message sets by their ID |
|
|
Newbie
Joined: 03 Jan 2011
Posts: 8
|
First of all thank you for your help.
| Vitor wrote: |
| As you've said the input nodes refer to the message set id, and code within the ESQL refers to the top level tag. Whilst it might have a reference to the name in the msgflow file I can't think of a good reason you should be looking in there. |
As I found it by some testing, the deployed msgflow just uses the msgset name to decide which msgset to use, despite that the toolkit displays the msg set ID on the MQInput node's property sheet. So I checked the source and found that it actually does not contain the msg set ID.
| Code: |
| <nodes xmi:type="ComIbmMQInput.msgnode:FCMComposite_1" xmi:id="FCMComposite_1_1" location="21,148" queueName="INQ" messageDomainProperty="XMLNSC" messageSetProperty="MyApplicationMessageSet1" validateTiming="immediate" validateMaster="content"> |
Which seems rather odd to me, so I searched for some way to use msg set ID instead with no success.
| Vitor wrote: |
That's an odd thing to want to do. Why would you deploy a different named message set to the one you've (presumably) been using in development?
Perhaps if you gave a little more detail on what requirement you're trying to fulfill? There could be another way to achieve the same end.
Certainly if you're committed to using a different name you shouldn't be messing with the flow source; you should promote the properties & use bar file overrides. |
What I'd like to get to is to use SVN for managing Broker source code including msgsets, and to be able to use revision numbers in development, and version numbers just at the end of it. And because there could be multiple versions of the same msgset deployed on the same exec group I need to include the version number in the name, but I'd not like to do that in development phase.
Last edited by aerosoul on Mon Jan 03, 2011 11:43 am; edited 1 time in total |
|
| Back to top |
|
|
| aerosoul |
| Posted: Mon Jan 03, 2011 11:41 am Post subject: |
|
|
Newbie
Joined: 03 Jan 2011
Posts: 8
|
| mqjeff wrote: |
If you are in any way shape or form trying to override the message set data on a SOAPInput node, and you are not at 7.0.0.2 and using Gateway mode, then you are flat out out of luck. This is set at design time and is not alterable at deploy or runtime.
If you are otherwise trying to do something on a node that is NOT SOAPInput like add a version identification string to the message set name so that you can see the deployed version information, then you should at least attempt to promote the properties as mentioned and use an override. |
Indeed I tried to promote the input message parsing properties of the MQInput, but for some reason they just don't show up in the Toolkit on the manage tab of the built BAR. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 03, 2011 12:16 pm Post subject: Re: Referencing message sets by their ID |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aerosoul wrote: |
| What I'd like to get to is to use SVN for managing Broker source code including msgsets, and to be able to use revision numbers in development, and version numbers just at the end of it. |
Well you'll find a wealth of discussions in here on using WMB & SVN, many of which are on the subject that you're talking about & may be useful to you.
| aerosoul wrote: |
| And because there could be multiple versions of the same msgset deployed on the same exec group I need to include the version number in the name, but I'd not like to do that in development phase. |
I'm interested to hear that your message sets are so dynamic that you can have multiple versions in development simultaniously, and slightly alarmed that you're trying to pile them all up in a single execution group. How (in this scenario) would you merge them back into a single production (user test / pre-production) version without a lot of regression testing?
You may well find your life is considerably simplified by having multiple execution groups and tagging the message sets (and their associated flows) with SVN. This would allow them to run in parallel in development & then be merged back by whatever means you're employing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 03, 2011 12:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aerosoul wrote: |
| Indeed I tried to promote the input message parsing properties of the MQInput, but for some reason they just don't show up in the Toolkit on the manage tab of the built BAR. |
This is a problem - they should, and this is far easier (and more supported!) than playing round with either the msgflow or bar files.
Are all these in main flows rather than sub flows? Does the node properties show "promoted to flow" as you'd expect? How are the prompted properties grouped? Does the flow use the same name & group for them as the node does?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| aerosoul |
| Posted: Mon Jan 03, 2011 12:33 pm Post subject: |
|
|
Newbie
Joined: 03 Jan 2011
Posts: 8
|
| Vitor wrote: |
This is a problem - they should, and this is far easier (and more supported!) than playing round with either the msgflow or bar files.
Are all these in main flows rather than sub flows? Does the node properties show "promoted to flow" as you'd expect? How are the prompted properties grouped? Does the flow use the same name & group for them as the node does? |
Yes I'm trying this on a main flow, on the MQInput I see the properties promoted, and on the property tab of the flow I can set them, and being the only promoted props in this sample they are in the default Basic group. But they don't show up on the BAR manage tab. (I tried other props, and verified that some others appear there.) |
|
| Back to top |
|
|
| aerosoul |
| Posted: Mon Jan 03, 2011 12:45 pm Post subject: Re: Referencing message sets by their ID |
|
|
Newbie
Joined: 03 Jan 2011
Posts: 8
|
| Vitor wrote: |
I'm interested to hear that your message sets are so dynamic that you can have multiple versions in development simultaniously, and slightly alarmed that you're trying to pile them all up in a single execution group. How (in this scenario) would you merge them back into a single production (user test / pre-production) version without a lot of regression testing?
You may well find your life is considerably simplified by having multiple execution groups and tagging the message sets (and their associated flows) with SVN. This would allow them to run in parallel in development & then be merged back by whatever means you're employing. |
I may not have expressed myself the way I wanted, most of the time there should be only one version under development, but in production there will be multiple versions in the same EG, or at least I can not close this possibility out.
The reason for me not wanting the version in the msgset name in the development phase is that I don't like filename changes in SVN. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 03, 2011 1:59 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aerosoul wrote: |
| Yes I'm trying this on a main flow, on the MQInput I see the properties promoted, and on the property tab of the flow I can set them, and being the only promoted props in this sample they are in the default Basic group. But they don't show up on the BAR manage tab. (I tried other props, and verified that some others appear there.) |
Then if you're certain it's done correctly you should raise a PMR. This should work, and does work for me.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 03, 2011 2:01 pm Post subject: Re: Referencing message sets by their ID |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aerosoul wrote: |
| I may not have expressed myself the way I wanted, most of the time there should be only one version under development, but in production there will be multiple versions in the same EG, or at least I can not close this possibility out. |
So your production system uses multiple versions of the same record layouts (or XML documents) at the same time? Seriously? How do you keep track of which uses what?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 03, 2011 7:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| What I'd like to get to is to use SVN for managing Broker source code including msgsets, and to be able to use revision numbers in development, and version numbers just at the end of it. And because there could be multiple versions of the same msgset deployed on the same exec group I need to include the version number in the name, but I'd not like to do that in development phase. |
We solved this a little bit differently.
- Keep the "base" (non versioned) message set in SVN trunk and update it as needed for each version...
- Copy the "base" message set to a "versioned" message set in the toolkit.
- Remember to change the "alias" to a versioned alias.
- Reference the "versioned" message set in your project and Input nodes
- upload the "versioned" message set used in the build (and referenced in the flow) to the SVN tag.
- upload the "versioned" message flow, referencing the "versioned" message set into the SVN tag
- upload the bar file using the flow into the SVN tag
It's a little bit more work but it gives us the right version for both flow (naming convention like java package) and the right message set.
As this is involved with some additional work I won't say it is an ideal solution... but it got the job done for us...
Hope this helps some. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
