Differences

This shows you the differences between two versions of the page.

--- custom_proc:custom_processors [2021/02/09 10:41] – benjamin
+++ custom_proc:custom_processors [2023/10/25 15:42] (current) – [Plugin Development] emcodem
@@ Line 55: / Line 55: @@
   * category: display category in the workflow canvas. possible values: TODO
   * enabled: when set to 0, processor is not shown in the processor menu in workflow canvas
+  * priority: 1 is default, when set to -1, the node is not counted as a running job. Used e.g. for sleeping and waiting processes while allowing other jobs to process instead of blocking the que
   * description: tooltip of the processor icon in workflow canvas
   * ** guid: must be unique for each custom plugin**, best use a guid generator. A workflow stores the plugin based on it's guid, so the guid should not ne changed after plugin installation.
@@ Line 253: / Line 254: @@
 ** Set Outputs from a processor **
 Setting outputs is optional. If you develop a processor that is not intended to deliver any output back to ffastrans, thats ok and you do not have to read on ;-)
@@ Line 275: / Line 275: @@
     * s_job_error_msg
       * setting this will cause the FFAStrans host to go the "error" path in the workflow or end the job with error
+Usually outputs are already part of the job json because they are passed in from the processor GUI html.
+So the processor code does not have to "generate" a new object but instead it only sets the "data" attribute of existing outputs in the existing job json.
+Take special note about the field names, "id" is optional as it is just the html id of the field on index.html GUI. FFAStrans only needs to know "value" and "data", where "value" has to be some existing variable (user var or predefined system var)
+<code>
+"proc_data": {
+    "inputs": [],
+    "outputs": [
+      {
+        "id": "",
+        "value": "s_source",
+        "data": "C:\\test\\test.ts"
+      }
+    ]
+  }
+</code>