Script

Scripts are small pieces of logic that are used to encapsulate logic that is used during Workflow execution. They are defined as outcomes conforming to the Script XMLSchema version 0, defined by the kernel in source:/src/main/resources/boot/OD/Script.xsd, which allows definition of input variables and their types, the name and type of the output variable, other scripts to import into the execution environment as well as the script text.

Older versions of the kernel used the Bean Scripting Framework (BSF), but since 2.3 this was replaced with the built-in javax.script framework (JSR-223). Both support many different languages (JSR-223 Languages), but all internal of CRISTAL-iSE scripts are written in Javascript and executed in the Mozilla Rhino engine. Jython is included as a runtime dependency of the kernel, but any language may be used that is supported by the scripting framework, by including the relevant libraries in the classpath and giving the correct identifier in the 'language' attribute of the 'Script' element.

There are a couple of compatibility options available. Java8 replaced the Rhino engine with the new Nashorn one as the default engine for javascript, but it is not 100% compatible. A new property namespace 'OverrideScriptLang' can be used to mitigate this by overriding all 'javascript' scripts to 'rhino', and this can also be used to override engine for other languages. In environments where the javax.script engine discovery mechanism doesn't work, such as OSGi, the ScriptEngineManager may be overridden with the property 'Script.EngineManager', supplying either a classname or an instance of the required ScriptEngineManager.

Activity scripts

The most common script type is the Activity script, which is executed by an Agent during completion transitions of an Activities. Crucially, this happens in the AgentProxy object in the client process - Activity scripts represent work done by the executing Agent. As user-authored code, it would be dangerous to allow scripts on the server, for performance and security reasons, and so the server only acts as an orchestrator of workflows.

Input parameters of Activity scripts are supplied through ActivityProperties. These properties can be explicit, in the case of Scripts that can be configured to behave in different ways in different Activities. Properties can be defined in Activity Definitions, or in the referencing slot in a containing Composite Activity definition, or in both, in which case the slot value overrides the original Activity definition value. Properties may also give a path to a value in an outcome, using the DataHelper.

When Activity Scripts run, their execution environment is pre-configured with object relevant to the activity context as follows:

• item - the Item containing the Activity's lifecycle.
• agent - the Agent executing the Activity
• job - the transition being performed. This also contains a full list of the Activity properties, and is where the Script should look for configuration. Any references to Viewpoint data will be already resolved to actual values.
• errors - an ErrorInfo object. The log for the script error stream. Text lines may be added. If a fatal error is encountered, then the ErrorInfo may be marshalled into XML, which will be compliant to the kernel 'Errors' schema, and so may be submitted in an alternate transition, such as the 'Suspend' transition in some StateMachines