Closed DavidBoike closed 10 years ago
I like it
Sent from my iPhone
On 19 feb 2014, at 15:44, David Boike notifications@github.com wrote:
@dannycohen and I were discussing the integration story for ServiceControl with other reporting services and he mentioned that special plugins for popular packages (SCOM, Nagios, New Relic, etc) were likely. While this is all good, you can never please everybody unless you provide a generic way to theoretically integrate with anything. I think web hooks (with a corresponding editor in ServicePulse perhaps) could fit that bill.
Basically when certain events occur, a JSON payload would be POSTed to a URI of the customer's choosing. You can recommend they use something like http://requestb.in/ to debug.
I've seen this work very well for Fog Creek with their Kiln source control project. When you push commits, they have pre-built hooks for popular stuff (HipChat, TeamCity, Campfire) but then you can do custom hooks. I used it to post to one of my servers, which relayed an NServiceBus command, which eventually triggered project builds on my behind-the-firewall Jenkins server.
The beauty is really if the web hook service can be made generic enough (replaceable JSON payload templates, etc.) then even if not all that functionality is exposed to the editing UI, more specialized plugins can be more easily made by inheriting from the web hooks components.
— Reply to this email directly or view it on GitHub.
I've done this before with HipChat and is awesome for iPhone/Android when your out of office.
@dannycohen @andreasohlund is this something we want to implement for 1.1?
@johnsimons - +1. (would be good to flesh out the details of the proposed implementation, e.g. config options, webhook parameters, async etc.)
+1
This opens up alot of integration scenarios!
On Wed, Apr 23, 2014 at 10:47 AM, Danny Cohen notifications@github.comwrote:
@johnsimons https://github.com/johnsimons - +1. (would be good to flesh out the details of the proposed implementation, e.g. config options, webhook parameters, async etc.)
Reply to this email directly or view it on GitHubhttps://github.com/Particular/ServiceControl/issues/242#issuecomment-41137936 .
:+1:
I like it a lot!
Still think the option of subscribing to events is another nice feature #337
Still think the option of subscribing to events is another nice feature
Yes, WebHooks will give you that feature
I guess the one caveat of web hooks is durability (if my web endpoint is down)?
Or we will need a feature that will store and retry in case of failure?
yes there is no queuing, but we are talking about real time monitoring so queuing notifications is really not a requirement as far as I can tell
Closing - This is now been raised in requirements which spawned issue #359
@dannycohen and I were discussing the integration story for ServiceControl with other reporting services and he mentioned that special plugins for popular packages (SCOM, Nagios, New Relic, etc) were likely. While this is all good, you can never please everybody unless you provide a generic way to theoretically integrate with anything. I think web hooks (with a corresponding editor in ServicePulse perhaps) could fit that bill.
Basically when certain events occur, a JSON payload would be POSTed to a URI of the customer's choosing. You can recommend they use something like http://requestb.in/ to debug.
I've seen this work very well for Fog Creek with their Kiln source control project. When you push commits, they have pre-built hooks for popular stuff (HipChat, TeamCity, Campfire) but then you can do custom hooks. I used it to post to one of my servers, which relayed an NServiceBus command, which eventually triggered project builds on my behind-the-firewall Jenkins server.
The beauty is really if the web hook service can be made generic enough (replaceable JSON payload templates, etc.) then even if not all that functionality is exposed to the editing UI, more specialized plugins can be more easily made by inheriting from the web hooks components.