Skip to main content
Version: Current

Quickstart

A very concise Nussknacker terminology primer

In Nussknacker, scenario describes a decision algorithm i.e. how data records ingested into scenario should be processed and what actions should be performed. Scenarios are composed of nodes, which work with data records. Nodes can organize the flow, transform data carried in data records, bring additional data ("enrich"), call actions in external systems, etc.

Get oriented with the example scenario

Once you sign up to Nussknacker Cloud, scenario my-scenario will be created for you. It contains only three nodes: a source (HTTP Endpoint), Log Message and Aggregate Sliding.

my-scenario works in the streaming processing mode and processes streams of data. A HTTP Endpoint source exposes a http endpoint which can be used to insert events into the data stream processed by a scenario.

The numbers shown next to the nodes indicate how many data records each node has processed while the scenario was running. If you want to explore this functionality in more detail — including live monitoring, debugging, and testing — see the dedicated guide.

The scenario created at sign up to Nussknacker cloud. It works in the streaming [processing mode](/about/GLOSSARY.md#processing-mode) and processes streams of data. It contains three nodes: a HTTP Endpoint source, Log Message and Aggregate Sliding.

Scenario automatically created at sign up.

  1. Double click on the HTTP Endpoint node to see its configuration and information on how to insert a new event into the scenario.

    Note, the Content type and Data sample - because of these settings, Nussknacker will assume that events payload is in JSON format and that field name will be present in the input events.

  2. Close the HTTP Endpoint node details window.

  3. Double click the Logger node.

    Logger will log a message of your choice to the processing log - we will examine its content later on.

  4. Click the icon in the message parameter entry field to understand how the string template works. You can find more here.

    Take a look at the #input.toString expression. The #input variable contains the data carried in the input event ingested by the scenario. The toString method converts it to the string - the message parameter needs to be of type string.

  5. Close the HTTP Endpoint node.

  6. Double click the Aggregate Sliding node

    This node keeps each event in memory for the time specified in windowLength; the events are put into dedicated "buckets" (groups) for every different value of name field and counted within each group. Whenever an event arrives, the count is updated and the event is enriched with an updated count value. Note the name of the variable which will contain the count - we will use this variable soon. As there is no downstream node which would consume those events, we cannot see this value for now - we will address it soon.

  7. Close the Aggregate Sliding node details window.

Inspect live data records for a node

You should see the scenario graph now.

  1. Ensure that the scenario is running - deploy it if necessary. Also, ensure that Live Data functionality is activated - the Live Data icon should be green .

  2. Double click the the HTTP Endpoint node and decide how you want to insert events into the scenario. The simplest way is to click the Send Request button (do it more than once, if you want).
    Inspecting data records stops Live Data; re-enable Live Data once you are finished.

  3. Watch the output data records (called events in the streaming mode) shown in the right part of the node details window. Double click on the data record 'tile' to inspect data (variables) carried by the chosen event.

When data record inspection starts, the Live Data functionality is disabled. You can re-enable it once you are finished.
  1. Close the HTTP Endpoint node details window.

  2. Double click the Aggregate Sliding node. Next, double click any of the output data records in the right panel. Examine the data (variables) carried by the data record. Check content of the #aggregate_sliding_output_var variable - we will use it soon. This variable carries the result of the aggregation in the sliding window, the content of its "fields" was configured in the Aggregate Sliding node.

  3. Click the Admin button (top right corner) and choose Logs tab. You should see messages logged by the Logger node.

  4. Return to the scenario - click Open scenario link.

Modify the scenario

Let's add another Logger node to the scenario to log the result of the aggregation in the Aggregation Sliding node.

  1. Click the bottom dock of the Aggregate Sliding node; the Component Pallette will open. Scroll to Processors section and choose Logger - the new node will be automatically appended to the scenario.

  2. Double click the newly added Logger node.

  3. Enter the following text into the message field:

I have seen #{ #input.name }  #{ #aggregate_sliding_output_var.count } times in the last 60s 
The message field is of type string, the default expression type used is a string template. You do not need to use quotes as text delimiters. Also, although #aggregate_sliding_output_var.count is of type integer, Nussknacker silently converted it to string, to ensure that the expression evaluates to string.
  1. Close the Logger node details window.

  2. Save the scenario by pressing the Save button.

  3. Deploy scenario by pressing the Deploy button.

Observe the newly added Logger node

  1. Ensure that the scenario is running - deploy it if necessary. Also, ensure that Live Data functionality is activated - the Live Data icon should be green.

  2. Insert one or more events into the scenario - do it in same way as before.

  3. Double click the newly added Logger node to inspect data records live.

  4. Go to the Admin Panel, Logs tab to check messages logged by the scenario.

Try a small challenge

The text I have seen Hannah 1 times in the last 60s does not sound correct in English. Your task is to improve the scenario so that message handles singular and plural form correctly.

You can do it in two ways. In the first method you add an IF-ELSE logic in the form of an additional node - in Nussknacker this would be a filter - it can have true and false outgoing branches. Next, you will have to merge both branches or have a dedicated Logger node in each of the branches.
The alternative is to use conditional processing
conditionExpression ? expressionIfTrue : expressionIfFalse
to compute text value in the message field. In this case you may find that using a SpEL expression may be easier than using a string template expression (opinions vary).