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 » Need help in ConfigmanagerproxyAPI and mqsireportproperties

Post new topic  Reply to topic Goto page 1, 2  Next
 Need help in ConfigmanagerproxyAPI and mqsireportproperties « View previous topic :: View next topic » 
Author Message
talk2shelly
PostPosted: Thu Aug 05, 2010 2:24 am    Post subject: Need help in ConfigmanagerproxyAPI and mqsireportproperties Reply with quote

Newbie

Joined: 05 Aug 2010
Posts: 3

With the help of mqsireportproperties command I can see the contents of esql file.

Same thing I want to achieve with the help of configmanagerproxyAPI but not getting any clue how to do it.

I tried most of the available features provided by proxy API.


Thanks in Advance to guide me to the solution !
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Thu Aug 05, 2010 9:43 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

Hi Shelly,

Give this a try and see if it works for you:

Code:


BrokerProxy b = BrokerProxy.getLocalInstance();
ExecutionGroupProxy e = b.getExecutionGroupByName(this.getExecutionGroup().getName());
String egUuid = e.getProperty("uuid");  // ExecutionGroup UUID.
DeployedObject xfs = e.getDeployedObjectByName("WhateverFile_youWant_toSee.esql");


  if( xfs != null ){
       
    String envMQSIWorkpath = System.getenv("MQSI_WORKPATH");
       
    if( envMQSIWorkpath != null ){
           
      // Change "config/XML" to the directory you want.
      String file = envMQSIWorkpath+"/components/"+getBroker().getName()+"/"+egUuid+"/config/XML/"+"WhateverFile_youWant_toSee.esql";
           
      try {
               
        BufferedReader input =  new BufferedReader(new FileReader( file ));
           
      } catch (IOException ex){}

    }



Lance
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
talk2shelly
PostPosted: Fri Aug 06, 2010 2:23 am    Post subject: Reply with quote

Newbie

Joined: 05 Aug 2010
Posts: 3

Thanks for your reply !

but in that location there are no esql or cmf files.
I am unable to understand where does this files being kept by BROKER after deployment.
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Fri Aug 06, 2010 3:53 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

If you try to help the chick emerge from it's shell, you greatly endanger it's life, because it does not build the necessary muscle mass needed to live.

Some things you need to figure out for yourself. As Pooh Bear says while poking at his head, "think, think, think, think."


HOW THE CHICK EMERGES FROM THE SHELL

The head of the chick develops at the large end of the egg. Between the 15th and 16th days, the chick orients itself so that its head is near the air cell at the large end of the egg. Not long before the chick is ready to attempt to make its way out of the shell its neck acquires a double bend so that its beak is under its right wing and pointed toward the air cell. About the 19th day the chick thrusts its head forward. Its beak quickly breaks through the inner shell membrane, and the chick's lungs begin to function. Complete breathing by the lungs usually does not occur until the 20th day of incubation.

Using its egg tooth (a tiny, sharp, horny projection on the end of its beak), the chick pecks at the shell thousands of times. Finally, the young bird pips its way through the shell and begins to breathe air directly from the outside. After the chick has made a hole in the shell, it stops pipping for three to eight hours and rests. During this time, it is acclimating its lungs to the outside atmosphere. After the resting stage is completed, the second stage of pipping begins.

The chick begins to turn slowly inside the egg. As it turns, usually counter-clockwise, the cutting edge of the chick tooth continues to chip away. In two to five hours, the chick has made about three quarters of a turn inside the egg. As the chick progresses in its movement around the shell, it begins pushing on the egg cap (large end). Squirming and struggling, the chick works feverishly for about 40 minutes pushing at the cap. Finally with a vigorous shove, the chick breaks free from the shell, still wet and panting.

When the chick is freed completely from the shell, it lies still. Its energy has been virtually exhausted, and it is extremely tired. After a rest of some few minutes, the chick begins to rise to its feet and gain coordination of its muscles. Within a few days the egg tooth, its usefulness over, will disappear.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Fri Aug 06, 2010 4:34 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

talk2shelly wrote:
Thanks for your reply !

but in that location there are no esql or cmf files.
I am unable to understand where does this files being kept by BROKER after deployment.


You are taking entirely the wrong approach.

You should not in the slightest be trying to preserve or inquire after deployed artifacts.

You *should* be backing up your broker, just to cover bases in case you need to roll back a disasterous change.

BUT, that has nothing to do with maintaining deployed resources.

You should be sticking ALL of your Message Flows and Message Sets and JavaCompute and other developmental artifacts into change control, and maintaining a copy of ESQL and source there.

You should also be sticking all of your JAR files and BAR files and other administrative artifacts into change control, and maintaining a copy of them there.

You SHOULD NOT be developing a process to recover either of these types of artifacts from a deployed system, regardless of the nature of the system and TWICE AS MUCH not from Broker.
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Fri Aug 06, 2010 5:36 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

@mqjeff

A valid reason to read a deployed resource would be to determine what version exists in that instance.

I agree with you that an adminstrator should not try to modify internal resources once a bar file has been deployed.

There are valid reasons to perform the task of reading a file. I re-read the original post, and did not see where Shelly was going to try to backup her broker? Maybe you saw something I did not?

In any event, a potential feature request would be to have the Broker produce MD5 or similar checksums to compare deployed artifacts against a source repository.

In my environment, we have three dev Broker instances, two QA Broker instances, one performance test Broker instance, and four Prod Brokers. With all those, sometimes we loose track of what version of Bar file is deployed where. We have six execution groups, each with difference Bars in them on each instance. If I wanted to verify a certain source code change was on a certain Broker, it's a manual process. Adding a feature to MQ Explorer or Toolkit interface to display checksum and compare against checksum for same source on my laptop would be a good thing. Until then, one must write custom code to do so.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Fri Aug 06, 2010 5:41 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

lancelotlinc wrote:
@mqjeff

A valid reason to read a deployed resource would be to determine what version exists in that instance.


Yes.

This is done by examining the properties of the message flow through the CMP API, not by trying to read the compiled ESQL.

Even if one does need to read the compiled ESQL (and there remains no valid reason for doing so, if one has properly managed change), Shelly has already been able to do that by using mqsireportproperties. So any reason that exists for reading the compiled ESQL has already been accomplished.

Ergo, any need to read the compiled ESQL from a CMP API script is twice as questionable as the need to read compiled ESQL in the first place.
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Fri Aug 06, 2010 5:54 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

Another valid reason to want to read a deployed resource is when setting up a Singleton or other static object. Sometimes you want to read a config file that had been included in the Bar as a resource.

It's Friday! Relax. Have an Irish tea.

As great as WebSphere Message Broker is, there are still things that it lacks. Build engineering, deployment management, and object caching are some areas that could stand additional features and product improvement. WMB has come along way since IBM acquired it. The best part about this forum is the ability to describe features that users want and have other users comment on them so the Product Roadmap could one day reflect the desires of the user community rather than the guesses of the marketing department.

Would you agree that meeting users' needs through a more finely tuned product roadmap would be better than limiting the roadmap direction to just market-driven dynamics?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Fri Aug 06, 2010 5:59 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

lancelotlinc wrote:
In my environment, we have three dev Broker instances, two QA Broker instances, one performance test Broker instance, and four Prod Brokers. With all those, sometimes we loose track of what version of Bar file is deployed where. We have six execution groups, each with difference Bars in them on each instance. If I wanted to verify a certain source code change was on a certain Broker, it's a manual process.


It's potentially automatable with existing WMB features. That's also not an especially large or complex estate you're managing there.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Aug 06, 2010 6:06 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

lancelotlinc wrote:
Would you agree that meeting users' needs through a more finely tuned product roadmap would be better than limiting the roadmap direction to just market-driven dynamics?




IMHO there's a difference between meeting user's needs and adding additional features to fill gaps in process or understanding. If the output in question wasn't a flow but compiled C or COBOL code this discussion wouldn't be happening because it's accepted that getting usable source out of these compiled objects is like getting flour back out of a cake.

This is not to say that methods are not needed to determine which compiled object matches which source version are not essential but these methods exist and are surprisingly similar to those which are best practice for controling broker flows for obvious reasons.

Remember that when my most worthy associate talks about examining the properties of the flow, those properties are user extendable.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Fri Aug 06, 2010 6:32 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

Indirectly, the user community is expressing a need to have better automation and control in deployment processes. (Just look at the various threads in this forum around this general topic area.)

Ant + CruiseControl is a great solution. Better Ant support from Toolkit would go along way to helping the user community.

For instance, a WMB-Ant wizard that is similar to the Prepare tab on Broker Archives members of projects and generates an Ant script that promotes clean builds for Continuous Integration.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Fri Aug 06, 2010 6:46 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

lancelotlinc wrote:
Indirectly, the user community is expressing a need to have better automation and control in deployment processes.


A view I've been expressing directly for some decades now. It's comforting to have some support finally.

lancelotlinc wrote:
Ant + CruiseControl is a great solution.


Ant + anything is a great solution. I've had good results with an Ant script running inside Hudson.

lancelotlinc wrote:
For instance, a WMB-Ant wizard that is similar to the Prepare tab on Broker Archives members of projects and generates an Ant script that promotes clean builds for Continuous Integration.


I look forward to adding my support to your enhacement request.

But to get back on topic (or closer to it) this is still dealing with the problem from the perspective of source control rather than reverse engineering the position from the deployed object.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Fri Aug 06, 2010 6:53 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

I'm not understanding where the conclusion comes from, that because someone wants to read a file, they are trying to reverse engineer the source?

There are valid reasons, other than reverse engineering, to want to read a file in the contents of the deployed Broker archive.

I include xml files in my Broker archives that help me configure at runtime the behaviour of some static objects. I want to read these files at object initialization time (the first message through, not subsequent messages). This helps me set certain things that would be messy if UDP. I can also have separate settings for dev env or prod env.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Fri Aug 06, 2010 7:24 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

lancelotlinc wrote:
I'm not understanding where the conclusion comes from, that because someone wants to read a file, they are trying to reverse engineer the source?


My conclusion is based on the original post:

talk2shelly wrote:
With the help of mqsireportproperties command I can see the contents of esql file.

Same thing I want to achieve with the help of configmanagerproxyAPI but not getting any clue how to do it.


From this I conluded the OP was trying to access the source in the ESQL file.


lancelotlinc wrote:
I want to read these files at object initialization time (the first message through, not subsequent messages). This helps me set certain things that would be messy if UDP.


You'd get a trout from me. I seriously dislike such things, especially the "first time does something different" design model.

lancelotlinc wrote:
I can also have separate settings for dev env or prod env.


Which you can achieve with UDP.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Fri Aug 06, 2010 7:31 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

At our present CMMI maturity level, UDPs depend on human intervention to override them. Our team really needs a dedicated Build Engineer to manage this process. If we had that resource, we could automate alot of things, including Bar file overrides. Then UDPs make sense.

I hope one day our team is able to achieve CMMI level 2. One can only dream.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Need help in ConfigmanagerproxyAPI and mqsireportproperties
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.