Spell check on spec documents (#212)
* Spell check on spec documents * adding spell check of references doc * add spell check of extending doc
This commit is contained in:
Tihomir Surdilovic
parent
6b93e86ed6
commit
a91ea32847
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
<details>
|
||||
<summary>BPMN model</summary>
|
||||
|
|
@ -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
|
|||
|
||||
|
||||
|
||||
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**
|
||||
|
||||
|
||||
|
||||
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)
|
||||
</details>
|
||||
|
||||
## 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.
|
||||
|
||||
<details>
|
||||
<summary>FunctionFlow FDL (Flow Definition Language) model</summary>
|
||||
|
|
|
|||
|
|
@ -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:
|
|||
</table>
|
||||
|
||||
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:
|
|||
<img src="media/spec/event-data-filter-example1.png" with="300px" height="400px" alt="Event Data Filter Example"/>
|
||||
</p>
|
||||
|
||||
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.
|
||||
|
||||
#### <a name="error-data-filter"></a> 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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
<p align="center"><img src="media/usecases/usecase-continuous-integration.png"/></p>
|
||||
|
|
|
|||
Loading…
Reference in New Issue