As you may or may not know, I've created an integration between Jive and Marketo that uses WebHooks, and I see tons of value with just that piece of the integration. However, we are nearly 6 months into our integration, and as we start to add more and more uses of WebHooks, we are finding that the rigidity in configuration is sending us down a path where there is a foreseeable management problem.
Currently, a WebHook is defined as a distinct Server Call (such ://host/context/resource?parameter=values…) rather than a distinct resource ( ://host/context/resource ) … This means that in the event I want to call the same WebHook service with different parameters, I have to setup completely new WebHooks. For things like integrating with VEvent, where we need to pass in new Ids each time a new event comes up…this means a constant creation of new one-off WebHooks that rarely gets deleted.
To help with this, I propose the following model be setup:
1.) Create an independent "Host Record" responsible for (://username:password@host) information (this will keep users from having to copy/paste service credentials over and over again, and should those credentials change…it makes it one place to do it.
2.) Alter the WebHook structure such that it has a "Host Record" as a child attribute and store (/content/resource/parameters names) as the WebHook. Basically setting up the skeleton of the WebHook call.
3.) Create a "Templated Parameter Values" Construct, that can store sets of Parameter Values for a specific WebHook. Values may be 1234,ABC,xsd13 in the set, but providing a pretty name like "Welcome Email" to provide context to what they mean will help people select them from a drop down. This allows the business is isolate business rules to a series of Named sets … such that the WebHook Flow reads…Call WebHook "Send Jive Notification" with Parameter Set: "Welcome to Jive"
What's the Flow Like, beginning to End?
The difference? In the current paradigm we have 5 (soon to be 6-7) endpoints for WebHooks. These are written to be very generic and rely on parameters to control their behavior. In configuring our needs (we are just getting started) we are using only 4 of the WebHooks End-Points and we have nearly 40 WebHooks defined. In this new structure, it would be 1 Host Record … 4 WebHooks … and 2-8 "templates" per WebHook. This makes a huge difference in maintenance, and the end-user experience when calling a web hook in a flow step.
That's all I had for now, but definitely wanted to get that out of my head.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.