We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.IoT.Backend.TemplateHandler - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.IoT.Backend.TemplateHandler
Chapter IoT Services Enablement,
Catalogue-Link to Implementation [(to be inserted) Template Handler]
Owner SAP, Carsten Magerkurth



Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


  • Copyright © 2014 by SAP

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.


The NGSI Backend Template Handler allows modeling and executing BPMN business processes. BPMN is a description standard for business processes. A quick introduction as well as the full standard can be found via the official BPMN home page. The Template Handler enriches this standard by additional NGSI-enabled components.

Template Handler consists of two components:


The modeler allows users to model BPMN processes and enriches BPMN with the NGSI specific extensions.

Modeler user interface

Execution environment

Activiti is an environment for BPMN process execution. It has been extended for the execution of NGSI sensing tasks to request values from the NGSI server. Additionally, start events may trigger business processes on receipt of NGSI notifications.

Execution engine's web interface

Data model outline

Template Handler bridges the gap between business process modelling level and IoT concepts. Existing graphical and executable process modelling languages are not designed for representing IoT-aware business processes. Therefore Template Handler introduces an extension of the existing BPMN seeking to lower the barrier for applying IoT technology like sensors and actuators to current and new business processes. Process modellers without a deep programmatic understanding get an advanced guidance during the modelling activities, so that they can create IoT-aware processes. The created and abstract process models are stored in files based on BPMN 2.0 XML format extended by IoT-specific elements. These new elements are derived from the NGSI specification defining how to retrieve context information in a NGSI compliant environment. This abstract process models are constitutively completed by a process resolution environment that will create an executable IoT-aware process model. Finally, the process models presented in the IAPMC BPMN 2.0 integration can be executed by the IAPMC BPMN 2.0 compliant process execution engine, which is also part of the Template Handler.

Functionality outline

The functionality of the Template Handler Theme is to provide the means to define and execute IoT-aware business process templates/models. For the process template provision within the Template Handler Theme, it is essential to provide means of explicitly modelling process models or templates with respective IoT-specific BPMN extensions, in addition to the semi-automatic recommendations of the template handler. This aspect relates to the Exposure Theme which will be capable of utilizing process models with such IoT extensions. The IoT extensions take into account the idiosyncrasies of IoT services such as the inherent uncertainty of sensor information, the mobility of IoT resources, or the temporal dynamicity of physical things. In order to model IoT-aware business processes with the respective BPMN extensions, the Template Handler will provide a set of new modelling concepts in addition to the standard concepts form the BPMN world. This Enabler will be capable of serializing the process models for the Process Handler of the Exposure.

Main Concepts

Basic Concepts


To gather information about the context Template Handler follows the NGSI standard, to be found under NGSI Context Management v1.0. The communication protocol is HTTP and follows NGSI RestFUL Binding, v1.0

There is a FI-WARE NGSI Context Management tutorial.


Business process modeling complies with the BPMN v2.0 standard. An inofficial overview for the most important elements can be found at this tutorial.

Additional Concepts

NGSI specific BPMN extensions

In general, Template Handler is a modeling and execution platform for BPMN processes. In order to be integrated in a real world environment, Template Handler enables them to access information on the existing entities. The transmission is based on the NGSI standard. However, Template Handler acts on a very high level of abstraction. Users without any detailed knowledge of the NGSI protocol are able to use measured information about these real world entities within business processes. The BPMN standard is extended by the following new elements:

  • PhysicalEntity: A Physical Entity in an IoT-aware business process represents the real-world entity, with which the process interacts. Its graphical representation is a collapsed pool decorated with a cow. In order to specify the real-world object, an NGSI EntityId has to be defined by the process modeler. Its symbol is the picture below, a box with a cow picture and the entity's id as label.
Physical Entity
  • SensingTask: A Sensing Task is a newly introduced BPMN task type needed for the interaction of the process with the Physical Entity. It is drawn as a BPMN task decorated with a WLAN symbol. For the execution of such a task, an NGSI10 queryContext operation is executed. Therefore the ContextAttribute to be measured must be specified in the SensingTask by the process modeler. The EntityId for the NGSI queryContext operation is taken from the PhysicalEntity to which the SensingTask is connected. After the execution of the queryContext operation the value returned from the NGSI Context Management Component is written to the DataObject connected to the SensingTask, so that it is available during the remainder of the execution of the process. Its symbol is shown below, a task symbol with a start event in the upper left corner.
Physical Entity
  • NGSIStartEvent: If a business process is to be started due to certain events in the real world, an NGSIStartEvent can be used as the first element of a sequence flow. Like the SensingTask, this is connected to a PhysicalEntity, which holds the specification of the NGSI EntityId, and a DataObject, which receives the real-world attribute value. When a business process with an NGSIStartEvent is loaded into a business process execution engine, the engine sends a subscribeContextRequest to the NGSI Context Management Component. Therefore the attributes to be observed for events, the NGSI NotifyCondition and the duration of the subscription have to be specified in the NGSIStartEvent by the process modeler. When the execution engine receives the notifyContextRequest from the NGSI Context Management Component, it writes the real-world value into the associated DataObject and starts the process. Its symbol is the following:
Start Event

Main Interactions

The Template Handler GE offers interfaces to interact with end users on the one hand and NGSI capable network devices on the other hand.

End User Interactions

Modeling processes

The modeler allows users to model BPMN processes and enriches BPMN with the NGSI specific extensions.

Template Handler Modeler

Executing processes

The Activiti Explorer is an environment for BPMN process execution. It has been extended for the execution of NGSI sensing tasks to request values from the NGSI server. Additionally, start events may trigger business processes on receipt of NGSI notifications.

Template Handler Execution Environment

NGSI Interactions

The NGSI server component is a part of the Template Handler. It is intended to receive and store context information from other participants in the IoT network environment.

Context Query

Receiving information about a context entity is possible due to the implementation of the "Query Context Operation" defined in the NGSI specification.

Context Update

Updating information about a context entity is possible due to the implementation of the "Update Context Operation" defined in the NGSI specification. This may trigger context notifications to be sent to interested network participants.

Subscription Request & Notification

The NGSI server is capable to receive "subscribeContextRequests" according to the NGSI specification. These express the wish to be informed when the state of another context entity changes. In effect, notifications containing the information are sent to other participant's "notifyContext" interface.

Basic Design Principles

  • No knowledge about the NGSI domain required: Template Handler a fully integrated toolkit so users can use BPMN and NGSI together at a high level of abstraction. All necessary steps happen only based on the graphical web interface. They can be simply executed through graphical interface, without any understanding of the programming behind it.
  • All in one: Template Handler is a standalone toolkit. It requires nothing but a Java/Web server environment and does not depend on other software. So modeling and executing BPMN processes integrates smoothly without compatibility issues.

Re-utilised Technologies/Specifications

The interfaces of the TemplateHandler GE are based on RESTful Design Principles. The technologies and specifications used in this GE are:

  • RESTful web services
  • HTTP/1.1 (RFC2616)
  • XML data serialization format.

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Thing. One instance of a physical object, living organism, person or concept interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Examples of physical objects are: building, table, bridge (classes), the Kreml, the tennis table from John’s garden, the Tower bridge (instances). Examples of living organisms are: frog, tree, person (classes), the green frog from the garden, the oak tree in front of this building, Dr. Green.
  • Class of thing. Defines the type of a thing in the style of object-oriented programming: a construct that is used as a blueprint to create instances, defining constituent members which enable class instances to have state and behavior. An example of class of thing is “person”, whereas an instance of a thing is “Dr. Green”, with all the static/dynamically changing properties of this particular person.
  • Group of things. A physical/logical group of things. Examples are all office buildings from Munich, all bridges above the Thames, all screws from a drawer, the planes of Lufthansa currently above Germany, all cars inside a traffic jam driven by a female driver, the trees from the Amazonian forest, the squids from the Mediterranean see the mushrooms from Alice’s garden, all the fish from the aquarium of John., the soccer team of Manchester, the colleagues from OrangeLabs currently working abroad (from the perspective of France), all patients above 60 years of age of Dr. Green, the traffic jams from Budapest, the wheat crop in France in the year 2011, the Research and Development Department of the company Telefónica.
  • Device. Hardware entity, component or system that may be in a relationship with a thing or a group of things called association. A device has the means either to measure properties of a thing/group of things and convert it to an analog or digital signal that can be read by a program or user or to potentially influence the properties of a thing/group of things or both to measure/influence. In case when it can only measure the properties, then we call it a sensor. In case when it can potentially influence the properties of a thing, we call it an actuator. Sensors and actuators may be elementary or composed from a set of elementary sensors/actuators. The simplest elementary sensor is a piece of hardware measuring a simple quantity, such as speed of the wind, and displaying it in a mechanical fashion. Sensors may be the combination of software and hardware components, such as a vehicle on-board unit, that consists of simple sensors measuring various quantities such as the speed of the car, fuel consumption etc and a wireless module transmitting the measurement result to an application platform. The simplest elementary actuator is a light switch. We have emphasized potentially because as a result of the light switch being switched on it is not sure that the effect will be that light bulb goes on: only an associated sensor will be able to determine whether it went on or not. Other examples of devices are smart meters, mobile POS devices. More sophisticated devices may have a unique identifier, embedded computing capabilities and local data storage utilities, as well as embedded communication capabilities over short and/or long distances to communicate with IoT backend. Simple devices may not have all these capabilities and they can for instance only disclose the measurement results via mechanical means. In this latter case the further disclosure of the measurement result towards IoT backend requires another kind of device, called IoT Gateway.
  • Association. It is a physical/logical relationship between a device and a thing or a device and a group of things or a group of devices and a group of things from the perspective of a FI-WARE instance, an application within a usage area project or other stakeholder. A device is associated with a thing if it can sense or (potentially) influence at least one property of the thing, property capturing an aspect of the thing interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Devices are associated with things in fully dynamic or mainly static or fully static manner. The association may have several different embodiments: physical attachment, physical embedding, physical neighborhood, logical relation etc. Physical attachment means that the device is physically attached to the thing in order to monitor and interact with it, enabling the thing to be connected to the Internet. An example is the on-board device installed inside the vehicle to allow sending sensor data from the car to the FI-WARE instances. Physical embedding means that the device is deeply built inside the thing or almost part of the thing. An example of physical embedding is the GPS sensor inside a mobile phone. Physical neighborhood means that the device is in the physical neighborhood of the thing, but not in physical contact with it. An example of physical neighborhood is the association of the mobile phone of a subscriber who is caught in a traffic jam with the traffic jam itself: the mobile phone is the device, the traffic jam is the thing and the association means that the mobile phone is in the physical neighborhood of the area inside which the traffic jam is constrained (e.g. within 100 m from the region where the average speed of cars is below 5 km/h). Logical association means that there is a relationship between the device and the thing which is neither fully physical in the sense of attachment or embedding, nor fully physical proximity related. An example of logical association is between the car and the garage door opener of the garage where the car usually parks during the night.
  • IoT gateway. A device that additionally to or instead of sensing/actuating provides inter-networking and protocol conversion functionalities between devices and IoT backend potentially in any combination of these hosts a number of features of one or several Generic Enablers of the IoT Service Enablement. It is usually located at proximity of the devices to be connected. An example of an IoT gateway is a home gateway that may represent an aggregation point for all the sensors/actuators inside a smart home. The IoT gateway will support all the IoT backend features, taking into consideration the local constraints of devices such as the available computing, power, storage and energy consumption. The level of functional split between the IoT backend and the IoT gateway will also depend on the available resources on the IoT gateway, the cost and quality of connectivity and the desired level for the distribution of intelligence and service abstraction.
  • IoT resource. Computational elements (software) that provide the technical means to perform sensing and/or actuation on the device. There may be one-to-one or one-to-many relationship between a device and its IoT resource. Actuation capabilities exposed by the IoT resource may comprise configuration of the management/application features of the device, such as connectivity, access control, information, while sensing may comprise the gathering of faults, performance metrics, accounting/administration data from the device, as well as application data about the properties of the thing with which the device is associated. The resource is usually hosted on the device.
  • Management service. It is the feature of the IoT resource providing programmatic access to readable and/or writable data belonging to the functioning of the device, comprising a subset of the FCAPS categories, that is, configuration management, fault management, accounting /access management/administration, performance management/provisioning and security management. The extent of the subset depends on the usage area. Example of configuration management data is the IP endpoint of the IoT backend instance to which the device communicates. Example of fault management is an error given as a result of the overheating of the device because of extensive exposure to the sun. Example of accounting/administration is setting the link quota for applications using data from a certain sensor. Example of security management is the provisioning of a list of device ID-s of peer devices with which the device may directly communicate.
  • Application service. It is the feature of the IoT resource providing programmatic access to readable or writable data in connection with the thing which is associated with the device hosting the resource. The application service exchanges application data with another device (including IoT gateway) and/or the IoT backend. Measured sensory data are example of application data flowing from devices to sensors. Setting the steering angle of a security camera or sending a “start wetting” command to the irrigation system are examples of application data flowing from the application towards the sensor.
  • Event. An event can be defined as an activity that happens, occurs in a device, gateway, IoT backend or is created by a software component inside the IoT service enablement. The digital representation of this activity in a device, IoT resource, IoT gateway or IoT backend instance, or more generally, in a FI-WARE instance, is also called an event. Events may be simple and complex. A simple event is an event that is not an abstraction or composition of other events. An example of a simple event is that “smart meter X got broken”. A complex event is an abstraction of other events called member events. For example a stock market crash or a cellular network blackout is an abstraction denoting many thousand of member events. In many cases a complex event references the set of its members, the implication being that the event contains a reference. For example, the cellular network blackout may be caused by a power failure of the air conditioning in the operator’s data center. In other cases such a reference may not exist. For example there is no accepted agreement as to which events are members of a stock market crash complex event. Complex events may be created of simple events or other complex events by an IoT resource or the IoT backend instance.
  • IoT Backend. Provides management functionalities for the devices and IoT domain-specific support for the applications. Integrant component of FI-WARE instances.
  • IoT application. An application that uses the application programming interface of the IoT service enablement component. May have parts running on one/set of devices, one/set of IoT gateways and one/set of IoT backends.
  • Virtual thing. It is the digital representation of a thing inside the IoT service enablement component. Consists of a set of properties which are interesting to a person or an application from the perspective of a FI-WARE instance, one particular usage area or to several usage areas. Classes of things have the same set of properties, only the value of the properties change from instance to instance.
Personal tools
Create a book