@@ -1081,10 +1081,9 @@ In addition to defining RESTful and RPC services and their operations, workflow
1081
1081
can also be used to define expressions that should be evaluated during workflow execution.
1082
1082
1083
1083
Defining expressions as part of function definitions has the benefit of being able to reference
1084
- them by their logical name through workflow states where expression evaluation is required, thus making them
1085
- reusable definitions.
1084
+ them by their logical name through workflow states where expression evaluation is required.
1086
1085
1087
- Expression expression functions must declare their `type` parameter to be `expression`.
1086
+ Expression functions must declare their `type` parameter to be `expression`.
1088
1087
1089
1088
Let's take at an example of such definitions :
1090
1089
@@ -1106,9 +1105,9 @@ Let's take at an example of such definitions:
1106
1105
` ` `
1107
1106
1108
1107
Here we define two reusable expression functions. Expressions in Serverless Workflow
1109
- are evaluated against the workflow data. Note that different data filters play a big role as to which parts of the
1110
- workflow data are selected . Reference the
1111
- [State Data Filtering](#State-data-filters ) section for more information on this.
1108
+ can be evaluated against the workflow, or workflow state data. Note that different data filters play a big role as to which parts of the
1109
+ workflow data are being evaluated by the expressions . Reference the
1110
+ [State Data Filtering](#State-Data-Filtering ) section for more information on this.
1112
1111
1113
1112
Our expression function definitions can now be referenced by workflow states when they need to be evaluated. For example :
1114
1113
@@ -1138,6 +1137,61 @@ Our expression function definitions can now be referenced by workflow states whe
1138
1137
}
1139
1138
` ` `
1140
1139
1140
+ Our expression functions can also be referenced and executed as part of state [action](#Action-Definition) execution.
1141
+ Let's say we have the following workflow definition :
1142
+
1143
+ ` ` ` json
1144
+ {
1145
+ "name": "simpleadd",
1146
+ "functions": [
1147
+ {
1148
+ "name": "Increment Count Function",
1149
+ "type": "expression",
1150
+ "operation": ".count += 1 | .count"
1151
+ }
1152
+ ],
1153
+ "start": "Initialize Count",
1154
+ "states": [
1155
+ {
1156
+ "name": "Initialize Count",
1157
+ "type": "inject",
1158
+ "data": {
1159
+ "count": 0
1160
+ },
1161
+ "transition": "Increment Count"
1162
+ },
1163
+ {
1164
+ "name": "Increment Count",
1165
+ "type": "operation",
1166
+ "actions": [
1167
+ {
1168
+ "functionRef": "Increment Count Function",
1169
+ "actionFilter": {
1170
+ "toStateData": "${ .count }"
1171
+ }
1172
+ }
1173
+ ],
1174
+ "end": true
1175
+ }
1176
+ ]
1177
+ }
1178
+ ` ` `
1179
+
1180
+ The starting [inject state](#Inject-State) "Initialize Count" injects the count element into our state data,
1181
+ which then becomes the state data input of our "Increment Count" [operation state](#Operation-State).
1182
+ This state defines an invocation of the "Increment Count Function" expression function defined in our workflow definition.
1183
+
1184
+ This triggers the evaluation of the defined expression. The input of this expression is by default the current state data.
1185
+ Just like with "rest", and "rpc" type functions, expression functions also produce a result. In this case
1186
+ the result of the expression is just the number 1.
1187
+ The actions filter then assigns this result to the state data element "count" and the state data becomes :
1188
+
1189
+ ` ` ` json
1190
+ {
1191
+ "count": 1
1192
+ }
1193
+ ` ` `
1194
+
1141
1195
Note that the used function definition type in this case must be `expression`.
1142
1196
1143
1197
For more information about functions, reference the [Functions definitions](#Function-Definition) section.
0 commit comments