Does anyone have an example of an add-on which can itself consume a web hook and execute an API call? That is to say that the logic is self contained in the add-on and does not require a 3rd party server.
This unfortunately is not possible. By definition, a webhook requires a serviceable UI to ping ... that can then process the result. One suggestion might be to try out one of our JiveWorld16 hackathon sponsor's solution. Built.io Flow. It is a way to quickly stand-up an end-point that can be pinged by anything. It currently has some basic Jive connectors (with more on the way), but it also has lots of means to doing things yourself with custom Node.js code blocks.
Hope that helps, and long time no talk dude! =)
We routinely create Add-Ons that process webhooks and perform some business related function that does not rely on any information outside the connected community. Adding workflow around the automated processing of Ideas is an example. The Add-On backend receives the webhook calls, then only makes API calls to the connected Jive community. So, in a sense it is a closed system between Jive and the Add-On. A server is still required for the Add-On code to execute on.
Thank you both for your answers. My solution is already created, I was just looking for a way to negate that external need. Looks like that it not possible in this scenario.
For those who are interested. Here is an example of an add-on that does not have a need for middleware: Creating a Twitter Widget Custom View Tile with Configuration
It doesn't change the answers above regarding web hooks and api calls, but shows that with some help from outside services there is a way to create a tile that doesn't require your own middleware server.
Roguen is correct. As long as the Jive is the initiator and pulling data from multiple sources, there are a lot of options on the table. In some cases, such as Dev Tool: Simple Stream App with Bi-Directional Communication (3 of 3) ... we can get a 1x push of data from an external source and Jive can stitch together other calls to services through the apps framework. Building out these non-middleware options for some of these more straight forward use-cases in the platform has been a focus for us this past year and we'll be covering that and more in our JiveWorld16 Developer Conference next week =)
Retrieving data ...