Differences

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

--- custom_proc:custom_processors [2020/11/16 11:26] – emcodem
+++ custom_proc:custom_processors [2023/10/25 15:42] (current) – [Plugin Development] emcodem
@@ Line 10: / Line 10: @@
 So the folder \Processors\plugin_nodes\custom_nodes can only contain folders, not files. Each subfolder represents one plugin processor. For information about the contents of each plugin subfolder, keep on reading.
-{{:custom_proc:plugin_base_dir.png?400|}}
+{{gallery>:custom_proc:plugin_base_dir.png?400x400&800X800&lightbox}}
 In this picture, we see the plugin base directory \Processors\plugin_nodes\custom_nodes. The 2 folders represent each one custom plugin.
-{{:custom_proc:plugin.png?400|}}
+{{gallery>:custom_proc:plugin.png?400x400&800X800&lightbox}}
 In this picture we see the contents of an example plugin. The file style.css is not mandatory, it is just used by this processor's index.html. The folder /bin is mandatory, it must contain the script/executeable.
@@ 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 118: / Line 119: @@
 This index.html is used to create the User interface of the processor in the workflow editor ONLY, it is not involved in the actual execution of the processor in a running job. You can create a custom web page that accepts inputs from the user. The input names and values of the saved processor instance in your workflow are passed using a temp JSON file to the processor.exe.
-{{:custom_proc:custom_proc.png?400|}}
+{{gallery>:custom_proc:custom_proc.png?400x400&lightbox}}
 In the picture above, you see the area in green where your index.html is rendered using IE11. You cannot change the area outside as those buttons are created by FFAStrans host. The only thing you can influence is the display height by altering the plugin definition json.
@@ 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>