Using Python in Tines: a quick how-to guide

Written by Nick Page

Published on December 18, 2023

While you can build nearly anything in Tines without writing code, users occasionally prefer to use Python scripts to perform a step in their stories. The reasons for this vary, but we're happy to share that there's a simple way to securely execute Python scripts in Tines.

So let's take a closer look at how it works, and talk through some best practices for using Python in Tines.

💡Note

Using Python in Tines: a quick how-to guide 

Using the action 

First, from your storyboard, find Templates on the left pane. Search for “Python” and drag on the action named “Run Python Script”. Note that we have set up a basic script here as an example.

▲  Using Python in Tines

Let’s talk about each part of the Run Python Script action.

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

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.

Running Python script in Tines

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.

Timeout 

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:

  1. Your code is executed in a secure, regulated environment.

  2. 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 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 delete the old Lambda and build a new one with the new contents. If they are the same, we execute the existing Lambda.

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.

Loading story...