Learn how to develop and manage Scripts that you can re-use throughout all your Processes.
Loading...
Manage your Scripts.
Manage your Script Categories.
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
View the Script Categories in your organization.
Your user account or group membership must have the following permissions to view Script Categories unless your user account has the Make this user a Super Admin setting selected:
Script: View Script Categories
Script: View Scripts
See the Scripts permissions or ask your Administrator for assistance.
Follow these steps to view Script Categories:
Log on to ProcessMaker Platform.
Click the Designer option from the top menu. The Processes page displays.
Click the Categories tab. The Script Categories display.
The Categories tab displays the following information in tabular format about Script Categories:
Name: The Name column displays the name of the Script Category. The Script Category named Uncategorized is the default Category.
Status: The Status column displays the status of the Script Category. Below is a description of each status:
Active: Active Script Categories can have Scripts assigned to them. The Script Category named Uncategorized is active by default.
Inactive: Inactive Script Categories cannot have Scripts assigned to them.
Scripts: The # Scripts column displays how many Scripts in your organization have been assigned to that Script Category.
Modified: The Modified column displays the date and time the Script Category was last modified. The time zone setting to display the time is according to the ProcessMaker Platform instance unless your user profile's Time zone setting is specified.
Created: The Created column displays the date and time the Script Category was created. The time zone setting to display the time is according to the ProcessMaker Platform instance unless your user profile's Time zone setting is specified.
If no Script Categories exist, the following message displays: No Results.
Use the Search setting to filter Script Categories by their names.
​Control how tabular information displays, including how to sort columns or how many items display per page.
Understand what Script Categories are and how they can help organize your Scripts.
Use Script Categories to organize your Scripts. Organizing your Scripts into Categories makes it easier to search for a Script based on its assigned Category. Assign multiple Script Categories to a Script if necessary. For example, assign a Script named "Database Call" to the "Database Scripts" and "Data Management" Script Categories.
Script Categories can be in active or inactive status. Following is a description of each status:
Active: Active Script Categories can have Scripts assigned to them.
Inactive: Inactive Script Categories cannot have Scripts assigned to them.
ProcessMaker Platform has multiple Category types for different types of assets. Each Category type is distinct from the others and can only be used for its type of ProcessMaker Platform asset. Following is a description of each Category type:
Process Categories: Organize your Processes.
Script Categories: Organize your Scripts.
Screen Categories: Organize your Screens.
Data Connector Categories: Organize your Data Connectors (if the Data Connector package is installed).
Improve your Script organization by creating Categories to which to assign them.
Your user account or group membership must have the following permissions to create a new Script Category unless your user account has the Make this user a Super Admin setting selected:
Scripts: Create Script Categories
Scripts: View Script Categories
Scripts: View Scripts
In the Category Name setting, enter the name of the new Script Category. The Script Category name must be unique from all other Script Category names in your organization and can only use apostrophe characters ('
) and spaces. This is a required setting.
From the Status drop-down menu, select one of the following options for the Script Category's status:
Active: Active Script Categories can have Scripts assigned to them.
Inactive: Inactive Script Categories cannot have Scripts assigned to them.
This is a required setting.
Click Save.
Understand what a Script does in ProcessMaker Platform.
See an example in the following video how ProcessMaker Platform integrates with third-party services Amazon Textract and UiPath Robotic Process Automation (RPA) so a loan application workflow scans, analyzes, and intelligently routes a Request and provision a bot accordingly.
Intended audience: Process designers and business analysts
Viewing time: 11 minutes; contains narration
ProcessMaker Platform supports the following programming languages in the Open-Source edition:
PHP
Lua
JavaScript
ProcessMaker Platform Enterprise edition supports the following additional programming languages:
When the Script Executor creates a Docker container to run a Script, required libraries are already built in that Docker container. Furthermore, all default Script Executors that run ProcessMaker Platform-supported programming languages also contain the Software Development Kits (SDKs) for those languages.
See an example in the following video how to use a Script Executor that includes a Docker RUN command to package the Google Client class provided by Google into that Script Executor, thereby allowing Scripts using that Script Executor to successfully call the Google API.
Intended audience: Administrators, software developers, and coding engineers
Viewing time: 3 minutes; contains narration
While designing a Script, test it before you deploy it. Scripts are tested within the authoring environment to ensure they function as intended. While testing, do the following:
Incorporate other JSON-formatted data, such as API keys, to ensure your Script uses them correctly during your testing.
Search for a Script Category.
Your user account or group membership must have the following permissions to search Script Categories unless your user account has the Make this user a Super Admin setting selected:
Script: View Script Categories
Script: View Scripts
Enter in the Search setting the text to filter Script Categories by name.
As you enter text into the Search setting, Script Categories display that match your entered text.
If there are no search results, the following message displays: No Results.
Click the Scripts icon from the left sidebar. The Scripts tab displays all Scripts in the Scripts page.
See the permissions or ask your Administrator for assistance.
Follow these steps to create a new :
.
Click the +Category button. The Create Script Category screen displays.
In ProcessMaker Platform, Scripts allow Process designers and developers to write self-contained programmatic actions that can be called from any Process at run-time. The same Script can be deployed in any . In other words, "write once, use anywhere."
C# (requires the )
Java (requires the )
Python (requires the )
R (requires the )
Scripts run securely and in isolation from within containers called . 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 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 designed and tested in the .
Use the JSON data model that you can to ensure that variables designed from a Screen function as intended in your Script.
See the permissions or ask your Administrator for assistance.
Follow these steps to search for :
.
Edit the name and/or status of a Script Category.
Your user account or group membership must have the following permissions to edit a Script Category unless your user account has the Make this user a Super Admin setting selected:
Scripts: Edit Script Categories
Scripts: View Script Categories
Scripts: View Scripts
See the Scripts permissions or ask your Administrator for assistance.
Follow these steps to edit a Script Category:
Edit the following information about the Script Category as necessary:
In the Category Name setting, edit the name of the Script Category if necessary. The Script Category name must be unique from all other Script Category names in your organization. This is a required setting.
From the Status drop-down menu, change the status of the Script Category, if necessary, from the following options:
Active: Active Script Categories can have Scripts assigned to them.
Inactive: Inactive Script Categories cannot have Scripts assigned to them.
This is a required setting.
Click Save.
Delete a Script Category when it is no longer needed.
Your user account or group membership must have the following permissions to delete a Script Category unless your user account has the Make this user a Super Admin setting selected:
Scripts: Delete Script Categories
Scripts: View Script Categories
Scripts: View Scripts
Deleting a Script Category cannot be undone.
Click Confirm. The following message displays: The category was deleted.
Select the Edit iconfor the Script Category to edit. The Edit Script Category page displays.
See the permissions or ask your Administrator for assistance.
To delete a Script Category, no Scripts can be assigned to it. If any Scripts are assigned to the Script Category, its Delete icondoes not display. .
Follow these steps to delete a :
.
Select the Delete iconfor the Script Category to delete. A message displays to confirm deletion of the Script Category.
Filter all Scripts in your organization to find that one you need.
Use the Search function to filter all Scripts from the Scripts page based on your entered text.
Your user account or group membership must have the "Scripts: View Scripts" permission to search for Scripts unless your user account has the Make this user a Super Admin setting selected.
See the Scripts permissions or ask your Administrator for assistance.
Follow these steps to search for a Script:
View your Scripts. The Scripts page displays.
Enter in the Search setting the text to filter Scripts using any of the following criteria:
Name: Filter by the Script name that displays in the Name column.
Category: Filter by the Script Category name that displays in the Category column.
Description: Filter by the Script description that displays in the Description column.
As you enter text into the Search setting, Scripts display that match your entered text.
If there are no search results, the following message displays: No Results.
View the Scripts in your organization.
ProcessMaker Platform displays all Scripts in one location. Any Script developed by any Process Owner or Developer can be used in any Process model. This makes it easy to manage Scripts.
Your user account or group membership must have the "Scripts: View Scripts" permission to view the list of Scripts unless your user account has the Make this user a Super Admin setting selected.
See the Scripts permissions or ask your Administrator for assistance.
Follow these steps to view all Scripts in your organization:
Log on to ProcessMaker Platform.
Click the Designer option from the top menu. The Processes page displays.
The Scripts tab displays the following information in tabular format about Scripts:
Name: The Name column displays the name of the Script. Click the name to edit the Script in Scripts Editor.
Description: The Description column displays the description of the Script. See Edit Script Configuration for more information.
Category: The Category column displays to which Script Category the Script is assigned.
Language: The Language column displays the programming language with which the Script was written.
Modified: The Modified column displays the date and time the Script was last modified. The time zone setting to display the time is according to the ProcessMaker Platform instance unless your user profile's Time zone setting is specified.
Created: The Created column displays the date and time the Script was created. The time zone setting to display the time is according to the ProcessMaker Platform instance unless your user profile's Time zone setting is specified.
Use the Search setting to filter Scripts that display.
Click the +Script button. See Create a New Script.
If no Scripts exist, the following message displays: No Results.
Control how tabular information displays, including how to sort columns or how many items display per page.
Create a new Script to automate or add functionality to any Process.
Your user account or group membership must have the following permissions to create a Script unless your user account has the Make this user a Super Admin setting selected:
Scripts: Create Scripts
Scripts: View Scripts
Follow these steps to create a new Script:
Click the +Script button. The Create Script screen displays.
In the Name setting, enter the name of the Script. Script names must be unique in your organization and can only use apostrophe characters ('
) and spaces. This is a required setting.
In the Description setting, enter the description of the Script. This is a required setting.
javascript - Node Executor: This is the default Script Executor to run Scripts developed using JavaScript.
lua - LUA Executor: This is the default Script Executor to run Scripts developed using Lua.
This is a required setting.
In the Timeout setting, use the slider control or enter how many seconds the Script is allowed to run before it times out. Use 0
to indicate that the Script never times out. The default timeout is 60 seconds. This setting requires an integer.
Click the Scripts icon from the left sidebar. The Scripts tab displays all Scripts in the Scripts page.
Click the Edit icon. See Edit a Script.
Click the Configure icon. See Edit Script Configuration.
Click the Copy icon. See Copy a Script.
Click the Delete icon. See Delete a Script.
See the permissions or ask your Administrator for assistance.
. The Scripts page displays.
From the Category drop-down menu, select one or more Script Categories to associate with this Script. In doing so, may be sorted from the . To remove a Script Category that is currently selected, click theicon for that selection or press Enter
when the drop-down is visible. This is a required setting.
From the Language drop-down menu, select the from which to run the Script for this Script's programming language. Your Administrator may have created custom Script Executors using ProcessMaker Platform-supported languages to run sanctioned custom third-party code and/or that allow Scripts to successfully call third-party Application Program Interfaces (APIs) and Software Development Kits (SDKs). Below are the Script Executors ProcessMaker Platform provides, though some require packages to be installed:
csharp - C# Executor: This is the default Script Executor to run Scripts developed using C#. Note that if the is not installed, this Script Executor is not available.
java - Java Executor: This is the default Script Executor to run Scripts developed using Java. Note that if the is not installed, this Script Executor is not available.
python - Python Executor: This is the default Script Executor to run Scripts developed using Python. Note that if the is not installed, this Script Executor is not available.
r - R Executor: This is the default Script Executor to run Scripts developed using R. Note that if the is not installed, this Script Executor is not available.
From the Run script as drop-down menu, select which user's API client token to use with our REST API. Ensure that the selected user's account has the appropriate API to access our REST API. This is a required setting.
Click Save. Script Editor displays so you can develop your Script. See .
Edit a Script.
Edit the configuration for a Script.
Your user account or group membership must have the following permissions to configure a Script unless your user account has the Make this user a Super Admin setting selected:
Scripts: Edit Scripts
Scripts: View Scripts
Follow these steps to configure general settings for a Script:
Edit the following information about the Script as necessary:
In the Name setting, edit the unique name of the Script. This is a required setting.
javascript - Node Executor: This is the default Script Executor to run Scripts developed using JavaScript.
lua - LUA Executor: This is the default Script Executor to run Scripts developed using Lua.
This is a required setting.
In the Description setting, edit the description of the Script. This is a required setting.
In the Timeout setting, use the slider control or enter how many seconds the Script is allowed to run before it times out. Use 0
to indicate that the Script never times out. The default timeout is 60 seconds. This setting requires an integer.
Click Save.
Enable a Script to function as an Application Program Interface (API) endpoint. Use a Script as an API endpoint to perform multiple scripting tasks that do not require be run from a Process. The Script may use either GET
and/or POST
methods as an independent endpoint. By enabling the Script with direct API access, a unique API URL is generated. Copy the API URL and insert it wherever that Script's API endpoint must be called. Enabling and then disabling a Script's API access maintains the same API URL.
Specify Basic Authentication of user name and password, if used.
Specify from which URLs may access the Script's independent API endpoint if other Scripts run this one.
Refer to the following HTTP responses for their corresponding events when using a Script's API endpoint:
200 OK
: The Script's API endpoint successfully returns the JSON response when set to run synchronously.
204 No Content
: There is no content for the Script API endpoint to return because it is being run asynchronously. The Script's API endpoint successfully fulfilled the request and that there is no JSON response in payload body.
Error 403 Forbidden
: The Script's API access is not accessible to that URL. Grant that URL access.
Error 404 Not Found
: The Script's API access is not available. Enable the Script's API endpoint.
Follow these steps to enable a Script with API access as an independent endpoint:
View your Scripts. The Scripts page displays.
Locate the Enable Direct API access setting. This setting is disabled by default.
Disable the Run Synchronously toggle key to run the Script asynchronously. The Run Synchronously toggle key is enabled by default.
From the Accepted methods setting, select which method(s) this Script uses as an endpoint:
GET/ Query String: The GET / Query String method retrieves data using parameters passed in the Script's auto-generated URL. The GET toggle key is disabled by default.
POST: The POST method sends JSON data as provided in the Script. The POST toggle key is enabled by default.
From the Authentication setting, select either None or Basic Authentication as the authentication method. Follow these steps to configure basic authentication settings when selecting the Basic Authentication option from the Authentication section:
In the User setting, enter or edit the user name that the Script authenticates endpoint access.
In the Password setting, enter or edit the password that the Script authenticates endpoint access.
From the Allow Access From setting, enter or edit from which URLs may access this Script's endpoint. The default setting is All, allowing any URL to access the Script's endpoint. Follow these guidelines to specify URLs:
Click the +URL button to add a URL. A field displays to enter the URL.
Enter the URL that this Script allows access to its endpoint.
From the API URL setting, copy the generated API endpoint and insert it wherever that Script's API endpoint must be called.
Click Save.
Furthermore, your user account or group membership must have the following permissions unless your user account has the Make this user a Super Admin setting selected:
Scripts: Edit Scripts
Scripts: View Scripts
Version History: Edit Version History
Version History: View Version History
Follow these steps to view or edit the version history of your Script:
Click on the Version History tab. The Version History page displays.
Name: The name of this version as entered by a Process designer when saving the Script in Script Editor.
Description: A description of the changes in this version as entered by a Process designer when saving the Script in Script Editor.
Saved by: The name of the Process designer who saved this version.
Toggle the Only show named versions toggle key to show only the versions with a name assigned to them.
Optionally, edit any of the following existing details about this named version:
In the Version Name setting, edit the name to this named version. If saving this named version with no name, this version does not display in the Version History page if the Only show named versions toggle key is enabled.
In the Additional Details (optional) setting, edit the details about this version. For example, describe the changes in this version for auditing, historical, or maintenance purposes.
Click Confirm and Save to save your changes. Otherwise, click Cancel.
Click Confirm and Save to set this version as the current version. Otherwise, click Cancel.
See the permissions or ask your Administrator for assistance.
. The Scripts page displays.
Click the Edit iconfor the Script to edit. The Script opens in Script Editor. See .
See the permissions or ask your Administrator for assistance.
.
. Among these best practices are to verify all user accounts that run Scripts are valid and appropriate.
The Scripts page displays.
Click the Configure iconfor your Script. The Edit Configuration page displays.
From the Category drop-down menu, select one or more Script Categories to associate with this Script. In doing so, may be sorted from the . To remove a Script Category that is currently selected, click the icon for that selection or press Enter
when the drop-down is visible. This is a required setting.
From the Run script as drop-down menu, select which user's API client token to use with our REST API. Ensure that the selected user's account has the appropriate API to access our REST API. This is a required setting.
From the Script Executor drop-down menu, select which to run this Script. This setting only displays Script Executors that this Script has been developed using. Your Administrator may have created custom Script Executors using ProcessMaker Platform-supported languages to run sanctioned custom third-party code and/or that allow Scripts to successfully call third-party Application Program Interfaces (APIs) and Software Development Kits (SDKs). Below are the Script Executors ProcessMaker Platform provides, though some require packages to be installed:
csharp - C# Executor: This is the default Script Executor to run Scripts developed using C#. Note that if the is not installed, this Script Executor is not available.
java - Java Executor: This is the default Script Executor to run Scripts developed using Java. Note that if the is not installed, this Script Executor is not available.
python - Python Executor: This is the default Script Executor to run Scripts developed using Python. Note that if the is not installed, this Script Executor is not available.
r - R Executor: This is the default Script Executor to run Scripts developed using R. Note that if the is not installed, this Script Executor is not available.
.
Configure API access settings independently from the . API access settings require the following:
Use an application like that can send API requests to the Script to more easily inspect and debug the Script's API endpoint responses.
.
Click the Configure iconfor your Script. The Edit Configuration page displays. Ensure that the Script's basic settings are configured properly to run.
Select the Enable Direct API access toggle key. Settings display to configure the Script's API access.
Click the Deleteicon to delete the URL, if necessary.
The must be installed to view or edit the version history for a Script.
See the and permissions or ask your Administrator for assistance.
A version is a set of changes made to a Script at a particular time by a Process designer. Versioning maintains a record of all named and unnamed changes to that Script. Any of these versions may be viewed or retrieved, if needed. The Version History page displays all saved versions of the Script in a tabular format from where they can be edited and/or marked as the Current Version
according to your business needs. The current version of a Script is used in all new in which that Script is run from elements or . Version changes are not reflected in Requests which were in-progress or already completed when the version changed. .
The Scripts page displays.
Click the Configure iconfor your Script. The Configuration tab of the Edit Configuration page displays.
The Version History page organizes versions in a monthly format and displays the following information:
Date: The date and time of when a Process Designer in .
Current Version: The most recent version of the Script is displayed at the top and is marked as the Current Version
. This version is used in all in-progress and new .
Click the Change Version Details iconto edit version details for this version. The Change Version Details screen displays.
Click the Copy to Latest iconto set a version as the current version. The Copy to Latest screen displays.
The screen displays the warning This version will become the active version for this asset
,
indicating that this action will set this version as the current version.
Copy an existing Script.
Your user account or group membership must have the following permissions to copy a Script unless your user account has the Make this user a Super Admin setting selected:
Scripts: View Scripts
Scripts: Create Scripts
See the Scripts permissions or ask your Administrator for assistance.
Follow these steps to copy a Script:
View your Scripts. The Scripts page displays.
Edit the following information from the original Script as necessary:
In the Name setting, edit the name of the duplicated Script. After the original Script is duplicated, the word Copy is suffixed to the original Script's name. This is a required setting.
In the Description setting, edit the description of the original Script.
Click Save.
Delete a Script from being used in any Process.
Your user account or group membership must have the following permissions to delete a Script:
Scripts: Delete Scripts
Scripts: View Scripts
See the Scripts permissions or ask your Administrator for assistance.
When a Script is deleted, Process models that use that Script in Script Task elements are not affected. However, that Script can no longer be referenced from other Process models.
Deleting a Script from the Scripts page cannot be undone.
Follow these steps to delete a Script:
View your Scripts. The Scripts page displays.
Click Confirm.
Click the Copy iconfor your Script. The Copy Script screen displays.
Click the Delete iconfor the Script to delete. The Caution screen displays to confirm the deletion of the Script.
Develop and test your Script in a secure and isolated environment.‌
Use Script Editor to develop and test your Scripts. Any Script can be used in any Process in your organization developed using programming languages that Script Editor supports.‌
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.
Access the Script Editor in the following ways:
​Create a new Script.​
​Edit an existing Script.​
‌Below is the Script Editor displaying a Script written in PHP.‌
‌Follow these guidelines to develop and test Scripts in the 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 you are editing a long Script.‌
‌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.
Define the variables in a Screen when you configure its controls. See information about each control.‌
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.
‌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:
‌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.‌
‌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 Email
is being passed to the Script using the Script Configuration panel of a Script Task element.
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_NAME
represents the name of the Environment Variable. See Variable Syntax, Usage, and Examples.
‌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).
The C# package must be installed.
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).
The Java package must be installed.
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).
The Python package must be installed.
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).
The R package must be installed.
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.
A Script can be saved in two ways depending if the Versioning package is installed. See the following sections regarding how a Script may be saved:
Versioning package is not installed: Save a single version of your Script.
Versioning package is installed: Save multiple versions of your Script.
Permissions are required to do this.
The Versioning package must be installed to save multiple versions of a Script.
When the Versioning package is installed, multiple versions of a Script can be saved. A version is a set of changes made to a Script at a particular time by a Process designer. Versioning maintains a record of all named and unnamed changes to that Script. Any of these versions may be viewed or retrieved, if needed. See the Versioning package for more information.
Follow these guidelines to save a new version of your Script:‌
Do one of the following:
Save an unnamed version:
Follow these steps to save an unnamed version:
Click Save to save an unnamed version. Otherwise, click Cancel to return to Script Editor without saving this version. As a best practice, save unnamed versions only to save work that is in active development and do not need a "milestone" set for this Script. 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 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 the "milestone" set for 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 saving this version.
Click the Save iconfrom Script Editor's top menu to save the Script.‌ When the Versioning package is not installed, this action overwrites any previous changes made to this Script and a record of previous changes is not maintained. To save multiple versions of a Script, the Versioning package must be installed.
Click the Save iconfrom Script Editor's top menu.‌
If the Versioning package is installed, the Commit Changes screen displays to save a new version of this Script.
ProcessMaker 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.