Orion Context Broker NGSI-v2 Overview for Developers That Already Know NGSI-v1 20220301

Contact twitter
@fermingalan
Contact email
fermin.galanmarquez@telefonica.com
(Reference Orion Context Broker version: 3.6.0 - Reference NGSIv2 version: 2.0)
NGSIv2 Overview for Developers
That Already Know NGSIv1

Outline
• Introduction to NGSIv2
• RESTful-ness
• URL & payload simplification
• Native JSON datatypes
• Text-based attribute value set/get
• Geolocation capabilities
• Datetime support
• Transient entities
• Filtering
• Subscription improvements
• Registration improvements
• Batch operations
• Working with IDs
• Pagination
• Unrestricted text attributes
• Flow control
• Update operators
2

Two “flavors” of NGSI API
• NGSIv1 (the one you already know )
– Original NGSI RESTful binding of OMA-NGSI
– Implemented in 2013
– Uses the /v1 prefix in resource URL
– Deprecated, so support to it will be removed at the end. You are strongly discouraged of
using NGSIv1.
• NGSIv2
– A revamped, simplified binding of OMA-NGSI
• Simple things must be easy
• Complex things should be possible
• Agile, implementation-driven approach
• Make it as developer-friendly as possible (RESTful, JSON, …)
– Enhanced functionality compared to NGSIv1 (e.g. filtering)
– Stable, ready for production, version already available
• Current NGSIv2 version is Release Candidate 2018.07 http://telefonicaid.github.io/fiware-
orion/api/v2/stable
• New features coming (see last part of this presentation)
– Uses the /v2 prefix in resource URL
• Introduction to NGSIv2
– https://docs.google.com/presentation/d/1_fv9dB5joCsOCHlb4Ld6A-
QmeIYhDzHgFHUWreGmvKU/edit#slide=id.g53c31d7074fd7bc7_0
3

The NGSI model is kept as it is in NGSIv2
Attributes
• Name
• Type
• Value
Entity
• EntityId
• EntityType
1 n
“has”
Metadata
• Name
• Type
• Value
1 n
“has”
4

RESTful-ness
• In NGSIv1
– Originally based on OMA-NGSI standard operations, not really
RESTful
• The URL doesn’t identify a resource, but an operation type
• The verb is always POST
• Actually, NGSIv1 is closer to HTTP-based RPC than to RESTful
– An extended set of operations (convenience operations) were
added in a later stage but with “legacy” from standard
operations that make it hard to apply full RESTful principles
• E.g. dual response code
• NGSIv2 has been designed from scratch with RESTful
principles in mind
– Batch operations (similar to standard operations in NGSIv1)
are also provided, but without impacting the RESTful
operations in the API
5

RESTful-ness
6
200 OK
...
{
"contextElement" : {
"type" : "",
"isPattern" : "false",
"id" : "Car1"
},
"statusCode" : {
"code" : "404",
"reasonPhrase" : "No context element found",
"details" : "Entity id: /Car1/"
}
}
GET /v1/contextEntities/Car1
404 Not Found
...
{
"error": "NotFound",
"description": "The requested entity has not
been found. Check type and id“
}
GET /v2/entities/Car1
NGSIv1
NGSIv2
both status codes have to be taken into account by
the client in order to detect error conditions,
which increases complexity
only HTTP response code,
following RESTful principles -
simpler to process
Example: get Car1 entity

URL & payload simplification
• In NGSIv1 the strict alignment with OMA NGSI involves
complexity and ineffectiveness
– Message payloads include a lot of structural overhead elements not
actually needed
– Response payload in methods that don’t really need a payload from a
semantic point of view (e.g. update operation)
– Unnecessarily long structural elements in URLs
• NGSIv2 simplifies URLs and payload, leading to a much
more lean and less verbose API
7

8
POST /v1/contextEntities
...
{
"id": "Car1",
"type": "Car",
"attributes": [
{
"name": "colour",
"type": "Text",
"value": "red"
}
]
}
200 OK
Location: /v2/entities?type=Car
POST /v2/entities
…
{
"id": "Car1",
"type": "Car",
"colour": {
"value": "red",
"type": "Text",
}
}
NGSIv1
NGSIv2
Most of the NGSIv1 response payload is
useless: clients only need to know the
status code. In NGSIv2 the response has
no payload at all
shorter URLs in
NGSIv2
200 OK
...
{
"contextResponses": [
{
"attributes": [
{
"name": "colour",
"type": "float",
"value": ""
}
],
"statusCode": {
"code": "200",
"reasonPhrase": "OK"
}
}
],
"id": "Car1",
"isPattern": "false",
"type": “Car"
}
structural
overhead
Example: create Car1
entity (type Car) with
attribute colour set to
“Red”

9
GET /v1/contextEntities/type/Car/id/Car1/attributes/colour GET /v2/entities/Car1/attrs/colour?type=Car
NGSIv1 NGSIv2
redundant (already part of the request URL)
200 OK
...
{
"attributes": [
{
"name": "colour",
"type": "Text",
"value": " red"
}
],
"statusCode": {
"code": "200",
}
}
mostly useless
200 OK
...
{
"value": "red",
"type": "Text",
"metadata": {}
}
shorter URL in
NGSIv2
structural
overhead
Example: get attribute
colour at Car1 entity
(type Car)

• Moreover, NGSIv2 provides simplified data representations
– keyValues: exclude attribute type and metadata
– values: only attribute values (attrs is used to order the values in the
resulting vector)
– unique: like values which in addition removes duplicate values
• Not only for retrieval operations, also for creation/update
operations
– Default attribute types are used in that case
10
GET /v2/entities/Car1/attrs?options=keyValues
200 OK
...
{
"model": "Ford",
"colour": "red",
"temp": 22
}
GET /v2/entities/Car1/attrs?options=values&attrs=model,colour,temp
200 OK
...
["Ford", "red", 22]
Example: get attribute
colour at Car1 entity (type
Car)

Native JSON datatypes
• In NGSIv1
– All attribute values are string based to align with XML encoding
• At the end, XML support was removed (in Orion 1.0.0), but it left
an awful legacy 
– Although creation/update operations can use numbers, bool,
etc. at the end they are transformed to strings and stored in
that way internally (*)
– Retrieve operation always provides string encoded values (**)
• NGSIv2 fully supports all the types described in the JSON
specification (string, number, boolean, object, array and
null)
11
(*) Except if NGSIv1 autocast feature is used, for some types (see https://fiware-
orion.readthedocs.io/en/master/user/ngsiv1autocast/index.html)
(**) Exception: entities created/updated with NGSIv2 (which support native types) and retrieved
with NGSIv1 will render without stringification.

Native JSON datatypes
12
12
POST /v1/contextEntities
...
{
"id": "Car1",
"type": "Car",
"attributes": [
{
"name": "speed",
"type": "Number",
"value": 98
}
]
}
POST /v2/entities?options=keyValues
…
{
"id": "Car1",
"type": "Car",
"speed": 98,
"isActive": true
}
NGSIv1
NGSIv2
created as
number but
retrieved as
string… weird!
GET /v1/contextEntities/Car1/attributes/speed
...
{
"attributes": [
{
"name": "speed",
"type": "Number",
"value": "98"
}
],
"statusCode": { … }
}
GET /v2/entities/Car1/attrs?options=keyValues
…
{
"speed": 98,
"isActive": true
}
coherent result
Example: create Car1
entity (type Car) with
attribute speed set to 98

Text-based attribute value set/get
• In NGSIv1
– There is no similar functionality
• NGSIv2 offers set/get attribute access directly without
anything else than the attribute value itself in the
request/response payload
– In the set operation, attribute type and metadata are kept as they are
13
PUT /v2/entities/Car1/attrs/speed/value
Content-Type: text/plain
…
86
GET /v2/entities/Car1/attrs/speed/value
200 OK
…
86
200 OK
…
Example: set speed attribute
value at Car1 entity
Example: get speed attribute
value at Car1 entity

Geolocation capabilities
• In NGSIv1
– Entity location must be a point
– Queries are based on an area specification (circle or polygon, inner or
outer area)
– Query as part of queryContext payload scope
• In NGSIv2
– In addition to point, entity location can be a line, box, polygon or
arbitrary GeoJSON
• null is also supported meaning "no location"
– Queries are based on a spatial relationship and a geometry
• Spatial relationships: near (max and min distance), coveredBy, intersect,
equal and disjoint
• Geometries: point, line, box, polygon
– Query as part of URL (more user-friendly than payload-based
approach)
14

15
NGSIv1
NGSIv2
Much easier and more compact in NGSIv2
POST /v1/queryContext
…
{
"entities": [
{
"type": "City",
"isPattern": "true",
"id": ".*"
}
],
"restriction": {
"scopes": [
{
"type" : "FIWARE::Location",
"value" : {
"circle": {
"centerLatitude": "40.418889",
"centerLongitude": "-3.691944",
"radius": "13500"
}
}
}
]
}
}
GET /v2/entities?
idPattern=.*&
type=City&
georel=near;maxDistance:13500&
geometry=point&
coords=40.418889,-3.691944
Example: retrieve all entities of type
“City” (no matter the id) whose
distance to Madrid city center (GPS
coordinates 40.418889,-3691944) is
less than 13.5 km

16
Point location
(the only one supported by NGSIv1)
POST /v2/entities
{
"id": "E",
"type": "T",
"location": {
"type": "geo:json",
"value": {
"type": "Polygon",
"coordinates": [ [ [2, 1], [4, 3], [5, -1], [2, 1] ] ]
} } }
POST /v2/entities
{
"id": "E",
"type": "T",
"location": {
"type": "geo:polygon",
"value": [ "2, 2", "8, 7", "-1, 4", "2, 2"]
}
}
POST /v2/entities
{
"id": "E",
"type": "T",
"location": {
"type": "geo:box",
"value": [ "2, 2", "8, 7" ]
}
}
POST /v2/entities
{
"id": "E",
"type": "T",
"location": {
"type": "geo:point",
"value": "40.41,-3.69"
}
}
POST /v2/entities
{
"id": "E",
"type": "T",
"location": {
"type": "geo:line",
"value": [ "2, 2", "8, 7" ]
}
}
Line location (e.g. a street) Box location (e.g. a squared building)
Polygon location (e.g. a city district) GeoJSON geometry (full flexibility)

Datetime support
• In NGSIv1
– There is no support for attributes meaning dates, they
are treated as conventional strings
• NGSIv2 implements date support
– Based on ISO ISO8601 format with milliseconds
precision, including partial representations and
timezones
• See https://fiware-
orion.readthedocs.io/en/master/user/ngsiv2_implementati
on_notes/index.html#datetime-support for syntax details
• null is also supported meaning "no date"
– Use reserved attribute type DateTime to express a date
– Date-based filters are supported
17

Datetime support
• Attribute value arithmetic filters can be used with dates as if they
were numbers
• Entity dateModified and dateCreated special attributes, to get
entity creation and last modification timestamps
– They are shown in query responses using
attrs=dateModified,dateCreated
• Entity dateModified and dateCreated special metadata, to get
attribute creation and last modification timestamps
– They are shown in query responses using
metadata=dateModified,dateCreated
18
POST /v2/entities
…
{
"id": "John",
"birthDate": {
"type": "DateTime",
"value": "1979-10-14T07:21:24.238Z"
}
}
GET /v2/entities?q=birthDate<1985-01-01T00:00:00
Example: create entity John,
with birthDate attribute using
type DateTime

Transient entities
• In NGSIv1
– There is no support for transient entities
• NGSIv2 implements transient entities
– Attribute dateExpires (of type DateTime) provided at
creation/update time, with special semantic: once that
time is reached, the entity is expired
– What “expires” means depends on implementation
• In the case of Orion, expired entities are automatically removed
(check Orion documentation for more detail)
– Date-based filters are supported also for dateExpires
attribute
19

Filtering
• In NGSIv1
– Limited filtering functionality, much of it based on queryContext
complex scopes
– Filters are not supported in subscriptions
• In NGSIv2 the mechanism
– Is simpler (see next slide)
– Can be applied to both queries and subscriptions (described in a later
topic of this presentation)
20
…
{
"restriction": {
"scopes": [
{
"type" : "FIWARE::StringFilter",
"value" : "temp<24"
…
}
This is the only interesting
part, all the rest is
structural overhead
Example: filtering entities
which temperature is less
than 24

• For the GET /v2/entities operation, retrieve all entities…
– … of a given entity type
– … whose entity id is in a list
– ... whose entity id match a regex pattern
• Example: the id starts with “Room” followed by a digit from 2 to 5
– … with an attribute that matches a given expression
• Example: attribute temp is greater than 25
• Filters can be used simultaneously (i.e. like AND condition)
21
GET /v2/entities?type=Room
GET /v2/entities?id=Room1,Room2
GET /v2/entities?idPattern=^Room[2-5]
Filtering
GET /v2/entities?q=temp>25
supported operators:
• == (or :), equal
• !=, unequal
• >, greater than
• <, less than
• >=, greater than or
equal
• <=, less than or equal
• A..B, range
• ^=, pattern (regex)
• Existence/inexistence

• For the GET /v2/entities operation, retrieve all entities…
– ... whose entity type match a regex pattern
– … with an attribute which sub-key matches a given expression
– … with an attribute metadata that matches a given expression
– … with an attribute metadata which sub-key matches a given
expression
22
GET /v2/entities?q=tirePressure.frontRight >130
attribute name attribute sub-key (for compound
attribute values only)
GET /v2/entities?mq=temperature.avg>25
GET /v2/entities?mq=tirePressure.accuracy.frontRight >90
metadata sub-key (for compound
metadata values only)
metadata name
Filtering
GET /v2/entities?typePattern=T[ABC]

• By default all attribute are included in query
responses or notifications
• The attrs field (as parameter in GET operations
and as notification sub-field in subscriptions)
can be used to specify a filtering list
• The attrs field can be also used to explicitly
include some special attributes (not included by
default)
– dateCreated: entity creation date
– dateModified: entity last modification date
– dateExpires: entity expiration date
• The “*” can be used as an alias of “all the
(regular) attributes”
23
Attributes filtering and special attributes

• Examples
– Include only attributes temp and lum
• In queries: GET /v2/entities?attrs=temp,lum
• In subscriptions: "attrs": [ "temp", "lum" ]
– Include dateCreated and not any other attribute
• In queries: GET /v2/entities?attrs=dateCreated
• In subscriptions: "attrs": [ "dateCreated" ]
– Include dateModified and all the other (regular)
attributes
• In queries: GET /v2/entities?attrs=dateModified,*
• In subscriptions: "attrs": [ "actionType", "*" ]
– Include all attributes (same effect that not using attrs,
not very interesting)
• In queries: GET /v2/entities?attrs=*
• In subscriptions: "attrs": [ "*" ]
24
Attributes filtering and special attributes

• By default all attribute metadata are included in query responses
and notifications
• The metadata field (as parameter in GET operations and as
notification sub-field in subscriptions) can be used to specify a
filtering list
• The metadata field can be also used to explicitly include some
special metadata (not included by default)
– dateCreated, dateModified: attribute creation or last modification
date
– actionType: which value is the action type corresponding to the
update triggering the notification: “update”, “append” or “delete” (*)
– previousValue: which provides the value of the attribute previous to
processing the update that triggers the notification
• The “*” can be used as an alias of “all the (regular) metadata”
25
(*) actionType “delete” not yet supported by Orion in 3.6.0.
Metadata filtering and special metadata

• Examples
– Include only metadata MD1 and MD2
• In queries: GET /v2/entities?metadata=MD1,MD2
• In subscriptions: "metadata": [ "MD1", "MD2" ]
– Include previousValue and not any other metadata
• In queries: GET /v2/entities?metadata=previousValue
• In subscriptions: "attrs": [ "previousValue" ]
– Include actionType and all the other (regular) metadata
• In queries: GET /v2/entities?metadata=actionType,*
• In subscriptions: "attrs": [ "actionType", "*" ]
– Include all metadatata (same effect that not using
metadata, not very interesting)
• In queries: GET /v2/entities?metadata=*
• In subscriptions: "metadata": [ "*" ]
26
Metadata filtering and special metadata

Subscription improvements
• NGSIv1 context subscription API is very limited
– There is no operation to list existing subscriptions
• If a client loses the ID of created subscriptions, there is no way to retrieve
them through the API
– No support for permanent subscriptions
• Creating absurdly long subscriptions (e.g. 100 years) is a dirty workaround
– Fix notification structure
• Difficult to integrate to arbitrary endpoints (e.g. public REST services)
– No support for filters
– Initial notification cannot be avoided (at it is problematic in some use
cases)
– Updates not actually changing attribute value don’t trigger notification
– Failing notification endpoints (consuming Orion resources) cannot be
automatically disabled
– Only HTTP notifications
27

Subscription improvements
• NGSIv2 subscription API solves all these limitations and
introduces some additional enhancements
– Notification attributes based on “blacklist” (in addition to the
“whitelist” approach in NGSIv1)
– Ability to pause/resume subscriptions
– Oneshot subscriptions
– ?options=forcedUpdate URI parameter to force notification no
matter if update was actual or not
– Extra fields: timesSent, last*, timeout and description
– onChangedAttributes to notify only attributes that change
– Subscription auto-disabling for failing endpoints is supported
– MTTQ notifications are also supported
28

Anatomy of a NGSIv2 subscription
29
POST /v2/subscriptions
…
{
"subject": {
"entities": [
{
"id": "Room1",
"type": "Room"
}
]
},
"condition": {
"attrs": [ "temp" ]
},
"notification": {
"http": {
"url": "http://<host>:<port>/publish"
},
"attrs": [ "temp" ]
},
"expires": "2026-04-05T14:00:00.000Z",
"throttling": 5
}
201 Created
Location: /v2/subscriptions/51c0ac9ed714fb3b37d7d5a8
...
POST /v1/subscribeContext
…
{
"entities": [
{
"type": "Room",
"id": "Room1"
}
],
"attributes": [ "temp“ ],
"reference": "http://<host>:<port>/publish",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [ "temp" ]
}
],
"throttling": "PT5S"
}
200 OK
...
{ "subscribeResponse": {
"duration": "P1M",
"subscriptionId": "51c0ac9ed714fb3b37d7d5a8",
"throttling": "PT5S"
} }
NGSIv1 NGSIv2
Simpler response
(no payload)
Simpler way of specifying
expiration and throttling
in NGSIv2
Redundant Example: subscribe to
Room1 entity, so
whenever a change
occurs in the temp
attribute a notification
including only temp is
sent

List subscriptions and special fields in NGSIv2
• List operations (not available in NGSIv1)
– GET /v2/subscriptions lists all subscriptions
– GET /v2/subscriptions/<id> retrieves information of a particular
subscription
• Whitelist vs. blacklist (in the notification field)
– Use "attrs": [ "A", "B" ] to “include A and B in the notification”
(whitelist)
– Use "exceptAttrs": [ "A", "B" ] to “include all the attributes except
A and B” (blacklist)
– Use "attrs": [ ] to include “all the attributes” (special case)
• Other informative fields (in the notification field)
– timesSent: the number of times that the subscription has been
triggered and a notification has been sent
– lastNotification: datetime corresponding to the last notification
• Other informative fields (at root level)
– description, free text descriptive text for user convenience
30

Permanent and paused subscriptions in NGSIv2
• The status attribute can be used to pause/resume
subscriptions
• In GET operations, the status field can be
– active: subscription is active (notifications will be sent)
– inactive: subscription is inactive (notifications will not be sent)
– expired: subscription is expired (notifications will not be sent)
– failed: described in next slide
– oneshot: described in the next to the next slide
31
PATCH /v2/subscriptions/<id>
…
{
"status": "active"
}
PATCH /v2/subscriptions/<id>
…
{
"status": "inactive"
}
To pause To resume

• Detailed information in the notifications
element
– timesSent: total number of notifications
attempts (both successful and failed)
– failsCounter: number of consecutive
notifications fails
• failsCounter > 0 means subscription is in
failing state
– lastSuccess: last time that notification was
successfully sent
– lastFailure: last time that notification was
tried and failed
– lastNotification: last time the notification was
sent (either success or failure)
• Corollary: lastNotification value is the same
than either lastFailure or lastSuccess
– lastFailureReason: cause of last failure (text)
– lastSuccessCode: the HTTP code (number)
returned by receiving endpoint last time a
successful notification was sent
• lastSuccessCode and
lastFailureReason fields only in HTTP
notifications (not in MQTT ones)
32
200 OK
Content-Type: application/json
…
[{
"id": " 51c0ac9ed714fb3b37d7d5a8 ",
"status": "active",
"subject": { … },
"notification": {
"timesSent": 3,
"failsCounter": 1,
"lastNotification": "2016-05-31T11:19:32.000Z",
"lastSuccess": "2016-05-31T10:07:32.000Z",
"lastSuccessCode": 200,
"lastFailure": "2016-05-31T11:19:32.000Z",
"lastFailureReason": "Timeout was reached",
…
}
}]
Notification status

33
Notification diagnosis workflow
"status" field
value?
"lastSuccessCode“
field value?
Subscription is inactive
so notifications are not
being sent. Update
subscription to
activate it.
Notifications are being
sent and the receiving
endpoint confirms
correct reception.
Notifications are
being sent but the
receiving endpoint
is reporting HTTP
error. Check
receiving endpoint
(e.g. logs, etc.)
Some problem is
precluding
notifications to be
sent. In HTTP
subscriptions, the
"lastFailureReason"
field value should
provide additional
information on it.
inactive
Subscription is expired
so notifications are not
being sent. Update
subscription to make it
permanent or extend
expiration time
expired
active/oneshot
YES
2xx
4xx,
5xx
Only for HTTP notifications
failsCounter > 0?
NO

• A variant of the active
status, so when the
subscription is triggered
one time (i.e. a
notification is sent) it
automatically steps to
inactive status
• An inactive subscription
can step to oneshot,
starting again the process
• Initial notification upon
subscription creation or
update is not sent in this
case
34
Oneshot subscription
200 OK
…
[{
"id": "51c0ac..",
"status": "oneshot",
…
}
}]
200 OK
…
[{
"id": "51c0ac..",
"status": "inactive",
…
}
}]
Subscription is
triggered
PATCH /v2/subscriptions/51c0ac..
{
"status": "oneshot"
}

35
Subscription auto-disabling
• A maxFailsLimit can be specified for subscriptions
so when the number of consecutive notifications
overpasses that value, the subscription
automatically passes to inactive state
• failsCounter is reset to 0 whenever a successful
notification is sent
• This allow to protect Orion against failing
notification endpoints what would consume
notification resources (pool workers, etc.)
• When a subscription is auto-disabled, a trace about
it is printed in logs:
{
"subject": { … },
"notification": {
"maxFailsLimit": 3,
…
}
}
failsCounter > maxFailsLimit => status := inactive
time=... | lvl=WARN | ... | msg= Subscription 51c0ac9ed714fb3b37d7d5a8
automatically disabled due to failsCounter (4) overpasses maxFailsLimit (3)

Notification formats in NGSIv2
• The optional attrsFormat field can be used to choose between different notification
flavors, aligned with the representation modes
• Notifications include the NGSIv2-AttrsFormat header to help the receiver identify
the format
• legacy can be used as value for attrsFormat in order to send notifications in
NGSIv1 format
– Very useful when integrating legacy notification endpoints
36
{
"subscriptionId": "12345",
"data": [
{
"id": "Room1",
"type": "Room",
"temperature": {
"value": 23,
"type": "Number",
"metadata": {}
}
}
]
}
{
"data": [
{
"id": "Room1",
"type": "Room",
"temperature": 23
}
]
}
{
"data": [ [ 23 ] ]
}
normalized (default) keyValues values
Outer vector represent the list of
entities, inner vector the values of
the attribute of each entity (not too
interesting in this single-entity
single-attribute example)

Custom notifications in NGSIv2
• Apart from the standard formats defined in the
previous slide, NGSIv2 allows to re-define all the
notification aspects
• httpCustom is used (instead of http) with the
following subfields
– URL query parameters
– HTTP method
– HTTP headers
– Payload (not necessarily JSON!)
• A simple macro substitution language based on ${..}
syntax can be used to “fill the gaps” with entity data (id,
type or attribute values)
37

Custom notifications in NGSIv2
38
…
"httpCustom": {
"url": "http://foo.com/entity/${id}",
"headers": {
"Content-Type": "text/plain"
},
"method": "PUT",
"qs": {
"type": "${type}"
},
"payload": "The temperature is ${temp} degrees"
}
…
PUT http://foo.com/entity/DC_S1-D41?type=Room
Content-Length: 31
The temperature is 23.4 degrees
PUT /v2/entities/DC_S1-D41/attrs/temp/value?type=Room
…
23.4
Custom notification configuration
update
notification
Example: send a text
notification (i.e. not
JSON) with temperature
value, using the entity id
and type as part of the
URL

39
…
{
"subject": {
"entities": [
{
"id": "Truck11",
"type": "RoadVehicle"
},
{
"idPattern": "^Car[2-5]",
"type": "RoadVehicle"
}
],
"condition": {
"attrs": [ "speed" ],
"expression": {
"q": "speed>90",
"georel": "near;maxDistance:100000",
"geometry": "point",
"coords": "40.418889,-3.691944"
}
}
},
…
}
• Filters (described in previous
slides) can be also used in
subscriptions
– id
– type
– id pattern
– attribute values
– geographical location
Subscription filters in NGSIv2
Example: subscribe to speed changes in
entities with id Truck11 or Car2 to Car5 (both
case of type RoadVehicle) whenever speed is
greater than 90 and the vehicle distance to
Madrid city center is less than 100 km

40
…
{
"subject": {
"entities": [
{
"idPattern": ".*",
"typePattern": ".*Vehicle"
},
],
"condition": {
"attrs": [ "speed" ],
"expression": {
"q": "speed>90",
"mq": "speed.average==80..100",
"coords": "40.418889,-3.691944"
}
}
},
…
}
• They can be used also in
subscriptions
– type pattern
– metadata value
Subscription filters in NGSIv2
Example: subscribe to speed changes in any
entities of any type ending with Vehicle (such
as RoadVehicle, AirVehicle, etc.) whenever
speed is greater than 90 its average metadata
is between 80 and 90 and the vehicle distance
to Madrid city center is less than 100 km

Registration improvements
• NGSIv1 registration API has some limitations
– There is no way of controlling if the registration is for queries,
updates or both (both is always assumed)
• NGSIv2 registration API solve these limitations
– The supportedForwardingMode field allows to specify if
Orion has to forward to the Context Provider only queries, only
updates or both
– Forwarding can be disabled in queries using
?options=skipForwardking
• In this case, query is evaluated using exclusively Context Broker local
context information
41

Batch operations
• In NGSIv1 we have standard operations
– POST /v1/updateContext
– POST /v1/queryContext
• Similar but more user-friendly operations have
been included in NGSIv2
– POST /v2/op/update
– POST /v2/op/query
42

Batch operations
43
POST /v1/updateContext
…
{
"updateAction": "APPEND“,
"contextElements": [
{
"type": "Room",
"id": "Room1",
"attributes": [
{
"name": "temp",
"type": "float",
"value": "29"
}
]
}
]
}
POST /v2/op/update
{
"actionType": "append",
"entities": [
{
"type": "Room",
"id": "Room1",
"temperature":
{
"type": "Number",
"value": 29
}
}
]
}
201 Created
NGSIv1 NGSIv2
structural
overhead
200 OK
...
{
"contextResponses" : [ … ],
"statusCode" : {
"code" : "200",
"details" : "OK"
}
}
NGSIv2 response doesn’t
have any payload at all
lots of useless
stuff here
Example: create
Room1 entity (type
Room) with attribute
temp set to 29

Batch operations
44
…
{
"entities": [
{
"type": "Room",
"isPattern": "true",
"id": ".*"
} ,
"attributes": [ "temp" ]
]
}
POST /v2/op/query
…
{
"entities": [
{
"idPattern": ".*",
"type": "T"
}
],
"attrs": [ "temp" ]
}
NGSIv1
NGSIv2
Requests are more or
less the same, but the
simplicity of NGSIv2
becomes evident
when comparing
responses
200 OK
...
{
"contextResponses": [
{
"contextElement": {
"attributes": [
{
"name": "temp",
"type": "Number",
"value": "25"
}
],
"id": "Room1",
"type": "Room"
},
"statusCode": { … }}
]
}
200 OK
...
[
{
"id": "Room1",
"type": "Room",
"temp": {
"type": "Number",
"value": 25
}
}
]
Example: get
temp attribute of
all entities with
type Room

Batch query scope
• This is the way of including q,
mq and geo filters (typically
used as URL param of a GET
operation) in a batch query
45
POST /v2/op/query
…
{
"entities": [
{
"idPattern": ".*",
"type": "T"
}
],
"attrs": [ "temp" ],
"expression": {
"q": "temp>40",
"coords": "40.31,-3.75"
}
}
Example: get all entities of type T
with the attribute temp as long as
that attribute is greater than 40 and
the entity distance to coordinates
(40.31, -3.75) is less than 20 km

Working with IDs
• In NGSIv1
– Fields such as entity id, attribute name, etc. may have any value (*)
– This could cause a lot of problems as these fields use to act as IDs in
many places when propagated through notifications
• E.g. Cygnus MySQL sink may have problems when these fields are mapped
to tables names, whose allowed charset is very strict
– In addition, NGSIv1 allows ids or attribute names as "" (empty string)
which is weird and typically an error condition in the client
• NGSIv2 establishes a set of restrictions to ensure sanity in the
usage of ID fields. In particular:
– Allowed characters are those in the plain ASCII set, except the following ones:
control characters, whitespace, &, ?, / and #.
– Maximum field length is 256 characters.
– Minimum field length is 1 character.
– The rules above apply to the following six fields (identified as ID fields): entity
id, entity type, attribute name, attribute type, metadata name, metadata type
46
(*) Excluding the forbidden characters described in the Orion manual, which are general for all the fields in both
NGSIv1 and NGSIv2 APIs

Pagination
• In NGSIv1
– based on limit, offset and details
– Dirty workaround to fit count into NGSIv1
payloads, using an errorCode for something
that actually is not an error and forcing to
text based processing of the details field
– Fixed order: always by creation date
• In NGSIv2
– based on limit, offset and options=count
• This part doesn’t change too much
– Cleaner and easier way of returning count,
with the Fiware-Total-Count HTTP header
in the response
– Configurable ordering based on orderBy
parameter
• See details in the NGSIv2 specification
47
"errorCode": {
"code": "200",
"details": "Count: 322",
}
Fiware-Total-Count: 322

Unrestricted text attributes
• In NGSIv1
– Forbidden chars (https://fiware-
orion.readthedocs.io/en/master/user/forbidden_characters/index.html
) always apply
• In NGSIv2, you can avoid this check in attribute values using the
special attribute type TextUnrestricted
– It may have security implications (injection attacks). Use it at your
own risk!
48
…
"description": {
"type": "TextUnrestricted",
"value": "Hey! I'm using <forbidden chars>"
}
…

Flow control
• In NGSIv1
– Orion updates responses are decoupled from the sending of the
notifications triggered by these updates
– This may cause that if the client sending updates is much faster than
the receiver processing notifications, saturation will happen
• NGSIv2, implements a new option (flowControl) so Orion doesn’t
response updates immediately. It introduces a delay based on
occupation size of the notification queue (the more the
occupation, the more the delay)
– Used in combination with -notifFlowControl CLI option
– Functionality description: https://fiware-
orion.readthedocs.io/en/master/admin/perf_tuning/index.html#update
s-flow-control-mechanism
– Detailed example/tutorial: https://github.com/telefonicaid/fiware-
orion/blob/master/test/flowControlTest/README.md
49

Flow control
50
Client Receiver
…
client sending
updates too fast
at some point in time, Orion
notification queue will saturate and
new notifications will be discarded
receiver is not so
fast
…
Client Receiver
…
…
?options=flowControl
delays
introduced
by Orion
With NGSIv1:
With NGSIv2:

Update operators
• In NGSIv1
– Attribute value updates use always particular values, e.g. 1, "on", etc.
– This may be inefficient for context producers and cause race
conditions in some cases
• NGSIv2 implement update operators that allow to simplify context
producers and avoid race conditions
– Eg. "increase count attribute by 2"
– Full list of operators (check Orion documentation)
• $inc, $mul, $max, $min, $push, $addToSet, $pull, $pullAll, $set,
$unset
51
…
"count": {
"type": "Number",
"value": { "$inc": 2 }
}
…

• Example without update operators: two context producers update
the same entity attribute
– Complexity: context producers have to do local calculations
– Race conditions may occur, as shown in diagram below
52
CP A
GET /v2/entity/E/attrs/count
CP B
count = 10
Sum 2 Sum 3
GET /v2/entity/E/attrs/count
10
10
10 +2 = 12
10 +3 = 13
count = 12
count = 13
PUT /v2/entity/E/attrs/count (12)
PUT /v2/entity/E/attrs/count (13)
Final value is 13 but it
should be 15!
Calculation
at CP:
Calculation
at CP:
Update operators

• Same example using update operator $inc
– No need of calculations in context producers (simplification)
– No race condition may occur
53
CP A
PUT /v2/entity/E/attrs/count
{$inc: 2}
CP B
count = 10
Sum 2 Sum 3
count = 12
count = 15
Final result is correct
PUT /v2/entity/E/attrs/count
{$inc: 3}
Update operators

Useful references
• Introduction to NGSI and Orion
– https://github.com/telefonicaid/fiware-orion#introductory-
presentations
• Orion Manual
– https://fiware-orion.readthedocs.io
• Orion page at FIWARE Catalogue
– http://catalogue.fiware.org/enablers/publishsubscribe-
context-broker-orion-context-broker
• NGSIv2 specs
– http://fiware.github.io/specifications/ngsiv2/stable
– http://fiware.github.io/specifications/ngsiv2/latest
• Orion support at StackOverflow
– Look for existing questions at
http://stackoverflow.com/questions/tagged/fiware-orion
– Ask your questions using the “fiware-orion” tag
• FIWARE Tour Guide Application
– https://github.com/fiware/tutorials.TourGuide-App
54

Orion Context Broker NGSI-v2 Overview for Developers That Already Know NGSI-v1 20220301

More Related Content

What's hot (20)

Similar to Orion Context Broker NGSI-v2 Overview for Developers That Already Know NGSI-v1 20220301 (20)

More from Fermin Galan (19)

Recently uploaded (20)

Orion Context Broker NGSI-v2 Overview for Developers That Already Know NGSI-v1 20220301