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

Orchestrator context sharing capability

XMLWordPrintable

    • Orchestrator context sharing capability
    • False
    • Hide

      None

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

      The context sharing in Orchestrator is the desire to share typically inputs and/or outputs parameters from a workflow to another that are somehow correlated. In other words, if workflow A and workflow B are correlated and workflow B being the one invoked after A, it is desired that workflow B has access to inputs and/or outputs of workflow A. Consequently, any input(s) that workflow B can get from workflow A will be disabled and no longer requested from the user executing B. This way workflow B re-uses parameters available in A and won't let user hacking into B.

      The typical use case is the assessment workflow and its recommended infrastructure workflows. Typically, the inputs provided for the assessment workflows, will be re-used thru the selected infrastructure workflow. Currently both assessment and infrastructure workflow(s) are correlated thru business key (that's the process instance id of the assessment). 

      Example: MTA (assessment workflow required repo Url and other inputs) and M2K (Infra workflow re-using repo Url of the assessment when invoked with the business key linking them).

      Although the backstage plugin (UI) has provided a mechanism to achieve this goal FLPATH-858, this item intends to support this requirement at the backend (SonataFlow) level. 

              ftirados Francisco Javier Tirado Sarti
              pkliczew@redhat.com Piotr Kliczewski
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: