Differences

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

--- custom_proc:custom_processors [2020/06/21 07:07] – 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.
 The example processor that you can download above contains examples how to use all possible functions and inteactions between the FFAStrans Engine and the index.html.
 When a user opens the processor GUI on the workflow editor, FFAStrans will create an Embedded Browser which is Internet Explorer 11 so always develop and test in IE 11.
+Note that on some Systems, it is needed to force the document to run in IE11 mode by having these 2 lines at the top of index.html. If you do not add this, the javascript base64 encoder and decoder atob and btoa migth not be available and your plugin might randomly not work on a recent Windows Version.
+<code>
+<!DOCTYPE html>
+<meta http-equiv="X-UA-Compatible" content="IE=11" />
+</code>
 For interacting with the embedded Browser, FFAStrans host "executes" or evaluates javascript functions with predefined names and passes Base64 encoded data as argument to the functions. See the example processor for more description. The opening procedure is like that:
@@ Line 248: / 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 270: / 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>