How to implement such workflow using 1.0

[Flex-Xuan]

In 0.8 x we can easily to implement the workflow shows below, but in 1.0, it seems that very hard to do so.

Can any one tell me how to call a open api when I listen one event occurred.

[cdavernas]

@Flex-Xuan I'm not sure why you would think that this workflow is harder to implement in 1.0.0, as IMHO everything is simpler than before.

As a matter of fact, there actually are many ways to achieve it:

Using a combination of fork and listen tasks, allowing parallel monitoring:

document:
  dsl: '1.0.0'
  namespace: default
  name: monitor-vitals
  version: '0.1.0'
do:
  - monitorVitals:
      fork:
        branches:
          - monitorBloodPressure:
              do:
                - onHighBloodPressure:
                    listen:
                      to:
                        one:
                          with:
                            type: com.event-driven-hospital-api.events.measurements.blood-pressure.v1
                            data: ${ .bp > 120 } #adds a condition to events to match
                - handleHighBloodPressure:
                    ...
                    then: onHighBloodPressure #loop back to listen
          - monitorBodyTemperature:
              do:
                - onHighTemperature:
                    listen:
                      to:
                        one:
                          with:
                            type: com.event-driven-hospital-api.events.measurements.temperature.v1
                            data: ${ .temperature > 39 } #adds a condition to events to match
                - handleHighTemperature:
                    ...
                    then: onHighTemperature #loop back to listen
          - monitorRespirationRate:
              do:
                - onHighRespirationRate:
                    listen:
                      to:
                        one:
                          with:
                            type: com.event-driven-hospital-api.events.measurements.respiration.v1
                            data: ${ .rate > 20 } #adds a condition to events to match
                - handleHighRespirationRate:
                    ...
                    then: onHighRespirationRate #loop back to listen

Using a combination of an any listen and a switch tasks:

document:
  dsl: '1.0.0'
  namespace: default
  name: monitor-vitals
  version: '0.1.0'
do:
  - monitorVitals:
      listen:
        to:
          any:
            - with:
                type: com.event-driven-hospital-api.events.measurements.blood-pressure.v1
                data: ${ .bp > 120 } #adds a condition to events to match
            - with:         
                type: com.event-driven-hospital-api.events.measurements.temperature.v1
                data: ${ .temperature > 39 } #adds a condition to events to match
            - with:
                type: com.event-driven-hospital-api.events.measurements.respiration.v1
                data: ${ .rate > 20 } #adds a condition to events to match
  - evaluateActionToUndertake:
      switch:
        - highBloodPressure:
            when: .type == "com.event-driven-hospital-api.events.measurements.blood-pressure.v1"
            then: handleHighBloodPressure
        - highTemperature:
            when: .type == "com.event-driven-hospital-api.events.measurements.temperature.v1"
            then: handleHighTemperature
        - highRespirationRate:
            when: .type == "com.event-driven-hospital-api.events.measurements.respiration.v1"
            then: handleHighRespiration
        - default:
            then: raiseUnsupportedEventType
  - handleHighBloodPressure:
      ...
      then: monitorVitals #loopback
  - handleHighTemperature:
      ...
      then: monitorVitals #loopback
  - handleHighTemperature:
      ...
      then: handleHighRespiration #loopback
  - raiseUnsupportedEventType:
      raise:
        type: https://event-driven-hospital-api.com/errors/unsupportedEventType
        status: 400
        title: Unsupported Event Type
        detail: ...

I hope this answers your question 😉

[Flex-Xuan]

Thanks @cdavernas for your quick response, I am sorry, may be I am not clearly explain what I want to do. The picture is just for reference.
Actually for each event, I will do a specific action for that event, and only all three events all occurred, then move to next task. This is what I want. Please help to give me some advice.

[cdavernas]

@Flex-Xuan You are welcome!

Ok, so if I understood you correctly, all you need is the following, which is the same than my first suggestion, but without the looping back:

document:
  dsl: '1.0.0'
  namespace: default
  name: monitor-vitals
  version: '0.1.0'
do:
  - monitorVitals:
      fork:
        branches:
          - monitorBloodPressure:
              do:
                - onHighBloodPressure:
                    listen:
                      to:
                        one:
                          with:
                            type: com.event-driven-hospital-api.events.measurements.blood-pressure.v1
                            data: ${ .bp > 120 } #adds a condition to events to match
                - handleHighBloodPressure:
                    ...
          - monitorBodyTemperature:
              do:
                - onHighTemperature:
                    listen:
                      to:
                        one:
                          with:
                            type: com.event-driven-hospital-api.events.measurements.temperature.v1
                            data: ${ .temperature > 39 } #adds a condition to events to match
                - handleHighTemperature:
                    ...
          - monitorRespirationRate:
              do:
                - onHighRespirationRate:
                    listen:
                      to:
                        one:
                          with:
                            type: com.event-driven-hospital-api.events.measurements.respiration.v1
                            data: ${ .rate > 20 } #adds a condition to events to match
                - handleHighRespirationRate:
                    ...
  - doSomethingWhenThe3EventsHaveBeenConsumed:
      ...

Here's the flow's breakdown:

1. Parallel Monitoring (fork:)

The workflow forks into three parallel branches to monitor different vital signs:

Branch 1: Monitor Blood Pressure (monitorBloodPressure)

• Task: onHighBloodPressure

  • Type: Event Listener
  • Event: Listens for a blood pressure measurement event.
  • Condition: data: ${ .bp > 120 }
    • Description: The event is triggered if the blood pressure (bp) measurement exceeds 120.

• Task: handleHighBloodPressure

  • Type: Placeholder for handling logic.
  • Description: Specific steps for handling high blood pressure would be defined here.

Branch 2: Monitor Body Temperature (monitorBodyTemperature)

• Task: onHighTemperature

  • Type: Event Listener
  • Event: Listens for a body temperature measurement event.
  • Condition: data: ${ .temperature > 39 }
    • Description: The event is triggered if the body temperature exceeds 39°C.

• Task: handleHighTemperature

  • Type: Placeholder for handling logic.
  • Description: Specific steps for handling high body temperature would be defined here.

Branch 3: Monitor Respiration Rate (monitorRespirationRate)

• Task: onHighRespirationRate

  • Type: Event Listener
  • Event: Listens for a respiration rate measurement event.
  • Condition: data: ${ .rate > 20 }
    • Description: The event is triggered if the respiration rate exceeds 20 breaths per minute.

• Task: handleHighRespirationRate

  • Type: Placeholder for handling logic.
  • Description: Specific steps for handling high respiration rate would be defined here.

2. Completion Task

After all three branches complete their execution:

Task: doSomethingWhenThe3EventsHaveBeenConsumed

• Type: Placeholder for an action that takes place after all three monitoring branches have processed their respective events.
• Description: This task could be an aggregation of results, sending a notification, or any other workflow-specific action that should happen after all vital sign monitoring has been completed.

[Flex-Xuan]

Thanks @cdavernas for your detailed explanation, I understand that very clearly. I have one more question, If I use "fork“, How do I know all three events are all occurred?
Do you mean that monitorVitals and doSomethingWhenThe3EventsHaveBeenConsumed are in a do task, so they will be executed sequentially, and although the fork support concurrently, it still need wait all the tasks inside to be execute completed, right?

[cdavernas]

fork support concurrently, it still need wait all the tasks inside to be execute completed, right?

To quote the spec about fork tasks:

Allows workflows to execute multiple subtasks concurrently, enabling parallel processing

@Flex-Xuan Yes, all branches must complete for a fork task to complete, unless you set compete: true, in which case it completes when the first branch ran to completion.

Do you mean that monitorVitals and doSomethingWhenThe3EventsHaveBeenConsumed are in a do task, so they will be executed sequentially

Yes, exactly! To quote the spec about do tasks:

Serves as a fundamental building block within workflows, enabling the sequential execution of multiple subtasks

[Flex-Xuan]

Thanks a lot @cdavernas , very clear now.

[Flex-Xuan]

Hi @cdavernas ，
One more question, according to the quote about the "Distinguishing event-driven scheduling from start listen Tasks"

While schedule.on is concerned with when a new workflow instance should be initiated, a start listener task deals with what should happen once the instance is active. This distinction is crucial because it influences how errors and timeouts are handled—schedule.on faults are typically invisible and do not affect the workflow, whereas start listener task failures can directly and potentially severely impact the workflow instance they belong to.

In the above case, we have three event, if I want is: any of each event coming first, it will trigger the workflow, and then any other two will bind to the same workflow instance. how should I do?