EVENT task is a task used to publish an event into one of the supported eventing systems in Conductor.
Consider a use case where at some point in the execution, an event is published to an external eventing system such as SQS. Event tasks are useful for creating event based dependencies for workflows and tasks.
Supported Queuing Systems
Conductor supports the the following eventing models:
- Conductor internal events (prefix:
- SQS (prefix:
- NATS (prefix:
- AMQP (prefix:
amqp_queue or amqp_exchange)
The following parameters are specified at the top level of the task configuration.
|sink||External event queue in the format of
|asyncComplete||Boolean. See below|
falseto mark status COMPLETED upon execution
trueto keep it IN_PROGRESS, wait for an external event (via Conductor or SQS or EventHandler) to complete it.
When producing an event with Conductor as sink, the event name follows the structure:
When using Conductor as sink, you have two options: defining the sink as
conductor in which case the queue name will default to the taskReferenceName of the Event Task, or specifying the queue name in the sink, as
conductor:<queue_name>. The queue name is in the
event value of the event Handler, as
For SQS, use the name of the queue and NOT the URI. Conductor looks up the URI based on the name.
When using SQS add the ContribsModule to the deployment. The module needs to be configured with AWSCredentialsProvider for Conductor to be able to use AWS APIs.
Tasks's output are sent as a payload to the external event. In case of SQS the task's output is sent to the SQS message a a payload.
|sink||String||Copy of the input data "sink"|
|asyncComplete||Boolean||Copy of the input data "asyncComplete|
|event_produced||String||Name of the event produced|
The published event's payload is identical to the output of the task (except "event_produced").
Consider an example where we want to publish an event into SQS to notify an external system.
An example where we want to publish a messase to conductor's internal queuing system.