Script Modules¶
Script modules provide reusable JavaScript libraries for process definitions. They encapsulate common functions, promoting code reusability and maintainability.
Module Scope and Sharing¶
By default, a script module is only accessible within its defining process definition. However, modules can be published for import into other processes.
Module Versions and Updates¶
When importing a script module, its content is copied into your process definition. Direct modifications to the imported script are not allowed.
If the source process definition (the one containing the original script module) is updated, all importing processes automatically receive the updated module content upon deployment.
Deployment of Script Modules¶
Script modules are deployed automatically alongside the process definition; separate deployment is not required.
Calling Module Functions¶
Consider a module named MyModule
:
1 2 3 |
|
Server-Side Function Calls¶
Server-side (pre/post-work scripts) call functions directly:
1 |
|
Client-Side Function Calls¶
Client-side scripts (browser-based) require asynchronous calls using Async
-suffixed function names:
1 |
|
The async/await
syntax handles the asynchronous nature; the server-side sum
function is automatically exposed as sumAsync
on the client.
REST Service Calls¶
Script modules are also exposed as REST services, enabling external system access. When called via REST, the following variables are available in addition to standard variables:
$ActiveUser
: The authenticated user's identity.$GrantedScopes
: Comma-separated string of granted API scopes.$Headers
: An object representing the HTTP request headers.$Cookies
: An object representing the HTTP request cookies.
Example REST Call:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
The Authorization
header uses a bearer token obtained via REST authentication.
Within the module function, $Headers
and $Cookies
would be populated as objects:
1 2 3 4 5 6 7 8 9 10 11 |
|