Advanced navigation

[levice14]

we want to be able to define custom navigation logic on task level

• advanced navigation is based on the same context as in case of publish section: subflow outputs and flow context - related to #568
• we will be able to navigate on subflow results (current behavior)

e.g. we had this problem when ssh op became flow and we wanted to define custom results for ssh_flow based on outputs, will be handy with switch construct

[levice14]

• navigate section becomes a list instead of a map since evaluation order counts
• navigate section contains a list of navigation rules:

navigate:
- rule1
- rule2

• a rule is an object: it has a name (unique in the navigation section of a task) and content: - name: content
• content can be simple value or a map:

- SUCCESS: success_step
or
- SUCCESS:
    condition: ${ boolean_expression }
    target: task_name

• a rule has the following fields:

  • name if the rule: string identifier e.g. SUCCESS
  • target:
  • task name or flow result to navigate to
  • on_failure:
    • a task cannot be named on_failure, if we have on_failure section
    • we will be able to explicitly navigate to on_failure section based on the keyword
  • condition:
  • type:
    • boolean:
    • true / false
    • used to ingnore / force a result (default result)
    • string:
    • e.g. SUCCESS / FAILURE / CUSTOM
    • meaning: condition -> executable ended with this result
    • expression:
    • syntax: ${ expr }
    • throw exception if it does not evaluate to boolean
    • expression context is composed of executable context (subflow outputs) and current flow context (accessing mode depends on self keyword decesions #568 )
  • if there is no condition specified, it takes its value from the rule name

  - CUSTOM: task_name
  
  translates to
  
  - CUSTOM:
      condition: CUSTOM
      target: task_name

  • if no navigate section, default navigation remains the same: next step or FAILURE (on_failure)

Open questions:

• validating all executable results are wired in navigation section:
  • currently we do
  • with custom navigation rules, this validation may not be handy
  • suggestion: if we navigate only based on executable results, validate that all of them are wired; if we define custom rules, validation consists of having a default result with true condition (boolean value) will not be done (I don't want to put them if I don't need them)
  • if no possible navigation rule was matched, we throw an exception
• we can define new rules that are not necessary related to executable results (not even with name of the result) another possibility is to be able to redefine only the results of the executable - no new ones, no result wiring validation problem - in this case we could go with a map like current case)

notes:

• executable refers to flow / operation

[levice14]

sample files - consider nav_op operation with results SUCCESS / FAILURE and nav_flow flow:

flow:
  name: nav_flow

  workflow:
    - task_legacy: # current syntax
        do:
          nav_op: []
        navigate:
          SUCCESS: success_step
          FAILURE: failure_step

    # equivalent with new syntax:

    - task_results_legacy_in_new_format:
        do:
          nav_op: []
        navigate:
          - SUCCESS: success_step
          - FAILURE: failure_step

    # custom rules
    - task_custom_rules:
        do:
          nav_op: []
        navigate:
          - SUCCESS_RESULT:
              condition: ${ boolean_expression }
              target: task_name
          - SUCCESS: task_name # operation ended with SUCCESS
          # note FAILURE result from operation does not need to be declared here
          - CUSTOM_1:
              condition: ${ subflow_output == 'expected output' and flow_input == 'expected input' }
              target: FLOW_RESULT
          - DEFAULT:
              condition: true # boolean value
              target: task_name

[levice14]

@CloudSlang/slang-functional-reviewers please give feedback

[meshipeer]

i think we might need here special syntax to get the result name, for cases i want a condition like: result[SUCCESS] && output(output1) == '400'

[levice14]

I think the solution for that is to reserve a word that will hold the subflow result - e.g. ${ result == 'SUCCESS' && output(output1) == '400' }