In ProcessMaker, Scripts allow Process Owners and ProcessMaker Developers to write self-contained programmatic actions that can be called from any Process Request at run-time. The same Script can be deployed in any Process model. In other words, "write once, use anywhere."
See an example in the following video how ProcessMaker 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 supports the following programming languages in the open-source edition:
ProcessMaker Enterprise edition supports the following additional programming languages:
C# (requires the C# package)
Java (requires the Java package)
Python (requires the Python package)
R (requires the R package)
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. When the ProcessMaker 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 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.
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-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
Scripts are designed and tested in the Script Editor.
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:
Use the JSON data model that you can preview from your Screens to ensure that variables designed from a Screen function as intended in your Script.
Incorporate other JSON-formatted data, such as API keys, to ensure your Script uses them correctly during your testing.