. If type is `expression`, defines the workflow expression. | string | yes |
| type | Defines the function type. Can be either `rest`, `asyncapi`, `rpc`, `graphql`, `odata`, `expression`, or [`custom`](#defining-custom-function-types). Default is `rest` | enum | no |
| authRef | References an [auth definition](#Auth-Definition) name to be used to access to resource defined in the operation parameter | string | no |
@@ -3205,7 +3208,7 @@ Note that `transition` and `end` properties are mutually exclusive, meaning that
```json
{
- "name": "HelloWorldFunction",
+ "name": "hello-world-function",
"operation": "https://hellworldservice.api.com/api.json#helloWorld"
}
```
@@ -3214,7 +3217,7 @@ Note that `transition` and `end` properties are mutually exclusive, meaning that
|
```yaml
-name: HelloWorldFunction
+name: hello-world-function
operation: https://hellworldservice.api.com/api.json#helloWorld
```
@@ -3316,7 +3319,7 @@ It's worth noting that if an [auth definition](#Auth-Definition) has been define
| Parameter | Description | Type | Required |
| --- | --- | --- | --- |
-| name | Unique event name | string | yes |
+| name | Unique event name. Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | yes |
| source | CloudEvent source. If not set when `kind` is `produced`, runtimes are expected to use a default value, such as https://serverlessworkflow.io in order to comply with the [CloudEvent spec constraints](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md#source-1))| string | yes (if `type` is not defined. |
| type | CloudEvent type | string | yes (if `source` is not defined) |
| kind | Defines the event is either `consumed` or `produced` by the workflow. Default is `consumed` | enum | no |
@@ -3337,7 +3340,7 @@ It's worth noting that if an [auth definition](#Auth-Definition) has been define
```json
{
- "name": "ApplicantInfo",
+ "name": "applicant-info",
"type": "org.application.info",
"source": "applicationssource",
"kind": "consumed",
@@ -3353,7 +3356,7 @@ It's worth noting that if an [auth definition](#Auth-Definition) has been define
|
```yaml
-name: ApplicantInfo
+name: applicant-info
type: org.application.info
source: applicationssource
kind: consumed
@@ -3441,7 +3444,7 @@ type that have the **same** value of the `patientId` property to be correlated t
{
"events": [
{
- "name": "HeartRateReadingEvent",
+ "name": "heart-rate-reading-event",
"source": "hospitalMonitorSystem",
"type": "com.hospital.patient.heartRateMonitor",
"kind": "consumed",
@@ -3466,7 +3469,7 @@ and we want to make sure that both are correlated, as in the above example, with
{
"events": [
{
- "name": "HeartRateReadingEvent",
+ "name": "heart-rate-reading-event",
"source": "hospitalMonitorSystem",
"type": "com.hospital.patient.heartRateMonitor",
"kind": "consumed",
@@ -3477,7 +3480,7 @@ and we want to make sure that both are correlated, as in the above example, with
]
},
{
- "name": "BloodPressureReadingEvent",
+ "name": "blood-pressure-reading-event",
"source": "hospitalMonitorSystem",
"type": "com.hospital.patient.bloodPressureMonitor",
"kind": "consumed",
@@ -3498,7 +3501,7 @@ on comparing it to custom defined values (string, or expression). For example:
{
"events": [
{
- "name": "HeartRateReadingEvent",
+ "name": "heart-rate-reading-event",
"source": "hospitalMonitorSystem",
"type": "com.hospital.patient.heartRateMonitor",
"kind": "consumed",
@@ -3534,7 +3537,9 @@ It can be used for both the retrieval of the function's resource (as defined by
| Parameter | Description | Type | Required |
| --- | --- | --- | --- |
-| name | Unique auth definition name | string | yes |
+| name | Unique auth definition name. Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | yes |
+| scheme | Auth scheme, can be "basic", "bearer", or "oauth2". Default is "basic" | enum | yes |
+| name | Unique auth definition name. Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | yes |
| scheme | Auth scheme, can be "basic", "bearer", or "oauth2". Default is "basic" | enum | no |
| properties | Auth scheme properties. Can be one of ["Basic properties definition"](#basic-properties-definition), ["Bearer properties definition"](#bearer-properties-definition), or ["OAuth2 properties definition"](#oauth2-properties-definition) | object | yes |
@@ -3660,10 +3665,10 @@ The `contextAttributeValue` property defines the value of the defined CloudEvent
```json
{
- "eventRefs": ["HighBodyTemperature"],
+ "eventRefs": ["high-body-temperature"],
"actions": [{
"functionRef": {
- "refName": "sendTylenolOrder",
+ "refName": "send-tylenol-order",
"arguments": {
"patientid": "${ .patientId }"
}
@@ -3677,10 +3682,10 @@ The `contextAttributeValue` property defines the value of the defined CloudEvent
```yaml
eventRefs:
-- HighBodyTemperature
+- high-body-temperature
actions:
- functionRef:
- refName: sendTylenolOrder
+ refName: send-tylenol-order
arguments:
patientid: "${ .patientId }"
```
@@ -3706,10 +3711,10 @@ Let's look at the following JSON definition of 'onEvents' to show this:
```json
{
"onEvents": [{
- "eventRefs": ["HighBodyTemperature", "HighBloodPressure"],
+ "eventRefs": ["high-body-temperature", "high-blood-pressure"],
"actions": [{
"functionRef": {
- "refName": "SendTylenolOrder",
+ "refName": "send-tylenol-order",
"arguments": {
"patient": "${ .patientId }"
}
@@ -3717,7 +3722,7 @@ Let's look at the following JSON definition of 'onEvents' to show this:
},
{
"functionRef": {
- "refName": "CallNurse",
+ "refName": "call-nurse",
"arguments": {
"patient": "${ .patientId }"
}
@@ -3744,7 +3749,7 @@ This is visualized in the diagram below:
| Parameter | Description | Type | Required |
| --- | --- | --- | --- |
-| name | Unique Action name | string | no |
+| name | Unique Action name. Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | yes |
| [functionRef](#FunctionRef-Definition) | References a reusable function definition | object or string | yes (if `eventRef` & `subFlowRef` are not defined) |
| [eventRef](#EventRef-Definition) | References a `produce` and `consume` reusable event definitions | object | yes (if `functionRef` & `subFlowRef` are not defined) |
| [subFlowRef](#SubFlowRef-Definition) | References a workflow to be invoked | object or string | yes (if `eventRef` & `functionRef` are not defined) |
@@ -3768,9 +3773,9 @@ This is visualized in the diagram below:
```json
{
- "name": "Finalize Application Action",
+ "name": "finalize-application-action",
"functionRef": {
- "refName": "finalizeApplicationFunction",
+ "refName": "finalize-application-function",
"arguments": {
"applicantid": "${ .applicantId }"
}
@@ -3782,9 +3787,9 @@ This is visualized in the diagram below:
|
```yaml
-name: Finalize Application Action
+name: finalize-application-action
functionRef:
- refName: finalizeApplicationFunction
+ refName: finalize-application-function
arguments:
applicantid: "${ .applicantId }"
```
@@ -3860,7 +3865,7 @@ If `string` type, it defines the name of the referenced [function](#Function-Def
This can be used as a short-cut definition when you don't need to define any other parameters, for example:
```json
-"functionRef": "myFunction"
+"functionRef": "my-function"
```
Note that if used with `string` type, the invocation of the function is synchronous.
@@ -3870,7 +3875,7 @@ it with its `object` type which has the following properties:
| Parameter | Description | Type | Required |
| --- | --- | --- | --- |
-| refName | Name of the referenced [function](#Function-Definition) | string | yes |
+| refName | Name of the referenced [function](#Function-Definition). Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | yes |
| arguments | Arguments (inputs) to be passed to the referenced function | object | yes (if function type is `graphql`, otherwise no) |
| selectionSet | Used if function type is `graphql`. String containing a valid GraphQL [selection set](https://spec.graphql.org/June2018/#sec-Selection-Sets) | string | yes (if function type is `graphql`, otherwise no) |
| invoke | Specifies if the function should be invoked `sync` or `async`. Default is `sync` | enum | no |
@@ -3888,7 +3893,7 @@ it with its `object` type which has the following properties:
```json
{
- "refName": "finalizeApplicationFunction",
+ "refName": "finalize-application-function",
"arguments": {
"applicantid": "${ .applicantId }"
}
@@ -3899,7 +3904,7 @@ it with its `object` type which has the following properties:
|
```yaml
-refName: finalizeApplicationFunction
+refName: finalize-application-function
arguments:
applicantid: "${ .applicantId }"
```
@@ -3917,7 +3922,7 @@ Here is an example of using the `arguments` property:
```json
{
- "refName": "checkFundsAvailabe",
+ "refName": "check-funds-available",
"arguments": {
"account": {
"id": "${ .accountId }"
@@ -3943,8 +3948,8 @@ Allows defining invocation of a function via event.
| Parameter | Description | Type | Required |
| --- | --- | --- | --- |
-| [produceEventRef](#Event-Definition) | Reference to the unique name of a `produced` event definition | string | yes |
-| [consumeEventRef](#Event-Definition) | Reference to the unique name of a `consumed` event definition | string | no |
+| [produceEventRef](#Event-Definition) | Reference to the unique name of a `produced` event definition. Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | yes |
+| [consumeEventRef](#Event-Definition) | Reference to the unique name of a `consumed` event definition. Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | no |
| consumeEventTimeout | Maximum amount of time (ISO 8601 format) to wait for the consume event. If not defined it be set to the [actionExecutionTimeout](#Workflow-Timeout-Definition) | string | no |
| data | If string type, an expression which selects parts of the states data output to become the data (payload) of the event referenced by `produceEventRef`. If object type, a custom object to become the data (payload) of the event referenced by `produceEventRef`. | string or object | no |
| contextAttributes | Add additional event extension context attributes to the trigger/produced event | object | no |
@@ -3964,9 +3969,9 @@ Allows defining invocation of a function via event.
```json
{
"eventRef": {
- "produceEventRef": "MakeVetAppointment",
+ "produceEventRef": "make-vet-appointment",
"data": "${ .patientInfo }",
- "consumeEventRef": "VetAppointmentInfo"
+ "consumeEventRef": "vet-appointment-info"
}
}
```
@@ -3976,9 +3981,9 @@ Allows defining invocation of a function via event.
```yaml
eventRef:
- produceEventRef: MakeVetAppointment
+ produceEventRef: make-vet-appointment
data: "${ .patientInfo }"
- consumeEventRef: VetAppointmentInfo
+ consumeEventRef: vet-appointment-info
```
|
@@ -4172,7 +4177,7 @@ For more information, see the [Workflow Error Handling](#Workflow-Error-Handling
```json
{
- "name": "TimeoutRetryStrat",
+ "name": "timeout-retry-strat",
"delay": "PT2M",
"maxAttempts": 3,
"jitter": "PT0.001S"
@@ -4183,7 +4188,7 @@ For more information, see the [Workflow Error Handling](#Workflow-Error-Handling
```yaml
-name: TimeoutRetryStrat
+name: timeout-retry-strat
delay: PT2M
maxAttempts: 3
jitter: PT0.001S
@@ -4208,7 +4213,7 @@ To explain this better, let's say we have the following retry definition:
```json
{
- "name": "Timeout Errors Strategy",
+ "name": "timeout-errors-strategy",
"delay": "PT10S",
"increment": "PT2S",
"maxAttempts": 4
@@ -4223,7 +4228,7 @@ To explain this better, let's say we have the following retry definition:
```json
{
- "name": "Timeout Errors Strategy",
+ "name": "timeout-errors-strategy",
"delay": "PT10S",
"multiplier": 2,
"maxAttempts": 4
@@ -4263,7 +4268,7 @@ To explain this better, let's say we have the following retry definition:
```json
{
- "name": "Timeout Errors Strategy",
+ "name": "timeout-errors-strategy",
"delay": "PT10S",
"maxDelay": "PT100S",
"multiplier": 4,
@@ -4287,7 +4292,7 @@ If `string`, it defines the name of the state to transition to.
This can be used as a short-cut definition when you don't need to define any other parameters, for example:
```json
-"transition": "myNextState"
+"transition": "my-next-state"
```
If you need to define additional parameters in your `transition` definition, you can define
@@ -4313,10 +4318,10 @@ it with its `object` type which has the following properties:
```json
{
"produceEvents": [{
- "eventRef": "produceResultEvent",
+ "eventRef": "produce-result-event",
"data": "${ .result.data }"
}],
- "nextState": "EvalResultState"
+ "nextState": "eval-result-state"
}
```
@@ -4325,9 +4330,9 @@ it with its `object` type which has the following properties:
```yaml
produceEvents:
-- eventRef: produceResultEvent
+- eventRef: produce-result-event
data: "${ .result.data }"
-nextState: EvalResultState
+nextState: eval-result-state
```
|
@@ -4347,7 +4352,7 @@ Transitions allow you to move from one state (control-logic block) to another. F
| Parameter | Description | Type | Required |
| --- | --- | --- | --- |
-| name | Data condition name | string | no |
+| name | Data condition name. Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | yes |
| [condition](#Workflow-Expressions) | Workflow expression evaluated against state data. Must evaluate to `true` or `false` | string | yes |
| [transition](#Transitions) | Transition to another state if condition is `true` | string or object | yes (if `end` is not defined) |
| [end](#End-Definition) | End workflow execution if condition is `true` | boolean or object | yes (if `transition` is not defined) |
@@ -4366,9 +4371,9 @@ Transitions allow you to move from one state (control-logic block) to another. F
```json
{
- "name": "Eighteen or older",
+ "name": "eighteen-or-older",
"condition": "${ .applicant | .age >= 18 }",
- "transition": "StartApplication"
+ "transition": "start-application"
}
```
@@ -4376,9 +4381,9 @@ Transitions allow you to move from one state (control-logic block) to another. F
```yaml
-name: Eighteen or older
+name: eighteen-or-older
condition: "${ .applicant | .age >= 18 }"
-transition: StartApplication
+transition: start-application
```
|
@@ -4400,7 +4405,7 @@ definitions are mutually exclusive, meaning that you can specify either one or t
| Parameter | Description | Type | Required |
| --- | --- | --- | --- |
-| name | Event condition name | string | no |
+| name | Event condition name. Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | yes |
| eventRef | References an unique event name in the defined workflow events | string | yes |
| [transition](#Transitions) | Transition to another state if condition is `true` | string or object | yes (if `end` is not defined) |
| [end](#End-Definition) | End workflow execution if condition is `true` | boolean or object | yes (if `transition` is not defined) |
@@ -4420,9 +4425,9 @@ definitions are mutually exclusive, meaning that you can specify either one or t
```json
{
- "name": "Visa approved",
- "eventRef": "visaApprovedEvent",
- "transition": "HandleApprovedVisa"
+ "name": "visa-approved",
+ "eventRef": "visa-approved-event",
+ "transition": "handle-approved-visa"
}
```
@@ -4430,9 +4435,9 @@ definitions are mutually exclusive, meaning that you can specify either one or t
```yaml
-name: Visa approved
-eventRef: visaApprovedEvent
-transition: HandleApprovedVisa
+name: visa-approved
+eventRef: visa-approved-event
+transition: handle-approved-visa
```
|
@@ -4457,7 +4462,7 @@ definitions are mutually exclusive, meaning that you can specify either one or t
| Parameter | Description | Type | Required |
| --- | --- | --- | --- |
-| name | Branch name | string | yes |
+| name | Branch name. Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | yes |
| [actions](#Action-Definition) | Actions to be executed in this branch | array | yes |
| [timeouts](#Workflow-Timeouts) | Branch specific timeout settings | object | no |
@@ -4474,11 +4479,11 @@ definitions are mutually exclusive, meaning that you can specify either one or t
```json
{
- "name": "Branch1",
+ "name": "branch-1",
"actions": [
{
"functionRef": {
- "refName": "functionNameOne",
+ "refName": "function-name-one",
"arguments": {
"order": "${ .someParam }"
}
@@ -4486,7 +4491,7 @@ definitions are mutually exclusive, meaning that you can specify either one or t
},
{
"functionRef": {
- "refName": "functionNameTwo",
+ "refName": "function-name-two",
"arguments": {
"order": "${ .someParamTwo }"
}
@@ -4500,14 +4505,14 @@ definitions are mutually exclusive, meaning that you can specify either one or t
```yaml
-name: Branch1
+name: branch-1
actions:
- functionRef:
- refName: functionNameOne
+ refName: function-name-one
arguments:
order: "${ .someParam }"
- functionRef:
- refName: functionNameTwo
+ refName: function-name-two
arguments:
order: "${ .someParamTwo }"
```
@@ -4555,7 +4560,7 @@ For more information, see the [Workflow Error Handling](#Workflow-Error-Handling
Can be either `string` or `object` type. If type string, it defines the name of the workflow starting state.
```json
-"start": "MyStartingState"
+"start": "my-starting-state"
```
In this case it's assumed that the `schedule` property is not defined.
@@ -4564,7 +4569,7 @@ If the start definition is of type `object`, it has the following structure:
| Parameter | Description | Type | Required |
| --- | --- | --- | --- |
-| stateName | Name of the starting workflow state | string | no |
+| stateName | Name of the starting workflow state. Must follow the [Serverless Workflow Naming Convention](#naming-convention) | string | no |
| [schedule](#Schedule-Definition) | Define the recurring time intervals or cron expressions at which workflow instances should be automatically started. | string or object | yes |
Click to view example definition
@@ -4580,7 +4585,7 @@ If the start definition is of type `object`, it has the following structure:
```json
{
- "stateName": "MyStartingstate",
+ "stateName": "my-starting-state",
"schedule": "2020-03-20T09:00:00Z/PT2H"
}
```
@@ -4589,7 +4594,7 @@ If the start definition is of type `object`, it has the following structure:
```yaml
-stateName: MyStartingstate
+stateName: my-starting-state
schedule: 2020-03-20T09:00:00Z/PT2H
```
@@ -4823,7 +4828,7 @@ If the end definition is of type `object`, it has the following structure:
{
"terminate": true,
"produceEvents": [{
- "eventRef": "provisioningCompleteEvent",
+ "eventRef": "provisioning-complete-event",
"data": "${ .provisionedOrders }"
}]
}
@@ -4835,7 +4840,7 @@ If the end definition is of type `object`, it has the following structure:
```yaml
terminate: true
produceEvents:
-- eventRef: provisioningCompleteEvent
+- eventRef: provisioning-complete-event
data: "${ .provisionedOrders }"
```
@@ -4894,7 +4899,7 @@ before the workflow execution is stopped, and continued as a new workflow instan
```json
{
- "eventRef": "provisioningCompleteEvent",
+ "eventRef": "provisioning-complete-event",
"data": "${ .provisionedOrders }",
"contextAttributes": [{
"buyerId": "${ .buyerId }"
@@ -4906,7 +4911,7 @@ before the workflow execution is stopped, and continued as a new workflow instan
|
```yaml
-eventRef: provisioningCompleteEvent
+eventRef: provisioning-complete-event
data: "${ .provisionedOrders }"
contextAttributes:
- buyerId: "${ .buyerId }"
@@ -5145,12 +5150,12 @@ Let's take a look at an example. To start, let's define a workflow top-level `re
{
"retries": [
{
- "name": "FirstRetryStrategy",
+ "name": "first-retry-strategy",
"delay": "PT1M",
"maxAttempts": 5
},
{
- "name": "SecondRetryStrategy",
+ "name": "second-retry-strategy",
"delay": "PT10M",
"maxAttempts": 10
}
@@ -5163,10 +5168,10 @@ Let's take a look at an example. To start, let's define a workflow top-level `re
```yaml
retries:
- - name: FirstRetryStrategy
+ - name: first-retry-strategy
delay: PT1M
maxAttempts: 5
- - name: SecondRetryStrategy
+ - name: second-retry-strategy
delay: PT10M
maxAttempts: 10
@@ -5190,17 +5195,17 @@ Our `retries` definitions can be referenced by actions. For example:
{
"actions": [
{
- "functionRef": "MyFirstFunction",
- "retryRef": "FirstRetryStrategy",
+ "functionRef": "my-first-function",
+ "retryRef": "first-retry-strategy",
"retryableErrors": ["SomeErrorOne", "SomeErrorTwo"]
},
{
- "functionRef": "MySecondFunction",
- "retryRef": "SecondRetryStrategy",
+ "functionRef": "my-second-function",
+ "retryRef": "second-retry-strategy",
"retryableErrors": ["SomeErrorTwo", "SomeErrorThree"]
},
{
- "functionRef": "MyThirdFunction"
+ "functionRef": "my-third-function"
}
]
}
@@ -5211,17 +5216,17 @@ Our `retries` definitions can be referenced by actions. For example:
```yaml
actions:
- - functionRef: MyFirstFunction
- retryRef: FirstRetryStrategy
+ - functionRef: my-first-function
+ retryRef: first-retry-strategy
nonRetryableErrors:
- SomeErrorOne
- SomeErrorTwo
- - functionRef: MySecondFunction
- retryRef: SecondRetryStrategy
+ - functionRef: my-second-function
+ retryRef: second-retry-strategy
nonRetryableErrors:
- SomeErrorTwo
- SomeErrorThree
- - functionRef: MyThirdFunction
+ - functionRef: my-third-function
```
|
@@ -5283,17 +5288,17 @@ To start, let's define a workflow top-level `retries` definition:
{
"retries": [
{
- "name": "FirstRetryStrategy",
+ "name": "first-retry-strategy",
"delay": "PT1M",
"maxAttempts": 5
},
{
- "name": "SecondRetryStrategy",
+ "name": "second-retry-strategy",
"delay": "PT10M",
"maxAttempts": 10
},
{
- "name": "DoNotRetryStrategy",
+ "name": "no-retry-strategy",
"maxAttempts": 1
}
]
@@ -5305,13 +5310,13 @@ To start, let's define a workflow top-level `retries` definition:
```yaml
retries:
- - name: FirstRetryStrategy
+ - name: first-retry-strategy
delay: PT1M
maxAttempts: 5
- - name: SecondRetryStrategy
+ - name: second-retry-strategy
delay: PT10M
maxAttempts: 10
- - name: DoNotRetryStrategy
+ - name: no-retry-strategy
maxAttempts: 1
```
@@ -5334,21 +5339,21 @@ Our retry definitions can be referenced by state actions. For example:
{
"actions": [
{
- "functionRef": "MyFirstFunction",
- "retryRef": "FirstRetryStrategy",
+ "functionRef": "my-first-function",
+ "retryRef": "first-retry-strategy",
"nonRetryableErrors": ["SomeErrorOne", "SomeErrorTwo"]
},
{
- "functionRef": "MySecondFunction",
- "retryRef": "SecondRetryStrategy",
+ "functionRef": "my-second-function",
+ "retryRef": "second-retry-strategy",
"nonRetryableErrors": ["SomeErrorTwo", "SomeErrorThree"]
},
{
- "functionRef": "MyThirdFunction"
+ "functionRef": "my-thrid-function"
},
{
- "functionRef": "MyFourthFunction",
- "retryRef": "DoNotRetryStrategy"
+ "functionRef": "my-fourth-function",
+ "retryRef": "no-retry-strategy"
}
]
}
@@ -5359,19 +5364,19 @@ Our retry definitions can be referenced by state actions. For example:
```yaml
actions:
- - functionRef: MyFirstFunction
- retryRef: FirstRetryStrategy
+ - functionRef: my-first-function
+ retryRef: first-retry-strategy
nonRetryableErrors:
- SomeErrorOne
- SomeErrorTwo
- - functionRef: MySecondFunction
- retryRef: SecondRetryStrategy
+ - functionRef: my-second-function
+ retryRef: second-retry-strategy
nonRetryableErrors:
- SomeErrorTwo
- SomeErrorThree
- - functionRef: MyThirdFunction
- - functionRef: MyFourthFunction
- retryRef: DoNotRetryStrategy
+ - functionRef: my-third-function
+ - functionRef: my-fourth-function
+ retryRef: no-retry-strategy
```
@@ -5430,7 +5435,7 @@ Now let's say that we have worfklow states "A" and "B". State "A" does not defin
```json
{
- "name": "B",
+ "name": "b",
"type": "operation",
...
"timeouts": {
@@ -5592,7 +5597,7 @@ between arrival of specified events. To give an example, consider the following:
{
"states": [
{
- "name": "ExampleEventState",
+ "name": "example-event-state",
"type": "event",
"exclusive": false,
"timeouts": {
@@ -5601,8 +5606,8 @@ between arrival of specified events. To give an example, consider the following:
"onEvents": [
{
"eventRefs": [
- "ExampleEvent1",
- "ExampleEvent2"
+ "example-event-1",
+ "example-event-2"
],
"actions": [
...
@@ -5676,17 +5681,17 @@ state it references:
{
"states": [
{
- "name": "NewItemPurchase",
+ "name": "new-item-purchase",
"type": "event",
"onEvents": [
{
"eventRefs": [
- "NewPurchase"
+ "new-purchase"
],
"actions": [
{
"functionRef": {
- "refName": "DebitCustomerFunction",
+ "refName": "debit-customer-function",
"arguments": {
"customerid": "${ .purchase.customerid }",
"amount": "${ .purchase.amount }"
@@ -5695,7 +5700,7 @@ state it references:
},
{
"functionRef": {
- "refName": "SendPurchaseConfirmationEmailFunction",
+ "refName": "send-purchase-confirmation-email-function",
"arguments": {
"customerid": "${ .purchase.customerid }"
}
@@ -5704,17 +5709,17 @@ state it references:
]
}
],
- "compensatedBy": "CancelPurchase",
- "transition": "SomeNextWorkflowState"
+ "compensatedBy": "cancel-purchase",
+ "transition": "some-next-workflow-state"
},
{
- "name": "CancelPurchase",
+ "name": "cancel-purchase",
"type": "operation",
"usedForCompensation": true,
"actions": [
{
"functionRef": {
- "refName": "CreditCustomerFunction",
+ "refName": "credit-customer-function",
"arguments": {
"customerid": "${ .purchase.customerid }",
"amount": "${ .purchase.amount }"
@@ -5723,7 +5728,7 @@ state it references:
},
{
"functionRef": {
- "refName": "SendPurchaseCancellationEmailFunction",
+ "refName": "send-purchase-cancellation-email-function",
"arguments": {
"customerid": "${ .purchase.customerid }"
}
@@ -5740,34 +5745,34 @@ state it references:
```yaml
states:
-- name: NewItemPurchase
+- name: new-item-purchase
type: event
onEvents:
- eventRefs:
- - NewPurchase
+ - new-purchase
actions:
- functionRef:
- refName: DebitCustomerFunction
+ refName: debit-customer-function
arguments:
customerid: "${ .purchase.customerid }"
amount: "${ .purchase.amount }"
- functionRef:
- refName: SendPurchaseConfirmationEmailFunction
+ refName: send-purchase-confirmation-email-function
arguments:
customerid: "${ .purchase.customerid }"
- compensatedBy: CancelPurchase
- transition: SomeNextWorkflowState
+ compensatedBy: cancel-purchase
+ transition: some-next-workflow-state
- name: CancelPurchase
type: operation
usedForCompensation: true
actions:
- functionRef:
- refName: CreditCustomerFunction
+ refName: credit-customer-function
arguments:
customerid: "${ .purchase.customerid }"
amount: "${ .purchase.amount }"
- functionRef:
- refName: SendPurchaseCancellationEmailFunction
+ refName: send-purchase-cancellation-email-function
arguments:
customerid: "${ .purchase.customerid }"
```
@@ -5802,7 +5807,7 @@ Let's take a look at each:
{
"transition": {
"compensate": true,
- "nextState": "NextWorkflowState"
+ "nextState": "next-workflow-state"
}
}
```
@@ -5813,7 +5818,7 @@ Let's take a look at each:
```yaml
transition:
compensate: true
- nextState: NextWorkflowState
+ nextState: next-workflow-state
```
|
@@ -6020,18 +6025,18 @@ Here is an example of using constants in Workflow expressions:
...
"states":[
{
- "name":"CheckApplicant",
+ "name":"check-applicant",
"type":"switch",
"dataConditions": [
{
- "name": "Applicant is adult",
+ "name": "applicant-is-adult",
"condition": "${ .applicant | .age >= $CONST.AGE.MIN_ADULT }",
- "transition": "ApproveApplication"
+ "transition": "approve-application"
},
{
- "name": "Applicant is minor",
+ "name": "applicant-is-minor",
"condition": "${ .applicant | .age < $CONST.AGE.MIN_ADULT }",
- "transition": "RejectApplication"
+ "transition": "reject-application"
}
],
...
@@ -6048,12 +6053,12 @@ for example:
{
"functions": [
{
- "name": "isAdult",
+ "name": "is-adult",
"operation": ".applicant | .age >= $CONST.AGE.MIN_ADULT",
"type": "expression"
},
{
- "name": "isMinor",
+ "name": "is-minor",
"operation": ".applicant | .age < $CONST.AGE.MIN_ADULT",
"type": "expression"
}
@@ -6092,7 +6097,7 @@ Here is an example on how to use secrets and pass them as arguments to a functio
...
{
- "refName": "uploadToAzure",
+ "refName": "upload-to-azure",
"arguments": {
"account": "${ $SECRETS.AZURE_STORAGE_ACCOUNT }",
"account-key": "${ $SECRETS.AZURE_STORAGE_KEY }",
@@ -6168,17 +6173,17 @@ Implementations may use this keyword to give access to any relevant information
"name": "Process Sales Orders",
"version": "1.0.0",
"specVersion": "0.8",
- "start": "MyStartingState",
+ "start": "my-starting-state",
"functions": [{
- "name": "myFunction",
+ "name": "my-function",
"operation": "myopenapi.json#myFunction"
}],
"states":[
{
- "name":"MyStartingState",
+ "name":"my-starting-state",
"type":"operation",
"actions": [{
- "functionRef": "myFunction",
+ "functionRef": "my-function",
"args": {
"order": "${ .orderId }",
"callerId": "${ $WORKFLOW.instanceId }"
@@ -6193,6 +6198,14 @@ In this use case, a third-party service may require information from the caller
The specification doesn't define any specific variable within the `WORKFLOW` bucket, but it's considered a reserved keyword.
+### Naming Convention
+
+Identifiable components of a workflow definition, such as states, actions, branches, events and functions define a required non-null `name` property which is based on DNS label names as defined by [RFC 1123](https://datatracker.ietf.org/doc/html/rfc1123#page-13) with further restrictions.
+
+Specifically, `names` must be lowercase, start and end with an alphanumeric character, and consist entirely of alphanumeric characters with optional isolated medial dashes '-' (i.e., dashes must not be adjacent to each other).
+
+The regular expression used in [schemas](/schema/workflow.json) is: `^[a-z0-9](-?[a-z0-9])*$`.
+
## Extensions
The workflow extension mechanism allows you to enhance your model definitions with additional information useful for