Your Lair can be configured with triggers that can execute processes through internal or external events. The WayScript team plans to add additional triggers based on user request. Please visit our feedback page to vote for your favorites!
Internal triggers
  • cron - invoke process on schedule
  • deploy - invoke process when Lair is deployed; used to start long-running processes such as active services
External triggers
  • http - invoke process when a request is made to a HTTP endpoint
Special considerations for triggers:
  • deploy and http triggers generate custom endpoints for your Lair. See Endpoints for more details on how to manage endpoints.
  • cron triggers only invoke processes in your Lair's production environment. See Deployments for more details on how to deploy your tool to your Lair's production environment.

Trigger operations

Adding a trigger to your Lair

Triggers are configured through the .triggers file stored within your Lair’s root directory. Open the .triggers file from your file system and select “+ New Trigger” to add a new trigger.
Choosing a trigger will open a configuration modal. Along with custom fields specific to the intended functionality, triggers have the following basic configuration elements:
  • Choose a name for your trigger.
  • Set a run command to invoke a process for your trigger.
  • (Optional) Select a JSON file that contains a test event object. See Events for more details.
After editing your trigger’s configuration, press “Save” to add your configuration to the .triggers file. You will also have to “Push” your workspace’s file system to update this configuration on your remote Lair.
Configured triggers only invoke processes in production Lair environments. However, you can test your triggers by manually running them through the configuration modal or using the generated development endpoints. See Hosted environments for more details on development vs. production environments.

Manually invoking your trigger

After opening the .triggers file, select an existing trigger to open the configuration modal. Press “Run” to execute your trigger’s run command and start the process execution. See Processes for more details on how to view and manage processes.

Accessing your trigger’s events

Your triggers can pass data payloads, called events in WayScript, to your processes. See Events for more details on how these events can be accessed.

Implementation considerations

Your triggers in WayScript are flexible, whereas they can invoke a process through any run command. However, in general, the http trigger routes HTTP requests to independent, asynchronous processes running in separate containers, while using the deploy trigger routes HTTP requests to a running service process in a single container.
Therefore, when designing your tool, it is useful to consider the following system characteristics to optimize performance of your tool.

Request latency

Requests made to http triggers vs. running service processes deployed via the deploy trigger will ALWAYS have higher latency due to serverless execution. When a request is made to an http trigger, the WayScript system must provision a new container, install any new dependencies, and attach logs before the request can be returned.

Request volume

If your tool will receive a high volume of requests, we recommend setting up a running service to reduce the number of logs generated and mitigate any losses of latency during periods of high WayScript system use (usually during ET business hours).
However, the WayScript team is actively working on improving the system's container orchestration, so this issue may be less pronounced in the future.

Scalability of endpoints

You can add multiple http triggers to your Lair and specify different paths for each trigger, but setting up a running service process gives you unlimited scalability of endpoints and more fine-tuned control of endpoint characteristics.

Runtime usage

While WayScript has not yet implemented workspace runtime restrictions, the team may add these in the future. Containers provisioned for processes invoked by http triggers will be torn down on process exit, and therefore in cases of low volume of requests, this approach will use less system runtime.