Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "SensiNact/AppManager"

(If button state is ON, and slider is over 500 then turn on the light)
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= AppManager =
 
 
 
The AppManager aims at creating higher level applications based on the resources provided by the sensiNact gateway. The AppManager provides a way to develop event driven applications, i.e., based on the Event-Condition-Actions (ECA) axiom. Thus, the application is only triggered when the required events occur. Then, if all conditions are satisfied, the actions are done. Events are created from sNa sensors and the actions are performed using the sNa actuators available in the environment.
 
The AppManager aims at creating higher level applications based on the resources provided by the sensiNact gateway. The AppManager provides a way to develop event driven applications, i.e., based on the Event-Condition-Actions (ECA) axiom. Thus, the application is only triggered when the required events occur. Then, if all conditions are satisfied, the actions are done. Events are created from sNa sensors and the actions are performed using the sNa actuators available in the environment.
  
== Data model and JSON format ==
+
= Data model and JSON format =
  
 
The AppManager assumes that an application is a set of bound components. Each component processes a single function (e.g., addition, comparison, action). The result of this function is stored in a variable in the current instance of the application. The components using this result as input listen to the corresponding variable. When the variable changes, they are notified and can process their own function leading to a new result.
 
The AppManager assumes that an application is a set of bound components. Each component processes a single function (e.g., addition, comparison, action). The result of this function is stored in a variable in the current instance of the application. The components using this result as input listen to the corresponding variable. When the variable changes, they are notified and can process their own function leading to a new result.
Line 9: Line 7:
 
[[File:sna_component.png|300px|An AppManager component]]
 
[[File:sna_component.png|300px|An AppManager component]]
  
=== Data model of a component ===
+
== Data model of a component ==
  
 
The component is the atomic element of an application, thus an application can consider a single component to perform an action. It holds the minimal requirements to create an ECA application:
 
The component is the atomic element of an application, thus an application can consider a single component to perform an action. It holds the minimal requirements to create an ECA application:
Line 23: Line 21:
 
[[File:sna-appmanager_data_model.png|800px|The data model of the AppManager]]
 
[[File:sna-appmanager_data_model.png|800px|The data model of the AppManager]]
  
=== Component example ===
+
== Component example ==
  
 
The following JSON code example corresponds to the code of a single component:
 
The following JSON code example corresponds to the code of a single component:
Line 53: Line 51:
 
This component specifies that when the <code>resource1</code> is greater or equals to <code>100</code>, the <code>function_name</code> is called with the <code>string</code> parameter <code>"ON"</code>. The result of the function is stored in the fixed <code>output</code> variable, available at the URI: <code>/application_name/component_name/output</code> in the OSGi registry, and triggers a new event that may be used by others components.
 
This component specifies that when the <code>resource1</code> is greater or equals to <code>100</code>, the <code>function_name</code> is called with the <code>string</code> parameter <code>"ON"</code>. The result of the function is stored in the fixed <code>output</code> variable, available at the URI: <code>/application_name/component_name/output</code> in the OSGi registry, and triggers a new event that may be used by others components.
  
=== Description of the fields of the JSON ===
+
== Description of the fields of the JSON ==
  
==== Access to a parameter ====
+
=== Access to a parameter ===
  
 
The variable or resources present in the component must be provided with their full URI. For a sNa resource you must provide: <code>/provider/service/resource</code>. For a variable you must provide <code>/application_name/component_name/output</code>, where the <code>application_name</code> is the name of the application, <code>component_name</code> is the identifier of the component, i.e., the field <code>identifier</code> and <code>output</code> is a fixed name.
 
The variable or resources present in the component must be provided with their full URI. For a sNa resource you must provide: <code>/provider/service/resource</code>. For a variable you must provide <code>/application_name/component_name/output</code>, where the <code>application_name</code> is the name of the application, <code>component_name</code> is the identifier of the component, i.e., the field <code>identifier</code> and <code>output</code> is a fixed name.
  
==== Types of parameters ====
+
=== Types of parameters ===
  
 
Supported types are:
 
Supported types are:
Line 90: Line 88:
 
|}
 
|}
  
==== Function field ====
+
=== Function field ===
  
 
The function object in the JSON requires to provide at least the name of the function that is called in the component (field <code>name</code>) and the runtime parameters associated to the function (field <code>runparameters</code>) which are defined for each function and are available in the JSON schema of each function.  
 
The function object in the JSON requires to provide at least the name of the function that is called in the component (field <code>name</code>) and the runtime parameters associated to the function (field <code>runparameters</code>) which are defined for each function and are available in the JSON schema of each function.  
Line 96: Line 94:
 
The field <code>buildparameters</code> might be required to instantiate the component before the processing of the first event. This field is optional and you have to refer to the JSON schema of each function to determine if you have to specify it or not.
 
The field <code>buildparameters</code> might be required to instantiate the component before the processing of the first event. This field is optional and you have to refer to the JSON schema of each function to determine if you have to specify it or not.
  
==== Properties field ====
+
=== Properties field ===
  
 
This optional field aims at providing various properties associated to the component. For now, the available properties are:
 
This optional field aims at providing various properties associated to the component. For now, the available properties are:
 
* <code>register</code> (boolean): enable to share publicly the result of the component. It enable to create virtual resources that can be used by others applications. Default is false.
 
* <code>register</code> (boolean): enable to share publicly the result of the component. It enable to create virtual resources that can be used by others applications. Default is false.
  
==== JSON validation ====
+
=== JSON validation ===
  
 
The AppManager supports the validation of the JSON files against a JSON schema. Schemas exist in the plugins and may be used by the developers of the applications. In order to provide a validation of the application during the installation phase, a JSON validator has been integrated.
 
The AppManager supports the validation of the JSON files against a JSON schema. Schemas exist in the plugins and may be used by the developers of the applications. In order to provide a validation of the application during the installation phase, a JSON validator has been integrated.
  
== Architecture ==
+
= Architecture =
  
 
The AppManager is designed to be used as any sNa service provider. Thus it provides an Install and an Uninstall resources, enabling a client to install/uninstall an application. These resources are accessible using different bridges, such as any actuators.
 
The AppManager is designed to be used as any sNa service provider. Thus it provides an Install and an Uninstall resources, enabling a client to install/uninstall an application. These resources are accessible using different bridges, such as any actuators.
Line 111: Line 109:
 
The AppManager architecture is also designed to easily add new functions and to handle the lifecycle of applications in order to perform checks.
 
The AppManager architecture is also designed to easily add new functions and to handle the lifecycle of applications in order to perform checks.
  
=== Plugins ===
+
== Plugins ==
  
 
Plugins enable to add new function to the AppManager. New plugins require to implements the mandatory interfaces Java interface to be found in the OSGi registry and thus be used by the AppManager. The AppManager is currently supporting the following functions.
 
Plugins enable to add new function to the AppManager. New plugins require to implements the mandatory interfaces Java interface to be found in the OSGi registry and thus be used by the AppManager. The AppManager is currently supporting the following functions.
Line 123: Line 121:
 
|}
 
|}
  
=== Lifecycle ===
+
== Lifecycle ==
  
 
The AppManager provides a lifecycle to manage the applications. It enables to process various checks during different steps of the lifecycle of the application (e.g., ADL consistency, resources permissions). The first step is to install the application, i.e., send the ADL of the application. If there is a problem, the AppManager returns an error. Once the application is installed, it can be started and its state changes to “Resolving”. If there is a problem during this step, the application enters in the “Unresolved” state. Otherwise, the application is active until it is stopped or an exception occurs.  
 
The AppManager provides a lifecycle to manage the applications. It enables to process various checks during different steps of the lifecycle of the application (e.g., ADL consistency, resources permissions). The first step is to install the application, i.e., send the ADL of the application. If there is a problem, the AppManager returns an error. Once the application is installed, it can be started and its state changes to “Resolving”. If there is a problem during this step, the application enters in the “Unresolved” state. Otherwise, the application is active until it is stopped or an exception occurs.  
Line 129: Line 127:
 
[[File:sna_lifecycle.png|300px|The lifecycle of a sensiNact application]]
 
[[File:sna_lifecycle.png|300px|The lifecycle of a sensiNact application]]
  
=== Instances ===
+
== Instances ==
  
 
The AppManager allows multiple instances of the same application to run in parallel. When an event occurs, the <code>InstanceFactory</code> of the application instantiates a new set of components and passes the event to the first component. The number of instances can be set in the application properties. If, there is more events than available instances, events are stored and processed when an instance ends.
 
The AppManager allows multiple instances of the same application to run in parallel. When an event occurs, the <code>InstanceFactory</code> of the application instantiates a new set of components and passes the event to the first component. The number of instances can be set in the application properties. If, there is more events than available instances, events are stored and processed when an instance ends.
  
== Installation ==
+
= Installation =
  
 
To install the AppManager, you just need to copy the JAR in the sNa Gateway. Usually, it is copied in the $SNA_HOME/load/application. No dependencies are required for this bundle.
 
To install the AppManager, you just need to copy the JAR in the sNa Gateway. Usually, it is copied in the $SNA_HOME/load/application. No dependencies are required for this bundle.
  
== How to use ==
+
= Advanced Features =
  
=== Base ===
+
== Introduction ==
  
 
The AppManager is accessible as any resources in the sensiNact Gateway. Thus, it is accessible using the REST Northbound bridge. At start, the AppManager holds only the AdminService. To install/uninstall an application, you have to perform an ACT on the INSTALL/UNINSTALL resources in the AdminService of the AppManager.
 
The AppManager is accessible as any resources in the sensiNact Gateway. Thus, it is accessible using the REST Northbound bridge. At start, the AppManager holds only the AdminService. To install/uninstall an application, you have to perform an ACT on the INSTALL/UNINSTALL resources in the AdminService of the AppManager.
Line 147: Line 145:
 
You can also uses a REST client (e.g., [https://www.getpostman.com/ POSTMAN]) to send JSON files to the AppManager but you will send a valid JSON file.
 
You can also uses a REST client (e.g., [https://www.getpostman.com/ POSTMAN]) to send JSON files to the AppManager but you will send a valid JSON file.
  
=== SNA Auto Resolution (SAR) ===
+
== SNA Auto Resolution (SAR) ==
  
The initial behavior of Application Manager is to be passive in relation to the application dependency, meaning that the user should control the dependencies manually, by try and error method, thus checking up the application content manually and verify that all the dependencies are satisfied, and just then start the application.
+
The default behavior of Application Manager itself is create an independent entity inside Sensinact Gateway that will establish a link among sensors and actuators according to custom conditions defined by Common Intermediate Language (CIL) named SNA. SNA is a ECA component description HyperText Application Language (HAL) that is interpreted by AppManager to materialize an external user will. This is called an ''application'', an application points to different resouces, in which one part of them will serve as input by providing their current data, and others will be user as actuators.
  
This is where The SNA Auto Resolution service comes it. It will watch the platform resource availability and verify the resources required by the application applications deployed, and for those application which the dependencies are satisfied, it will be start the application automatically.  
+
<pre>
 +
// #1 Dependencies
 +
resource LIGHTON=[gateway/light/switch/turn_on]
 +
resource LIGHTOFF=[gateway/light/switch/turn_off]
 +
resource SLIDER=[localhost/slider/cursor/position]
 +
// #2 Business rule
 +
on SLIDER.subscribe() 
 +
if SLIDER.get() > 200  do
 +
    LIGHTON.act()
 +
else do
 +
    LIGHTOFF.act()
 +
end if
 +
</pre>
  
In the opposite side, case any of the resources required disappears while the application is ACTIVE, the application will switch to INSTALLED state until the resource is back online, if so the application will be back to ACTIVE.
+
Above is an example of SNA Application, as seen above this application declares sensors, ''SLIDER'', and actuators, ''LIGHTON'' and ''LIGHTOFF''. The role of application manager once the application is started is to create an independent system that will follow the data updates on the sensors and execute the business rules defined in the application. The start procedure of an application is entirely manual, the user must to ensure that all resource required by the application are present in the platform at the moment he invokes the START method of the application deployed, which can be done via the RESTful API or via Sensinact Studio.
 +
 
 +
In order to overcome this limitation a feature called SAR is embbeded in the AppManager to allow the user to deploy independent application in which their activation will be taken care by the SAR system, which will monitor the resource availability in the platform and will ''wake up'' the applications in which their sensor/actuators requirements can be fulfilled. It will watch the platform resource availability and verify the resources required by the application applications are deployed, and for those application which the dependencies are satisfied, it will start the application automatically.
 +
 
 +
SAR is alive during the entire application lifecycle, if any of the resources required by a given application disappears while the application is ACTIVE, the application will become INSTALLED until all the required resources are back online.
  
 
It is important to notice that the property ''autostart'' MUST be set to ''true'' in case you want the SNA Auto Resolution handle the dependency resolution for you.
 
It is important to notice that the property ''autostart'' MUST be set to ''true'' in case you want the SNA Auto Resolution handle the dependency resolution for you.
 +
 +
The SNA application example given above is the exact source of the SNA HAL produced in the example [0]
  
 
[[File:SNAAppSAR.jpg|700px|SNA Auto Resolution]]
 
[[File:SNAAppSAR.jpg|700px|SNA Auto Resolution]]
  
=== Persistent SNA Applications ===
+
== Persistent SNA Applications (PSA) ==
  
The default behavior of an SNA application is to live as long as the Gateway instance is up and running, not persistent during after reboots.  
+
The default behavior of an SNA application is to live as long as the Gateway instance is up and running, not persistent after reboots.  
  
 
Eventhough this is the default behavior, it is possible to indicated to the AppManager to persist the application in a storage system. Native implementation of the storage system is to persist the SNA Application in the gateway filesystem.
 
Eventhough this is the default behavior, it is possible to indicated to the AppManager to persist the application in a storage system. Native implementation of the storage system is to persist the SNA Application in the gateway filesystem.
Line 189: Line 205:
 
[[File:SNAAppPersistent.png|800px|Persitent App components]]
 
[[File:SNAAppPersistent.png|800px|Persitent App components]]
  
=== Example of using Persistent Applications ===
+
== Testing examples ==
  
The ''json'' payload shown below is an SNA Application, this is exactly the same payload recognized by REST API of the AppManager service. Meaning that this content[0] can be sent directly via REST API by calling the resource INSTALL of AppManager provider or deployed in a text file named ''lamp.json'' in the folder ''application'' of sensinact gateway. This all can be done without the gateway restart.
+
The ''json'' payload shown in ''examples'' section is an SNA Application, this is exactly the same payload recognized by REST API of the AppManager service.  
  
The application below connects the simulated ''slider'' and the ''light'', the application monitors the ''slider'' position and case the position is over ''200'', it should turn on the light.
+
Meaning that presented in the ''examples'' section can be either deployed using REST API by calling the resource INSTALL of AppManager provider; or deployed in a by creating a text file with the extension ''.json'' in the folder ''application'' of Sensinact Gateway. The deployment will be taken into account directly by the gateway if it is already running, no need to reload.
  
=== SNA Application examples ===
+
= SNA Application examples =
  
==== If simulated slider value is over 200, turn on the light, otherwise turn it off[0] ====
+
== If simulated slider value is over 200, turn on the light, otherwise turn it off [0] ==
 
   
 
   
 
<pre>
 
<pre>
Line 291: Line 307:
 
             },
 
             },
 
             "initialize":{   
 
             "initialize":{   
"options":{"autostart":false}
+
"options":{"autostart":true}
 
             }
 
             }
 
         }
 
         }
Line 299: Line 315:
 
</pre>
 
</pre>
  
==== Connect simulated slider value into display[1] ====
+
== Show the simulated slider value INTO billboard [1] ==
  
 
<pre>
 
<pre>
Line 314: Line 330:
 
         "value":{   
 
         "value":{   
 
             "initialize":{   
 
             "initialize":{   
"autorestart":true
+
"options":{"autostart":true}
 
             },
 
             },
 
             "application":[   
 
             "application":[   
Line 357: Line 373:
 
</pre>
 
</pre>
  
==== If button state is ON, and slider is over 500 then turn on the light[2] ====
+
== If button state is ON , AND slider is over 500 then turn on the light [2] ==
  
 
<pre>
 
<pre>
Line 499: Line 515:
 
             },
 
             },
 
             "initialize":{   
 
             "initialize":{   
 
+
"options":{"autostart":true}
 
             }
 
             }
 
         }
 
         }
Line 507: Line 523:
 
</pre>
 
</pre>
  
== Known issues ==
+
= Known issues =
  
 
No issues for now.
 
No issues for now.

Revision as of 10:02, 23 October 2018

The AppManager aims at creating higher level applications based on the resources provided by the sensiNact gateway. The AppManager provides a way to develop event driven applications, i.e., based on the Event-Condition-Actions (ECA) axiom. Thus, the application is only triggered when the required events occur. Then, if all conditions are satisfied, the actions are done. Events are created from sNa sensors and the actions are performed using the sNa actuators available in the environment.

Data model and JSON format

The AppManager assumes that an application is a set of bound components. Each component processes a single function (e.g., addition, comparison, action). The result of this function is stored in a variable in the current instance of the application. The components using this result as input listen to the corresponding variable. When the variable changes, they are notified and can process their own function leading to a new result.

An AppManager component

Data model of a component

The component is the atomic element of an application, thus an application can consider a single component to perform an action. It holds the minimal requirements to create an ECA application:

  • Identifier: the unique name of the component in the application ;
  • Events: events that trigger the process of a component. Trigger can be conditioned to a specific event or a specific value of the event (e.g., when the value of the sensor reach a threshold) ;
  • Function: function wrapped in the component (e.g., addition, comparison, action). The acquisition of the parameters is realized in the transition block before the function block. This object includes the name of the function and the parameters of the function that are not available in the event (e.g., static value, sensors values) ;
  • Properties: nonfunctional properties of the component (e.g., register the result as a new resource in sNa).

The AppManager is a sNa service provider, thus it provides an Install and an Uninstall resources, enabling a client to install/uninstall an application. These resources are accessible using different bridges.

A sNa application is described using a JSON file. We developed a specific Architecture Description Language (ADL) to describe the components used in an application and the bindings between the components. Below you will find the data model of the ADL of a component. The dotted line box are optional information in the component.

The data model of the AppManager

Component example

The following JSON code example corresponds to the code of a single component:

{
 "identifier": "identifier",
 "events": [
 {
   "value": "resource1",
   "type": "resource",
   "conditions": [{
     "operator": ">=",
     "value": 100,
     "type": "integer",
     "complement": false
   }]
 }],
 "function": {
   "name": "function_name",
   "runparameters": [
   {
     "value": "ON",
     "type": "string"
   }
 },
 "properties": {}
}

This component specifies that when the resource1 is greater or equals to 100, the function_name is called with the string parameter "ON". The result of the function is stored in the fixed output variable, available at the URI: /application_name/component_name/output in the OSGi registry, and triggers a new event that may be used by others components.

Description of the fields of the JSON

Access to a parameter

The variable or resources present in the component must be provided with their full URI. For a sNa resource you must provide: /provider/service/resource. For a variable you must provide /application_name/component_name/output, where the application_name is the name of the application, component_name is the identifier of the component, i.e., the field identifier and output is a fixed name.

Types of parameters

Supported types are:

  • Primitives types: integer, boolean, long, double, float, string. This is used to described a static variable;
  • Resource type: resource. This is used to refer to a resource. If this is set in the JSON Event section of the JSON, a SUBSCRIBE is done on the resource. If this is done in any JSON Parameters section, a GET is done on the resource and returns the current value;
  • Variable type: variable. This is used to refer to the output of a previously processed component;

Here after is a synthesis of the type that can be used in the different parts of the JSON file.

Primitive types Resource type Variable type
In event type No Yes Yes
In event/condition type Yes Yes Yes
In parameters type Yes Yes Yes

Function field

The function object in the JSON requires to provide at least the name of the function that is called in the component (field name) and the runtime parameters associated to the function (field runparameters) which are defined for each function and are available in the JSON schema of each function.

The field buildparameters might be required to instantiate the component before the processing of the first event. This field is optional and you have to refer to the JSON schema of each function to determine if you have to specify it or not.

Properties field

This optional field aims at providing various properties associated to the component. For now, the available properties are:

  • register (boolean): enable to share publicly the result of the component. It enable to create virtual resources that can be used by others applications. Default is false.

JSON validation

The AppManager supports the validation of the JSON files against a JSON schema. Schemas exist in the plugins and may be used by the developers of the applications. In order to provide a validation of the application during the installation phase, a JSON validator has been integrated.

Architecture

The AppManager is designed to be used as any sNa service provider. Thus it provides an Install and an Uninstall resources, enabling a client to install/uninstall an application. These resources are accessible using different bridges, such as any actuators.

The AppManager architecture is also designed to easily add new functions and to handle the lifecycle of applications in order to perform checks.

Plugins

Plugins enable to add new function to the AppManager. New plugins require to implements the mandatory interfaces Java interface to be found in the OSGi registry and thus be used by the AppManager. The AppManager is currently supporting the following functions.

Plugin Functions supported
Basic Plugin various operators (e.g., equals, greater than, lesser than, different), addition, subtraction, division, multiplication, modulo, concatenation, substring, ACT and SET methods on resources

Lifecycle

The AppManager provides a lifecycle to manage the applications. It enables to process various checks during different steps of the lifecycle of the application (e.g., ADL consistency, resources permissions). The first step is to install the application, i.e., send the ADL of the application. If there is a problem, the AppManager returns an error. Once the application is installed, it can be started and its state changes to “Resolving”. If there is a problem during this step, the application enters in the “Unresolved” state. Otherwise, the application is active until it is stopped or an exception occurs.

The lifecycle of a sensiNact application

Instances

The AppManager allows multiple instances of the same application to run in parallel. When an event occurs, the InstanceFactory of the application instantiates a new set of components and passes the event to the first component. The number of instances can be set in the application properties. If, there is more events than available instances, events are stored and processed when an instance ends.

Installation

To install the AppManager, you just need to copy the JAR in the sNa Gateway. Usually, it is copied in the $SNA_HOME/load/application. No dependencies are required for this bundle.

Advanced Features

Introduction

The AppManager is accessible as any resources in the sensiNact Gateway. Thus, it is accessible using the REST Northbound bridge. At start, the AppManager holds only the AdminService. To install/uninstall an application, you have to perform an ACT on the INSTALL/UNINSTALL resources in the AdminService of the AppManager.

To send JSON files, it is recommanded to use the sensiNact Studio that will format the JSON ADL from the sNa language.

You can also uses a REST client (e.g., POSTMAN) to send JSON files to the AppManager but you will send a valid JSON file.

SNA Auto Resolution (SAR)

The default behavior of Application Manager itself is create an independent entity inside Sensinact Gateway that will establish a link among sensors and actuators according to custom conditions defined by Common Intermediate Language (CIL) named SNA. SNA is a ECA component description HyperText Application Language (HAL) that is interpreted by AppManager to materialize an external user will. This is called an application, an application points to different resouces, in which one part of them will serve as input by providing their current data, and others will be user as actuators.

// #1 Dependencies 
resource LIGHTON=[gateway/light/switch/turn_on]
resource LIGHTOFF=[gateway/light/switch/turn_off]
resource SLIDER=[localhost/slider/cursor/position]
// #2 Business rule
on SLIDER.subscribe()  
if SLIDER.get() > 200  do
    LIGHTON.act()
else do 
    LIGHTOFF.act()
end if

Above is an example of SNA Application, as seen above this application declares sensors, SLIDER, and actuators, LIGHTON and LIGHTOFF. The role of application manager once the application is started is to create an independent system that will follow the data updates on the sensors and execute the business rules defined in the application. The start procedure of an application is entirely manual, the user must to ensure that all resource required by the application are present in the platform at the moment he invokes the START method of the application deployed, which can be done via the RESTful API or via Sensinact Studio.

In order to overcome this limitation a feature called SAR is embbeded in the AppManager to allow the user to deploy independent application in which their activation will be taken care by the SAR system, which will monitor the resource availability in the platform and will wake up the applications in which their sensor/actuators requirements can be fulfilled. It will watch the platform resource availability and verify the resources required by the application applications are deployed, and for those application which the dependencies are satisfied, it will start the application automatically.

SAR is alive during the entire application lifecycle, if any of the resources required by a given application disappears while the application is ACTIVE, the application will become INSTALLED until all the required resources are back online.

It is important to notice that the property autostart MUST be set to true in case you want the SNA Auto Resolution handle the dependency resolution for you.

The SNA application example given above is the exact source of the SNA HAL produced in the example [0]

SNA Auto Resolution

Persistent SNA Applications (PSA)

The default behavior of an SNA application is to live as long as the Gateway instance is up and running, not persistent after reboots.

Eventhough this is the default behavior, it is possible to indicated to the AppManager to persist the application in a storage system. Native implementation of the storage system is to persist the SNA Application in the gateway filesystem.

Application Manager itself alow the administrator to customize a certain number of properties, the currently available configurable properties.

  • applicationPersist: mandatory field, this field specify if the Application Manager should persist the application in the filesystem and reload those applications in case of the Sensinact Gateway restart. This is a boolean type field
  • updateFileCheck: mandatory field, this property define the number, in miliseconds, that persistence system should wait until the next verification to check up on modification or new deployments in the directory defined for such purpose, which is defined in directory property below.
  • directory: optional field, this property defines which directory will be watched in order to load (at startup) and monitor the file modification in order to reload the application in the gateway. The value of this property is an alphanumeric value.
  • applicationFileExtension: optional field, with default value set to json, this means that the application persistence monitor will target only file with the ".json" extention. You may change this extension by modifying this property. This is an alphanumeric value.

In case of non-respect of the value mask expected on each of those properties, the LOG system will warn you about the invalid value provided, thus, pay attention to the DEBUG logs to know exactly what is expected by those properties.

This configuration file is deployed on the designed directory to configure Sensinact service bundles. In the case of Application Manager, it will take into consideration the configuration file deployed in cfgs directory in the gateway base directory named application-manager.properties

Below is an example of a property configuration file content:

directory=application
applicationPersist=true
updateFileCheck=2000
applicationFileExtension=json

One important restriction that worth to mention is that it is mandatory that the application name defined into an application JSON definition is the same as the filesystem name (without the extention), case the application name and the file name do not match the application deployment will be bypassed and ignored by the next verification cycle.

Persitent App components

Testing examples

The json payload shown in examples section is an SNA Application, this is exactly the same payload recognized by REST API of the AppManager service.

Meaning that presented in the examples section can be either deployed using REST API by calling the resource INSTALL of AppManager provider; or deployed in a by creating a text file with the extension .json in the folder application of Sensinact Gateway. The deployment will be taken into account directly by the gateway if it is already running, no need to reload.

SNA Application examples

If simulated slider value is over 200, turn on the light, otherwise turn it off [0]

{  
   "parameters":[
      {  
         "name":"name",
         "type":"string",
         "value":"lamp"
      },
      {  
         "name":"content",
         "type":"object",
         "value":{  
            "application":[  
               {  
                  "identifier":"condition",
                  "function":{  
                     "name":"greaterThan",
                     "runparameters":[  
                        {  
                           "type":"resource",
                           "value":"/slider/cursor/position"
                        },
                        {  
                           "type":"long",
                           "value":200
                        }
                     ]
                  },
                  "events":[  
                     {  
                        "type":"resource",
                        "value":"/slider/cursor/position"
                     }
                  ]
               },
               {  
                  "identifier":"turnonlamp",
                  "function":{  
                     "name":"act",
                     "runparameters":[  
                        {  
                           "type":"resource",
                           "value":"/light/switch/turn_on"
                        }
                     ]
                  },
                  "events":[  
                     {  
                        "type":"variable",
                        "conditions":[  
                           {  
                              "type":"boolean",
                              "complement":false,
                              "value":true,
                              "operator":"="
                           }
                        ],
                        "value":"/lamp/condition/result"
                     }
                  ]
               },
               {  
                  "identifier":"turnofflamp",
                  "function":{  
                     "name":"act",
                     "runparameters":[  
                        {  
                           "type":"resource",
                           "value":"/light/switch/turn_off"
                        }
                     ]
                  },
                  "events":[  
                     {  
                        "type":"variable",
                        "conditions":[  
                           {  
                              "type":"boolean",
                              "complement":true,
                              "value":true,
                              "operator":"="
                           }
                        ],
                        "value":"/lamp/condition/result"
                     }
                  ]
               }
            ],
            "finalize":{  

            },
            "initialize":{  
		"options":{"autostart":true}
            }
         }
      }
   ]
}

Show the simulated slider value INTO billboard [1]

{  
   "parameters":[  
      {  
         "name":"name",
         "type":"string",
         "value":"simple_test_subscription"
      },
      {  
         "name":"content",
         "type":"object",
         "value":{  
            "initialize":{  
				"options":{"autostart":true}
            },
            "application":[  
               {  
                  "identifier":"result1",
                  "events":[  
                     {  
                        "value":"/slider/cursor/position",
                        "type":"resource",
                        "conditions":[  
                           {  
                              "operator":"greaterEqual",
                              "value":600,
                              "type":"int",
                              "complement":false
                           }
                        ]
                     }
                  ],
                  "function":{  
                     "name":"act",
                     "runparameters":[  
                        {  
                           "value":"/billboard/screen/display",
                           "type":"resource"
                        },
                        {  
                           "value":"/slider/cursor/position",
                           "type":"resource"
                        }
                     ]
                  }
               }
            ],
            "finalize":{  

            }
         }
      }
   ]
}

If button state is ON , AND slider is over 500 then turn on the light [2]

{  
   "parameters":[  
      {  
         "name":"name",
         "type":"string",
         "value":"appconjunction"
      },
      {  
         "name":"content",
         "type":"object",
         "value":{  
            "application":[  
               {  
                  "identifier":"condition",
                  "function":{  
                     "name":"and",
                     "runparameters":[  
                        {  
                           "type":"variable",
                           "value":"/appconjunction/condition1/result"
                        },
                        {  
                           "type":"variable",
                           "value":"/appconjunction/condition2/result"
                        }
                     ]
                  },
                  "events":[  
                     {  
                        "type":"variable",
                        "value":"/appconjunction/condition1/result"
                     },
                     {  
                        "type":"variable",
                        "value":"/appconjunction/condition2/result"
                     }
                  ]
               },
               {  
                  "identifier":"condition1",
                  "function":{  
                     "name":"greaterThan",
                     "runparameters":[  
                        {  
                           "type":"resource",
                           "value":"/slider/cursor/position"
                        },
                        {  
                           "type":"long",
                           "value":500
                        }
                     ]
                  },
                  "events":[  
                     {  
                        "type":"resource",
                        "value":"/slider/cursor/position"
                     }
                  ]
               },
               {  
                  "identifier":"condition2",
                  "function":{  
                     "name":"equal",
                     "runparameters":[  
                        {  
                           "type":"resource",
                           "value":"/button/switch/state"
                        },
                        {  
                           "type":"boolean",
                           "value":true
                        }
                     ]
                  },
                  "events":[  
                     {  
                        "type":"resource",
                        "value":"/button/switch/state"
                     }
                  ]
               },
               {  
                  "identifier":"turnonlamp",
                  "function":{  
                     "name":"act",
                     "runparameters":[  
                        {  
                           "type":"resource",
                           "value":"/light/switch/turn_on"
                        }
                     ]
                  },
                  "events":[  
                     {  
                        "type":"variable",
                        "conditions":[  
                           {  
                              "type":"boolean",
                              "complement":false,
                              "value":true,
                              "operator":"="
                           }
                        ],
                        "value":"/appconjunction/condition/result"
                     }
                  ]
               },
               {  
                  "identifier":"turnofflamp",
                  "function":{  
                     "name":"act",
                     "runparameters":[  
                        {  
                           "type":"resource",
                           "value":"/light/switch/turn_off"
                        }
                     ]
                  },
                  "events":[  
                     {  
                        "type":"variable",
                        "conditions":[  
                           {  
                              "type":"boolean",
                              "complement":false,
                              "value":false,
                              "operator":"="
                           }
                        ],
                        "value":"/appconjunction/condition/result"
                     }
                  ]
               }
            ],
            "finalize":{  

            },
            "initialize":{  
				"options":{"autostart":true}
            }
         }
      }
   ]
}

Known issues

No issues for now.

Back to the top