Triggers
A trigger is the entry point of a workflow: it defines when the workflow starts, how data is received and which data is passed to the workflow. Each workflow is associated with a single trigger.
What is a trigger?
A trigger connects an external event to a workflow. When the event occurs (HTTP request, dropped file, scheduled time, message in a queue…), Ecosystem executes the workflow, providing it with the received data via data; the context, for its part, starts empty and is enriched by the following nodes:
{
"data": { "orderId": "CMD-4821", "total": 149.9 },
"context": {}
}
The object actually received depends on the trigger type — see Trigger node for the detail per type.
Lifecycle of a trigger
The lifecycle of a trigger follows a fixed order: creation with the Inactive status, configuration of type-specific options, association of a workflow, activation (switch to Active), deployment in one or more environments, then execution — the trigger receives events or data and starts the workflow.
Two statuses apply to the trigger itself:
| Status | Meaning |
|---|---|
| Inactive | Created but triggers nothing. |
| Active | Can be deployed and start workflows according to its configuration. |
Trigger types
Ecosystem supports six families of triggers:
| Type | When to use it | Documentation |
|---|---|---|
| API route | Expose a REST API or receive webhooks (HTTP notifications). | API route |
| File | Start a workflow when a file arrives (upload, FTP/SFTP, email). | File |
| Scheduler | Execute on a schedule (CRON expression). | Scheduler |
| Polling | Poll an external API periodically and process the results. | Polling |
| Google Pub/Sub event | React to every message of a Google Pub/Sub subscription. | Google Pub/Sub event |
| AWS SQS | React to every message of an Amazon SQS queue. | AWS SQS |
Slug and public URL
Each trigger has a unique slug, used in the public URL, which must remain unique within the organization.
The slug is the part of the URL that identifies the trigger: it is generated from the name (lowercase letters, digits, dots and dashes) and appears after the environment domain. New triggers use dots as separators; already created triggers keep their existing slug.
The URL is built in the https://<environment>-<company>.ecosystem.apizr.io/<slug> format. For example, for an "Order reception API" trigger deployed on the studio development environment of the testdev company:
| Element | Example |
|---|---|
| Slug | api.reception.commandes |
| Full URL | https://studio-testdev.ecosystem.apizr.io/api.reception.commandes |
The full URL is displayed after deployment — see API route and Deploy a trigger.
Apps, tags and deployments
- Apps: attach triggers and workflows to a business application and feed the mapping — Apps.
- Tags: categorize and filter triggers in the lists.
- Deployment: a trigger must be deployed in an environment to be operational there; it can be deployed in several environments — Deploy a trigger.
Next steps
See also: Trigger node · Permissions — Workflows and triggers