Author |
Message
|
ganesh |
Posted: Mon Jun 13, 2011 11:33 am Post subject: version info- Message sets and jar's |
|
|
Master
Joined: 18 Jul 2010 Posts: 294
|
I am setting the perforce change list number of message flow by replacing the token in the compiled message flow using ant scripts.
Code: |
<replacefilter token="<version/>" value="<version value="$MQSI_VERSION=${serviceVersion}-${changelist} MQSI$" />"/> |
Has anyone been able to set version for message sets and jar files?[/quote] |
|
Back to top |
|
 |
ganesh |
Posted: Tue Jun 14, 2011 6:02 am Post subject: |
|
|
Master
Joined: 18 Jul 2010 Posts: 294
|
Has no one attempted to do this before? |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 14, 2011 6:11 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
ganesh wrote: |
Has no one attempted to do this before? |
Possibly not, though I do remember some discussions a while back on directly editing the flow.
It's more typical to change these values in the source prior to build rather than afterwards. Using ant and/or source control there are a number of ways to achieve this.
Do let us know how your method works out for you. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
ganesh |
Posted: Tue Jun 14, 2011 9:37 am Post subject: |
|
|
Master
Joined: 18 Jul 2010 Posts: 294
|
Code: |
ExecutionGroupProxy e = b.getExecutionGroupByName("default");
MessageFlowDependency mfd = e.getMessageFlowDependencyByName("a.jar");
|
Does getMessageFLowDependencyByName("") exist or not? The editor is throwing an error. I saw a old post regarding this -
http://mqseries.net/phpBB/viewtopic.php?t=45908&highlight=&sid=841be285e11379ce4c3eee2da53d3214
It says e.getDeployedObjectByName() will do what we want but this will help me get version number
Code: |
MessageFlowDependency mfd = e.getMessageFlowDependencyByName("a.jar");
mfd.getVersion();
|
|
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 14, 2011 9:59 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
ganesh wrote: |
Does getMessageFLowDependencyByName("") exist or not? The editor is throwing an error. |
In that post @mqmatt says it doesn't & he's in a position to know.
It does also strike me that this all a bit backwards; why are you trying to set version information and obtain dependancies from the compiled flow rather than from the source? How does doing this assist you in tracking deployed object back to source version?
As a minimum, you seem to be building a stick to beat yourself with.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
ganesh |
Posted: Tue Jun 14, 2011 10:34 am Post subject: |
|
|
Master
Joined: 18 Jul 2010 Posts: 294
|
Quote: |
It does also strike me that this all a bit backwards; |
We are trying to get information of objects after it is deployed to a execution group like - deployment time, version number, queues associated with it .... |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Jun 14, 2011 10:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
ganesh wrote: |
Quote: |
It does also strike me that this all a bit backwards; |
We are trying to get information of objects after it is deployed to a execution group like - deployment time, version number, queues associated with it .... |
So first, if you can't see this information in Message Broker Explorer or other official administrative views (you haven't said specifically what version of Broker you are using), then you won't be able to find it out using the Admin API (CMP API). And you should take the necessary steps up front to make the information you need available, by creating user defined properties or other such things in the tooling. And you shouldn't then try to read it out of the compiled message resources.
Secondly, you should be able to get all of the information you need by writing code that calls Admin API functions.
Thirdly, the post you reference is from early timeframes of version 6.1 CMP API. It's likely that the APIs have changed between then and version 7.
So you should refer to the existing current documentation for the Admin API to figure out what you need, and you should use the Admin API Exerciser (CMP API Exerciser) to show you what data is and is not actually available. The API Exerciser is the best tool available for figuring out how to read the data you want from the Admin API. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 14, 2011 10:42 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
ganesh wrote: |
Quote: |
It does also strike me that this all a bit backwards; |
We are trying to get information of objects after it is deployed to a execution group like - deployment time, version number, queues associated with it .... |
It still seems to me this would be easier the more "conventional" way - capturing it before build rather than after it. This may also be the answer to your question:
ganesh wrote: |
Has no one attempted to do this before? |
No, because everyone who has a requirement to capture this is doing it via build & source procedures.
So I repeat my earlier request for you to let us know how this goes for you.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
ganesh |
Posted: Tue Jun 14, 2011 10:55 am Post subject: |
|
|
Master
Joined: 18 Jul 2010 Posts: 294
|
Quote: |
It still seems to me this would be easier the more "conventional" way - capturing it before build rather than after it. So I repeat my earlier request for you to let us know how this goes for you. |
Version number - Yes can be obtained before deployment.
Dependencies - Yes can be obtained before deployment.
Deployment time - Can be obtained only after deployment.
So this is why i am trying to get all the three parameters after deployment instead of having 2 different process. |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Jun 14, 2011 10:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
You can technically acquire deployment time at the time of actual deployment, rather than necessarily waiting until after deployment.
But, again, the information you're looking for should be available through the Admin API, and you should use the Admin API Exerciser to discover where it is, then you can write code to get the same information. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 14, 2011 11:00 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
ganesh wrote: |
Version number - Yes can be obtained before deployment.
Dependencies - Yes can be obtained before deployment.
Deployment time - Can be obtained only after deployment.
So this is why i am trying to get all the three parameters after deployment instead of having 2 different process. |
If we take the model I've been refering to, the deployment is performed by the process that sets the version numbers, resolves the dependancies (by building the bar file) and deploys it (thereby capturing the deployment time).
I have at no time said that your method won't work, nor that your method doesn't meet your requirements. I'm just pointing out an alternative and proposing a theory why you got no responses to your original post. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
ganesh |
Posted: Tue Jun 14, 2011 11:24 am Post subject: |
|
|
Master
Joined: 18 Jul 2010 Posts: 294
|
Quote: |
I have at no time said that your method won't work, nor that your method doesn't meet your requirements |
I never took it that way, i am sorry if my post sent that signal to you.
Quote: |
If we take the model I've been refering to, the deployment is performed by the process that sets the version numbers, resolves the dependancies (by building the bar file) and deploys it (thereby capturing the deployment time).
|
In this i guess you are referring to the build process and capturing the timestamp the script runs, so deployment time = time when deployment was initiated by scripts. In my organization some of the bar files are deployed into all 20 execution groups of a broker , so the time of actual deployment into EG20 will be way different from the time when the script initiated deployment. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Jun 14, 2011 11:32 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
ganesh wrote: |
Quote: |
I have at no time said that your method won't work, nor that your method doesn't meet your requirements |
I never took it that way, i am sorry if my post sent that signal to you. |
Not at all, and indeed I was pre-empting any inadvertent signal on my part that I felt your method to be "wrong".
ganesh wrote: |
Quote: |
If we take the model I've been refering to, the deployment is performed by the process that sets the version numbers, resolves the dependancies (by building the bar file) and deploys it (thereby capturing the deployment time).
|
In this i guess you are referring to the build process and capturing the timestamp the script runs, so deployment time = time when deployment was initiated by scripts. In my organization some of the bar files are deployed into all 20 execution groups of a broker , so the time of actual deployment into EG20 will be way different from the time when the script initiated deployment. |
No, I was refering to the script recording the time a given deploy command was issued rather than capturing the time the script started. It really depends on the granularity you're looking for. Some sites in my experience are happy with "this release of the source was deployed on the 20th", others with "this release of the source was deployed on the afternoon of the 20th", others want to know the deploy time to the second, still others don't care when it was deployed as long as the version & MQSI tags match the source code repository. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
ganesh |
Posted: Mon Jun 20, 2011 6:13 am Post subject: |
|
|
Master
Joined: 18 Jul 2010 Posts: 294
|
|
Back to top |
|
 |
|