diff --git a/workflow/spec/examples.md b/workflow/spec/examples.md index f9796ff..dd1acaf 100644 --- a/workflow/spec/examples.md +++ b/workflow/spec/examples.md @@ -426,7 +426,7 @@ The ForEach state will execute a single defined operation state for each math ex state contains an action which calls a serverless function which actually solves the expression and returns its result. -Results of all mathe expressions are accumulated into the data output of the ForEach state which become the final +Results of all math expressions are accumulated into the data output of the ForEach state which become the final result of the workflow execution. #### Workflow Definition @@ -1508,9 +1508,10 @@ states: ### Monitor Patient Vital Signs Example #### Description + In this example a hospital patient is monitored by a Vial Sign Monitoring system. This device can produce three different Cloud Events, namely "High Body Temperature", "High Blood Pressure", and "High Respiration Rate". -Our workflow which needs to take propert actions depending on the event the Vital Sign Monitor produces needs to start +Our workflow which needs to take proper actions depending on the event the Vital Sign Monitor produces needs to start if any of these events occur. For each of these events a new instance of the workflow is started. Since the hospital may include many patients that are being monitored it is assumed that all events include a patientId context attribute in the event diff --git a/workflow/spec/extending.md b/workflow/spec/extending.md index 8e1a085..adca209 100644 --- a/workflow/spec/extending.md +++ b/workflow/spec/extending.md @@ -22,10 +22,10 @@ Hope this gives implementors an idea on how to start adding their own custom ext Let's say we are developing an extension which adds additional information to a serverless workflow that can be passed and processed by a simulation tool. -Our example extension can add one more more simulation "scenarios". Each scenario +Our example extension can add "scenarios". Each scenario can add "time" parameters for each of the workflow states and define a min and max value within which the workflow state should be executed in. It should also add a "probability" parameter -which defines the probabily that a state is triggered during the execution of the workflow. +which defines the probability that a state is triggered during the execution of the workflow. So let's define a simple example workflow model and then add our custom extension into it: diff --git a/workflow/spec/references.md b/workflow/spec/references.md index 7b47527..5468737 100644 --- a/workflow/spec/references.md +++ b/workflow/spec/references.md @@ -15,7 +15,7 @@ The research of the [Workflow Patterns Initiative](http://www.workflowpatterns.c ## Business Process Model and Notation -[Business Process Modeling and Notation (BPMN)](https://www.omg.org/spec/BPMN/) was standardized by Object Management Group (OMG) in collaboration with companies such as: IBM, Red Hat, Oracle, SAP, TIBCO, Software AG, among others. The latest version of the specification has even been [adopted by the ISO](https://www.iso.org/standard/62652.html) and provides a rich set of constructs to define workflows in a technology-agnostic way. One of the main advatages of the BPMN spec is that it visually defines how a workflow should look like and most importantly, it defines the execution semantics of such workflows. [This article](https://www.esentri.com/bpmn-and-serverless-workflows/) describes how BPMN can be used for serverless workflows. +[Business Process Modeling and Notation (BPMN)](https://www.omg.org/spec/BPMN/) was standardized by Object Management Group (OMG) in collaboration with companies such as: IBM, Red Hat, Oracle, SAP, TIBCO, Software AG, among others. The latest version of the specification has even been [adopted by the ISO](https://www.iso.org/standard/62652.html) and provides a rich set of constructs to define workflows in a technology-agnostic way. One of the main advantages of the BPMN spec is that it visually defines how a workflow should look like and most importantly, it defines the execution semantics of such workflows. [This article](https://www.esentri.com/bpmn-and-serverless-workflows/) describes how BPMN can be used for serverless workflows.
BPMN model @@ -32,7 +32,7 @@ The research of the [Workflow Patterns Initiative](http://www.workflowpatterns.c - Throw - Catch - Timer Events -- Gateways: Enable fork/join behaviours based on certain condition +- Gateways: Enable fork/join behaviors based on certain condition - Exclusive - Parallel - Complex @@ -52,13 +52,13 @@ The [BPMN specification](https://www.omg.org/spec/BPMN/) provides XML Schemas fo ![Loan Approval Example](media/references/loan-approval-workflow.png) - You can find the BPMN XML which can be executed in a number of Open Source and Propietary engines [here](media/references/loan-approval-workflow.bpmn) + You can find the BPMN XML which can be executed in a number of Open Source and Proprietary engines [here](media/references/loan-approval-workflow.bpmn) **Travel Booking Workflow** ![Travel Booking Example](media/references/travel-booking-workflow.png) - You can find the BPMN XML which can be executed in a number of Open Source and Propietary engines [here](media/references/travel-booking-workflow.bpmn) + You can find the BPMN XML which can be executed in a number of Open Source and Proprietary engines [here](media/references/travel-booking-workflow.bpmn)
## Mistral Workflow Language @@ -97,11 +97,11 @@ The [BPMN specification](https://www.omg.org/spec/BPMN/) provides XML Schemas fo - name - description -- action or workflow, otherwise it's a noop +- action or workflow, otherwise it's a no-op - input (constructs action/subworkflow input parameters from the context of the task) - publish (decides which action/subworkflow outputs are put into the context) - publish-on-error -- with-items (processes items of a collection, i.e. the action/workflow excutes multiple times) +- with-items (processes items of a collection, i.e. the action/workflow executes multiple times) - keep-result (can be used to discard the action/subworkflow output) - target (which worker should execute the task) - pause-before @@ -128,7 +128,7 @@ The [BPMN specification](https://www.omg.org/spec/BPMN/) provides XML Schemas fo ## Alibaba FunctionFlow -FunctionFlow defines workflows of steps using yaml arrays and a simple control logic that starts with the first step in the array, allows jumps with goto and ending a flow either by reaching the last ste in the array or by marking a step as the end of the flow. +FunctionFlow defines workflows of steps using yaml arrays and a simple control logic that starts with the first step in the array, allows jumps with goto and ending a flow either by reaching the last step in the array or by marking a step as the end of the flow.
FunctionFlow FDL (Flow Definition Language) model diff --git a/workflow/spec/spec.md b/workflow/spec/spec.md index aa126e5..427690f 100644 --- a/workflow/spec/spec.md +++ b/workflow/spec/spec.md @@ -38,7 +38,7 @@ clear separation between business and orchestration logic. Some of the many benefits using workflows in serverless applications include: -- Allow developers to fucus on business requirements and not orchestration logic. +- Allow developers to focus on business requirements and not orchestration logic. - Externalize cross-cutting concerns such as parallel execution, branching, timeouts, compensation, callbacks, etc. thus allowing clear focus on business requirements in functions. - Greatly reduce the amount of code developers have to write, maintain, and test. @@ -442,7 +442,7 @@ States define building blocks of the Serverless Workflow. The specification defi | **[ForEach](#ForEach-State)** | Parallel execution of states for each element of a data array | no | yes | no | yes (includes retries) | yes | no | | **[Callback](#Callback-State)** | Manual decision step. Executes a function and waits for callback event that indicates completion of the manual decision.| yes | yes | yes (including retries) | yes | no | no | -Following is a detailed decription of each of the defined states: +Following is a detailed description of each of the defined states: #### Event State @@ -642,7 +642,7 @@ have not been received during this time, the state should transition to the next Event actions reference one or more events in the workflow [events definitions](#Event-Definition). Both the source and type of incoming events must match the ones defined in the references events in order for -the event to be considered. In case of mutliple events the event definition "correlationToken" context attribute +the event to be considered. In case of multiple events the event definition "correlationToken" context attribute value must also match between events. If a correlation token is not defined, all events that match the other attributes can be considered. @@ -888,7 +888,7 @@ This assures that both execution errors as well as actions error results can be The interval parameter specifies the retry interval (in ISO 8601 repeatable format). For example: "R5/PT15M" would mean repeat 5 times with 1 minute intervals before each retry. The multiplier parameter specifies value by which the interval time is increased for each of the retry attempts. -To eplain this better, let's say we have: +To explain this better, let's say we have: ```json { @@ -1913,7 +1913,7 @@ as data output to the transition state: type: RELAY inject: person: - fnam: John + fname: John lname: Doe address: 1234 SomeStreet age: 40 @@ -1996,15 +1996,15 @@ what you need as data output of the state. Let's say we have: type: RELAY inject: people: - - fnam: John + - fname: John lname: Doe address: 1234 SomeStreet age: 40 - - fnam: Marry + - fname: Marry lname: Allice address: 1234 SomeStreet age: 25 - - fnam: Kelly + - fname: Kelly lname: Mill address: 1234 SomeStreet age: 30 @@ -2019,7 +2019,7 @@ what you need as data output of the state. Let's say we have: In which case the states data output would include people who's age is less than 40. -You can change your output path easily during testin, for example: +You can change your output path easily during testing, for example: ```text $.people[?(@.age >= 40)] @@ -3112,7 +3112,7 @@ Here is an example using an even filter: Event Data Filter Example

-Similarly the consumed callback CloudEvent in [Callback states](#Callback-State) can be filered using +Similarly the consumed callback CloudEvent in [Callback states](#Callback-State) can be filtered using an event filter. #### State information filtering - Error Data Filter @@ -3349,7 +3349,7 @@ decide to strictly enforce it. ### Workflow Error Handling -Any state can encounter runtime errors. Errors can arise from state failures such as exeptions thrown during function +Any state can encounter runtime errors. Errors can arise from state failures such as exceptions thrown during function execution, network errors, or errors in the workflow definition (incorrect paths for example). If a runtime error is not explicitly handled within the state definition, the default course of action should be to halt workflow execution. @@ -3589,8 +3589,8 @@ If those errors occur after two max 2 retries, the onError definition states tha ### Workflow Metadata -Metdata enables you to enrich the serverless workflow model with information beyond its core definitions. -It is inteded to be used by clients such as tools and libraries, as well as users that find this information relevant. +Metadata enables you to enrich the serverless workflow model with information beyond its core definitions. +It is intended to be used by clients such as tools and libraries, as well as users that find this information relevant. Metadata should not affect workflow execution. Implementations may chose to use metadata information or ignore it. Note however that using metadata to control workflow execution can lead to vendor-locked implementations which do comply with the main goals of this specification, which is to be completely vendor-neutral. diff --git a/workflow/spec/usecases.md b/workflow/spec/usecases.md index 0234bc4..d106d51 100644 --- a/workflow/spec/usecases.md +++ b/workflow/spec/usecases.md @@ -57,7 +57,7 @@ In conjunction with available messaging services you can notify developers on di ## Continuous Integration And Deployment Serverless Workflows can help you build solid continuous integration and deployment solutions. -Code checkins can trigger website builds and automatic redeploys. Pull requests can trigger +Code check-ins can trigger website builds and automatic redeploys. Pull requests can trigger running automated tests to make sure code is well-tested before human reviews.