Merge pull request #264 from RizaFarheen/main

Update terminate-workflow.md

docs/reference-docs/do-while-task.md

@@ -7,19 +7,19 @@ sidebar_position: 1
 "type" : "DO_WHILE"
 ```
 ## Introduction
-Sequentially execute a list of task as long as a condition is true. 
+Sequentially execute a list of tasks as long as a condition is true. 
 The list of tasks is executed first, before the condition is checked (even for the first iteration).
 
 When scheduled, each task of this loop will see its `taskReferenceName` concatenated with __i, with i being the iteration number, starting at 1. Warning: taskReferenceName containing arithmetic operators must not be used.
 
-Each task output is stored as part of the DO_WHILE task, indexed by the iteration value (see example below), allowing the condition to reference the output of a task for a specific iteration (eg. $.LoopTask['iteration]['first_task'])
+Each task output is stored as part of the DO_WHILE task, indexed by the iteration value (see example below), allowing the condition to reference the output of a task for a specific iteration (e.g., $.LoopTask['iteration]['first_task'])
 
-The DO_WHILE task is set to `FAILED` as soon as one of the loopTask fails. In such case retry, iteration starts from 1.
+The DO_WHILE task is set to `FAILED` as soon as one of the loopTask fails. In such cases, retry; iteration starts from 1.
 
 ## Limitations 
 - Domain or isolation group execution is unsupported.
-- Nested DO_WHILE is unsupported. However, DO_WHILE task supports SUB_WORKFLOW as loopOver task, so we can achieve similar functionality.
-- Since loopOver tasks will be executed in loop inside scope of parent do while task, crossing branching outside of DO_WHILE task is not respected. 
+- Nested DO_WHILE is unsupported. However, DO_WHILE task supports SUB_WORKFLOW as a loopOver task, so we can achieve similar functionality.
+- Since loopOver tasks will be executed in a loop inside the scope of a parent, do while task, crossing branching outside of DO_WHILE task is not respected. 
 
 Branching inside loopOver task is supported.
 
@@ -31,16 +31,16 @@ Branching inside loopOver task is supported.
 
 |name|type|description|
 |---|---|---|
-|loopCondition|String|Condition to be evaluated after every iteration. This is a Javascript expression, evaluated using the Nashorn engine. If an exception occurs during evaluation, the DO_WHILE task is set to FAILED_WITH_TERMINAL_ERROR.|
+|loopCondition|String|Condition to be evaluated after every iteration. This is a Javascript expression evaluated using the Nashorn engine. If an exception occurs during evaluation, the DO_WHILE task is set to FAILED_WITH_TERMINAL_ERROR.|
 |loopOver|List[Task]|List of tasks that needs to be executed as long as the condition is true.|
 
 ### Output Parameters
 
 |name|type|description|
 |---|---|---|
 |iteration|Integer|Iteration number: the current one while executing; the final one once the loop is finished|
-|`i`|Map[String, Any]|Iteration number as a string, mapped to the task references names and their output.|
-|*|Any|Any state can be stored here if the `loopCondition` does so. For example `storage` will exist if `loopCondition` is `if ($.LoopTask['iteration'] <= 10) {$.LoopTask.storage = 3; true } else {false}`|
+|`i`|Map[String, Any]|Iteration number as a string mapped to the task references names and their output.|
+|*|Any|Any state can be stored here if the `loopCondition` does so. For example, `storage` will exist if `loopCondition` is `if ($.LoopTask['iteration'] <= 10) {$.LoopTask.storage = 3; true } else {false}`|
 
 ## Examples
 
@@ -142,7 +142,7 @@ Sometimes, you may want to use the iteration value/counter in the tasks used in
 
 The Loop ```taskReferenceName``` is "get_all_stars_loop_ref".
 
-In the ```loopCondition``` the term ```$.get_all_stars_loop_ref['iteration']``` is used.
+In the ```loopCondition```, the term ```$.get_all_stars_loop_ref['iteration']``` is used.
 
 In tasks embedded in the loop, ```${get_all_stars_loop_ref.output.iteration}``` is used.  In this case, it is used to define which page of results the API should return.
 
@@ -199,6 +199,6 @@ In tasks embedded in the loop, ```${get_all_stars_loop_ref.output.iteration}```
 
 * [Order Fulfillment](/content/docs/codelab/orderfulfillment5_5#dowhile-loop):  Loops through each address to create a shipping label.
 
-* [Document Approvals](/content/docs/usecases/document_approvals): Should an approval be rejected, the Do/WHile loops back to the beginning for edits to the doc.
+* [Document Approvals](/content/docs/usecases/document_approvals): Should approval be rejected, the Do/WHile loops back to the beginning for edits to the doc.
 
 * [Extract, Transform, Load](/content/docs/usecases/Simple_ETL): GitHub extraction is 100 entries per call, so loop for the number of extractions required to get the data.  The Orbit API allows for one activity upload per API call, so the Do/while loop iterates through every upload.

docs/reference-docs/dynamic-fork-task.md

@@ -10,15 +10,15 @@ import TabItem from '@theme/TabItem';
 ```
 
 :::note Important Note
-This is the legacy method of using a dynamic fork join which requires a preparation task for the inputs. There is a new updated version of this that can operate of an array [Dynamic Fork Join using Arrays](./dynamic-fork-from-array-task) 
+This is the legacy method of using a dynamic fork join which requires a preparation task for the inputs. There is a new updated version of this that can operate on an array [Dynamic Fork Join using Arrays](./dynamic-fork-from-array-task) 
 :::
 
 ## Introduction
 
-When the number of forks must be determined at run-time, the FORK_JOIN_DYNAMIC task is needed.  (In a regular fork operation -the [FORK_JOIN](/content/docs/reference-docs/fork-task) task- the number of forks are defined during workflow creation.)
+When the number of forks must be determined at run-time, the FORK_JOIN_DYNAMIC task is needed.  (In a regular fork operation -the [FORK_JOIN](/content/docs/reference-docs/fork-task) task- the number of forks is defined during workflow creation.)
 
 :::info Note: 
-A `FORK_JOIN_DYNAMIC` can ony have ONE task per fork.  If there is a need for multiple tasks per fork, a SUBWORKFLOW can be utilized.
+A `FORK_JOIN_DYNAMIC` can only have one task per fork.  If there is a need for multiple tasks per fork, a sub-workflow can be utilized.
 :::
 
 <p align="center"><iframe width="560" height="315" src="https://www.youtube.com/embed/2VE2ys_85FM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></p>
@@ -89,7 +89,7 @@ Let's assume the workflow input appears as follows:
 }
 ```
 
-Note that the input has two outputFormats (png and Jpg) and two sizes (300x300 and 200x200). With 2 file formats and 2 sizes in the input, we'll be creating 4 images total.  We'll create a task & worker that will take the input data, and convert it into the JSON arrays that the `FORK_JOIN_DYNAMIC` requires. First, let's define what the inputs must look like:
+Note that the input has two outputFormats (png and Jpg) and two sizes (300x300 and 200x200). With two file formats and two sizes in the input, we'll be creating four images in total. We'll create a task & worker that will take the input data, and convert it into the JSON arrays that the `FORK_JOIN_DYNAMIC` requires. First, let's define what the inputs must look like:
 
 ### ```dynamicForkTasksParam``` 
 
@@ -299,7 +299,7 @@ Note: For `FORK_JOIN_DYNAMIC`, all tasks must complete before the `JOIN` will co
 
 ## Additional Examples
 
-* [Order Fulfillment Codelab](/content/docs/codelab/orderfulfillment8): In this Example, several JQ Transform System tasks are used to create the JSON inputs required for the Dynamic task to run. The outputs from the JQ transforms are used to create the `dynamicTasks` and the `dynamicTaskInputs`:
+* [Order Fulfillment Codelab](/content/docs/codelab/orderfulfillment8): In this example, several JQ Transform System tasks are used to create the JSON inputs required for the Dynamic task to run. The outputs from the JQ transforms are used to create the `dynamicTasks` and the `dynamicTaskInputs`:
 
 ```json
   "inputParameters": {

docs/reference-docs/fork-task.md

@@ -9,8 +9,8 @@ sidebar_position: 1
 
 ## Introduction
 
-A Fork operation lets you run a specified list of other tasks or sub workflows in parallel. A fork task is
-followed by a join operation that waits on the forked tasks or sub workflows to finish. The `JOIN`
+A Fork operation lets you run a specified list of other tasks or sub-workflows in parallel. A fork task is
+followed by a join operation that waits on the forked tasks or sub-workflows to finish. The `JOIN`
 task also collects outputs from each of the forked tasks or sub workflows.
 
 <p style={{textAlign: "center"}}>
@@ -22,14 +22,14 @@ style={{paddingBottom: 30, paddingTop: 30}} />
 
 ## Use Cases
 
-`FORK_JOIN` tasks are typically used when a list of tasks can be run in parallel. E.g In a notification workflow, there
-could be multiple ways of sending notifications, i,e e-mail, SMS, HTTP etc.. These notifications are not dependent on
+`FORK_JOIN` tasks are typically used when a list of tasks can be run in parallel. E.g., In a notification workflow, there
+could be multiple ways of sending notifications, i.e., e-mail, SMS, HTTP etc. These notifications are not dependent on
 each other, and so they can be run in parallel. In such cases, you can create 3 sub-lists of forked tasks for each of
 these operations.
 
 ## Configuration
 
-A `FORK_JOIN` task, has a `forkTasks` attribute that expects an array. Each array, is a sub-list of tasks. Each of these
+A `FORK_JOIN` task has a `forkTasks` attribute that expects an array. Each array is a sub-list of tasks. Each of these
 sub-lists and then invoked in parallel. The tasks defined within each sublist can be sequential or any other way as
 desired.
 
@@ -119,13 +119,13 @@ references that were being `joinOn`. The corresponding values are the outputs of
 | taskReferenceName   | Task Reference Name. A unique reference to this task. There can be multiple references of a task within the same workflow definition        |
 | type   | Task Type. In this case, `FORK_JOIN`        |
 | inputParameters   | The input parameters that will be supplied to this task    |
-| forkTasks   | A list of a list of tasks. Each of the outer list will be invoked in parallel. The inner list can be a graph of other tasks and sub-workflows   |
+| forkTasks   | A list of tasks. Each of the outer lists will be invoked in parallel. The inner list can be a graph of other tasks and sub-workflows   |
 
 ### Output Configuration
 
 This is the output configuration of the `JOIN` task that is used in conjunction with the `FORK_JOIN` task. The output of
 the
-`JOIN` task is a map, where the keys are the names of the task reference names where were being `joinOn` and the keys
+`JOIN` task is a map, where the keys are the names of the task reference names that were being `joinOn` and the keys
 are the corresponding outputs of those tasks.
 
 | Attribute      | Description |
@@ -138,7 +138,7 @@ are the corresponding outputs of those tasks.
 
 ## Example
 
-Imagine a workflow that sends 3 notifications: email, SMS and HTTP. Since none of these steps are dependant on the others, they can be run in parallel with a fork.
+Imagine a workflow that sends 3 notifications: email, SMS and HTTP. Since none of these steps are dependent on the others, they can be run in parallel with a fork.
 
 The diagram will appear as:
 

docs/reference-docs/switch-task.md

@@ -9,13 +9,13 @@ sidebar_position: 1
 ```
 ## Introduction
 
-A switch task is similar to `case...switch` statement in a programming language. The `switch` expression, is
+A switch task is similar to `case...switch` statement in a programming language. The `switch` expression is
 a configuration on the `SWITCH` task type. Currently, two evaluators are supported:
 
 |name|description|
 |---|---|
 | value-param | Use a parameter directly as the value |
-| javascript | Evaluate Javascript expressions and compute value |
+| javascript | Evaluate Javascript expressions and compute the value |
 
 <p align="center"><iframe width="560" height="315" src="https://www.youtube.com/embed/EpzdGDMSYYA" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></p>
 
@@ -31,17 +31,17 @@ Following are the task configuration parameters :
 |name|type|description|
 |---|---|---|
 |evaluatorType|String|Type of the evaluator used. Supported types: `value-param`, `javascript`, `graaljs`.|
-|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)|
+|expression|String|The expression that depends on the evaluator type. For the `value-param` evaluator, the expression is the input parameter; for the `javascript` evaluator, it is the javascript expression.|
+|decisionCases|Map[String, List[task]]|Map where the key is possible values that can result from the `expression` being evaluated by `evaluatorType` with the value being the list of tasks to be executed.|
+|defaultCase|List[task]|List of tasks to be executed when no matching value is 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.|
+|evaluationResult|List[String]|A List of strings representing the list of cases that matched.|
 
 
 ## Examples
@@ -81,14 +81,14 @@ Let's create a Workflow with the following switch task definition that uses `val
 }
 ```
 
-In the definition above the value of the parameter `switch_case_value`
+In the definition above, the value of the parameter `switch_case_value`
 is used to determine the switch-case. The evaluator type is `value-param` and the expression is a direct reference to
-the name of an input parameter. If the value of `switch_case_value` is `fedex` then the decision case `ship_via_fedex`is
+the name of an input parameter. If the value of `switch_case_value` is `fedex`, then the decision case `ship_via_fedex` is
 executed as shown below.
 
 ![Conductor UI - Workflow Run](/img/tutorial/Switch_Fedex.png)
 
-In a similar way - if the input was `ups`, then `ship_via_ups` will be executed. If none of the cases match then the
+Similarly, if the input was `ups`, then `ship_via_ups` will be executed. If none of the cases match, then the
 default option is executed.
 
 Here is an example using the `javascript` evaluator type:
@@ -125,5 +125,5 @@ Here is an example using the `javascript` evaluator type:
 
 ### Codelab examples
 * [Hello World codelab](/content/docs/codelab/helloworld5) using JavaScript Evaluation
-* [Post office Workflows](/content/docs/usecases/US_post_office) Switch handles success and failure mechanisms via `value-param`.
+* [Post office Workflows](/content/docs/usecases/US_post_office) - Switch handles success and failure mechanisms via `value-param`.
 * [Document Approval](/content/docs/usecases/document_approvals)

docs/reference-docs/system-tasks/terminate-workflow.md

@@ -21,10 +21,10 @@ Consider a use case where you want to terminate a long-running workflow (or a se
 | Attribute         | Description                                                                                                                                                                 |
 |-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | workflowId        | Either a workflow ID or a list of workflow IDs.                                                                                                                             |
-| terminationReason | Optional text used to update reason for termination of the workflows being terminated.                                                                                      |
+| terminationReason | Optional text used to update the reason for the workflows being terminated. |
 
 #### Output Configuration
-Task output will contain field "terminatedWorkflows" which is a set of workflow IDs corresponding to the workflows that were terminated.
+Task output will contain the field "terminatedWorkflows", which is a set of workflow IDs corresponding to the workflows that were terminated.
 
 ## Example