You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Nicola Ferraro (JIRA)" <ji...@apache.org> on 2019/04/15 09:02:00 UTC

[jira] [Resolved] (CAMEL-13401) Create a webhook meta-component

     [ https://issues.apache.org/jira/browse/CAMEL-13401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nicola Ferraro resolved CAMEL-13401.
------------------------------------
    Resolution: Fixed

> Create a webhook meta-component
> -------------------------------
>
>                 Key: CAMEL-13401
>                 URL: https://issues.apache.org/jira/browse/CAMEL-13401
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-core
>            Reporter: Nicola Ferraro
>            Assignee: Nicola Ferraro
>            Priority: Major
>             Fix For: 3.0.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> The intention is to create a meta-component that allows other components to define how they can configure themselves to create push-based consumers by remotely configuring a webhook.
> The way it's used is similar to the master component.
>  
> E.g.
> The following route starts from a Telegram polling consumer:
> {code:java}
> from("telegram:bots/token")
>   .to("log:info"){code}
>  
> By prepending the _webhook_ uri prefix, we literally _prepend a webhook listener_ to it:
> {code:java}
> from("webhook:telegram:bots/token")
>   .to("log:info"){code}
>  
> The role of the webhook meta-component is of:
>  * Exposing one or more endpoints using the rest consumer factory
>  * Running the delegate endpoint in webhook mode (each component defines the specific rules)
>  * Registering the webhook at the webhook provider site (specific per component, external URL configurable)
>  * Unregistering the webhook at the webhook provider site when it's no more necessary (specific per component)
> So, the meta-component sets up the infrastructure and orchestrates the workflow.
>  
> Registration/deregistration should be configurable:
>  * In standalone mode, the registration is done at route startup, the deregistration is done at route shutdown
>  * In Camel K mode, automatic registration is disabled by default, because the deployment can be scale up/down (especially in Knative mode, where this happens automatically):
>  ** Camel K will setup a webhook subscription resource that takes care of externally registering/deregistering the webhook when the integration is created/edited/deleted (will use the webhook component API for this)
>  
> With this meta-component, in Camel K + Knative mode, we can create integrations from telegram, slack, github, twitter, dropbox, .... that can scale down to 0 when not used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)