diff --git a/docs/codelab/orderfulfillment4.md b/docs/codelab/orderfulfillment4.md index ee84ccfc..d0af7f99 100644 --- a/docs/codelab/orderfulfillment4.md +++ b/docs/codelab/orderfulfillment4.md @@ -33,7 +33,7 @@ So, our new plan is to update the order every time widgets are shipped one for o You ask for the details of the API, and it turns out it is really simple: -You send a post message to the endpont ```appendorder``` with the items and quantity: +You send a post message to the endpoint ```appendorder``` with the items and quantity: ```json {"item": "widget", "count": "2"}' diff --git a/docs/codelab/orderfulfillment5.md b/docs/codelab/orderfulfillment5.md index 994841ac..9d239249 100644 --- a/docs/codelab/orderfulfillment5.md +++ b/docs/codelab/orderfulfillment5.md @@ -65,7 +65,7 @@ We know that a 'good' response from the API reads: ```Success![number] widgets o A [Switch task](https://orkes.io/content/docs/reference-docs/switch-task) takes in a value, and can choose which case the workflow should follow. There is a default case (in this workflow, we'll assume that a order will be placed), and then the alternative case is when the output reads "Order Failed". -The switch case can evaulate the input in several ways (including running JavaScript), but in this case, we can use the ``` "evaluatorType": "value-param"``` meaning the decision will be bsaed completely on the data that comes in the ```switchCaseValue``` parameter. The ```switchCaseValue``` reads the output body from the API, and if it says "Order failed." we'll run a different pathway for the workflow. +The switch case can evaluate the input in several ways (including running JavaScript), but in this case, we can use the ``` "evaluatorType": "value-param"``` meaning the decision will be based completely on the data that comes in the ```switchCaseValue``` parameter. The ```switchCaseValue``` reads the output body from the API, and if it says "Order failed." we'll run a different pathway for the workflow. ```json @@ -247,7 +247,7 @@ In the definition below, we've hidden the bot token in the url. The message sent } ``` -Now, we have instrumented our Workflow to tell us when there is a failure- in rder to reduce the number of surprises: +Now, we have instrumented our Workflow to tell us when there is a failure- inorder to reduce the number of surprises:

slack message indicating workflow failure

diff --git a/docs/example_usecases.md b/docs/example_usecases.md index b90bae3c..53d50b12 100644 --- a/docs/example_usecases.md +++ b/docs/example_usecases.md @@ -17,7 +17,7 @@ Conductor is a general-purpose orchestration engine that is language agnostic an 7. Orchestrating Microservices ([HTTP](/content/docs/codelab/sequentialHTTPtasks), background services, etc.) 8. Orchestrating business logic across various cloud functions (AWS Lambda, GCP functions, etc.) 9. Infrastructure Provisioning -10. CICD Pipelines +10. CI/CD Pipelines 11. Long running processes and workflows 12. Monitoring 13. Distributed Transactions diff --git a/docs/how-tos/Events/sqs_events.md b/docs/how-tos/Events/sqs_events.md index 1f8eb016..1ff767e6 100644 --- a/docs/how-tos/Events/sqs_events.md +++ b/docs/how-tos/Events/sqs_events.md @@ -67,7 +67,7 @@ This Event does exactly what the name says, it will start a workflow run. In the ### Complete Task -Imagine you have a workflow that requires a person to sign a document at Docusign. There would be a WAIT task in the IN_PROGRESS state, waiting for an EVENT so that the workflow can move forward. The message is sent to the `conductor_docusign_completed` SQS queue at AWS, which will fire this event: +Imagine you have a workflow that requires a person to sign a document at DocuSign. There would be a WAIT task in the IN_PROGRESS state, waiting for an EVENT so that the workflow can move forward. The message is sent to the `conductor_docusign_completed` SQS queue at AWS, which will fire this event: ```json { @@ -90,7 +90,7 @@ Imagine you have a workflow that requires a person to sign a document at Docusig ### Fail Task -Imagine you have a workflow that requires a person to sign a document at Docusign. There would be a WAIT task in the IN_PROGRESS state, waiting for an EVENT so that the workflow can move forward. In this case, the human refused to sign the document, and the message is sent to the `conductor_docusign_failed` SQS queue at AWS, which will fire this event: +Imagine you have a workflow that requires a person to sign a document at DocuSign. There would be a WAIT task in the IN_PROGRESS state, waiting for an EVENT so that the workflow can move forward. In this case, the human refused to sign the document, and the message is sent to the `conductor_docusign_failed` SQS queue at AWS, which will fire this event: ```json { diff --git a/docs/how-tos/Tasks/SQS-event-task.md b/docs/how-tos/Tasks/SQS-event-task.md index bab1215e..42c156a9 100644 --- a/docs/how-tos/Tasks/SQS-event-task.md +++ b/docs/how-tos/Tasks/SQS-event-task.md @@ -5,7 +5,7 @@ Amazon's Simple Queueing Service (SQS) is a handy way to send messages across sy In this example, we will: * Configure Conductor for SQS messaging -* Set up an SQS mewssage queue at AWS +* Set up an SQS message queue at AWS * Build a workflow with an EVENT task that sends messages to our SQS queue. * Add an EVENT to Conductor that will complete a WAIT event in the same workflow. @@ -54,7 +54,7 @@ export AWS_REGION = "{the region you are setting up the queue in}" ## Creating an SQS Queue -In your AWS account, open Amazon SQS (search for it in the search bar), and choose `Create queue`. Create a queue by entering a name, and scrolling to the botttom to `create queue`. In a minute or so, your new queue will appear in the queue list. +In your AWS account, open Amazon SQS (search for it in the search bar), and choose `Create queue`. Create a queue by entering a name, and scrolling to the bottom to `create queue`. In a minute or so, your new queue will appear in the queue list.

filtered SQS queue list

@@ -68,7 +68,7 @@ This workflow has two forks: * On the left fork there is just one task `task_1`. It is a WAIT task, and it is waiting for a message from the SQS server. > Note: for the SQS message to COMPLETE the task, we'll need to create a Conductor EVENT. -* The right fork has two tasks. `task_2` is also a WAIT task, but it just waits for 10s before completing and moving the workflow ahead. On the completetion of `task_2`, the EVENT task `send_sqs_messsage` fires. +* The right fork has two tasks. `task_2` is also a WAIT task, but it just waits for 10s before completing and moving the workflow ahead. On the completion of `task_2`, the EVENT task `send_sqs_messsage` fires. The reason for the delay in `task_2` to is to ensure that `task_1` is initialized and waiting for the event to come in before the SQS message is sent out. diff --git a/docs/how-tos/Tasks/reusing-tasks.md b/docs/how-tos/Tasks/reusing-tasks.md index be4860c8..8e4d42bc 100644 --- a/docs/how-tos/Tasks/reusing-tasks.md +++ b/docs/how-tos/Tasks/reusing-tasks.md @@ -10,7 +10,7 @@ workflows. Once a task is defined, you can re use multiple times in the same wor When re-using tasks, it's important to think of situations that a multi-tenant system faces. All the work assigned to this worker by default goes to the same task scheduling queue. This could result in your worker not being polled quickly -if there is a noisy neighbour in the ecosystem. One way you can tackle this situation is by re-using the worker code, +if there is a noisy neighbor in the ecosystem. One way you can tackle this situation is by re-using the worker code, but having different task names registered for different use cases. And for each task name, you can run an appropriate number of workers based on expected load. diff --git a/docs/running-workflows/execute-workflow.md b/docs/running-workflows/execute-workflow.md index af534f19..bf3149fd 100644 --- a/docs/running-workflows/execute-workflow.md +++ b/docs/running-workflows/execute-workflow.md @@ -4,7 +4,7 @@ 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](../how-tos/Workflows/view-workflow-executions.md) +A workflow can be executed 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](../how-tos/Workflows/view-workflow-executions.md) ## Start a workflow by calling an API TODO ## Start a workflow by posting an event diff --git a/docs/what-use-cases-can-conductor-solve.md b/docs/what-use-cases-can-conductor-solve.md index 7b7ce693..e283d8ff 100644 --- a/docs/what-use-cases-can-conductor-solve.md +++ b/docs/what-use-cases-can-conductor-solve.md @@ -19,7 +19,7 @@ Some common use cases that has been solved by Conductor are: 8. Orchestrating Microservices (HTTP, background services, etc.) 9. Orchestrating Business Logic across various cloud functions (AWS Lambda, GCP functions, etc.) 10. Infrastructure Provisioning -11. CI CD Pipelines +11. CI/CD Pipelines 12. Long-running Processes and Workflows 13. Monitoring 14. Distributed Transactions