How to Dev - Examples: Processing Logic / IoT App: typical patterns

×

Warning message

  • You can't delete this newsletter because it has not been sent to all its subscribers.
  • You can't delete this newsletter because it has not been sent to all its subscribers.

 

In this section, a number of data flow patterns are reported to give at a glance some examples to create your Independent Flows of Processing Logic. The nodes used are those reported before (some of them are specific of Snap4City Library). See also:

 

BEFORE PRESENTING THE USAGE OF PROCESSING LOGIC, IOT APP FOR DATA INGESTIOB, PROCESSING, ETC. WE SHOULD POINT OUT THAT THE BEST SOLUTION TO SEND DATA INTO THE PLATFORM IS BY USING A DIRECT MESSAGE PATCH/POST ON ONE ORION BROKER, JSON NGSI V2. That approach will need for you to be authenticated on the basis of OpenID connect as described in the following in this document. It is not complex, and you will have to do it in any case to perform data access via Smart City API. So that one kind of authentication for both loading and getting data results, in secure, scalable and simple manner. ANY other usage of naïve API and HTTP call to the Proc.Logic and IoT App are viable, but present a number of problems, as described in many points in this document.

 

 

1) Hello world of node-red, the inject may provide a string to the debug.

2) Hello world of node-red at two steps, the inject provides a push while a JSON is created into the function as msg.payload = {………….} and sent/shown to/by the debug.

3) SAVE on STORAGE: Event data reception from an MQTT broker, transformation and send it to the storage pushing data into the Orion Broker V2. A better solution would be to receive data from ORION BROKER NGSI V2 JSON directly on the broker and platform without any need of using a Proc.Logic for data ingestion. This approach is viable if the Entity Instances / Devices are created in advance with some registration procedure.

4) READ from STORAGE: request on inject of a SURI to the storage to see data on debug.

5) SEARCH from STORAGE: Preparation of data request on function, query to the storage and see data result on debug.

6) Event data reception from an MQTT broker, transformation to create an Entity Instance from a known Entity Model, debug to see eventual errors, for example if the device is already present (to avoid production of error, one may verify if the Entity Instance is already present by posing a query on the system). A better solution would be to receive data from ORION BROKER directly on it without passing on the Proc.Logic. This approach is viable is the Entity Instances / Devices are already created, that I would say it is quite normal that one prepares the Entity / devices with some registration procedure.

7) Preparation of data parameters on function, request computing Data Analytic, see data result on debug.

 


In the library of nodes accessible and provide on Snap4City Libraries on Node-RED there are more than 150 nodes and microservices. A relevant number of them are provided for interoperability with other platforms and brokers or to make more advanced Proc.Logic programs. For example, a number of nodes for NGSI brokers are also to work on NGSI V1, or V1.1, and to perform query on broker, that in most of the case is not useful since the Broker does not have the ServiceURI and thus the data collected on brokers are difficult to be used.