STEP Business Rule Test
This plugin provides an integration with the Stibo Systems STEP system.
Install
To install the distributable vsix package run
code --install-extension stepbusinessruletest-1.1.0.vsix
Setup
To allow development and testing of JavaScript business rules in VS Code, the STEP workbench can generate a VS Code workspace with an editable JavaScript file. The workspace will include a launch configuration configured to use this plugin to remotely execute the JavaScript file on the STEP server with all necessary configurations generated by STEP.
Usage
To test a JavaScript business rule, edit the JavaScript file, save it, and then run the JavaScript business rule from the Run and Debug tab.
Performance will be a bit slower than when the business rules run on the server normally for the following reasons.
- In this test execution we run the Rhino JavaScript engine in debug mode to have better controls for terminating scripts that have fallen into an infinite loop.
- The log messages written by the script will be sent back to VS Code as chunked HTTP response content inline in the script’s executing thread to provide the user with instant feedback while the business rule is still executing.
Business function parameters
The STEP Business Rule Test plugin does not support all parameter types available to STEP business functions. If the referenced node is of a type matching one of the node types supported by the business function, the plugin will map a node parameter type to the node reference by the nodeurl plugin parameter. All other parameter types are mapped to a null value. You can build a default value into the function code.
STEP business rule best practices
Every time a JavaScript business rule file is saved, the plugin enforces development conventions drawn from the STEP Business Rule Performance Recommendations:
Applied automatically on save (each one individually configurable, see Settings below):
- A standard STEP header comment is added if missing.
- A
getStepLogger(manager) helper is added if missing, resolving the STEP manager logger with a console fallback.
- A JSDoc stub is added above any undocumented top-level function.
- The
execute(...) function body is wrapped in a try { ... } catch (error) { logger.severe(...); throw error; } block. The catch re-throws - STEP requires this so the exception approval handler still runs; a caught-but-swallowed exception can leave objects inconsistently approved.
- Trailing whitespace is trimmed and line endings normalized.
- Optionally (off by default), the STEP-documented per-rule debug-flag pattern (
var isDebug = false; function logDebug(message) {...}) can be inserted for development-time verbose logging - remember to leave isDebug false before deploying.
Flagged as warnings in the Problems panel:
- Function/variable/library-alias names that are not camelCase (or UPPER_CASE for constants).
- Boolean variables not prefixed with
is/has/can/should.
- Write operations (
setValue, setSimpleValue, create, delete, approve) inside loop bodies - STEP guidance recommends keeping transactions short.
- Repeated node/value lookups inside loops - STEP guidance recommends consolidating into a single query ("Use Arrays Over Multiple Database Calls").
while(true)/for(;;) loops with no visible break/return - infinite loops can make the whole STEP installation unresponsive.
getChildren() usage - queryChildren() is recommended instead to avoid memory problems on large selections (>10,000 children).
catch blocks that do not re-throw.
- Business rule files above a configurable line-count threshold, since STEP recompiles rule/library code on every execution.
- Any user-configured deprecated-API regex patterns.
Run the STEP: Apply Business Rule Best Practices command (Command Palette) to apply all fixes on demand instead of waiting for save.
All of the above are configurable under Settings > Extensions > STEP Business Rule Test (stepbusinessruletest.bestPractices.*).