+
+## 3. Launch UI
+Building UI requires `node` and `yarn` to be installed. Download them if required:
+1. https://nodejs.org/en/download/
+2. https://classic.yarnpkg.com/lang/en/docs/install/
+
+Once downloaded, build and install UI
+
+```shell
+$ cd conductor/ui
+```
+```shell
+yarn install
+```
+```shell
+yarn run start
+```
+
+Navigate to [http://localhost:5000](http://localhost:5000) to open the UI
+
+
+
+
+> Congrats! You have successfully installed a fully working version of Conductor Server and UI on your local.
+
+* By default the UI will connect with the API server on 8080 port, if you need to change this port for any reason you
+ have to edit the configuration files to do so
+* All the data is stored in memory, so if you restart the services you will lose all the data. We will be publishing
+ guides on how to set up a persisted data store on your local shortly. Look out for it!
\ No newline at end of file
diff --git a/docs/reference-docs/do-while-task.md b/docs/reference-docs/do-while-task.md
new file mode 100644
index 00000000..6a405171
--- /dev/null
+++ b/docs/reference-docs/do-while-task.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Do While Task
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/reference-docs/dynamic-fork-task.md b/docs/reference-docs/dynamic-fork-task.md
new file mode 100644
index 00000000..0b631279
--- /dev/null
+++ b/docs/reference-docs/dynamic-fork-task.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Dynamic Fork Task
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/reference-docs/dynamic-task-legacy.md b/docs/reference-docs/dynamic-task-legacy.md
new file mode 100644
index 00000000..55a1041b
--- /dev/null
+++ b/docs/reference-docs/dynamic-task-legacy.md
@@ -0,0 +1,39 @@
+---
+sidebar_position: 1
+---
+# Dynamic Task
+
+## What is a Dynamic Task?
+
+TODO: What is a Dynamic task? How does it work?
+
+## Common Use Cases
+
+TODO: List out some common use cases
+
+## Configuration / Properties
+
+### Inputs
+
+TODO: Talk about inputs for the task
+
+### Output
+
+TODO: Talk about output of the task, what to expect
+
+
+## Examples
+
+TODO: Example 1
+
+TODO: Example 2
+
+## FAQs
+
+TODO: Gotchas and other nuances
+
+1. Question 1
+ 1. Answer
+
+1. Question 2
+ 1. Answer
diff --git a/docs/reference-docs/dynamic-task.md b/docs/reference-docs/dynamic-task.md
new file mode 100644
index 00000000..6ee72f68
--- /dev/null
+++ b/docs/reference-docs/dynamic-task.md
@@ -0,0 +1,178 @@
+---
+sidebar_position: 1
+---
+# Dynamic Task
+
+## What is a Dynamic Task?
+
+Dynamic Task allows to execute one of the registered Tasks dynamically at run-time.
+It accepts the task name to execute as `taskToExecute` in `inputParameters`.
+
+## Common Use Cases
+
+Consider a scenario, when we have to make decision of executing a task dynamically i.e. while the workflow is still
+running. In such cases, Dynamic Task would be useful.
+
+## Configuration / Properties
+
+Dynamic task is defined directly inside the workflow with type `DYNAMIC`.
+
+### Inputs
+
+Following are the input parameters :
+
+|name|description|
+|---|---|
+| dynamicTaskNameParam|Name of the parameter from the task input whose value is used to schedule the task. e.g. if the value of the parameter is ABC, the next task scheduled is of type 'ABC'.|
+
+### Output
+
+TODO: Talk about output of the task, what to expect
+
+
+## Examples
+
+Suppose in a workflow, we have to take decision to ship the courier with the shipping
+service providers on the basis of Post Code.
+
+Following task `shipping_info` generates an output on the basis of which decision would be
+taken to run the next task.
+
+```json
+{
+ "name": "shipping_info",
+ "retryCount": 3,
+ "timeoutSeconds": 600,
+ "pollTimeoutSeconds": 1200,
+ "timeoutPolicy": "TIME_OUT_WF",
+ "retryLogic": "FIXED",
+ "retryDelaySeconds": 300,
+ "responseTimeoutSeconds": 300,
+ "concurrentExecLimit": 100,
+ "rateLimitFrequencyInSeconds": 60,
+ "ownerEmail":"abc@example.com",
+ "rateLimitPerFrequency": 1
+}
+```
+
+Following are the two worker tasks, one among them would execute on the basis of output generated
+by the `shipping_info` task :
+
+```json
+{
+ "name": "ship_via_fedex",
+ "retryCount": 3,
+ "timeoutSeconds": 600,
+ "pollTimeoutSeconds": 1200,
+ "timeoutPolicy": "TIME_OUT_WF",
+ "retryLogic": "FIXED",
+ "retryDelaySeconds": 300,
+ "responseTimeoutSeconds": 300,
+ "concurrentExecLimit": 100,
+ "rateLimitFrequencyInSeconds": 60,
+ "ownerEmail":"abc@example.com",
+ "rateLimitPerFrequency": 2
+},
+{
+ "name": "ship_via_ups",
+ "retryCount": 3,
+ "timeoutSeconds": 600,
+ "pollTimeoutSeconds": 1200,
+ "timeoutPolicy": "TIME_OUT_WF",
+ "retryLogic": "FIXED",
+ "retryDelaySeconds": 300,
+ "responseTimeoutSeconds": 300,
+ "concurrentExecLimit": 100,
+ "rateLimitFrequencyInSeconds": 60,
+ "ownerEmail":"abc@example.com",
+ "rateLimitPerFrequency": 2
+}
+```
+
+
+We will create the Workflow with the following definition :
+
+```json
+{
+ "name": "Shipping_Flow",
+ "description": "Ships smartly on the basis of Shipping info",
+ "version": 1,
+ "tasks": [
+ {
+ "name": "shipping_info",
+ "taskReferenceName": "shipping_info",
+ "inputParameters": {
+ },
+ "type": "SIMPLE"
+ },
+ {
+ "name": "shipping_task",
+ "taskReferenceName": "shipping_task",
+ "inputParameters": {
+ "taskToExecute": "${shipping_info.output.shipping_service}"
+ },
+ "type": "DYNAMIC",
+ "dynamicTaskNameParam": "taskToExecute"
+ }
+
+ ],
+ "restartable": true,
+ "ownerEmail":"abc@example.com",
+ "workflowStatusListenerEnabled": true,
+ "schemaVersion": 2
+}
+```
+
+Workflow is the created as shown in the below diagram.
+
+
+
+
+
+Note : `shipping_task` is a `DYNAMIC` task and the `taskToExecute` parameter can be set
+with input value provided while running the workflow or with the output of previous tasks.
+Here, it is set to the output provided by the previous task i.e.
+`${shipping_info.output.shipping_service}`.
+
+If the input value is provided while running the workflow it can be accessed by
+`${workflow.input.shipping_service}`.
+
+```json
+{
+ "shipping_service": "ship_via_fedex"
+}
+```
+
+We can see in the below example that on the basis of Post Code the shipping service is being
+decided.
+
+```js reference
+https://github.com/orkes-io/orkesworkers/blob/main/src/main/java/io/orkes/samples/workers/ShippingInfoWorker.java#L10-L36
+```
+
+Based on given set of inputs i.e. Post Code starts with '9' hence, `ship_via_fedex` is executed -
+
+
+
+If the Post Code started with anything other than 9 `ship_via_ups` is executed -
+
+
+
+If the incorrect task name or the task that doesn't exist is provided then the workflow fails and
+we get the error `"Invalid task specified. Cannot find task by name in the task definitions."`
+
+If the null reference is provided in the task name then also the workflow fails and we get the
+error `"Cannot map a dynamic task based on the parameter and input. Parameter= taskToExecute, input= {taskToExecute=null}"`
+
+
+
+
+## FAQs
+
+TODO: Gotchas and other nuances
+
+1. Question 1
+ 1. Answer
+
+1. Question 2
+ 1. Answer
diff --git a/docs/reference-docs/exclusive-join-task.md b/docs/reference-docs/exclusive-join-task.md
new file mode 100644
index 00000000..3a9cd71b
--- /dev/null
+++ b/docs/reference-docs/exclusive-join-task.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Exclusive Join Task
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/reference-docs/fork-task.md b/docs/reference-docs/fork-task.md
new file mode 100644
index 00000000..575c5175
--- /dev/null
+++ b/docs/reference-docs/fork-task.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Fork Task
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/reference-docs/http-task.md b/docs/reference-docs/http-task.md
new file mode 100644
index 00000000..0e5b92c9
--- /dev/null
+++ b/docs/reference-docs/http-task.md
@@ -0,0 +1,134 @@
+---
+sidebar_position: 1
+---
+
+# Http Task
+
+## What is a HTTP Task?
+
+An HTTP task is useful when you have a requirements such as
+
+1. Making calls to another service that exposes an API via HTTP
+2. Fetch any resource or data present on an endpoint
+
+## Common Use Cases
+
+If there is a scenario where, we need to make a call to a microservice and fetch some data or resource and use it inside
+our workflow. In such cases HTTP Task would very helpful. Using HTTP tasks you can avoid having to write the code that
+talks to these services and instead let Conductor manage it directly. This can reduce the code you have to maintain and
+allows for a lot of flexibility.
+
+## Configuration / Properties
+
+HTTP task is defined directly inside the workflow with type `HTTP`.
+
+|name|type|description|
+|---|---|---|
+| http_request | HttpRequest | JSON object (see below) |
+
+### Inputs
+
+|Name|Type|Example|Description|
+|---|---|---|---|
+| uri | String || URI for the service. Can be a partial when using vipAddress or includes the server address.|
+| method | String || HTTP method. One of the GET, PUT, POST, DELETE, OPTIONS, HEAD|
+| accept | String || Accept header as required by server. Defaults to ```application/json``` |
+| contentType | String || Content Type - supported types are ```text/plain```, ```text/html```, and ```application/json``` (Default)|
+| headers| Map[String, Any] || A map of additional http headers to be sent along with the request.|
+| body| Map[] || Request body |
+| vipAddress | String || When using discovery based service URLs.|
+| asyncComplete | Boolean |TODO: Link to details| ```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.
+| oauthConsumerKey | String || [OAuth](https://oauth.net/core/1.0/) client consumer key |
+| oauthConsumerSecret | String || [OAuth](https://oauth.net/core/1.0/) client consumer secret |
+| connectionTimeOut | Integer || Connection Time Out in milliseconds. If set to 0, equivalent to infinity. Default: 100. |
+| readTimeOut | Integer || Read Time Out in milliseconds. If set to 0, equivalent to infinity. Default: 150. |
+
+### Output
+
+|name|type|description|
+|---|---|---|
+| response | Map | JSON body containing the response if one is present |
+| headers | Map[String, Any] | Response Headers |
+| statusCode | Integer | [Http Status Code](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) |
+| reasonPhrase | String | Http Status Code's reason phrase |
+
+## Examples
+
+Following is the example of HTTP task with `GET` method.
+
+```json
+
+{
+ "name": "Get Example",
+ "taskReferenceName": "get_example",
+ "inputParameters": {
+ "http_request": {
+ "uri": "https://jsonplaceholder.typicode.com/posts/1",
+ "method": "GET"
+ }
+ },
+ "type": "HTTP"
+}
+```
+
+Following is the example of HTTP task with `POST` method.
+
+```json
+{
+ "name": "POST Example",
+ "taskReferenceName": "post_example",
+ "inputParameters": {
+ "http_request": {
+ "uri": "https://jsonplaceholder.typicode.com/posts/",
+ "method": "POST"
+ }
+ },
+ "type": "HTTP"
+}
+```
+
+Following is the example of HTTP task with `PUT` method.
+
+```json
+{
+ "name": "PUT Example",
+ "taskReferenceName": "put_example",
+ "inputParameters": {
+ "http_request": {
+ "uri": "https://jsonplaceholder.typicode.com/posts/1",
+ "method": "PUT"
+ }
+ },
+ "type": "HTTP"
+}
+```
+
+Following is the example of HTTP task with `DELETE` method.
+
+```json
+{
+ "name": "DELETE Example",
+ "taskReferenceName": "delete_example",
+ "inputParameters": {
+ "http_request": {
+ "uri": "https://jsonplaceholder.typicode.com/posts/1",
+ "method": "DELETE"
+ }
+ },
+ "type": "HTTP"
+}
+```
+
+In order to implement HTTP task in our workflow, we need to define HTTP task as shown above under the tasks section in
+the workflow. We can choose our method type and specify all the attributes.
+
+## FAQs
+
+TODO: Gotchas and other nuances
+
+1. Question 1
+ 1. Answer
+
+1. Question 2
+ 1. Answer
+
diff --git a/docs/reference-docs/inline-task.md b/docs/reference-docs/inline-task.md
new file mode 100644
index 00000000..24f52d5a
--- /dev/null
+++ b/docs/reference-docs/inline-task.md
@@ -0,0 +1,70 @@
+---
+sidebar_position: 1
+---
+# Inline Task
+
+## What is a Inline Task?
+
+Inline Task helps execute necessary logic at Workflow run-time,
+using any evaluator engine. Supported evaluators are value-param
+evaluator which simply translates the input parameter to output and
+javascript evaluator that evaluates Javascript expression.
+
+## Common Use Cases
+
+Consider a scenario, we have to run simple evaluations in
+Conductor server while creating Workers. Inline task can be used to run these
+evaluations using an evaluator engine.
+
+## Configuration / Properties
+
+Inline task is defined directly inside the workflow with
+`"type":"INLINE"`.
+
+### Inputs
+
+Following are the input parameters :
+
+|name|type|description|notes|
+|---|---|---|---|
+|evaluatorType|String|Type of the evaluator. Supported evaluators: `value-param`, `javascript` which evaluates javascript expression.|
+|expression|String|Expression associated with the type of evaluator. For `javascript` evaluator, Javascript evaluation engine is used to evaluate expression defined as a string. Must return a value.|Must be non-empty.|
+
+Besides `expression`, any value is accessible as `$.value` for the `expression` to evaluate.
+
+### Output
+
+Following is the output generated :
+
+|name|type|description|
+|---|---|---|
+|result|Map|Contains the output returned by the evaluator based on the `expression`|
+
+The task output can then be referenced in downstream tasks like:
+```"${inline_test.output.result.testvalue}"```
+
+## Examples
+
+```json
+{
+ "name": "INLINE_TASK",
+ "taskReferenceName": "inline_test",
+ "type": "INLINE",
+ "inputParameters": {
+ "inlineValue": "${workflow.input.inlineValue}",
+ "evaluatorType": "javascript",
+ "expression": "function scriptFun(){if ($.inlineValue == 1){ return {testvalue: true} } else { return
+{testvalue: false} }} scriptFun();"
+ }
+}
+```
+
+## FAQs
+
+TODO: Gotchas and other nuances
+
+1. Question 1
+ 1. Answer
+
+1. Question 2
+ 1. Answer
diff --git a/docs/reference-docs/join-task.md b/docs/reference-docs/join-task.md
new file mode 100644
index 00000000..c128ca33
--- /dev/null
+++ b/docs/reference-docs/join-task.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Join Task
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/reference-docs/json-jq-transform-task.md b/docs/reference-docs/json-jq-transform-task.md
new file mode 100644
index 00000000..6689c4be
--- /dev/null
+++ b/docs/reference-docs/json-jq-transform-task.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Json JQ Transform Task
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/reference-docs/kafka-publish-task.md b/docs/reference-docs/kafka-publish-task.md
new file mode 100644
index 00000000..33a9ffe7
--- /dev/null
+++ b/docs/reference-docs/kafka-publish-task.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Kafka Publish Task
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/reference-docs/operators.md b/docs/reference-docs/operators.md
new file mode 100644
index 00000000..c41ac391
--- /dev/null
+++ b/docs/reference-docs/operators.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Operators
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/reference-docs/sample-layout.md b/docs/reference-docs/sample-layout.md
new file mode 100644
index 00000000..55a1041b
--- /dev/null
+++ b/docs/reference-docs/sample-layout.md
@@ -0,0 +1,39 @@
+---
+sidebar_position: 1
+---
+# Dynamic Task
+
+## What is a Dynamic Task?
+
+TODO: What is a Dynamic task? How does it work?
+
+## Common Use Cases
+
+TODO: List out some common use cases
+
+## Configuration / Properties
+
+### Inputs
+
+TODO: Talk about inputs for the task
+
+### Output
+
+TODO: Talk about output of the task, what to expect
+
+
+## Examples
+
+TODO: Example 1
+
+TODO: Example 2
+
+## FAQs
+
+TODO: Gotchas and other nuances
+
+1. Question 1
+ 1. Answer
+
+1. Question 2
+ 1. Answer
diff --git a/docs/reference-docs/set-variable-task.md b/docs/reference-docs/set-variable-task.md
new file mode 100644
index 00000000..b777208e
--- /dev/null
+++ b/docs/reference-docs/set-variable-task.md
@@ -0,0 +1,85 @@
+---
+sidebar_position: 1
+---
+
+# Set Variable Task
+
+## What is a Set Variable Task?
+
+This task allows us to set workflow variables by creating or updating them
+with new values.
+
+## Common Use Cases
+
+Variables can be initialized in the workflow definition as well as during
+the workflow run. Once a variable was initialized it can be read or
+overwritten with a new value by any other task.
+
+## Configuration / Properties
+
+Set Variable task is defined directly inside the workflow with type
+`SET_VARIABLE`.
+
+### Inputs
+
+No inputs
+
+### Output
+
+No output
+
+## Examples
+
+Suppose in a workflow, we have to store a value in a variable and then later in
+workflow reuse the value stored in the variable just as we do in programming, in such
+scenarios `Set Variable` task can be used.
+
+Following is the workflow definition with `SET_VARIABLE` task.
+
+```json
+{
+ "name": "Set_Variable_Workflow",
+ "description": "Set a value to a variable and then reuse it later in the workflow",
+ "version": 1,
+ "tasks": [
+ {
+ "name": "Set_Name",
+ "taskReferenceName": "Set_Name",
+ "type": "SET_VARIABLE",
+ "inputParameters": {
+ "name": "Orkes"
+ }
+ },
+ {
+ "name": "Read_Name",
+ "taskReferenceName": "Read_Name",
+ "inputParameters": {
+ "var_name" : "${workflow.variables.name}"
+ },
+ "type": "SIMPLE"
+ }
+ ],
+ "restartable": true,
+ "ownerEmail":"abc@example.com",
+ "workflowStatusListenerEnabled": true,
+ "schemaVersion": 2
+}
+```
+
+In the above example, it can be seen that the task `Set_Name` is a Set Variable Task and
+the variable `name` is set to `Orkes` and later in the workflow it is referenced by
+`"${workflow.variables.name}"` in another task.
+
+
+
+
+## FAQs
+
+TODO: Gotchas and other nuances
+
+1. Question 1
+ 1. Answer
+
+1. Question 2
+ 1. Answer
+
diff --git a/docs/reference-docs/sub-workflow-task.md b/docs/reference-docs/sub-workflow-task.md
new file mode 100644
index 00000000..543a0742
--- /dev/null
+++ b/docs/reference-docs/sub-workflow-task.md
@@ -0,0 +1,160 @@
+---
+sidebar_position: 1
+---
+# Sub Workflow Task
+
+## What is a Sub Workflow Task?
+
+Sub Workflow task allows for nesting a workflow within another workflow.
+
+## Common Use Cases
+
+Suppose we want to include another workflow inside our current workflow. In that
+case, Sub Workflow Task would be used.
+
+## Configuration / Properties
+
+Sub Workflow task is defined directly inside the workflow with `"SUB_WORKFLOW"`.
+
+### Inputs
+
+**Parameters:**
+
+|name|type|description|
+|---|---|---|
+| subWorkflowParam | Map[String, Any] | See below |
+
+**subWorkflowParam**
+
+|name|type|description|
+|---|---|---|
+| name | String | Name of the workflow to execute |
+| version | Integer | Version of the workflow to execute |
+| taskToDomain | Map[String, String] | Allows scheduling the sub workflow's tasks per given mappings. See [Task Domains](conductor/configuration/taskdomains/) for instructions to configure taskDomains. |
+| workflowDefinition | [WorkflowDefinition](conductor/configuration/workflowdef/) | Allows starting a subworkflow with a dynamic workflow definition. |
+
+### Output
+
+|name|type|description|
+|---|---|---|
+| subWorkflowId | String | Subworkflow execution Id generated when running the subworkflow |
+0
+## Examples
+
+Suppose in a workflow, we have to run another workflow. Consider the example that we took
+in Dynamic Task. Let's extend that example. Suppose in an E-Commerce website user places
+the order we have to take the decision based on the inputs to ship the product via a
+courier service. We can run another workflow inside our workflow which we already
+created in `Dynamic Task`.
+
+Following task `order_details` fetches data about the order.
+
+```json
+{
+ "name": "order_details",
+ "retryCount": 1,
+ "timeoutSeconds": 600,
+ "pollTimeoutSeconds": 1200,
+ "timeoutPolicy": "TIME_OUT_WF",
+ "retryLogic": "FIXED",
+ "retryDelaySeconds": 300,
+ "responseTimeoutSeconds": 300,
+ "concurrentExecLimit": 100,
+ "rateLimitFrequencyInSeconds": 60,
+ "ownerEmail":"abc@example.com",
+ "rateLimitPerFrequency": 1
+}
+```
+
+Now we will be nesting the workflow named `Shipping_Flow` (defined inside Dynamic Task section)
+inside our new Workflow by following definition -
+
+```json
+{
+ "name": "E_Commerce_Website_Example",
+ "description": "E_Commerce_Website_Example",
+ "version": 1,
+ "tasks": [
+ {
+ "name": "order_details",
+ "taskReferenceName": "order_details",
+ "inputParameters": {
+ },
+ "type": "SIMPLE"
+ },
+ {
+ "name": "Shipping_Flow",
+ "taskReferenceName": "Shipping_Flow",
+ "type": "SUB_WORKFLOW",
+ "inputParameters": {
+ "subWorkflowParam": {
+ "name": "Shipping_Flow",
+ "version": 1,
+ "taskToDomain": {
+ "*": "mydomain"
+ },
+ "workflowDefinition": {
+ "name": "Shipping_Flow",
+ "description": "Ships smartly on the basis of Shipping info",
+ "version": 1,
+ "tasks": [
+ {
+ "name": "shipping_info",
+ "taskReferenceName": "shipping_info",
+ "inputParameters": {
+ },
+ "type": "SIMPLE"
+ },
+ {
+ "name": "shipping_task",
+ "taskReferenceName": "shipping_task",
+ "inputParameters": {
+ "taskToExecute": "${shipping_info.output.shipping_service}"
+ },
+ "type": "DYNAMIC",
+ "dynamicTaskNameParam": "taskToExecute"
+ }
+
+ ],
+ "restartable": true,
+ "ownerEmail":"abc@example.com",
+ "workflowStatusListenerEnabled": true,
+ "schemaVersion": 2
+ }
+ }
+ }
+ }
+
+ ],
+ "restartable": true,
+ "ownerEmail":"abc@example.com",
+ "workflowStatusListenerEnabled": true,
+ "schemaVersion": 2
+}
+```
+
+Workflow is the created as shown in the below diagram.
+
+
+
+We can see in the above diagram that Workflow named `Shipping_Flow` gets nested inside
+the workflow we just created. Hence, in scenarios where we need to nest a workflow inside
+another workflow `Set Workflow` task can be used.
+
+We can create workers as we did in `Dynamic Task` section and for running this workflow.
+
+After execution workflow looks like.
+
+
+
+
+
+## FAQs
+
+TODO: Gotchas and other nuances
+
+1. Question 1
+ 1. Answer
+
+1. Question 2
+ 1. Answer
diff --git a/docs/reference-docs/switch-task.md b/docs/reference-docs/switch-task.md
new file mode 100644
index 00000000..06863dd3
--- /dev/null
+++ b/docs/reference-docs/switch-task.md
@@ -0,0 +1,149 @@
+---
+sidebar_position: 1
+---
+
+# Switch Task
+
+## What is a Switch Task?
+
+A switch task is similar to `case...switch` statement in a programming
+language. The `switch` expression, however, is simply an input parameter
+(`value-param` evaluator) or a complex javascript expression
+(`javascript` evaluator). Only two evaluators are supported by default
+in conductor.
+
+## Common Use Cases
+
+## Configuration / Properties
+
+Switch task is defined directly inside the workflow with
+`"type":"SWITCH"`.
+
+### Inputs
+
+Following are the input parameters :
+
+|name|type|description|
+|---|---|---|
+|evaluatorType|String|Type of the evaluator used. Supported types: `value-param`, `javascript`.|
+|expression|String|Expression that depends on the evaluator type. For `value-param` evaluator, expression is input parameter, for `javascript` evaluator, it is the javascript expression.|
+|decisionCases|Map[String, List[task]]|Map where key is possible values that can result from `expression` being evaluated by `evaluatorType` with value being list of tasks to be executed.|
+|defaultCase|List[task]|List of tasks to be executed when no matching value if found in decision case (default condition)|
+
+
+### Output
+
+Following is/are output generated by the `Switch` Task.
+
+|name|type|description|
+|---|---|---|
+|evaluationResult|List[String]|A List of string representing the list of cases that matched.|
+
+## Examples
+
+Suppose in a workflow, we have to take decision to ship the courier with the shipping
+service providers on the basis of input provided while running the workflow.
+
+Tasks are same as we defined in [Dynamic Task](/docs/reference-docs/dynamic-task).
+Tasks are same as we defined in `Dynamic Task`.
+
+We will create the Workflow with the following definition :
+
+```json
+{
+ "name": "Switch_Task_Shipping_Info",
+ "description": "Switch_Task_Shipping_Info",
+ "version": 1,
+ "ownerEmail":"abc@example.com",
+ "tasks": [
+ {
+ "name": "shipping_info",
+ "taskReferenceName": "shipping_info",
+ "inputParameters": {
+ },
+ "type": "SIMPLE"
+ },
+ {
+ "name": "switch_task",
+ "taskReferenceName": "switch_task",
+ "inputParameters": {
+ "case_value_param": "${workflow.input.service}"
+ },
+ "type": "SWITCH",
+ "ownerEmail":"abc@example.com",
+ "evaluatorType": "value-param",
+ "expression": "case_value_param",
+ "defaultCase": [
+ {
+ "name": "ship_via_dhl",
+ "taskReferenceName": "ship_via_dhl",
+ "inputParameters": {
+ },
+ "type": "SIMPLE"
+ }
+ ],
+ "decisionCases": {
+ "fedex": [
+ {
+ "name": "ship_via_fedex",
+ "taskReferenceName": "ship_via_fedex",
+ "inputParameters": {
+ },
+ "type": "SIMPLE"
+ }
+ ],
+ "ups": [
+ {
+ "name": "ship_via_ups",
+ "taskReferenceName": "ship_via_ups",
+ "inputParameters": {
+ },
+ "type": "SIMPLE"
+ }
+ ]
+ }
+}
+],
+ "restartable": true,
+ "workflowStatusListenerEnabled": true,
+ "schemaVersion": 2
+}
+```
+
+Workflow is the created as shown in the below diagram.
+
+
+
+Note : `switch_task` is a `SWITCH` task and the `case_value_param` parameter can be set
+with input value provided while running the workflow. i.e. `${workflow.input.service}`.
+
+```json
+{
+ "service": "fedex"
+}
+```
+
+Based on given set of inputs i.e. `"service":"fedex"`, `ship_via_fedex` is executed -
+
+
+
+
+If the input `"service":"ups"` is provided then, `ship_via_ups` is executed -
+
+
+
+If the any input other than above 2 is provided then `ship_via_dhl` is executed -
+
+
+
+
+
+## FAQs
+
+TODO: Gotchas and other nuances
+
+1. Question 1
+ 1. Answer
+
+1. Question 2
+ 1. Answer
diff --git a/docs/reference-docs/system-tasks.md b/docs/reference-docs/system-tasks.md
new file mode 100644
index 00000000..cd265a36
--- /dev/null
+++ b/docs/reference-docs/system-tasks.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# System Task
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/reference-docs/tasks-and-workers.md b/docs/reference-docs/tasks-and-workers.md
new file mode 100644
index 00000000..bf3d575b
--- /dev/null
+++ b/docs/reference-docs/tasks-and-workers.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Tasks and Workers
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/reference-docs/terminate-task.md b/docs/reference-docs/terminate-task.md
new file mode 100644
index 00000000..a10840ef
--- /dev/null
+++ b/docs/reference-docs/terminate-task.md
@@ -0,0 +1,157 @@
+---
+sidebar_position: 1
+---
+# Terminate Task
+
+## What is a Terminate Task?
+
+Task that can terminate a workflow with a given status and modify the
+workflow's output with a given parameter. It can act as a `"return"` statement
+for conditions where you simply want to terminate your workflow.
+
+## Common Use Cases
+
+Consider a scenario, if you have a decision where the first condition
+is met, you want to execute some tasks, otherwise you want to finish
+your workflow.
+
+## Configuration / Properties
+
+Terminate task is defined directly inside the workflow with type
+`TERMINATE`.
+
+```json
+{
+ "name": "terminate",
+ "taskReferenceName": "terminate0",
+ "inputParameters": {
+ "terminationStatus": "COMPLETED",
+ "workflowOutput": "${task0.output}"
+ },
+ "type": "TERMINATE",
+ "startDelay": 0,
+ "optional": false
+}
+```
+
+### Inputs
+
+**Parameters:**
+
+|name|type|description|notes|
+|---|---|---|---|
+|terminationStatus|String|can only accept "COMPLETED" or "FAILED"|task cannot be optional|
+|workflowOutput|Any|Expected workflow output||
+
+### Output
+
+**Outputs:**
+
+|name|type|description|
+|---|---|---|
+|output|Map|The content of `workflowOutput` from the inputParameters. An empty object if `workflowOutput` is not set.|
+
+## Examples
+
+Let's consider the same example we had in [Switch Task](/docs/reference-docs/switch-task).
+
+Suppose in a workflow, we have to take decision to ship the courier with the shipping
+service providers on the basis of input provided while running the workflow.
+If the input provided while running workflow does not match with the available
+shipping providers then the workflow will fail and return. If input provided
+matches then it goes ahead.
+
+We will create the Workflow with the following definition :
+
+```json
+{
+ "name": "Terminate_Task_Shipping_Info",
+ "description": "Terminate_Task_Shipping_Info",
+ "version": 1,
+ "ownerEmail":"abc@example.com",
+ "tasks": [
+ {
+ "name": "shipping_info",
+ "taskReferenceName": "shipping_info",
+ "inputParameters": {
+ },
+ "type": "SIMPLE"
+ },
+ {
+ "name": "switch_task",
+ "taskReferenceName": "switch_task",
+ "inputParameters": {
+ "case_value_param": "${workflow.input.service}"
+ },
+ "type": "SWITCH",
+ "ownerEmail":"abc@example.com",
+ "evaluatorType": "value-param",
+ "expression": "case_value_param",
+ "defaultCase": [
+ {
+ "name": "terminate",
+ "taskReferenceName": "terminate",
+ "inputParameters": {
+ "terminationStatus": "FAILED"
+ },
+ "type": "TERMINATE",
+ "startDelay": 0
+}
+ ],
+ "decisionCases": {
+ "fedex": [
+ {
+ "name": "ship_via_fedex",
+ "taskReferenceName": "ship_via_fedex",
+ "inputParameters": {
+ },
+ "type": "SIMPLE"
+ }
+ ],
+ "ups": [
+ {
+ "name": "ship_via_ups",
+ "taskReferenceName": "ship_via_ups",
+ "inputParameters": {
+ },
+ "type": "SIMPLE"
+ }
+ ]
+ }
+}
+],
+ "restartable": true,
+ "workflowStatusListenerEnabled": true,
+ "schemaVersion": 2
+}
+```
+
+Workflow gets created as shown in the diagram.
+
+
+
+Note : We have provided `"terminationStatus": "FAILED"` inside Terminate Task.
+Hence, it will return as `failed` if workflow goes in that direction.
+
+
+We can see in the below picture status as `FAILED` even though the all the task executed
+successfully. That happens because, we returned status as `FAILED` in terminate task.
+
+
+
+
+If we had provided `"terminationStatus": "COMPLETED"` inside Terminate Task. It would have
+returned as `completed`, as shown in the below picture.
+
+
+
+
+## FAQs
+
+TODO: Gotchas and other nuances
+
+1. Question 1
+ 1. Answer
+
+1. Question 2
+ 1. Answer
diff --git a/docs/reference-docs/wait-task.md b/docs/reference-docs/wait-task.md
new file mode 100644
index 00000000..ea1f6f1b
--- /dev/null
+++ b/docs/reference-docs/wait-task.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Wait Task
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/reference-docs/workflows.md b/docs/reference-docs/workflows.md
new file mode 100644
index 00000000..41c6bc05
--- /dev/null
+++ b/docs/reference-docs/workflows.md
@@ -0,0 +1,69 @@
+---
+sidebar_position: 1
+---
+
+# Workflows
+
+## What are Workflows?
+At a high level, a workflow is the Conductor primitive that encompasses the definition and flow of your business logic. It is through a workflow definition that you specify what are the Tasks that you want Conductor to execute, the ordering of execution flows across these Tasks and how results from different Tasks should be combined together to give you the final result.
+
+One key benefit of this approach is that you can build a complex application using simple and granular tasks that do not need to be aware of or keep track of the state of your application's execution flow. Conductor will keep track of that, calls tasks in the right order (sequentially or parallelly, as defined by you), retry calls if needed, handle failure scenarios gracefully and outputs the final result.
+
+Leveraging workflows in Conductor enables developers to truly focus on their core mission - building their application code. Conductor meanwhile does the heavy lifting associated with ensuring high reliability, transactional consistency and long durability of their workflows.
+
+## How does a Workflow look like?
+Lets start with a very basic workflow and understand what are the different aspects of it. In particular, we will talk about two stages of a workflow, *defining* a workflow and *executing* a workflow
+### *Simple Shipping Workflow*
+Assume your business logic is to simply to get some shipping information and then do the shipping. You start by logically partitioning them into two tasks
+* **shipping_info**
+* **shipping_task**
+
+The next step is to [create a workflow in Conductor using JSON](../running-workflows/create-workflow.md) and then [create the associated tasks in Conductor](../running-workflows/create-task.md) for the above identified ones.
+
+After that, you [add those tasks into the workflow](../running-workflows/adding-tasks.md) to have **shipping_info** called fist and then, if it is successful, call **shipping_task**. You now have a *definition* of the workflow in Conductor and Conductor will then generate an easy to understand visual representation of this workflow
+
+
+
+### *Multiple Vendor Shipping Workflow*
+
+Next lets see a more complex example where you want to support multiple shipping vendors (e.g. FedEx, DHL, UPS) and the code for each of them ive in separate services. This is a good design pattern to follow since you can now independtly change each of them without having to worry about breaking others. Usually this means you now have to take on the work of wiring up many different services into your primary execution path. But with Conductor, this just means adding a [switch operator](../system-tasks/switch-task.md) to decide which vendor to call depending on an incoming parameter, and then during execution time the right one will be called!
+
+
+
+Furthermore, with Conductor, in addition to the above design view of the workflow, you can also see the execution view of the workflow. In this particular example, the workflow picked UPS at runtime and as seen from the green color of the tasks in the execution path, this workflow completed successfully. If a particular task had failed, it would be show in red.
+
+
+
+
+> ### The Power of Seeing
+> These visual representations of workflows are key to how Conductor turbocharges the productivity of engineering teams.
+> * Workflows definitions serve as the enduring documentation for all the different applications a team owns and this benefit becomes even more powerful as the team scales in size and scope. Furthermore, it allows anyone new to the team to quickly get ramped up .
+> * The execution visualization allows you to quickly identify problem areas and provides you details on the error responses received, details on where the failing task was executing etc. This makes debugging much faster than digging across distributed logs and events amking Conductor's approach to workflows relevant not only during the creation time but also during live operations of the workflows in production
+
+## How do I use Workflows?
+
+### *Starting Workflows*
+Once a workflow is defined in Conductor, it is ready to be invoked. An invocation executes the workflow and passes in any arguments that were provided by the caller. There are three ways in which a workflow can be invoked.
+* [Calling the Conductor API via REST or gRPC](../running-workflows/execute-workflow.md#Start-a-workflow-by-calling-an-API). An example of how to do this is also in the [running workflows](../running-workflows/running-first-workflow.md#Running-our-First-Workflow) article
+* [Posting an event to a queue that Conductor is listening to for incoming workflow invocation requests](../running-workflows/execute-workflow.md#Start-a-workflow-by-posting-an-event)
+* [Scheduling a time at which Conductor should invoke the workflow](../running-workflows/execute-workflow.md#Schedule-a-workflow-for-later)
+
+### *View Workflows*
+Once a workflow is invoked, it starts running and you can [view details of its execution status](../how-tos/view-workflow-executions.md)
+
+### *Update Workflows*
+
+When your application's business logic evolves or you need to fix an error in your workflow definition, you can [udpate your workflows](../how-tos/updating-workflows.md) in Conductor with built-in support for versioning.
+
+> ### The Power of Versioning
+> Conductor's native support for versioning allows developers to rapidly iterate on new features even with multiple invocations of the same workflow are in-flight. Unlike other platforms where you either need to wait till those in-flight executions finsh or forcefully error them out, with Conductor you can have both versions in-flight at the same time. In addition to increase in developer agility, this also unlocks other benefits
+> * Experiment new features for a small subset of users
+> * Safely test changes in production while containing any issue's blast raidus to a known value
+
+## Further Reading
+* [Learn more about tasks and workers](../reference-docs/tasks-and-workers.md)
+* [Learn more about system tasks](../reference-docs/system-tasks.md)
+* [Learn more about operators](../reference-docs/operators.md)
+* [Run your first workflow](../running-workflows/running-first-workflow.md)
+
+
diff --git a/docs/running-workflows/adding-system-tasks.md b/docs/running-workflows/adding-system-tasks.md
new file mode 100644
index 00000000..58f70068
--- /dev/null
+++ b/docs/running-workflows/adding-system-tasks.md
@@ -0,0 +1,13 @@
+---
+sidebar_position: 1
+---
+
+# Adding System Tasks
+
+TODO
+
+Let's learn how to add and use system tasks to workflows
+
+## Summary
+
+TODO
diff --git a/docs/running-workflows/adding-tasks.md b/docs/running-workflows/adding-tasks.md
new file mode 100644
index 00000000..a0f961bc
--- /dev/null
+++ b/docs/running-workflows/adding-tasks.md
@@ -0,0 +1,13 @@
+---
+sidebar_position: 1
+---
+
+# Adding Tasks
+
+TODO
+
+Let's learn how to add tasks to workflows
+
+## Summary
+
+TODO
diff --git a/docs/running-workflows/create-task.md b/docs/running-workflows/create-task.md
new file mode 100644
index 00000000..de44be19
--- /dev/null
+++ b/docs/running-workflows/create-task.md
@@ -0,0 +1,7 @@
+# Create a Task
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/running-workflows/create-workflow.md b/docs/running-workflows/create-workflow.md
new file mode 100644
index 00000000..1b5368a5
--- /dev/null
+++ b/docs/running-workflows/create-workflow.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Creating Workflows
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/running-workflows/execute-workflow.md b/docs/running-workflows/execute-workflow.md
new file mode 100644
index 00000000..0bec3729
--- /dev/null
+++ b/docs/running-workflows/execute-workflow.md
@@ -0,0 +1,17 @@
+---
+sidebar_position: 1
+---
+
+# Executing Workflows
+
+A workflow can be exexcuted in three different ways as listed below. In all of these, once the invocation is made, Conductor will return a WorkflowID that you can use to [view the execution status of the invocation](docs/how-tos/view-workflow-executions.md)
+## Start a workflow by calling an API
+TODO
+## Start a workflow by posting an event
+TODO
+## Schedule a workflow for later
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/running-workflows/handling-errors.md b/docs/running-workflows/handling-errors.md
new file mode 100644
index 00000000..ebc9c1ad
--- /dev/null
+++ b/docs/running-workflows/handling-errors.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Handling Errors
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/running-workflows/pause-resume-workflows.md b/docs/running-workflows/pause-resume-workflows.md
new file mode 100644
index 00000000..dd0cc019
--- /dev/null
+++ b/docs/running-workflows/pause-resume-workflows.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Pause / Resume Workflows
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/running-workflows/restarting-workflows.md b/docs/running-workflows/restarting-workflows.md
new file mode 100644
index 00000000..a97fdbed
--- /dev/null
+++ b/docs/running-workflows/restarting-workflows.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Restarting Workflows
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/running-workflows/running-first-worker.md b/docs/running-workflows/running-first-worker.md
index 881043ee..8536dd7c 100644
--- a/docs/running-workflows/running-first-worker.md
+++ b/docs/running-workflows/running-first-worker.md
@@ -2,7 +2,7 @@
sidebar_position: 2
---
-# Running Hello World Worker
+# Running First Worker
In this article we will explore how you can get your first worker task running.
diff --git a/docs/running-workflows/running-first-workflow.md b/docs/running-workflows/running-first-workflow.md
index 4a5599ce..02f9e9f1 100644
--- a/docs/running-workflows/running-first-workflow.md
+++ b/docs/running-workflows/running-first-workflow.md
@@ -2,7 +2,7 @@
sidebar_position: 1
---
-# Running Hello World Workflow
+# Running First Workflow
In this article we will explore how we can run a really simple workflow that runs without any microservice. Yes!
Conductor has in-built tasks that we can use to run quite a bit of things. We will use one of these in-built tasks to
@@ -19,9 +19,9 @@ This post is specifically for running a sample workflow in our environment to en
expected. We can refer to one of the following posts to set up our environments before continuing with the post if we
don’t already have an environment up and running.
-1. [Running Locally - From Code](../getting-started-local/running-locally.md)
-2. [Running Locally - Docker Compose](../getting-started-local/running-locally-docker.md)
-3. [Running Locally - Kubernetes](../getting-started-local/running-locally-minikube.md)
+1. [Running Locally - From Code](../installing-conductor/running-locally.md)
+2. [Running Locally - Docker Compose](../installing-conductor/running-locally-docker.md)
+3. [Running Locally - Kubernetes](../installing-conductor/running-locally-minikube.md)
---
diff --git a/docs/running-workflows/running-task-workers.md b/docs/running-workflows/running-task-workers.md
new file mode 100644
index 00000000..6c7224e5
--- /dev/null
+++ b/docs/running-workflows/running-task-workers.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Running Task Workers
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/running-workflows/tasks-across-microservices.md b/docs/running-workflows/tasks-across-microservices.md
new file mode 100644
index 00000000..d8f0eb1c
--- /dev/null
+++ b/docs/running-workflows/tasks-across-microservices.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Tasks Across Microservices
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/running-workflows/using-java-client-sdk.md b/docs/running-workflows/using-java-client-sdk.md
new file mode 100644
index 00000000..73212805
--- /dev/null
+++ b/docs/running-workflows/using-java-client-sdk.md
@@ -0,0 +1,13 @@
+---
+sidebar_position: 1
+---
+
+# Using Client SDKs
+
+TODO
+
+Let's learn how to add and use system tasks to workflows
+
+## Summary
+
+TODO
diff --git a/docs/running-workflows/viewing-definitions.md b/docs/running-workflows/viewing-definitions.md
new file mode 100644
index 00000000..b4fbe118
--- /dev/null
+++ b/docs/running-workflows/viewing-definitions.md
@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Viewing Definitions
+
+TODO
+
+## Summary
+
+TODO
diff --git a/docs/showcase.md b/docs/showcase.md
new file mode 100644
index 00000000..a9a41a2c
--- /dev/null
+++ b/docs/showcase.md
@@ -0,0 +1,7 @@
+---
+sidebar_position: 1
+---
+
+# Conductor Showcase
+
+
diff --git a/docs/system-tasks/dynamic-task.md b/docs/system-tasks/dynamic-task.md
index 2591cd5d..59ea83d5 100644
--- a/docs/system-tasks/dynamic-task.md
+++ b/docs/system-tasks/dynamic-task.md
@@ -45,6 +45,140 @@ Following are the parameters -
If the workflow is started with input parameter `dynamicTaskToExecute` value as `fedex_shipping_task`, Conductor will
schedule `fedex_shipping_task` when scheduling this dynamic task.
+### Sample Use Case :
+
+Suppose in a workflow, we have to take decision to ship the courier with the shipping
+service providers on the basis of Post Code.
+
+Following task `shipping_info` generates an output on the basis of which decision would be
+taken to run the next task.
+
+```json
+{
+ "name": "shipping_info",
+ "retryCount": 3,
+ "timeoutSeconds": 600,
+ "pollTimeoutSeconds": 1200,
+ "timeoutPolicy": "TIME_OUT_WF",
+ "retryLogic": "FIXED",
+ "retryDelaySeconds": 300,
+ "responseTimeoutSeconds": 300,
+ "concurrentExecLimit": 100,
+ "rateLimitFrequencyInSeconds": 60,
+ "ownerEmail":"abc@example.com",
+ "rateLimitPerFrequency": 1
+}
+```
+
+Following are the two worker tasks, one among them would execute on the basis of output generated
+by the `shipping_info` task :
+
+```json
+{
+ "name": "ship_via_fedex",
+ "retryCount": 3,
+ "timeoutSeconds": 600,
+ "pollTimeoutSeconds": 1200,
+ "timeoutPolicy": "TIME_OUT_WF",
+ "retryLogic": "FIXED",
+ "retryDelaySeconds": 300,
+ "responseTimeoutSeconds": 300,
+ "concurrentExecLimit": 100,
+ "rateLimitFrequencyInSeconds": 60,
+ "ownerEmail":"abc@example.com",
+ "rateLimitPerFrequency": 2
+},
+{
+ "name": "ship_via_ups",
+ "retryCount": 3,
+ "timeoutSeconds": 600,
+ "pollTimeoutSeconds": 1200,
+ "timeoutPolicy": "TIME_OUT_WF",
+ "retryLogic": "FIXED",
+ "retryDelaySeconds": 300,
+ "responseTimeoutSeconds": 300,
+ "concurrentExecLimit": 100,
+ "rateLimitFrequencyInSeconds": 60,
+ "ownerEmail":"abc@example.com",
+ "rateLimitPerFrequency": 2
+}
+```
+
+
+We will create the Workflow with the following definition :
+
+```json
+{
+ "name": "Shipping_Flow",
+ "description": "Ships smartly on the basis of Shipping info",
+ "version": 1,
+ "tasks": [
+ {
+ "name": "shipping_info",
+ "taskReferenceName": "shipping_info",
+ "inputParameters": {
+ },
+ "type": "SIMPLE"
+ },
+ {
+ "name": "shipping_task",
+ "taskReferenceName": "shipping_task",
+ "inputParameters": {
+ "taskToExecute": "${shipping_info.output.shipping_service}"
+ },
+ "type": "DYNAMIC",
+ "dynamicTaskNameParam": "taskToExecute"
+ }
+
+ ],
+ "restartable": true,
+ "ownerEmail":"abc@example.com",
+ "workflowStatusListenerEnabled": true,
+ "schemaVersion": 2
+}
+```
+
+Workflow is the created as shown in the below diagram.
+
+
+
+
+
+Note : `shipping_task` is a `DYNAMIC` task and the `taskToExecute` parameter can be set
+with input value provided while running the workflow or with the output of previous tasks.
+Here, it is set to the output provided by the previous task i.e.
+`${shipping_info.output.shipping_service}`.
+
+If the input value is provided while running the workflow it can be accessed by
+`${workflow.input.shipping_service}`.
+
+```json
+{
+ "shipping_service": "ship_via_fedex"
+}
+```
+
+We can see in the below example that on the basis of Post Code the shipping service is being
+decided.
+
+```js reference
+https://github.com/orkes-io/orkesworkers/blob/main/src/main/java/io/orkes/samples/workers/ShippingInfoWorker.java#L10-L29
+```
+
+Based on given set of inputs i.e. Post Code starts with '9' hence, `ship_via_fedex` is executed -
+
+
+
+If the Post Code started with anything other than 9 `ship_via_ups` is executed -
+
+
+
+If the incorrect task name or the task that doesn't exist is provided then the workflow fails and
+we get the error " Invalid task specified. Cannot find task by name in the task definitions ".
+
+If the null reference is provided in the task name then also the workflow fails and we get the
+error " Cannot map a dynamic task based on the parameter and input. Parameter= taskToExecute, input= {taskToExecute=null} "
+
### FAQs
Example use case:
@@ -53,7 +187,7 @@ Example use case:
2. When the workflow starts, based on the input parameter, we can decide which worker to run
3. Show example of both workers running
4. Show example of what happens when you try to run a task that doesn't exist
- 1. Show what happens if we give a null reference
+ 1. Show what happens if we give a null reference
Sample Use Case
@@ -63,4 +197,3 @@ Sample Use Case
4. Start -> Read Shipping Info -> Run Dynamic Shipping Task -> End
Add code, refer to the
-
diff --git a/docs/tutorial-basics/_category_.json b/docs/tutorial-basics/_category_.json
deleted file mode 100644
index 765e6b0d..00000000
--- a/docs/tutorial-basics/_category_.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
- "label": "Tutorial - Basics",
- "position": 5
-}
diff --git a/docs/tutorial-basics/congratulations.md b/docs/tutorial-basics/congratulations.md
deleted file mode 100644
index 9ef99bba..00000000
--- a/docs/tutorial-basics/congratulations.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-sidebar_position: 6
----
-
-# Congratulations!
-
-You have just learned the **basics of Docusaurus** and made some changes to the **initial template**.
-
-Docusaurus has **much more to offer**!
-
-Have **5 more minutes**? Take a look at **[versioning](../tutorial-extras/manage-docs-versions.md)** and **[i18n](../tutorial-extras/translate-your-site.md)**.
-
-Anything **unclear** or **buggy** in this tutorial? [Please report it!](https://github.com/facebook/docusaurus/discussions/4610)
-
-## What's next?
-
-- Read the [official documentation](https://docusaurus.io/).
-- Add a custom [Design and Layout](https://docusaurus.io/docs/styling-layout)
-- Add a [search bar](https://docusaurus.io/docs/search)
-- Find inspirations in the [Docusaurus showcase](https://docusaurus.io/showcase)
-- Get involved in the [Docusaurus Community](https://docusaurus.io/community/support)
diff --git a/docs/tutorial-basics/create-a-blog-post.md b/docs/tutorial-basics/create-a-blog-post.md
deleted file mode 100644
index 0d50aaf3..00000000
--- a/docs/tutorial-basics/create-a-blog-post.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-sidebar_position: 3
----
-
-# Create a Blog Post
-
-Docusaurus creates a **page for each blog post**, but also a **blog index page**, a **tag system**, an **RSS** feed...
-
-## Create your first Post
-
-Create a file at `blog/2021-02-28-greetings.md`:
-
-```md title="blog/2021-02-28-greetings.md"
----
-slug: greetings
-title: Greetings!
-authors:
- - name: Joel Marcey
- title: Co-creator of Docusaurus 1
- url: https://github.com/JoelMarcey
- image_url: https://github.com/JoelMarcey.png
- - name: Sébastien Lorber
- title: Docusaurus maintainer
- url: https://sebastienlorber.com
- image_url: https://github.com/slorber.png
-tags: [greetings]
----
-
-Congratulations, you have made your first post!
-
-Feel free to play around and edit this post as much you like.
-```
-
-A new blog post is now available at `http://localhost:3000/blog/greetings`.
diff --git a/docs/tutorial-basics/create-a-document.md b/docs/tutorial-basics/create-a-document.md
deleted file mode 100644
index b4a072ec..00000000
--- a/docs/tutorial-basics/create-a-document.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-sidebar_position: 2
----
-
-# Create a Document
-
-Documents are **groups of pages** connected through:
-
-- a **sidebar**
-- **previous/next navigation**
-- **versioning**
-
-## Create your first Doc
-
-Create a markdown file at `docs/hello.md`:
-
-```md title="docs/hello.md"
-# Hello
-
-This is my **first Docusaurus document**!
-```
-
-A new document is now available at `http://localhost:3000/docs/hello`.
-
-## Configure the Sidebar
-
-Docusaurus automatically **creates a sidebar** from the `docs` folder.
-
-Add metadatas to customize the sidebar label and position:
-
-```md title="docs/hello.md" {1-4}
----
-sidebar_label: 'Hi!'
-sidebar_position: 3
----
-
-# Hello
-
-This is my **first Docusaurus document**!
-```
-
-It is also possible to create your sidebar explicitly in `sidebars.js`:
-
-```diff title="sidebars.js"
-module.exports = {
- tutorialSidebar: [
- {
- type: 'category',
- label: 'Tutorial',
-- items: [...],
-+ items: ['hello'],
- },
- ],
-};
-```
diff --git a/docs/tutorial-basics/create-a-page.md b/docs/tutorial-basics/create-a-page.md
deleted file mode 100644
index e112b005..00000000
--- a/docs/tutorial-basics/create-a-page.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-sidebar_position: 1
----
-
-# Create a Page
-
-Add **Markdown or React** files to `src/pages` to create a **standalone page**:
-
-- `src/pages/index.js` -> `localhost:3000/`
-- `src/pages/foo.md` -> `localhost:3000/foo`
-- `src/pages/foo/bar.js` -> `localhost:3000/foo/bar`
-
-## Create your first React Page
-
-Create a file at `src/pages/my-react-page.js`:
-
-```jsx title="src/pages/my-react-page.js"
-import React from 'react';
-import Layout from '@theme/Layout';
-
-export default function MyReactPage() {
- return (
- This is a React page
-