Extensions

A Node.js service written in TypeScript. It is the heart of the system as it parses and serves automation scripts. It also executes server-scripts.

The Corteza server is responsible for automation script execution. On its own, Corredor server is unable to do any code execution; it must be invoked either via Corteza server or manually via gRCP protocol.

Each Corteza webapp that allows client-script execution implements this. The Corredor Client is responsible for client-script registration and their execution. Automation scripts are received from the Corteza Server.

Go over all extensions defined in the CORREDOR_EXT_SEARCH_PATHS .env variable. Extensions are separated by :.

Load all requested dependencies by the given extension.

Go over each script file defined inside the server-scripts sub-tree. Parse the script and extract all the important bits such as dependencies, triggers, iterators and the exec function itself.

Go over each script file defined inside the client-scripts sub-tree. Parse the script and extract all the important bits such as dependencies, triggers, iterators and the exec function itself. Create a per-app bundle containing relevant automation scripts, dependencies and other relevant bits. Refer to Client-script bundling for details about creating bundles.

This allows us to inspect what scripts were loaded from inside web-apps. It also simplifies the process of determining available automation scripts from inside client-script bundles.

Provides a list of available automation scripts for the given Corteza application.

Provides the client-script automation bundle for the given Corteza application.

Requests explicit server-script execution on the Corredor server.

Provides an endpoint that server-scripts are able to listen on and perform operations for.

This provides a full automation script list, including invalid scripts (those that didn’t compile successfully) — these are excluded.

Define a lightweight handler struct for easier execution determination and script identification. Execution is performed by the handler function that allows a bit more flexibility on how to handle each script type.

Register the above simplified automation script on the event buss.

An event is a generic interface that allows the event bus to determine what scripts should be executed.

Iterate and execute any automation script that conforms to the dispatched event. This can be done either synchronously or asynchronously.

Explicit scripts are invoked by the front-end applications or manually via the API. When invoked, an event is constructed and dispatched via the event bus.

These are triggered as a side-effect of another operation, such as record creation, user registration, password change, …​ Each part of the system that performs some operation that may invoke script execution generates an event and dispatches it on the event bus.

Iterator script execution is invoked like any other deferred script. The important difference is that a new instance is executed for every resource that matches the trigger’s constraints.

If 10 records match the provided filter, the script will be executed 10 times.

This provides available client-script automation scripts defined for the given application. This allows us to register available client-scripts.

This provides a full automation script list, including invalid scripts (those that didn’t compile successfully) — these are excluded. This allows us to register explicit server-scripts.

Define a lightweight Handler object for easier execution determination and script identification. Execution is performed by the handler function that allows a bit more flexibility on how to handle each script type.

Register the above simplified automation script on the event buss.

An event is an object that allows the event bus to determine what automation scripts should be executed and their execution context/arguments.

Iterate and execute any automation script that conforms to the dispatched event. This can be done either synchronously or asynchronously.

Explicit scripts are invoked by the user by explicitly invoking the above mentioned UI hooks. The web-app creates an event and dispatches it on the event bus. The handler function requests the script’s execution on the Corteza server.

These are triggered as a side-effect of another operation, such as form submission, view render, validation error, …​ Each part of the system that performs some operation that may invoke script execution generates an event and dispatches it on the event bus.