Using the action
First, from your storyboard, find Templates on the left pane. Search for “Python” and drag on the template named “Python”. When you drag it on to the storyboard, it will prompt you to select a template from the right hand column - choose "Run Python Script". A basic sample script will generate in the Script field.
Let's go into detail about the fields on the Run Python Script.
Script
This is where to place the Python code you would like to execute.
If there are any dependencies to import for your script, declare them first as you normally would.
Define your main function and pass any inputs by using def main(input): and then write your script.
Important: you must define a main function in your script.
Define your return in the format of a JSON object. This will be the content of the event that gets emitted from the action. For example, this is the output of the sample script in the template.
Output of script
Inputs
These are the values that will be passed to your script at runtime. You can use pills in the builder to refer to any data from other actions upstream in your story.
To refer to these values in your script by calling input["<<object_name>>"].
In the template action, note that Input has a key named array_length. So, in the Script section, this is called with input["array_length"].
Requirements
List the dependencies required to run your script in the format of a requirements.txt file with each requirement separated by a new line. Example:
numpy==1.25
http==0.02Timeout
Time in seconds to wait before terminating the script. The default is 10 and the maximum is 25.
Python in Tines: How it works
Tines runs in AWS, and we make creative use of their underlying services so that we do not actually process any Python in the application. This is great for multiple reasons, but here are the top 2:
Your code is executed in a secure, regulated environment.
We did not have to update (and will not have to maintain) any of our code to support running Python in our Ruby-based platform. Granted, that is a selfish reason, but it means we get to spend more cycles building out more amazing features.
Behind the scenes
Your cloud tenant has a role that allows it to create or invoke Lambdas in our AWS environment, adjacent to your tenant. Each Lambda is only accessible by the tenant that created it.
The Lambda itself has the lambda-no-permissions role assigned, so your Lambda has zero access to any other resources.
Any packages in the Requirements will be built at runtime as Lambda Layers.
On the first run of your Python script action, you may notice a short delay while your Tines tenant dynamically builds the Lambda function required. Any subsequent requests should respond promptly.
Any time the Python script executes, we compare the script contents with the contents from the last time the Lambda was executed. If they differ, we proceed to pass the new script contents to execute the Lambda.
Note that since we are making requests to AWS, egress IPs may be different than the ones the tenant uses.
Limitations
Run Script Action is currently limited to
python3.9runtimeRun Script Action is not available for self-hosted deployments currently.
As we are using AWS lambda under the hood, we are subject to their quotas on script execution. Full listings available here
One limit of note is
requirements.txthas a package limit of250MB
Next level and best practices
1. Pull the script from your code repository. While Tines has version control and change management for your stories, we are an automation platform, not a code repository. When dealing with scripts, it is best practice to keep your code in a managed repository. Luckily, Tines makes it easy to call out to your repository of choice so you can maintain proper code hygiene and integrate your script with the rest of your Tines story. You can see an example of this in the Tines workflow below.
2. Depending on the nature of your scripts, you may not want all members of your Tines tenant to have direct access to them. In that case, we recommend using a separate Tines team to create a more isolated environment where only certain users have access. You can then configure any of the script workflows as send to stories. This would allow other teams in your tenant to call the send to story to execute a script and receive the output, but not permit access to the actual script itself.