Overview
#
After a workflow is built and ready for use, you must define how and when it will run.
A workflow can be executed in two ways:
- Triggered by a webhook request.
- Scheduled using a cron expression (a string that defines the execution times for the workflow).
Triggers Walkthrough #
Schedules Walkthrough #
Advanced Settings #
Triggers #
A workflow can have one or more associated triggers.
Each trigger has:
- A unique name.
- A randomly generated ID used to define the trigger URL.
Each trigger is linked to a single environment, allowing different trigger configurations for production and non-production environments.
A trigger can be configured in the following areas.
Payload Options
#
- Payload Required: A true/false value that determines whether a payload (request body) is required in the webhook request.
Validation Options
#
- Validation Required: A true/false value that determines whether the payload (request body) must be validated against a JSON schema.
- Validation Rules: A set of rule-based tests applied to payload data. Each rule must evaluate to
truefor the request to be considered valid. Only valid requests trigger workflow execution.
Validation Rule Components
Each validation rule contains:
- Name: A unique rule name.
- Statement: A SiPHON mapper statement that evaluates to
trueorfalse. The statement must return a boolean value. See mapper documentation for details.
Webhook Configuration
#
Webhook configuration is divided into three sections:
- Restrictions
- Registration
- Authentication
Restrictions
Available restriction types:
- IP Range
- None
IP Range Restriction Configuration
You can configure one or more allowed IP ranges. Only webhook requests originating from these ranges can trigger the workflow.
Each IP range entry must be provided as a CIDR notation string.
Registration
Some webhook emitters require a registration step before they can trigger a workflow.
When needed, these registration settings allow SiPHON to detect and handle registration requests automatically.
Registration options:
- Condition: A SiPHON mapper statement that evaluates to
trueorfalse. The statement must return a boolean value. See mapper documentation for details. If the condition evaluates totrue, the request is handled as a registration request. - Response: A SiPHON mapper statement used to generate the response to the registration request. The statement must return a JSON data structure in the format expected by the emitter. See mapper documentation for details.
- Secret: An optional secret used to authenticate the validation request.
Authentication
Some webhook emitters include authentication credentials in the request.
When authentication is configured, only requests that pass the configured authentication can trigger the workflow.
Five authentication types are available:
- HMAC SHA 256
- API Key
- Basic Authentication
- Bearer Token
- None
HMAC SHA 256 Authentication Configuration Options
- Header: The name of the authentication header.
- Secret: The secret used for authentication.
API Key Authentication Configuration Options
- Key: The API key used for authentication.
- Header: The name of the authentication header.
- NOTE: the header “x-api-key” is a reserved header that can’t be used in this field.
Basic Authentication Configuration Options
- Username: The username used for authentication.
- Password: The password used for authentication.
Bearer Token Authentication Configuration Options
- Token: The bearer token used for authentication.
Schedules #
A workflow can have one or more associated schedules.
Each schedule has:
- A unique name.
- Cron Configuration: See details below.
Each schedule may have:
- Correlation ID: An optional user-specified UUID included in every workflow execution that uses the schedule.
- Job Data: An optional JSON object included in every workflow execution that uses the schedule.
Cron Configuration
- Cron Expression: The cron expression that defines when the workflow runs.
- Timezone: The timezone applied to the schedule.