The Script Editor in ProcessMaker is a powerful tool designed to streamline the creation, documentation, and testing of scripts used in . Whether you're crafting custom logic, automating repetitive tasks, or enhancing process functionality, the Script Editor provides an intuitive interface and robust features to simplify script management. With built-in testing capabilities and support for documentation, it ensures your scripts are both efficient and maintainable.
Develop Your Script
The Script Editor provides a dedicated workspace for creating and managing your scripts seamlessly. Scripts execute securely and in isolation using Docker containers called Script Executors. Each Script Executor, tailored to a specific programming language, includes a Software Development Kit (SDK) that enables extensibility and programmatic interaction with ProcessMaker Platform.
When a script is invoked, the Script Executor spins up a Docker container, executes the script, and then destroys the container. This approach ensures that any potentially malicious scripts cannot compromise the hosting environment. Docker containers operate in complete isolation, without access to the hosting infrastructure. Additionally, they cannot accept inbound connections, ensuring that external access to Docker containers is fully restricted.
Saving a Script
The Script Editor saves changes automatically every five (5) seconds
Scripting AI Assistant
Easily create scripts using ProcessMaker's AI assistant. Leverage no-code options to efficiently generate scripts, enhancing productivity and reducing complexity in process design. The scripting AI assistance offers the following functionality:
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.
For more information, see Generate Scrips using the AI Assistant.
Discard Changes to Your Script
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:
While in Script Editor, click the ellipses menu, and then select Discard Draft.
Click the Discard button. Script Editor discards the changes since the last publication.
Publish Your Script
A Script can be published in two ways.
Publish a Single Version of a 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).
Publish Distinct Versions of a Script
Distinct versions of a script can be published, each representing changes made since the last publication. Versioning keeps a record of all named and unnamed publications, allowing any version to be viewed or retrieved as needed.
Follow these guidelines to publish a new distinct version of your Script:
Click the Publish button from Script Editor's top menu.
The Commit Changes screen displays.
Do one of the following:
Publish an unnamed version:
Click Save and Publish to publish an unnamed version.
Save 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.
Click Save and Publish to save this version. Otherwise, click Cancel to return to Script Editor without publishing.
Pass Request Data to Scripts
Pass Request-related data into your Script in the following ways:
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 Requests: Edit Request Data permission 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 configuring the Script task element in Process Modeler. In the example below, the data from JSON Variable
Emailis 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 Reference Magic Variables in ProcessMaker Platform Assets.Environment Variables: The sensitive information that an Environment Variable 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_NAMErepresents the name of the Environment Variable. See Variable Syntax, Usage, and Examples.
Enter Mock Request Data
Use the Sample Input panel to mock Request data that comes into your Script to test how the Script runs using Request data you expect.
Follow these guidelines to mock Request data coming into your Script:
Open the Screen in which to view its JSON data model.
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.
Optionally, mock the Magic Variables 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 Magic Variable Descriptions.Click Run.
In the Output panel, view the mocked Request data.
Enter Other JSON Data as Input to Your Script
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:
{
"Name": "FullName"
}Test Your Script
Click the Run button to test your Script. Script Editor evaluates any JSON data entered into the Configuration and Sample Input panels.
If the Script evaluates successfully, its output displays in the Output panel. If the Script does not evaluate successfully, the language engine evaluating the script displays an error.
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 Data Browser.
