Received Files

<< Click to Display Table of Contents >>

Navigation:  Nodes > Input > Triggers >

Received Files

 

Purpose

 

Mistika Workflows provides a REST-API to communicate with it. This node receives file uploads made via the Mistika Workflows REST-API, and it will trigger the workflow execution when receiving new files.

 

The File -> Preferences -> Network Listener menu defines the ip address and network ports where Workflows is listening for the REST-API.

 

We will illustrate it with a basic example:  Let's suppose that:

 

- The ip of the server running Mistika Workflows is 192.168.1.10.

 

- In the client computer we want to upload this file to the server: C:/temp/MyFile.mov

 

In Mistika Workflows (server computer), create an Received Filesnode with receivedFilesID = MyCustomId, and connect it to a pyPrintInputs node, and add the workflow to the queue. That way it will start listening for upload requests.

 

Then execute this command in the console of the client computer:

 

curl "http://192.168.1.10:8889/upload?overwrite=true&groupID=MyCustomId" -H "X-Filename: MyFile.mov"  -F "file=@C:/temp/MyFile.mov"

 

The MyFile.mov file will be uploaded to the server, and the pyPrintInputs node will print its metadata in the Script Editor panel. Meanwhile in the client console the command will show some metadata fields, such as the temporal folder used to store the file in the server and the operation result (either "ok" or an error description).  

 

For more useful examples you could connect the output of the Received Files node to other nodes,  such as encoder nodes to transcode received files to your preferred formats, or to a move node to store the uploaded file in a particular location.

 

The Workflows Bridge portal is another usage example based on this node, in this case it can provide a "push" method by receiving the EDL files from the Bridge portal as a trigger for the desired workflow (but note that the Bridge portal also has an alternative "pull" method via the Bridge In node )

 

 

Outputs

 

Out: To pass received files to other nodes.

 

 

Standard properties

Object Name

Color

Bypass

Lock

Name Convention

 

Path properties

Include

Exclude

Filter Mode

File Name Only

 

 

Node specific properties

 

Received Files ID (known as groupID in the REST-API): A user-defined identifier passed as a URL parameter during the upload. Each node instance will only be triggered by uploads providing the same id. In this way you can have multiple Received Files nodes waiting for each different upload, and each node will one react to the stream of files with this ID.

Also note that you can still send the same files to multiple nodes of different workflows if that is what you want, by just using the same Received Files ID value.

 

Delete After Processing: When enabled, the uploaded file is deleted from the temporary folder once it has been processed by downstream nodes.

 

Maintain Padding: When enabled, the original frame-number padding of file sequences is preserved in the output.

 

Render Farm Split Content: When enabled, the content can be split for distributed rendering across a render farm.

 

NOTE: The file uploads are stored in the default temporal folder of the server (which is OS dependent). If you need to change it just set the  <temppath> variable in this file:

 

SGO AppData/Workflows/localPreferences.xml

 

Example:

 

...

<networkListener>

   <ip>192.168.1.142</ip>

   <maxRequestSize>32</maxRequestSize>

   <port>8889,8890,8891,8892,8893,8894,8895,8896,8897,8898,8899</port>

   <temppath>D:/My/Desired/Uploads/Path</temppath>

 </networkListener>

...

 

Note that the temppath is also used to check if there is enough disk space for the incoming upload before starting it (otherwise the upload command will return a "413 Entity too large" error).  Also, there is an absolute limit defined by the maxRequestSize variable (in Gigabytes, being 32GB by default). For example you can reduce it if you expect potential abuse of storage resources from the client side.

 

In case of connection failures, a useful command for troubleshooting is this (using the same ip as in the above example):

 

curl "http://192.168.1.10:8889/info"

 

This will just check the connection and return basic metadata.

 

Developer reference (API Rest - node/ReceivedFiles/property/[Property ID])

 

Property Label

Property ID

receivedFilesId

receivedFilesId

deleteAfterProcessing

deleteAfterProcessing

Filter Mode

filterMode

File Name Only

fileNameOnly

Include

include

Exclude

exclude

Maintain Padding

maintainPadding

renderFarmSplitContent

renderFarmSplitContent