It is possible to create a Proc.Logic to receive data/message from an MQTT broker and their transformation to create an Entity Instance (of a known Entity Model) and use the debug to see eventual ingestion errors. This approach reported in this case in the following flow, is not optimal since at each new message from MQTT the Entity Directory is queried to see if the Entity has already been created in the past and if not to create it and then pass the data to register the message. In most cases, it is much better to decouple the activity of creating with respect to that of sending message. In fact, this approach would largely reduce the ingestion rate and probably when the Entities are already created would create un-useful workload on Entity Directory (IoT Directory).

8). 

Thus, if you have to ingest 1M of messages of a new Entity, you perform 1M of searches to understand if the device exists (all of them, except 1 will fail) and thus you do about 1M of messages on storage. So that, about 2M of actions to succeed 1M.

In most cases, the flow should be designed in the opposite order with this logic: try to send the Entity Message, if it fails than create a new Entity Instance by known model, and if successful send again the Entity Message, or just wait for the new message to save it the first. 

 

In this second case, if you have to ingest 1M of messages of a new Entity, you perform 1M posts on storage, and you got one fail. You try if the device exists, if not you create. So that about 1M of actions to succeed 1M.

Moreover, according to partner (8) it may happen that at each new message a new device is created, and a data is inserted into the platform since the first Function has a DeviceName depending on the message id, this implies that each new message from MQTT would create a brand new device with only one data inside. In this case, the flow (8) may be totally wrong since the Time Series is never create and thousands of single data are in the storage and they are not connected each other.