From 343d5a4a539a61beabaa21cf492ae51ef47af39b Mon Sep 17 00:00:00 2001 From: RizaFarheen Date: Fri, 1 Nov 2024 16:35:45 +0400 Subject: [PATCH] Update event-task.md --- .../workflowdef/systemtasks/event-task.md | 119 +++++++++++++----- 1 file changed, 91 insertions(+), 28 deletions(-) diff --git a/docs/documentation/configuration/workflowdef/systemtasks/event-task.md b/docs/documentation/configuration/workflowdef/systemtasks/event-task.md index c3e3ff180..b17db49a8 100644 --- a/docs/documentation/configuration/workflowdef/systemtasks/event-task.md +++ b/docs/documentation/configuration/workflowdef/systemtasks/event-task.md @@ -4,14 +4,13 @@ "type" : "EVENT" ``` -The `EVENT` task is a task used to publish an event into one of the supported eventing systems in Conductor. +The `EVENT` task type in Conductor is used to publish events to supported eventing systems. It enables event-based dependencies within workflows and tasks, making it possible to trigger external systems like SQS, NATS, or AMQP as part of the workflow execution. ## Use Cases -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. +An EVENT task can be configured to send an event to an external system at any specified point in a workflow, enabling integration with event-based dependencies. ## Supported Queuing Systems -Conductor supports the the following eventing models: +Conductor supports the following queuing systems for EVENT tasks: 1. Conductor internal events (prefix: `conductor`) 2. SQS (prefix: `sqs`) @@ -20,60 +19,124 @@ Conductor supports the the following eventing models: ## Configuration -The following parameters are specified at the top level of the task configuration. | Attribute | Description | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| sink | External event queue in the format of `prefix:location`. Prefix is either `sqs` or `conductor` and `location` specifies the actual queue name. e.g. `sqs:send_email_queue` | -| asyncComplete | Boolean. [See below](#asynccomplete) | +| sink | The sink specifies the target event queue in the format `prefix:location`, where the prefix denotes the queuing system (e.g., `conductor`, `sqs`, `nats`, or `amqp`/`amqp_exchange`), and the location represents the specific queue name (e.g., `send_email_queue`). | +| asyncComplete | Setting `false` marks the status as COMPLETED upon execution, while setting `true` keeps the status IN_PROGRESS, awaiting completion from an external event. | -### asyncComplete -* ```false``` to mark status COMPLETED upon execution -* ```true``` to keep it IN_PROGRESS, wait for an external event (via Conductor or SQS or EventHandler) to complete it. - -### Conductor sink -When producing an event with Conductor as sink, the event name follows the structure: +### Conductor Sink +When producing an event with Conductor as a sink, the event name follows the structure: ```conductor::``` -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:`. The queue name is in the `event` value of the event Handler, as `conductor::`. +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:`. The queue name is in the `event` value of the event Handler, as `conductor::`. -### SQS sink -For SQS, use the **name** of the queue and NOT the URI. Conductor looks up the URI based on the name. +### SQS/NATS/AMQP Sink +Use the **queue's name**, NOT the URI. Conductor looks up the URI based on the name. ## Output -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. +Upon execution, the task’s output is sent to the external event queue. The payload contains: | name | type | description | | ------------------ | ------- | ------------------------------------- | -| workflowInstanceId | String | Workflow id | +| workflowInstanceId | String | Workflow ID | | workflowType | String | Workflow Name | | workflowVersion | Integer | Workflow Version | -| correlationId | String | Workflow CorrelationId | -| sink | String | Copy of the input data "sink" | -| asyncComplete | Boolean | Copy of the input data "asyncComplete | +| correlationId | String | Workflow Correlation ID | +| sink | String | Copy of input data for "sink" | +| asyncComplete | Boolean | Copy of input data for "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"). - +The published event's payload is identical to the task output (except "event_produced"). ## Examples -Consider an example where we want to publish an event into SQS to notify an external system. - +**Conductor Event:** ```json { "type": "EVENT", - "sink": "sqs:sqs_queue_name", + "sink": "conductor:internal_event_name", "asyncComplete": false } ``` -An example where we want to publish a messase to conductor's internal queuing system. +**SQS Event:** ```json { "type": "EVENT", - "sink": "conductor:internal_event_name", + "sink": "sqs:sqs_queue_name", "asyncComplete": false } +``` + +**NATS Event:** +```json +{ + + "type": "EVENT", + + "sink": "nats:nats_queue_name", + + "asyncComplete": false + +} +``` + +**AMQP Event:** +```json +{ + + "type": "EVENT", + + "sink": "amqp:amqp_queue_name", + + "asyncComplete": false + +} +``` + +## Event Queue Published Artifacts + +Group: `com.netflix.conductor` + +| Published Artifact | Description | +| ------------------------------- | ----------------------------------- | +| conductor-amqp | Support for integration with AMQP | +| conductor-nats | Support for integration with NATS | + +### Modules + +#### AMQP + +Provides the capability to publish and consume messages from AMQP-compatible brokers. + +Configuration (default values shown below): + +```java +conductor.event-queues.amqp.enabled=true +conductor.event-queues.amqp.hosts=localhost +conductor.event-queues.amqp.port=5672 +conductor.event-queues.amqp.username=guest +conductor.event-queues.amqp.password=guest +conductor.event-queues.amqp.virtualhost=/ +conductor.event-queues.amqp.useSslProtocol=false +#milliseconds +conductor.event-queues.amqp.connectionTimeout=60000 +conductor.event-queues.amqp.useExchange=true +conductor.event-queues.amqp.listenerQueuePrefix= +``` + +#### NATS + +Provides the capability to publish and consume messages from NATS queues. + +Configuration (default values shown below): + +```java +conductor.event-queues.nats.enabled=true +conductor.event-queues.nats-stream.clusterId=test-cluster +conductor.event-queues.nats-stream.durableName= +conductor.event-queues.nats-stream.url=nats://localhost:4222 +conductor.event-queues.nats-stream.listenerQueuePrefix= ``` \ No newline at end of file