SA08 - Application orchestration used by a Participant

To help understand the content of this document, readers should familiarize themselves with the key definitions and actors.

Overview

This supporting activity enables Providers to design, execute, and monitor application orchestration workflows. These workflows coordinate a sequence of steps, allowing Participants to automate the generation and delivery of information required for application sharing in a structured way.

It is important to know that the purpose of these workflows is not to perform the actual deployment of applications, but to provide Consumers with the necessary instructions or credentials to complete the deployment or access process. Depending on the application consumption scenario, workflows generate credentials and connection details for code transfer, provide access information for Application-as-a-Service, or deliver structured deployment instructions for applications intended to run on Consumer-managed infrastructure. Once triggered, in fact, the workflow executes each defined step in order to deliver outputs such as deployment instructions, credentials, or configuration details according to the logic defined and configured by the Provider when publishing the application on the catalogue.

The application orchestration capability in Simpl-Open is based on a two-layered model:

Service: A service represents a single, self-contained unit of work. It performs a specific function within the orchestration process. Services are designed to be modular and independent components that can be combined to form a complete workflow.
Workflow: A workflow is a structured sequence of services executed in a defined order to achieve a specific goal related to deliver application deployment/usage instructions to the Consumer. A workflow receives input configurations and its execution is initiated by a triggering mechanism, which in this case occurs when an application resource is consumed.

Similarity Between SA08 and SA01

SA08 and SA01 share the same orchestration model/engine and the same user experience for defining, updating, and executing workflows.

What is the difference between SA08 and SA01

The difference lies in their scope: SA01 concerns workflows applied to data, while SA08 concerns workflows applied to applications.
SA08 manages workflow that is triggered during application consumption, while SA01 covers workflow logic related to data activities.
SA08 handles outputs that are specific to application sharing (e.g., sending or generating instructions or access details), whereas SA01 handles outputs related to data processing.

Why SA08 is needed for the application

SA08 is therefore required to support the automation of the information that Providers must deliver to enable application consumption.
The Provider may optionally create and link a workflow to an application resource to automate the delivery of information to the Consumer at the consumption phase; if no workflow is linked to the application resource, the Provider must manually generate the access information and send it to the Consumer (e.g., via email).
Keeping SA08 separate ensures a clear separation of responsibilities between application-related workflows and data‑related workflows.

What information must the Provider deliver to the Consumer

It depends on the consumption scenario.
When the application requires deployment on the Consumer’s environment, the Provider must send the deployment instructions that the Consumer will use with their application deployer (standard steps, pre-build workflow to do that provided by Simpl-Open as specified below).
When the application requires code transfer, the Provider must send the URL and the credentials needed to access the code (for example, to perform a pull from a repository).
When the application is delivered as a service, the Provider must send the URL and the credentials required to access the service.

The orchestration logic (so a workflow) is shared across applications that follow the same sharing flow (e.g. in the application deployment scenario), while differing in their configuration parameters. For example, the orchestration logic is the same for all applications that need to send deployment instructions to the application deployer. The workflow steps do not change: they always prepare secrets, variables, playbooks and send them through the deployer’s APIs. What changes across applications is only the content of these elements (the actual secrets, variable values, and playbook details). This content can be customised through the workflow configuration, which is provided by the Application Provider during publication of the resource description. The following figure shows the standard steps defined in the predefined workflow provided by Simpl-Open for sending deployment instructions to the application deployer.

This workflow includes several predefined steps in order to send instructions for the deployments, such as:

Generate and send access details to the repository: The workflow creates the access credentials and sends the link and login details to the Consumer so that they can retrieve the application. In this context, the repository does not necessarily expose the application's source code. Providers can choose how the application is packaged (e.g., as executables or deployment scripts) so Consumers only access what the Provider intends to share.
Prepare and send template variables: A set of basic configuration values is prepared and shared.
Prepare and send template secrets: The workflow also provides placeholder information for sensitive values (such as passwords or tokens). Unlike the secret in Step 1, this secret is application‑specific and is known only by the Consumer.
Send inventory template: A general structure describing how to organise the target environment is shared. The Consumer will complete it with the real servers and systems used in their infrastructure.
Send playbook: The deployment instructions are delivered to the Consumer. These instructions describe the steps needed to install the application.

Since the Provider cannot know the Consumer’s infrastructure details or specific configuration choices, several configurations are intentionally delivered as templates. The final configuration and the execution of the deployment process are therefore the full responsibility of the Consumer, as remarked in BP09B – Consumer consumes an application resource from a Provider. In addition to this workflow, as previously mentioned, the Provider may also define their own custom workflow (similar to what happens for data) to manage their App‑sharing process. This is particularly relevant in Consumption Scenarios 1 and 4, where the user can configure a workflow that automatically generates the credentials to be provided to the Consumer. For this, Simpl‑Open will also make available tools and comprehensive documentation describing how to create, update and delete a workflow autonomously. Simpl-Open will also provide a starting template that Providers can use as a guide for creating the workflow.

This supporting activity covers the following main steps:

Define a workflow: Initial definition of the workflow and associated services.
Update a workflow: Update of existing workflows.
Delete a workflow: Deletion of existing workflows.
Configure a workflow: Configuration of the defined workflow.
Execute a workflow: Execution of the defined workflow.
Monitor a workflow: Verification of execution status, access to real-time or historical logs, and identification of errors or bottlenecks.

Assumptions

The following assumptions are made:

Simpl-Open will provide a code repository template that Providers can use to create their own workflow in order to support Scenario 1 and 4 of Application Consumption
Simpl-Open will provide a ready-to-use pre-build workflow in the Provider's orchestration platform to support Scenario 3 of Application Consumption
Simpl-Open will not inspect or validate the internal business logic configured by the Participants within their workflows.
The services that a Participant can use are either built-in Simpl-Open or defined by the Participant itself

Actors

The actor involved in this business process is referred to as the Participant, and can corresponds to:

Provider

Consumer is not included as an actor in this SA because they do not take part in defining or maintaining the workflow itself. The workflow is executed during the application consumption process, but its design, configuration are entirely managed by the Provider. The Consumer's interactions occur only after the workflow execution (out of scope of SA08), and those actions are addressed in BP09BX rather than in this supporting activity.

Prerequisites

The following prerequisites must be fulfilled:

Template workflow available as code repository to the Participant: A workflow template is provided by Simpl-Open as a code repository. It serves as a starting point for developing a new workflow; the Participant uses it during the "Create a Workflow" step to implement their own logic.
Predefined workflow available in the orchestration platform: A pre-build workflow is provided in the Participant's orchestration platform. Unlike the template, this workflow is already implemented and can be selected and configured (with input parameters) when the Provider configure a workflow to be executed during the application consumption phase in the Scenario 3.
Participant onboarded: The Participant should have successfully completed the onboarding business process (Business Process 3A) before they can trigger the orchestration.
End-User authentication and authorisation: The End-User must be authenticated and possess the necessary roles and permissions to execute the process steps (Business Process 3B).

Details

The following shows the detailed supporting activity diagram and gives the step descriptions.

Trigger Application Orchestration

The Participant initiates the orchestration process. It is triggered by a End-User who intends to define a new workflow, manage, execute or monitor an existing one. This step acts as the entry point to the orchestration lifecycle. This process follows the same approach already used for data orchestration workflow (SA01 – Data orchestration used by a Participant). The Provider defines, adjusts, or removes what is needed. This ensures a consistent and familiar way of working for the End-User, aligned with the model already in place.

SA08.01 Create a workflow

The Provider initiates the creation of a new workflow. They define the logical sequence of services, specify the type of outputs to be delivered (such as credentials, connection details, or deployment instructions), and configure the triggering mechanism. Once all parameters are set, the workflow is available for execution. The expected outputs of the workflows are scenario‑dependent: in Scenario 1 (Code transfer), the workflow must deliver the credentials, connection details, and any information needed to transfer the application code. In Scenario 3 (Deployment on external, local, or cloud infrastructure), the workflow must provide the playbooks and deployment instructions required for the target environment. In Scenario 4 (Access to Application‑as‑a‑Service), the workflow must provide the credentials and service access details needed by the Consumer.

SA08.02 Update a workflow

The Provider selects an existing workflow and modifies its configuration to meet new requirements. This may include changing the service sequence, updating output details, or adjusting the logic. After applying the changes, the updated workflow replaces the previous version. A versioning system ensures that each modification is tracked, allowing rollback to previous states and maintaining an auditable history of changes.

SA08.03 Delete a workflow

The Provider identifies a workflow that is no longer needed and deletes it from the system. If the workflow has no active dependencies, it is deleted: the workflow will no longer be available for future execution, and its definition will be removed, while past logs and history are retained for auditability and traceability. If there are any dependencies, deletion is prevented, and the Participant is notified of the existing dependencies.

SA08.04 Configure a workflow to be triggered on application consumption phase

The Provider configures a workflow. This configuration is typically provided when linking a workflow to a specific application resource description and provides parameters specific for that application resource. Once associated, the workflow becomes part of the application’s sharing logic and can automatically deliver the information required by the Consumer, such as connection details deployment instructions or service access information, depending on the selected consumption scenario. If no workflow is linked, the Provider must manually perform all supporting actions when the application is consumed.

SA08.05 Execute a workflow

The Provider triggers the execution of a workflow when an application resource is consumed. The workflow runs according to its defined logic and configurations and delivers the expected outputs, such as deployment instructions or access credentials. Execution results for each step are logged and made available for monitoring. If a workflow is deleted but still referenced (e.g., linked to an application consumption event), an error will be thrown because the workflow cannot be found. In such cases, no information will be disclosed, and the process will not occur, but an error will be returned to the Provider.

SA08.06 Monitor a workflow execution

The Provider can observe the execution status in real time or access historical records of past runs. The monitoring functionality includes visual indicators of the current status (e.g., running, completed, failed) and detailed logs for each step or service. In the event of failures or bottlenecks, the End User can inspect log traces to identify the root cause and take corrective action.

Outcomes

Workflow created, updated, or deleted: The Participant has completed the operation of creation, update, or deletion of a workflow.
Workflow executed: The Participant executed the workflow. This can lead to a successful execution or a failing one.
Workflow monitored: The Participant has monitored the workflow by accessing the relevant logs and status information.