Uploaded image for project: 'Serverless logic'
  1. Serverless logic
  2. SRVLOGIC-350

Workflow input/output sharing capability

XMLWordPrintable

    • Orchestrator context sharing capability
    • False
    • None
    • False
    • Hide
      A new data index mutation, named "ExecuteAfter", has been added.
      This mutations will create and exeucte a new workflow instance.
      it expects as arguments:
      processId: Process Id of the workflow definition to be executed
      processVersion: Process Version of the workflow definition to be executed
      completedInstanceId: Optional id of a previously completed workflow which output will be used as input of the
      input: Optional input that will be merged with the output of completedInstanceId, if provided
      excludeProperties: Optional list of properties that won't be copied from completedInstanceId into the input of the new process instance.



      Show
      A new data index mutation, named "ExecuteAfter", has been added. This mutations will create and exeucte a new workflow instance. it expects as arguments: processId: Process Id of the workflow definition to be executed processVersion: Process Version of the workflow definition to be executed completedInstanceId: Optional id of a previously completed workflow which output will be used as input of the input: Optional input that will be merged with the output of completedInstanceId, if provided excludeProperties: Optional list of properties that won't be copied from completedInstanceId into the input of the new process instance.

      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
              Gonzalo Muñoz Fernández Gonzalo Muñoz Fernández
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: