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 ProcessMaker Script can be deployed in any Process model. In other words, "write once, use anywhere."
ProcessMaker supports the following programming languages and their corresponding software development kits (SDKs) in the open-source edition:
ProcessMaker Enterprise edition supports the following additional programming languages and their corresponding SDKs:
R (requires the R package)
ProcessMaker Scripts run securely and in isolation from within Docker containers. When the ProcessMaker instance calls a ProcessMaker Script to run, ProcessMaker creates a Docker container for corresponding with the programming language ProcessMaker supports, 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 ProcessMaker 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 ProcessMaker instance creates a Docker container to run a ProcessMaker Script, required libraries are already built in that Docker container.
ProcessMaker Scripts are designed and tested in Scripts Editor.
While designing a ProcessMaker Script, test it before you deploy it. ProcessMaker 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 ProcessMaker Screens to ensure that variables designed from a ProcessMaker Screen function as intended in your ProcessMaker Script.
Incorporate other JSON-formatted data, such as API keys, to ensure your ProcessMaker Script uses them correctly during your testing.