@@ -9,6 +9,8 @@ Provides Serverless Workflow language examples
99- [ Event-based greeting (Event State)] ( #Event-Based-Greeting-Example )
1010- [ Solving Math Problems (ForEach state)] ( #Solving-Math-Problems-Example )
1111- [ Parallel Execution] ( #Parallel-Execution-Example )
12+ - [ Async Function Invocation] ( #Async-Function-Invocation-Example )
13+ - [ Async SubFlow Invocation] ( #Async-SubFlow-Invocation-Example )
1214- [ Event Based Transitions (Event-based Switch)] ( #Event-Based-Transitions-Example )
1315- [ Applicant Request Decision (Data-based Switch + SubFlows)] ( #Applicant-Request-Decision-Example )
1416- [ Provision Orders (Error Handling)] ( #Provision-Orders-Example )
@@ -580,6 +582,179 @@ We assume that the two referenced workflows, namely `shortdelayworkflowid` and `
580582with the `shortdelayworkflowid` workflow delay state defining its `timeDelay` property to be shorter than that of the `longdelayworkflowid` workflows
581583delay state.
582584
585+ # ## Async Function Invocation Example
586+
587+ # ### Description
588+
589+ This example uses a [Operation State](../specification.md#operation-state) to invoke a function async.
590+ This functions sends an email to a customer.
591+ Async function execution is a "fire-and-forget" type of invocation. The function is invoked and workflow execution
592+ does not wait for its results.
593+
594+ # ### Workflow Diagram
595+
596+ <p align="center">
597+ <img src="../media/examples/example-asyncfunction.png" height="500px" alt="Async Function Example"/>
598+ </p>
599+
600+ # ### Workflow Definition
601+
602+ <table>
603+ <tr>
604+ <th>JSON</th>
605+ <th>YAML</th>
606+ </tr>
607+ <tr>
608+ <td valign="top">
609+
610+ ` ` ` json
611+ {
612+ "id": "sendcustomeremail",
613+ "version": "1.0",
614+ "specVersion": "0.7",
615+ "name": "Send customer email workflow",
616+ "description": "Send email to a customer",
617+ "start": "Send Email",
618+ "functions": [
619+ {
620+ "name": "emailFunction",
621+ "operation": "file://myapis/emailapis.json#sendEmail"
622+ }
623+ ],
624+ "states":[
625+ {
626+ "name":"Send Email",
627+ "type":"operation",
628+ "actions":[
629+ {
630+ "functionRef": {
631+ "invoke": "async",
632+ "refName": "emailFunction",
633+ "arguments": {
634+ "customer": "${ .customer }"
635+ }
636+ }
637+ }
638+ ],
639+ "end": true
640+ }
641+ ]
642+ }
643+ ` ` `
644+
645+ </td>
646+ <td valign="top">
647+
648+ ` ` ` yaml
649+ id: sendcustomeremail
650+ version: '1.0'
651+ specVersion: '0.7'
652+ name: Send customer email workflow
653+ description: Send email to a customer
654+ start: Send Email
655+ functions:
656+ - name: emailFunction
657+ operation: file://myapis/emailapis.json#sendEmail
658+ states:
659+ - name: Send Email
660+ type: operation
661+ actions:
662+ - functionRef:
663+ invoke: async
664+ refName: emailFunction
665+ arguments:
666+ customer: "${ .customer }"
667+ end: true
668+ ` ` `
669+
670+ </td>
671+ </tr>
672+ </table>
673+
674+ # ## Async SubFlow Invocation Example
675+
676+ # ### Description
677+
678+ This example uses a [Operation State](../specification.md#operation-state) to invoke a [SubFlow](../specification.md#Subflow-Action) async.
679+ This SubFlow is responsible for performing some customer business logic.
680+ Async SubFlow invocation is a "fire-and-forget" type of invocation. The SubFlow is invoked and workflow execution
681+ does not wait for its results. In addition, we specify that the SubFlow should be allowed to continue its execution
682+ event if the parent workflow completes its own execution. This is done by defining the actions `onParentComplete`
683+ property to `continue`.
684+
685+ # ### Workflow Diagram
686+
687+ <p align="center">
688+ <img src="../media/examples/example-asyncsubflow.png" height="500px" alt="Async SubFlow Example"/>
689+ </p>
690+
691+ # ### Workflow Definition
692+
693+ <table>
694+ <tr>
695+ <th>JSON</th>
696+ <th>YAML</th>
697+ </tr>
698+ <tr>
699+ <td valign="top">
700+
701+ ` ` ` json
702+ {
703+ "id": "onboardcustomer",
704+ "version": "1.0",
705+ "specVersion": "0.7",
706+ "name": "Onboard Customer",
707+ "description": "Onboard a Customer",
708+ "start": "Onboard",
709+ "states":[
710+ {
711+ "name":"Onboard",
712+ "type":"operation",
713+ "actions":[
714+ {
715+ "subFlowRef": {
716+ "invoke": "async",
717+ "onParentComplete": "continue",
718+ "workflowId": "customeronboardingworkflow",
719+ "version": "1.0"
720+ }
721+ }
722+ ],
723+ "end": true
724+ }
725+ ]
726+ }
727+ ` ` `
728+
729+ </td>
730+ <td valign="top">
731+
732+ ` ` ` yaml
733+ id: onboardcustomer
734+ version: '1.0'
735+ specVersion: '0.7'
736+ name: Onboard Customer
737+ description: Onboard a Customer
738+ start: Onboard
739+ states:
740+ - name: Onboard
741+ type: operation
742+ actions:
743+ - subFlowRef:
744+ invoke: async
745+ onParentComplete: continue
746+ workflowId: customeronboardingworkflow
747+ version: '1.0'
748+ end: true
749+ ` ` `
750+
751+ </td>
752+ </tr>
753+ </table>
754+
755+ For the sake of the example, the definition of "customeronboardingworkflow" workflow invoked as a SubFlow
756+ is not shown.
757+
583758# ## Event Based Transitions Example
584759
585760# ### Description
0 commit comments