In this quick start guide, we will write our first script in Python. getOperate provides a Python 3.11 environment.
Scripts are the basic building blocks in getOperate. They can be run and scheduled as standalone, chained together to create Flows or displayed with a personalized User Interface as Apps.
All the details on scripts.
Trigger flows on-demand, by schedule or on external events.
Scripts consist of 2 parts:
When stored in a code repository, these 2 parts are stored separately at <path>.ts
and <path>.script.yaml
This is a simple example of a script built in Python with getOperate:
In this quick start guide, we’ll create a script that greets the operator running it.
From the Home page, click +Script
. This will take you to the first step of script creation: Metadata.
As part of the settings menu, each script has metadata associated with it, enabling it to be defined and configured in depth.
path
by default.This menu also has additional settings, such as:
Each script has metadata & settings associated with it, enabling it to be defined and configured in depth.
Now click on the code editor on the left side, and let’s build our Hello World!
We provides an online editor to work on your Scripts. The left-side is the editor itself. The right-side previews the UI that getOperate will generate from the Script’s signature - this will be visible to the users of the Script. You can preview that UI, provide input values, and test your script there.
The code editor is getOperate’s integrated development environment.
We creates auto-generated user interfaces for scripts and flows based on their parameters.
As we picked python
for this example, We provided some python boilerplate. Let’s take a look:
Scripts need to have a main
function that will be the script’s entrypoint. There are a few important things to note about the main
.
JSON Schemas are used for defining the input specification for scripts and flows, and specifying resource types.
The last import line imports the client, which is needed for example to access variables or resources.
getOperate’s strength lies in its ability to run scripts without having to deal with separate dependency files.
The Python client library for getOperate provides a convenient way to interact with the getOperate platform’s API from within your script jobs.
Back to our Hello World. We can clean up unused import statements, change the
main to take in the user’s name. Let’s also return the name
, maybe we can use
this later if we use this Script within a flow or app and need to pass its result on.
Look at the UI preview on the right: it was updated to match the input
signature. Run a test (Ctrl
+ Enter
) to verify everything works.
You can change how the UI behaves by changing the main signature. For example,
if you add a default for the name
argument, the UI won’t consider this field
as required anymore.
On top of its integrated editors, We allows users to see and test what they are building directly from the editor, even before deployment.
Now let’s go to the last step: the “Generated UI” settings.
From the Settings menu, the “Generated UI” tab lets you customize the script’s arguments.
The UI is generated from the Script’s main function signature, but you can add additional constraints here. For example, we could use the Customize property
: add a regex by clicking on Pattern
to make sure users are providing a name with only alphanumeric characters: ^[A-Za-z0-9]+$
. Let’s still allow numbers in case you are some tech billionaire’s kid.
You can attach additional functionalities to Scripts by specializing them into specific Script kinds.
Some arguments’ types can be given advanced settings that will affect the inputs’ auto-generated UI and JSON Schema.
We’re done! Now let’s look at what users of the script will do. Click on the Deploy button to load the script. You’ll see the user input form we defined earlier.
Note that Scripts are versioned in getOperate, and each script version is uniquely identified by a hash
Fill in the input field, then hit “Run”. You should see a run view, as well as your logs. All script runs are also available in the Runs menu on the left.
You can also chose to run the script from the CLI with the pre-made Command-Line Interface call.
Trigger flows on-demand, by schedule or on external events.
This script is a minimal working example, but there’s a few more steps that can be useful in a real-world use case:
Scripts are immutable and there is an hash for each deployment of a given script. Scripts are never overwritten and referring to a script by path is referring to the latest deployed hash at that path.
Scripts, when deployed, can have a parent script identified by its hash.
For each script, a UI is autogenerated from the jsonchema inferred from the script signature, and can be customized further as standalone or embedded into rich UIs using the App builder.
We creates auto-generated user interfaces for scripts and flows based on their parameters.
Some arguments’ types can be given advanced settings that will affect the inputs’ auto-generated UI and JSON Schema.
In addition to the UI, sync and async webhooks are generated for each deployment.
Trigger scripts and flows from webhooks.
In this quick start guide, we will write our first script in Python. getOperate provides a Python 3.11 environment.
Scripts are the basic building blocks in getOperate. They can be run and scheduled as standalone, chained together to create Flows or displayed with a personalized User Interface as Apps.
All the details on scripts.
Trigger flows on-demand, by schedule or on external events.
Scripts consist of 2 parts:
When stored in a code repository, these 2 parts are stored separately at <path>.ts
and <path>.script.yaml
This is a simple example of a script built in Python with getOperate:
In this quick start guide, we’ll create a script that greets the operator running it.
From the Home page, click +Script
. This will take you to the first step of script creation: Metadata.
As part of the settings menu, each script has metadata associated with it, enabling it to be defined and configured in depth.
path
by default.This menu also has additional settings, such as:
Each script has metadata & settings associated with it, enabling it to be defined and configured in depth.
Now click on the code editor on the left side, and let’s build our Hello World!
We provides an online editor to work on your Scripts. The left-side is the editor itself. The right-side previews the UI that getOperate will generate from the Script’s signature - this will be visible to the users of the Script. You can preview that UI, provide input values, and test your script there.
The code editor is getOperate’s integrated development environment.
We creates auto-generated user interfaces for scripts and flows based on their parameters.
As we picked python
for this example, We provided some python boilerplate. Let’s take a look:
Scripts need to have a main
function that will be the script’s entrypoint. There are a few important things to note about the main
.
JSON Schemas are used for defining the input specification for scripts and flows, and specifying resource types.
The last import line imports the client, which is needed for example to access variables or resources.
getOperate’s strength lies in its ability to run scripts without having to deal with separate dependency files.
The Python client library for getOperate provides a convenient way to interact with the getOperate platform’s API from within your script jobs.
Back to our Hello World. We can clean up unused import statements, change the
main to take in the user’s name. Let’s also return the name
, maybe we can use
this later if we use this Script within a flow or app and need to pass its result on.
Look at the UI preview on the right: it was updated to match the input
signature. Run a test (Ctrl
+ Enter
) to verify everything works.
You can change how the UI behaves by changing the main signature. For example,
if you add a default for the name
argument, the UI won’t consider this field
as required anymore.
On top of its integrated editors, We allows users to see and test what they are building directly from the editor, even before deployment.
Now let’s go to the last step: the “Generated UI” settings.
From the Settings menu, the “Generated UI” tab lets you customize the script’s arguments.
The UI is generated from the Script’s main function signature, but you can add additional constraints here. For example, we could use the Customize property
: add a regex by clicking on Pattern
to make sure users are providing a name with only alphanumeric characters: ^[A-Za-z0-9]+$
. Let’s still allow numbers in case you are some tech billionaire’s kid.
You can attach additional functionalities to Scripts by specializing them into specific Script kinds.
Some arguments’ types can be given advanced settings that will affect the inputs’ auto-generated UI and JSON Schema.
We’re done! Now let’s look at what users of the script will do. Click on the Deploy button to load the script. You’ll see the user input form we defined earlier.
Note that Scripts are versioned in getOperate, and each script version is uniquely identified by a hash
Fill in the input field, then hit “Run”. You should see a run view, as well as your logs. All script runs are also available in the Runs menu on the left.
You can also chose to run the script from the CLI with the pre-made Command-Line Interface call.
Trigger flows on-demand, by schedule or on external events.
This script is a minimal working example, but there’s a few more steps that can be useful in a real-world use case:
Scripts are immutable and there is an hash for each deployment of a given script. Scripts are never overwritten and referring to a script by path is referring to the latest deployed hash at that path.
Scripts, when deployed, can have a parent script identified by its hash.
For each script, a UI is autogenerated from the jsonchema inferred from the script signature, and can be customized further as standalone or embedded into rich UIs using the App builder.
We creates auto-generated user interfaces for scripts and flows based on their parameters.
Some arguments’ types can be given advanced settings that will affect the inputs’ auto-generated UI and JSON Schema.
In addition to the UI, sync and async webhooks are generated for each deployment.
Trigger scripts and flows from webhooks.