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 scheduledeploy- 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
{% hint style="info" %} Special considerations for triggers:
deployandhttptriggers generate custom endpoints for your Lair. See endpoints.md for more details on how to manage endpoints.crontriggers only invoke processes in your Lair's production environment. See deployments.md for more details on how to deploy your tool to your Lair's production environment. {% endhint %}
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.
{% hint style="warning" %} 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. {% endhint %}
After adding a new trigger, you will see a corresponding entry in the Triggers panel. In the column labeled 'Test', there is a play (▶) button. Press this button to execute your trigger’s run command and start the process execution. See Processes for more details on how to view and manage processes.
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.
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.
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.
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.
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.
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.