title: Parsing non-fixed format binary payload with a custom javascript conversion in Vorto
body: <p>We are using Vorto now mainly as a normalized format and are starting to look into using the mapping engine for mapping different payload formats to Vorto model as well. I more or less understand how to map functionblock properties from JSON or binary payload using xpath and the conversion functions. However, I'm not clear how to support parsing of non-fixed format binary payload using this method.
  For instance we have an off the shelf LoRaWAN sensor which transmits in the following format:
  <code>&lt;length&gt;&lt;frame type&gt;[&lt;sensor-id&gt;&lt;sensor-value&gt;]</code> where length is the total frame length and sensor-id (for eg temperature, humidity, battery, ...) describes how to parse the sensor-value (ie length, datatype). In one frame multiple of these readings may be present in random order.</p>
  
  <p>Parsing this can be done easily in for instance loraserver.io using a small javascript function which iterates over all the bytes en returns the parsed properties. The same way will work in the Ditto payload mapping engine afaik.
  However, currently I don't see how to do something similar in Vorto mapping. This is just one specific sensor example of course, but more examples exist on the market using similar dynamic payload format. I know there is already an open issue (#1535) to improve the documentation, but it would already be helpful to know if such flexible parsing would be possible using the mapping DSL. </p>
  
  <p>I tried passing the raw payload as bytearray to the javascript function. In order to test this I duplicated the <code>org.eclipse.vorto.mapping.engine.converter.binary.BinaryMappingTest#testMappingBinaryContaining2DataPoints</code> and adapted the model to use a custom javascript function like this</p>
  
  <pre><code>    evaluator.addScriptFunction(new ScriptClassFunction("extractTemperature",
  "function extractTemperature(value) { " +
          " print(\"parameter of type \" + typeof value + \", value = \" + value);" +
          " print(value[1]);" +
          "}"));
  </code></pre>
  
  <p>The output of this function is </p>
  
  <pre><code>parameter of type number, value = 1
  undefined
  </code></pre>
  
  <p>Where the value 1 is the first element of the bytearray used.</p>
  
  <p>So the function does not seem to receive the parameter as bytarray. 
  The model is configured with <code>.withXPathStereotype("custom:extractTemperature(data)", "demo")</code> so the payload is passed (as <code>BinaryData</code>) in the same way as in the <code>testMappingBinaryContaining2DataPoints</code> test (<code>.withXPathStereotype("custom:convert(vorto_conversion1:byteArrayToInt(data,0,0,0,2))", "demo")</code>). The only difference I see now is that in the <code>testMappingBinaryContaining2DataPoints</code> test is that the byetarray parameter is passed to a Java function instead of a javascript function. Or am I missing something?</p>
  
  <p>Also, I noticed that loop keywords like <code>for</code> and <code>while</code> are not allowed in the javascript code. So even if I can access the bytearray parameter in the javascript function I see no way for now how to iterate over this.</p>
  
  <p>On gitter I received following reply (together with the suggestion to move discussion to SO)</p>
  
  <blockquote>
    <p>You are right. We restricted the Javascript function usage to very rudimentary set of language keywords excluding for loops as nasty stuff can be implemented there. What you could do Instead is to register a java function In your own namespace to the mapping engine. That function can hold a byte array. Later this function can be contributed to the mapping engine as a standard function to extract a certain value out for other developers to reuse. </p>
  </blockquote>
  
  <p>I don't think this is solution to the problem however. As mentioned above this is just one example of an off the shelf sensor payload format, and I don't see how this can be generalized enough to include as a generic function in the mapping engine. And I don't think it should be required to implement a sensor specific conversion in Java, since (as an end-user of an IoT platform wanting to deploy a new sensor type) this is more complex to develop and deploy than a little javascript function which can be altered at runtime in the mapping spec. I see a lot of value in being able to do simple mappings in javascript, just like this can be done in for example <a href="https://www.loraserver.io/lora-app-server/use/device-profiles/" rel="nofollow noreferrer">loraserver.io</a> and <a href="https://www.eclipse.org/ditto/connectivity-mapping.html#javascript-mapping-engine" rel="nofollow noreferrer">Eclipse Ditto</a>.</p>
  
  <p>I think being able to pass a byte array to javascript is a first step. Also I wonder where exactly the risk is in allowing loops in the javascript? For example Ditto also has some restrictions in the javascript sandbox (<a href="https://www.eclipse.org/ditto/connectivity-mapping.html#sandboxing" rel="nofollow noreferrer">see here</a>) but this allows loops and only prevents endless looping and recursion. 
  They state the following:</p>
  
  <blockquote>
    <p>Using Rhino instead of Nashorn, the newer JavaScript engine shipped with Java, has the benefit that sandboxing can be applied in a better way.
    Sandboxing of different payload scripts is required as Ditto is intended to be run as cloud service where multiple connections to different endpoints are managed for different tenants at the same time. This requires the isolation of each single script to avoid interference with other scripts and to protect the JVM executing the script against harmful code execution.</p>
  </blockquote>
  
  <p>Would using Rhino in Vorto as well allow to control the risks you see and allow loop construct in Vorto mapping?</p>
  
  <p>PS: can someone with enough SO reputation points add the tag <code>eclipse-vorto</code> please? </p>