HTTP Callback

Description

HTTP Callback allow to pass the 'decisions' taken by the Nussknacker scenarios (or simply results) to systems which do not have a streaming ingestion mechanism. With HTTP Callback sink, the external system can expose a HTTP endpoint, which will be called for each event entering the HTTP Callback node.

Parameters and configuration

Name	Description
URL	Address of the external system endpoint the callback requests are sent to. It is a SpEL template evaluated when the scenario is deployed, so it cannot read values from the processed event (e.g. #input).
Content type	JSON - Nussknacker will validate whether the specified message body is a valid JSON. If PLAIN no validation is performed.
Body	Payload sent with the callback request, in the format chosen in Content type. With JSON you can use the JSON template editor or a SpEL expression; with PLAIN the expression must evaluate to a String. Left empty with PLAIN, no callback request is sent for that event; with JSON, the payload is a literal null.

The following parameters are in the Advanced section of the node:

Name	Type	Default	Description
Headers	Map	{:}	HTTP headers sent with the callback request, as a map of header name to value, e.g. {"X-Correlation-Id": #input.id}. Evaluated for each event. Entries with a null name or value are skipped.
Rate limit (messages/second)	Integer	100	Caps the number of callback requests this node sends per second, across all events it processes.
Sending delay (milliseconds)	Integer	0	Delay applied before each callback request is sent.
Message TTL (seconds)	Integer	3600	Time after which an undelivered callback message is dropped.
Retry on 4xx status	Boolean	false	When enabled, delivery is retried after a 4xx response as well, not only after a server-side failure.
Retry backoff (milliseconds)	Integer	1000	The wait before the first delivery retry.
Retry backoff multiplier	Double	1.0	Factor the wait is multiplied by after each failed retry. A value of 1 keeps the wait constant; above 1 it grows exponentially.
Retry backoff maximal interval (seconds)	Integer	600	Upper bound on the wait between delivery retries.

How it works

The node does not call the endpoint directly from the scenario. Each event is written to an internal Kafka topic (named callback-<scenario name>-<node id>), and a delivery service subscribed to that topic (the subscription is registered when the scenario is deployed) sends the HTTP requests, applying the rate limit, delay, TTL and retry settings above. Because of that, a slow or failing endpoint does not slow down the scenario itself.

Example

To notify an external system about a fraud decision:

• URL: https://alerts.example.com/api/decisions
• Content type: JSON
• Body:

  {
    "transactionId": #input.transactionId,
    "decision": #decision,
    "score": #score
  }
• Headers: {"X-Correlation-Id": #input.transactionId}