Uploaded image for project: 'FlightPath'
  1. FlightPath
  2. FLPATH-592

Orchestrator escalations

XMLWordPrintable

    • Orchestrator escalations
    • False
    • Hide

      None

      Show
      None
    • False
    • To Do
    • 0% To Do, 0% In Progress, 100% Done

      In parodos v1 we have a concept of checkers. It was our way to automate manual steps like jira ticket approval.

      Checker is responsible for tracking the status of a ticket. It may take time to approve. Sometimes people are on PTO or do not approve for other reasons. We allow workflow developers to define approval timeout. If the approval is not in place we trigger an escalation flow.
      It could be as simple as sending an email. Escalations could be implemented using sonataFlows (kogito) but there are few steps needed and we want to simplify it.

      In v1 it was possible to define a single approver to a workflow. Therefore multiple checkers would end up being escalated to the same approver. For a workflow that may require approval from different approvers, it is less ideal. We'd like to define approver per escalation or a global one.

      The building blocks for it are:

      1. The checker - the condition to check. If met, move on with the workflow. We'd like to define the interval between condition checks. The condition may be one of many things (some resource creation, permission granted, or a Jira issue approved - which is real use case). It might be that a checker will include data in the response from the condition check.

      2. The timeout - A checker is a recurring check which should end when a timeout is reached. There is a need to define the timeout. In SonataFlow the responsibility for managing timeouts is controlled by the Job Service. 

      3. Escalation - When a timeout is reached, it is time to invoke the escalation logic. Escalation may be one of sending an email or sending a notification (we had a notification service in v1, no such thing in v2).

      4. Approver - the escalation targets an approver, which can resolve the checker condition. Then the workflow should proceed.

      We'd like to see how those building blocks can be reused by other workflows easily, to reduce escalation implementation complexity.

       

      References:

      Here is a workflow that shows how escalation is invoked as part of the flow:

      https://lucid.app/lucidchart/19a3dc80-f790-4055-88df-1dbcea72c334/edit?invitationId=inv_ab3bc934-1683-4f4d-8894-48bd6450bd0b&page=1DyJ2zjuxqB4#

       

       

       

              dmartino@redhat.com Daniele Martinoli
              pkliczew@redhat.com Piotr Kliczewski
              Yona First Yona First
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: