ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » version info- Message sets and jar's

Post new topic  Reply to topic
 version info- Message sets and jar's « View previous topic :: View next topic » 
Author Message
ganesh
PostPosted: Mon Jun 13, 2011 11:33 am    Post subject: version info- Message sets and jar's Reply with quote

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="&lt;version/&gt;" value="&lt;version value=&quot;$MQSI_VERSION=${serviceVersion}-${changelist} MQSI$&quot; /&gt;"/>


Has anyone been able to set version for message sets and jar files?[/quote]
Back to top
View user's profile Send private message
ganesh
PostPosted: Tue Jun 14, 2011 6:02 am    Post subject: Reply with quote

Master

Joined: 18 Jul 2010
Posts: 294

Has no one attempted to do this before?
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Jun 14, 2011 6:11 am    Post subject: Reply with quote

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
View user's profile Send private message
ganesh
PostPosted: Tue Jun 14, 2011 9:37 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Jun 14, 2011 9:59 am    Post subject: Reply with quote

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
View user's profile Send private message
ganesh
PostPosted: Tue Jun 14, 2011 10:34 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Tue Jun 14, 2011 10:42 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Jun 14, 2011 10:42 am    Post subject: Reply with quote

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
View user's profile Send private message
ganesh
PostPosted: Tue Jun 14, 2011 10:55 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Tue Jun 14, 2011 10:57 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Jun 14, 2011 11:00 am    Post subject: Reply with quote

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
View user's profile Send private message
ganesh
PostPosted: Tue Jun 14, 2011 11:24 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue Jun 14, 2011 11:32 am    Post subject: Reply with quote

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
View user's profile Send private message
ganesh
PostPosted: Mon Jun 20, 2011 6:13 am    Post subject: Reply with quote

Master

Joined: 18 Jul 2010
Posts: 294

For message sets i introduced a token for the version property in the toolkit and replaced the token in the dictionary file during the build. For jar files i followed the IBM link and was able to do it.
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp?topic=/com.ibm.iea.wmb_v6/wmb/6.0/Configuration/ConfigVersions/player.html
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » version info- Message sets and jar's
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.