Use ProcessMaker AI to code, document, and test your Script in a secure and isolated environment.
Use Script Editor to code, document, and test your Scripts. Any Script can be used in any Process in your organization developed using programming languages that Script Editor supports.
More efficiently produce your Scripts with ProcessMaker's AI assistant, Cornea AI. Use Cornea AI's no-coding option in the following ways to more efficiently produce Script assets:
Generate a Script using a natural language description of its function: Use almost any natural language to describe the Script's intended functionality.
Clean a Script to improve its code: Clean a Script to improve its coding structure and efficiency. Your Script does not need to have been generated by Cornea AI to clean it.
Document a Script: Use Cornea AI to add comments into the Script to document its functionality. Your Script does not need to have been generated by Cornea AI to document it.
Explain how a Script functions: Use Cornea AI to explain how a Script functions. Provide a Script, and Cornea AI describes its functionality in simple natural language. As with other Cornea AI features, your Script does not need to have been generated by Cornea AI to explain its functionality.
Note that Cornea AI features are only available when using Scripts in JavaScript or PHP programming languages.
Scripts run securely and in isolation from within Docker containers called Script Executors. The Script Executor for each supported programming language contains the Software Development Kit (SDK) that supports extensibility to provide programmatic interaction with ProcessMaker Platform. When the ProcessMaker Platform instance calls a Script to run, the Script Executor for that programming language creates a Docker container corresponding with that programming language, runs the Script, and then destroys the Docker container. This ensures that any malicious script that anyone in your organization might inadvertently introduce to ProcessMaker Platform does not affect the instance or its hosting environment: Docker containers cannot access them. Furthermore, Docker containers cannot listen for inbound connections; therefore, a Docker container cannot be accessed externally.
Scripts are developed and tested in the same environment.
Below is the Script Editor displaying a Script written in PHP.
Understand how to develop a Script in Script Editor.
Develop the Script below the script's name and language description. Use the scroll panel to navigate your code not currently displayed. This is useful especially when editing a long Script.
Script Editor automatically saves your Script every five (5) seconds when changes are made to any of the configuration panels. Regardless of whether you publish your Script prior to leaving Script Editor, the next time you edit that Script, the changes since its last publication remain intact.
Revisions made to Script Config Editor screen do not save until the Close button is clicked.
When discarding a draft of your Script, Script Editor discards all changes to that Script since its last publication.
Follow these steps to discard changes to your Script since its last publication:
Click the Discard button. Script Editor discards the changes since last starting to edit that Script, and then closes. The Scripts page displays.
Since Script Editor saves changes to your Script automatically, it is not necessary to manually save your changes. However, you may close Script Editor without publishing your changes, but keep all your changes intact.
While in Script Editor, click the Close button. Script Editor closes with your saved changes. The Scripts page displays.
A Script can be published in two ways. See the following sections regarding how a Script may be published:
Publish a single version of your Script.
Publish distinct versions of your Script.
Click the Publish button from Script Editor's top menu to publish the Script. This action overwrites the previous publication of this Script without maintaining a record of its previous publication(s).
Distinct versions of a Script can be published. A version is a set of changes published for a Script since the last publication. Versioning maintains a record of all named and unnamed publications to that Script. Any of these versions may be viewed or retrieved, if needed.
Follow these guidelines to publish a new distinct version of your Script:
Click the Publish button from Script Editor's top menu.
Do one of the following:
Publish an unnamed version:
Follow these steps to publish an unnamed version:
Click Save to publish an unnamed version. Otherwise, click Cancel to return to Script Editor without publishing. As a best practice, name each published version to provide auditing and documentation to what has changed in each publication. Otherwise, Process Designers that manage versions of this Script do not view unnamed versions when the Only show named versions toggle key is enabled while viewing that Script's version history.
Save a named version:
Follow these steps to publish a named version:
In the Version Name setting, enter a name for this version. The version name displays when viewing the version history of that Script and helps identify this version. Although this setting is not required, as a best practice name each version for easier maintenance, documentation, and auditing purposes. Name the version that describes changes in this Script.
In the Additional Details (optional) setting, optionally enter details of the changes made in this version. The additional details display when viewing the version history of that Script and helps other Process Designers or Administrators understand the changes made in that version. Enter details which concisely summarize the changes made in this version.
Click Save to save this version. Otherwise, click Cancel to return to Script Editor without publishing.
Generate a Script using ProcessMaker's Artificial Intelligence (AI) without using code. Describe how the Script is to function using natural language.
ProcessMaker's AI Assistant in Script Editor helps you create highly usable scripts faster than coding them yourself. Generate a Script without knowing how to code. Use almost any natural language to describe the Script's intended functionality.
For example, describe a Script to perform the following functionality using the following text:
First, visit a reputable travel website or an airline's official website. Next, enter the departure and destination locations, along with the preferred travel dates.
There is no need to describe which programming language in which to generate this Script because you select that programming language when creating the Script prior to describing its function.
Note that this feature is only available when creating a Script using JavaScript or PHP programming languages.
Follow these steps to generate a Script using a natural language description of its function:
The AI Assistant features display.
Click the Generate Script From Text option. The Generate Script From Text panel displays.
In the Description setting, enter a natural language description of how the script is to function. One Script description may use no more than 1000 tokens. A token is a common sequence of characters found in text for a particular language. Generally, one token corresponds to approximately four (4) characters of common English-language text. This corresponds to approximately 100 tokens to about 75 words in English. To the right of the Description label displays how many tokens your description currently uses. If your description exceeds 1000 tokens, shorten the length of your description.
Optionally, click the Give me inspiration! link for examples. From the Need Inspiration? field, view English-language phrases how to describe specific functions to generate in the Script. Click a phrase or phrase template to copy it into your Clipboard, and then paste it into into the appropriate location in your description.
Click the Generate button. The Before you continue screen displays.
Position your cursor in the position within Script Editor to place the generated script. By default, the cursor positions at the beginning of Line 1. Click the Confirm button. AI Assistant processes the natural language prompt describing the script, and then Script Editor displays two panes:
Current Script: The Current Script pane displays the script prior to the AI-generated script.
AI Generated Response: The AI Generated Response pane displays the AI-generated script. Differences in code from the script in the Current Script pane display with the following code highlighting:
Additional code: Additional code displays with a green-colored highlight.
Removed code: Removed code displays with a red-colored highlight.
Click one of the following buttons from the AI Generated Response pane:
Apply Changes: Click the Apply Changes button to accept the AI-generated script. Script Editor displays the AI-generated script in its default view.
Cancel: Click the Cancel button to not accept the AI-generated script. Script Editor displays the current script in its default view.
Clean a Script to improve its coding structure and efficiency. Your Script does not need to have been generated by AI Assistant to clean it.
Follow these steps to use AI Assistant to clean a Script:
Edit a Script in which to clean.
Expand the AI Assistant panel. The AI Assistant features display.
Click the Clean option. AI Assistant processes the currently displayed script, and then Script Editor displays two panes:
Current Script: The Current Script pane displays the script prior to recommended cleaning.
AI Generated Response: The AI Generated Response pane displays the AI-cleaned script. Differences in code from the script in the Current Script pane display with the following code highlighting:
Additional code: Additional code displays with a green-colored highlight.
Removed code: Removed code displays with a red-colored highlight.
If Cornea AI recommends no cleaning changes, the following message displays: Nothing to clean..
Click one of the following buttons from the AI Generated Response pane:
Apply: Click the Apply button to accept the AI-cleaned script. Script Editor displays the AI-cleaned script in its default view.
Cancel: Click the Cancel button to not accept the AI-cleaned script. Script Editor displays the current script in its default view.
Use ProcessMaker's AI Assistant to add comments into the Script to document its functionality. Your Script does not need to have been generated by AI Assistant to document it.
Follow these steps to use AI Assistant to document a Script:
Generate or edit a Script to document.
Expand the AI Assistant panel. The AI Assistant features display.
Click the Document option. AI Assistant processes the currently displayed script, and then Script Editor displays two panes:
Current Script: The Current Script pane displays the script prior to its documentation.
AI Generated Response: The AI Generated Response pane displays the AI-documented script. Additional lines of code that document functionality display with a green-colored highlight.
Click one of the following buttons from the AI Generated Response pane:
Apply: Click the Apply button to accept the AI-documented script. Script Editor displays the AI-documented script in its default view.
Cancel: Click the Cancel button to not accept the AI-documented script. Script Editor displays the current script in its default view.
Use ProcessMaker's AI Assistant to explain how a Script functions. Provide a Script, and AI Assistant describes its functionality in simple natural language. Your Script does not need to have been generated by AI Assistant to explain its functionality.
Follow these steps to use AI Assistant to explain how a Script functions:
Edit a Script in which to explain how it functions.
Expand the AI Assistant panel. The AI Assistant features display.
Click the Explain option. AI Assistant processes the currently displayed script, and then Script Editor displays two panes:
Current Script: The Current Script pane displays the script to be described its function.
AI Explanation: The AI Explanation pane displays the following structure within the explanation for the displayed script:
Summary: The Summary section describes in overview the displayed script's function.
Explanation: The Explanation section describes a sequential order in runtime what the script does in natural language.
Use Request data as input from which to run your Script.
Pass Request-related data into your Script in the following ways:
Follow these guidelines to mock Request data coming into your Script:
Enter Preview mode on the Screen page to view its JSON data model. Click the Preview button from Screen Builder's top menu to enter Preview mode.
Enter values into the control settings as if you were using the Screen in a Request. In the Data Preview panel, the JSON data model displays the key-value pairs in each object element. The keys' values are those you enter in the Screen preview. Understand what the key names are. Each key is derived from a Screen control's Variable Name setting value. Use these key names as variables in your Script. The Variable Name setting values become part of the Request data and contain the content that Request participants enter into that Screen during a Request. Mock these Variable Name setting values as input data to your Script.
After you have entered values into the Screen in Preview mode, the entire JSON data model displays in the Data Preview panel. Copy the JSON data model.
Paste the JSON data model into the Sample Input panel in Script Editor. If you use any variables as defined in the JSON data model in your Script, Script Editor uses those variable values during script testing.
Click Run.
In the Output panel, view the mocked Request data.
Use the Configuration panel to include JSON configuration settings your Script uses when it runs. For example, include the Client ID and Client Secret values in JSON format for OAuth 2.0 verification to a third-party service's API your Script must access to access the API. By entering these values into the Configuration panel, you can verify during testing that these values are valid for the third-party service.
A Script may reference Screen control values during a Request by placing their Variable Name setting values within quotation marks ("
). In the example below, FullName
is the Variable Name setting value for a control to store a Request participant's full name:
While in Script Editor, click the ellipses menu, and then select Discard Draft.
The Commit Changes screen displays to name that published version of this Script.
While in Script Editor, expand the AI Assistant panel.
Request data: ProcessMaker Platform uses a schema-less JSON data model from which to read, write, and store Request data. Since the JSON data model is schema-less, meaning that it does not require a specific schema or structure from which ProcessMaker Platform assets must conform, the JSON data model is structured from the JSON objects in assets used in a Request, such as the Variable Name setting values in a Screen or variables a Script creates. When an in-progress Request routes through the Process, Request data aggregates into the JSON data model, thereby becoming Request data. Users or group members that have the may view the JSON data model for a completed Request. This JSON data model displays from the Data tab in a completed Request's summary. Below is an example. Scripts can call Request data by referencing these JSON objects derived from Variable Name setting values in Screens.
Script Task element Configuration: Enter JSON data to pass to the Script when in Process Modeler. In the example below, the data from JSON Variable Email
is being passed to the Script using the Script Configuration panel of a Script Task element. Note that revisions made to Script Config Editor screen do not save until the Close button is clicked.
Magic Variables: ProcessMaker Platform uses a set of Magic Variables that become part of the JSON data model for all Requests. ProcessMaker Platform uses these Magic Variables to store user, Process, and Request related data for all Requests. During an in-progress Request, these Magic Variables are updated. All Magic Variables are preceded by an underscore (_
) character in the JSON data model. See .
Environment Variables: The sensitive information that an represents can pass to a Script when it runs. Usage depends on the programming language that the Script uses. In the usage examples below, ENV_VAR_NAME
represents the name of the Environment Variable. See .
Use the Sample Input panel to mock that comes into your Script to test how the Script runs using Request data you expect.
Define the variables in a when you configure its controls. See .
Your user account or group membership must have the following permissions to enter mock Request data into a :
See the permissions or ask your Administrator for assistance.
in which to view its JSON data model.
Optionally, mock the that your Script would reference during an in-progress Request. ProcessMaker Platform uses a set of Magic Variables that become part of the JSON data model for all Requests. ProcessMaker Platform uses these Magic Variables to store user, Process, and Request related data for all Requests. During an in-progress Request, these Magic Variables are updated. All Magic Variables are preceded by an underscore (_
) character in the JSON data model. Enter the Magic Variable into the Sample Input panel as part of the JSON data model, and then enter mock values for each. See .
Click the Run button to test your . Script Editor evaluates any JSON data entered into the Configuration and Sample Input panels.
Click the icon to open a preview of the data. The Output Preview Panel displays the JSON structure and the Data Browser canvas. To navigate JSON data in the Data Browser, see .
Reference Environment Variables and Magic Variables in your Scripts.
ProcessMaker Platform uses two global variables that Scripts can call. Variable usage depends on the programming language that the Script uses. Below is a description of these global variables:
Data: The data
variable is a JSON object that contains all Request data to the moment a Script runs.
Config: The config
variable is a JSON object that contains any special configuration to be passed to the Script prior to it running. In Script Task elements of a Process model, special configurations are entered into the Script Configuration setting. See Reference a Request Variable from a Script Configuration Setting as to the best practice when configuring Scripts from Script Task elements in a Process model.
Every Script Executor from which a Script runs has the following default Environment Variables from which a Script may get its value. Refer to the tabs below how to get these Environment Variable values for each supported programming language. Below is a description of these default Environment Variables.
Refer to the tabs below how to use variables in supported programming languages.
Below is a sample Script that uses PHP. Refer to the comments denoted with //
that describe how the sample functions:
How to get an Environment Variable.
How to get a value from the configuration object.
How to get a value from a data object.
Call the Software Development Kit (SDK).
Below is a sample Script that uses Lua. Refer to the comments denoted with --
that describe how the sample functions:
How to get an Environment Variable.
How to get a value from the configuration object.
How to get a value from a data object.
Call the Software Development Kit (SDK).
Below is a sample Script that uses JavaScript. Refer to the comments denoted with //
that describe how the sample functions:
How to get an Environment Variable.
How to get a value from the configuration object.
How to get a value from a data object.
Call the Software Development Kit (SDK).
Below is a sample Script that uses C#. Refer to the comments denoted with //
that describe how the sample functions:
How to get an Environment Variable.
How to get a value from the configuration object.
How to get a value from a data object.
Call the Software Development Kit (SDK).
Below is a sample Script that uses Java. Refer to the comments denoted with //
that describe how the sample functions:
How to get an Environment Variable.
How to get a value from the configuration object.
How to get a value from a data object.
Call the Software Development Kit (SDK).
Below is a sample Script that uses Python. Refer to the comments denoted with #
that describe how the sample functions:
How to get an Environment Variable.
How to get a value from the configuration object.
How to get a value from a data object.
Call the Software Development Kit (SDK).
Below is a sample Script that uses R. Refer to the comments denoted with #
that describe how the sample functions:
How to get an Environment Variable.
How to get a value from the configuration object.
How to get a value from a data object.
Call the Software Development Kit (SDK).
The following sample PHP script provides an example to get all Tasks currently assigned to a user. This example also demonstrates the use of optional arguments such as the Request ID or a Task filter.
The following sample PHP script provides an example to retrieve a single Task using its Task ID.
The following sample PHP script provides an example of completing a Task when the Task ID is known.
If a script runs under a different user than the one who started the request and the task involves date variables, automatic detection and formatting of Datetime variables will not occur. Users must manually implement date formatting logic within their scripts.
Here is a sample to retrieve, format, and apply a date format to a Datetime variable using a sample PHP script:
Environment Variable
Description
HOST_URL
Domain for the ProcessMaker Platform instance.
API_HOST
ProcessMaker Platform instance API to which to make all RESTful API calls.
API_TOKEN
Token a Script uses to authenticate to our API host. Note that this API token is only valid for the lifetime of the Script: after the Script runs and the Script Executor's Docker container from which that Script ran, its API token is no longer valid.