SpEL Cheat Sheet
Expressions and types
Expressions used in Nussknacker are primarily written using SpEL (Spring Expression language) - simple, yet powerful expression language. SpEL is based on Java (reference documentation), but no prior Java knowledge is needed to use it.
The easiest way to learn SpEL is looking at examples which are further down this page. Some attention should be paid to data types, described in more detail in the next section, as depending on the context in which data are processed or displayed, different data type schemes are in use.
Check out SpEL overview for the overview of how SpEL is used by Nussknacker.
Data types and structures
The data types are used primarily for:
- validation - e.g. to detect attempt to use incorrect data type, for example numeric field instead of a string, or checking if field used in expression exists at all.
- code completion - suggestions appearing in UI when editing expressions.
Types of events in the Kafka streams or data returned by enrichers can be often discovered from some sort of schema registry, for example Confluent Schema Registry, SQL table schema or description of REST API. Nussknacker can also infer types of variables defined by user.
The data types used in the execution engine, SpEL expressions and data structures are Java based. These are also the data type names that appear in code completion hints. In most cases Nussknacker can automatically convert between Java data types and JSON and AVRO formats. JSON will be used for REST API enrichers, while AVRO should be first choice for format of Kafka messages.
Below is the list of the most common data types. In Java types column package names are omitted for brevity,
they are usually java.lang
(primitives), java.util
(List, Map) and java.time
Basic (primitive data types)
Java type | Comment |
---|---|
null | |
String | UTF-8 |
Boolean | |
Integer | 32bit |
Long | 64bit |
Float | single precision |
Double | double precision |
BigDecimal | enable computation without rounding errors |
UUID | uuid |
More information about how to declare each type in Avro you can find in Avro ducumentation, especially about Avro logical types.
Records/objects/maps
In Nussknacker, the following data types share common processing characteristics:
object
in JSONrecord
ormap
in AvroMap
and POJO in Java
In many cases Nussknacker can convert between them automatically.
For the user, the most significant difference is (using Avro terminology)
between record
and map
. Both can describe following JSON structure:
input = { name: 'John', surname: 'Doe'}
The main difference is that in case of record
Nussknacker "knows" which fields (name
and surname
)
are available and suggests and validates fields and their types.
For example, #input.name
is valid, while #input.noname
or #input.name > 0
as field name or type do not match.
On the other hand, map
describes "generic" structure - Nussknacker tacitly assumes it can contain any field, but only of certain type (e.g. we can have a "map of Strings", "map of Integers" etc. If this type is Unknown
the values might be of any type).
Nussknacker usually infers structure of record from external source (e.g. AVRO schema), but it can also detect it from map literals.
Arrays/lists
In Nussknacker (e.g. in code completion) JSON / Avro arrays are refered to as Lists
;
also in some context Collection
can be met (it's Java API for handling lists, sets etc.).
Handling date/time.
Date/time data types
Formats of date/time are pretty complex - especially in Java. There are basically three ways of storing date:
- as timestamp - absolute value, number of milliseconds since 1970-01-01T00:00:00 UTC. In Nussknacker this is
usually seen as
Instant
orLong
. This format is handy for storing/sending values, a bit problematic when it comes to computations like adding a month or extracting date. - as date/time without timezone information (this is usually handy if your system is in one timezone).
Converting to timestamp is done using Nussknacker server timezone.
In Nussknacker they are usually represented as
LocalDate
andLocalDateTime
. Suitable for date computations like adding a month or extracting date. - as date/time with stored timezone. In Nussknacker usually seen as
ZonedDateTime
. Suitable for date computations like adding a month or extracting date. - as date/time with stored time offset. In Nussknacker usually seen as
OffsetDateTime
. Contrary toZonedDateTime
doesn't handle daylight saving time. Quite often used to hold timestamp with additional information showing what was the local date/time from "user perspective"
Conversions between date/time types
Conversions of different types of dates are handled either by
#DATE
helper methods e.g.:#DATE.toEpochMilli(#zondeDate)
- methods on some types of objects, e.g.
#instantObj.toEpochMilli
returns timestamp for#instantObj
of typeInstant
#localDate.atStartOfDay()
- returnsLocalDateTime
at midnight for#localDate
of typeLocalDate
#localDateTime.toLocalDate
- truncates to date for#localDateTime
of typeLocalDateTime
#zonedDate.toInstant
- convertsZonedDateTime
toInstant
#instant.atZone('Europe/Paris')
- convertsZonedDateTime
toInstant
#instant.atOffset('+01:00')
- convertsOffsetDateTime
toInstant
- automatically by implicit conversion mechanism e.g.
#instant.atZone('Europe/Paris')
-Europe/Paris
String was automatically converted toZonedId
#instant.atOffset('+01:00')
-+01:00
String was automatically converted toZonedId
#time.isAfter('09:00')
-09:00
String was automatically converted toLocalTime
#date.isBefore('2020-07-01')
-2020-07-01
String was automatically converted toLocalDate
#dateTime.isAfter('2020-05-01T11:00:00')
-2020-05-01T11:00:00
String was automatically converted toLocalDateTime
Date/time utility methods
DATE
helper contains also some other useful helper methods, mainly for date range checks and computations of periods and durations e.g.:
#DATE.isBetween(#localTime, '09:00', '17:00')
- checks ifLocalTime
is in (inclusive) range<09:00, 17:00>
#DATE.isBetween(#dayOfWeek, #DATE.MONDAY, #DATE.FRIDAY)
- checks ifDayOfWeek
is in (inclusive) range<MONDAY, FRIDAY>
#DATE.isBetween(#localDate, '2020-06-01', '2020-07-01')
- checks ifLocalDate
is in (inclusive) range<2020-06-01, 2020-07-01>
#DATE.isBetween(#localDateTime, '2020-06-01T11:00:00', '2020-07-01T11:00:00')
- checks ifLocalDateTime
is in (inclusive) range<2020-06-01T11:00:00, 2020-07-01T11:00:00>
#DATE.periodBetween(#from, #to).getMonths
- computesPeriod
betweenfrom
andto
and return number of full months between those two dates#DATE.durationBetween(#from, #to).toDays
- computesDuration
betweenfrom
andto
and return number of full days between those two dates. Keep in mind thatDuration
is not daylight saving time aware - it computes seconds difference and divide it by number of seconds in given period.- In case of days it will be
86400
seconds.
Some useful constants are also available:
#DATE.MONDAY
,#DATE.TUESDAY
, ... - day of weeks#DATE.JANUARY
,#DATE.FEBRUARY
, ... - months#DATE.zuluTimeZone
- Zulu timezone which always has time zone offset equals to UTC#DATE.UTCOffset
- UTC offset#DATE.defaultTimeZone
- Default time zone for Nussknacker application
Parsing of date/time
Also, #DATE_FORMAT
helper methods can be used to parse or format certain data type from/to the String. It is not recommended to use parsing
in scenarios because it will obfuscate logic. Better way is to configure properly message schema. But sometimes it is the only way to handle it. Available helpers:
#DATE_FORMAT.parseOffsetDateTime('2020-01-01T11:12:13+01:00')
- parseOffsetDateTime
in ISO-8601 format#DATE_FORMAT.parseOffsetDateTime('2020-01-01T11:12:13+01:00', 'yyyy-MM-dd'T'HH:mm:ssXXX')
- parseOffsetDateTime
in givenDateTimeFormatter
format#DATE_FORMAT.parseOffsetDateTime('2020-01-01T11:12:13+01:00', #dateTimeFormatter)
- parseOffsetDateTime
using givenDateTimeFormatter
Equivalent variants of parse
methods are available also for other date/time types: LocalTime
, LocalDate
, LocalDateTime
, Instant
and ZonedDateTime
.
Formatting of date/time
To format date/time can be used #DATE_FORMAT.format(#dateTime)
method which accept various date/time types and formats it in ISO-8601 format.
Also DateTimeFormatter
can be used directly via e.g. #DATE_FORMAT.formatter('EEEE').format(#date)
. Other formatter factory methods:
#DATE_FORMAT.formatter('EEEE', 'PL')
- createsDateTimeFormatter
using given pattern (EEEE
) and locale (PL
)#DATE_FORMAT.lenientFormatter('yyyy-MM-dd')
- creates lenient version ofDateTimeFormatter
using given pattern. Lenient parser may use heuristics to interpret inputs that do not precisely match format e.g. formatE
will accept:mon
,Mon
andMONDAY
inputs. On the other hand, formatter created using#DATE_FORMAT.formatter()
method will accept onlyMon
input.#DATE_FORMAT.lenientFormatter('yyyy-MM-dd EEEE', 'PL')
- creates lenient versionDateTimeFormatter
using given pattern and locale
For full list of available format options take a look at DateTimeFormatter api docs.