| Author |
Message
|
| akil |
 Posted: Tue Mar 29, 2016 7:10 am Post subject: IIB9: CMP API, IBM Events |
 |
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
Hi
We on the LINUX machine, where we've configured the syslog to log the events from the broker to a text file https://www.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.etools.mft.doc/an04230_.htm?lang=en
This is useful to track the progress of a deployment via mqsideploy & a restart of an execution group & many other things.
I am however unable to figure out how to get access to these from the CMP API . Is there a way to subscribe to these events from the CMP API?
None of the following seem to get the events that are coming via syslog :
# registerListener at the EG
# getDeployResponses
# getActivityLog
Is access to this possible via the CMP API ?
_________________
Regards |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Mar 29, 2016 9:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The items being put to syslog are not events. They're log entries.
There are all kinds of things you can use to read and react to log entries.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| akil |
| Posted: Tue Mar 29, 2016 9:29 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
Do you mean within the cmp or outside of the cmp?
Any suggestions?
_________________
Regards |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 29, 2016 10:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| akil wrote: |
| Do you mean within the cmp or outside of the cmp? |
Outside the CMP. As my most worthy associate correctly points out, these are log entries not events.
| akil wrote: |
| Any suggestions? |
Any monitoring tool capable of log scraping can do this. I'll mention SPLUNK as an example, but I'll bet you have something on site already capable of this in your monitoring stack.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| akil |
| Posted: Tue Mar 29, 2016 10:29 pm Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
We were attempting to use the CMP API to do a deployment, and also report progress, but from what you are saying, it does not look to be feasible - right?
I mean the API sample suggests introspecting the DeployResult (but that's not updated once the call returns ) , so one just blocks on the API ,and has to then look at the 'log entries' via an external tool ?
Even registering to the monitoring event, does not seem to give any update (like you said it is possibly because these are not events but log entries)..
_________________
Regards |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 30, 2016 4:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| akil wrote: |
| We were attempting to use the CMP API to do a deployment, and also report progress, but from what you are saying, it does not look to be feasible - right? |
It's not a natural use of the CMP in my view.
Don't forget that if you've got a lot of deploy requests (or you're deploying a really big bar file) then the deployment can take a significant period of time to complete. So you're better off looking for the "deploy successful" / "deploy failed" in the log rather than polling for a status.
And there's no functional difference between subscribing to an event and waiting for a log entry to go past.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 30, 2016 5:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The CMP API will return something that tells you whether the deploy succeeded or not.
It may return information about why. The log may contain additional information.
There's nothing that prevents you from using any number of things that store log entries, and can provide a query interface, so you can retrieve log entries from your program after the CMP API call has been made.
Logstash probably does this.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| akil |
| Posted: Wed Mar 30, 2016 7:42 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
It would be nice if the deploy command would also a listener to be registered , where the progress could be reported.. Would have saved a workaround to go via the log files ..
_________________
Regards |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 30, 2016 8:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| akil wrote: |
| It would be nice if the deploy command would also a listener to be registered , where the progress could be reported.. Would have saved a workaround to go via the log files .. |
That would require that the broker maintain a read handle on the log file, and some kind of in-memory cache.
Again, these are log entries, not events. They're entirely outside the function of the CMP Api. It's job is to send commands to the broker and report the status of those commands - success or failure. Not potentially unrelated log entries.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| bobbee |
| Posted: Wed Jun 14, 2017 2:08 pm Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 541
Location: Tampa
|
| I look at the console in the Toolkit and it displays certin information regarding the deploy. Can you get this information using the API. The client has a requirement for Auditing and would like to see User, Flow, etc logged. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 14, 2017 7:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Deployment is a state change. Did you look at the state / status messages being published by the broker? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bobbee |
| Posted: Thu Jun 15, 2017 2:20 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 541
Location: Tampa
|
yes, I set these two up. the 'status' message has almost noting in it except the UUID of the Broker and EG. The 'congiguration' looked more promising but lacked the USER ID that requested the build. This does show up in the Toolkit Console. If I had that and the 'configuration' message I think i will be fine. I am looking into the API DeployBAR java routine and seeing what is hidden in:
| Code: |
System.out.println("Result = "+deployResult.getCompletionCode());
// You may like to improve this application by querying
// the deployResult for more information, particularly if
// deployResult.getCompletionCode() == CompletionCodeType.failure.
|
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 15, 2017 2:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| bobbee wrote: |
yes, I set these two up. the 'status' message has almost noting in it except the UUID of the Broker and EG. The 'congiguration' looked more promising but lacked the USER ID that requested the build. This does show up in the Toolkit Console. If I had that and the 'configuration' message I think i will be fine. I am looking into the API DeployBAR java routine and seeing what is hidden in:
| Code: |
System.out.println("Result = "+deployResult.getCompletionCode());
// You may like to improve this application by querying
// the deployResult for more information, particularly if
// deployResult.getCompletionCode() == CompletionCodeType.failure.
|
|
Bobee, I am confused here.
How is the user that requested the build of any relevance to the userid that performed it or deployed it? Or even to the userid that put the bar file into the deployable directory?
I think what you are looking for here is some automation that would upon requesting a build create the entry in a DB of who requested the build, and update the build with build result and deployment result. The same DB should probably also record who requested the deployment of said build.
Typically in bigger shops the requester and the userid doing the build may be quite different as the build can be automated.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bobbee |
| Posted: Thu Jun 15, 2017 2:45 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 541
Location: Tampa
|
Couple of things here and sorry for the confusion.
First, I want to see if I can get to the messages that say the 'who'. I can see the 'what' and 'when'.
I do have automation. I took the ANT SCRIPT Deploy Support pack and worked on it till it was actually running. I have that in place and you can right click on a build in Rational Team Concert and it works like a charm. Instead of mqsideploy I was thinking of changing it to use my modified DeployBar.java code (there is actually a script that comes with this) and have it capture the details. So anyone who uses the RTC Build approach will have the details captured to a AUDIT log.
I have not gotten to thinking about this yet but, in the customers Development environment, they are sticking to the Toolkit build and deploy. This may change because of the strict AUDIT requirements by SO and Security team at the client. If not, The end game is to consider trapping the messages generated when a Deploy is done from Toolkit. So I would need the 'what', 'When' and 'who'. This as one would assume id a finger pointing requirement, so the 'who' is a must'.
Do a deploy in Toolkit, Look at your DEPLOY result in the console. There is a twistie on that line. If you expand, there is alot of data in there and on my v9.0.0.6 it has a message, in my case, because in our sandbox that id is in the channel, that 'mqm' requested the deploy.
In the description of the java method, it sez that the return from the get deployment messages is an enumeration of all the messages. I am thinking this is there. But I have to modify the sample to display the rest of the messages.
Sorry for the length of this message. Too early for this much!!! |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jun 15, 2017 3:02 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
I agree that the CMP API should provide more info on deployment success.
Without it, it's very hard to build reliable automation and that includes using Urban Deploy.
Coding RYO scripts defeats the object of using products like UrbanCode Deploy.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
