Stage Management

The Stage Management feature enables you to ensure that all the workflows created inside a specific project are working as expected and then only make them available to the tenant users. To do so, it is necessary to isolate the working copy of your project, where you will be making changes from the live project itself. This gives you the freedom to make changes to your project workflows at any time, without affecting their current functionality.

How It Works

There are three main concepts associated with Stage Management:

  1. Environments - Tenants from which and to which the projects are published.
  2. Publishes - Projects published by the source environment
  3. Deployments - Projects made available in the destination environment
  4. Before we understand more about these concepts, let’s get an overview of how Stage Management works:

    • Each webMethods.io Integration tenant comes with a Default environment, which can be used to create projects and add flows/workflows in it.

    • Through your Default environment, you can register other tenants as different environments to which you can publish the created projects.

    Note: Only pre-existing tenants can be registered with your default environment. So ensure that you create a tenant first (sign up for one here), before starting the tenant registration process.

    • Once you have created a project with necessary workflows, you can publish it to one of the registered environments. When you do so, your default environment becomes the source environment for that particular project.

    • The published project becomes available in the destination environment as a deployment. The destination environment user can then configure this deployment to start using the flows/workflows within.

    Note: Any user who intends to perform asset promotion from one Software AG Cloud environment to another, must have logged in at least once in the environment where they are trying to push the assets.

    • If the source environment user makes further changes to the same project and re-publishes it to the destination environment, the destination environment user gets notified about it with an option to update his current project as per the changes in the newly available deployment.

Working with Environments

To register, view, and update environments, click on the Current Environment drop down icon located in the navigation bar.

The drop down list that appears contains two sections:

Managing environments

To manage your existing environments and register new ones, navigate to Current Environment drop down and click Manage Environments option.

Note: The Manage Environments option will be visible to you only if the Environments feature is enabled for your tenant in the Software AG Cloud. To enable this feature for your tenant please contact Global Support .

If the Environments option is enabled for you by your tenant administrator in Software AG Cloud, you will be redirected to the ENVIRONMENT screen in the Software AG Cloud from where you can create, link, and manage environments.

Otherwise, you will be redirected to the Manage Environments screen inside your webMethods.io Integration tenant from where you can register and manage environments.

Managing environments from Software AG Cloud

If the Environments option is enabled for you by your tenant administrator in Software AG Portal, then on clicking the Manage Environment option, you will be redirected to the ENVIRONMENT screen in the Software AG Cloud.

All environments associated with your tenant are listed in the ENVIRONMENT screen. Here you will see two tabs:

Creating a new environment

You can create other environments for your tenant. To do so, follow the steps below:

This will create a new environment for your tenant.

Managing environments

The Environments tab lets you view the display name, environment name, region, stage, tags, and allowed users associated with each created environment.

When you hover over an environment name, you will see three action icons on the right hand side:

Linking a new environment

You can link your existing tenants as environments. To do so, follow the steps given below:

This will link the specified environment with your default environment.

Note: If you link an environment belonging to a different region, the linked environment name will not be listed under the current environment drop down list inside your webMethods.io Integration tenant.

For example, if your tenant belongs to the AWS-US region and you link an environment belonging to the AWS-DE region, then the linked AWS-DE environment will not be listed under the current environment drop down list inside the webMethods.io Integration tenant.

Adding and managing stages

You can add new stages and then assign them to the relevant environments. To do so, follow the steps given below:

This will add the specified stage for your tenant.

Managing environments from tenant

If the Environments option is disabled for you by your tenant administrator in Software AG Cloud, then on clicking the Manage Environment option, you will be redirected to the Manage Environments screen in your webMethods.io Integration tenant.

Registering a new environment

You can register environments for your tenant. To do so, follow the steps given below:

This will register the specified tenant as an environment in your tenant.

Note: If you have registered the same environment in Software AG Cloud as well as in your webMethods.io Integration tenant, then in the Current Environment drop down list, it will appear under the stage it is assigned to in Software AG Cloud and not under the Default environments’ list.

Managing Environments

When you navigate to the Manage Environments screen, you can see the list of all environments associated with your tenant. On this page, you can see the following details:

Once this is done, you can start creating projects and publishing them to other environments.

Managing legacy environments

If the Environments option is enabled for you by your tenant administrator in the Software AG Cloud, only then you can view the Manage Legacy Environment option under the Current Environment drop down list.

When you click on it, it will take you to the Manage Environments screen where you can see the list of legacy environments registered in your webMethods.io Integration tenant. From here, you can edit the environment details or delete the environments.

Note: If ‘Environments’ is enabled for you in Software AG Cloud, then you won’t see the Register Environmentbutton on this screen. In such a scenario, you will need to navigate to Software AG Cloud to create new environments.

Working with Publishes

The process of creating projects and adding workflows to a project remains the same as before.

For example, let’s say we have a Demo Project 1 in our tenant which we want to publish to another. This project contains 5 workflows as shown below:

Note: Notice that the Webhook - Send an Email workflow contains error(s) while the rest of the workflows are configured correctly.

  1. Once you are done creating workflows inside your projects, navigate back to the Projects dashboard, locate the project you want to publish, and click on the vertical ellipsis icon placed at the right side of the project card.

  2. Select the Publish Project option from the list of options that appear.

    You will be redirected to the Publish Project Screen, where you will be prompted to configure some project settings before publishing the project.

  3. Select the assets to be published

    While publishing a project, you need to specify which of the assets (workflows, flows, SOAP APIs, and REST APIs) available in the project should be published along with it.

    In the Select Assets screen, you will see the list of all assets available in your project.

    Note: Only error-free assets of your project will be displayed on the screen. Any assets containing error(s) cannot be published to another environment.

    If you check the Assets checkbox, all the assets of your project will be published. You can alternatively select specific assets to be published.

    1. To do so, click on the drop down icon given beside the asset type. For the purpose of our example, we will click the drop down icon given beside the asset type - workflow.

      You will see the list of workflows available under the selected project. As previously mentioned, since the Webhook - Send an Email workflow contains error(s), it is not displayed in the workflow list.

    2. Now, select the workflow(s) you want to publish along with the project. You can select specific workflows by checking respective checkboxes, or all workflows by selecting the Workflows checkbox.

    3. Once this is done, click Next.

      This will take you to the Confirm Dependencies screen.

  4. Confirm asset dependencies

    On this page, you can view the list of selected assets and their dependent assets (if any) which will be published to the specified environment. If you have not selected an asset for publishing, but its dependent on another asset which is selected for publishing, the dependent asset will still get published.

    In our example, the Runflow workflow calls the Subflow Box workflow during its execution, which means the Subflow Box workflow is dependent on Runflow workflow (know more about how Run Workflow action works).

    Previously, while selecting assets, we had not selected the Subflow Box workflow for publishing. But since it’s dependent on the Runflow workflow which is selected for publishing, the Subflow-Box workflow will get published by default.

    Once you have verified the assets to be published, click Next.

  5. Add publish settings

    1. Once you have selected and confirmed the assets to be published, add the remaining settings such as publish name, description, and the environment on which you want to publish.

      Note: Only environments that you have registered with your tenant will be available in the Select Environment drop down list.

      When you select the environment on which you want to publish the project, you will be shown the username associated with the selected tenant and prompted to enter the password for the same.

      Note: If the environment to which you want to publish a project has already added your environment under Allow users, then you will be prompted to enter the password in the above step.

    2. Once this is done, click Publish.

      With this, your project is successfully published to the specified environment (tenant).

      Now, when you check the destination environment (tenant), you will see the published project listed in the Projects dashboard.

Working with Deployments

Projects published to your environment are called Deployments. You can access these deployments, and configure and deploy them to start using the workflows within.

  1. Deploy the first deployment associated with the project.

    When any project is published to your tenant for the first time, you will see a project card associated with it as shown below:

    • Deploy:Click this icon to start configuring the deployment

    • Project name: The Name of the deployment

    • Workflow count:Total number of workflows available in the deployment

    • Notification:Message notifying the name of the tenant from which the project was published

      1. Click on the Deploy icon. You will be redirected to the Deploy Project screen from where you can configure the deployment settings.

        • Name: Provide a unique project name for the deployment.

      2. Once this is done, click Save and Continue. This will redirect you to the Configure Accounts screen.

  2. Configure required accounts.

    You will see the list of actions being used in the workflows inside the current deployment.

    Note: You can optionally skip this step by clicking on Next. If you do so, you will have to manually configure the relevant accounts before executing the workflow.

    1. Specify the accounts to be used to execute the flow/workflow along with the values for the dependent lookup fields.

    2. Once this is done, click Next. This will take you to the Configure Triggers screen.
  3. Configure required triggers.

    You will see the list of triggers being used in the workflows inside the current deployment.

    Note: You must configure all triggers displayed on this screen in order to proceed to the next step.

    1. Once you have specified the trigger service account to be used to execute the trigger, along with the values for the lookup fields (if any), click Next. This will take you to the Configure Parameters screen.
  4. Configure required parameters

    If your project contains any parameters, you can view and edit the value of such parameters through this screen.

    Note: You must configure all parameters displayed on this screen in order to deploy the project.

    1. To do so, click on the vertical ellipsis icon and click the Edit Parameter option, and edit the parameter value.

    2. Once this is done, click Deploy.

      With this, the project published by another tenant is successfully deployed in your tenant.

      Now when you check your Projects dashboard, you can see the Project card associated with the deployed project and use the workflows withtin as you would normally do.

    3. Note:

      • To ensure data security, all deployed workflows containing a webhook will by default have the webhook authentication method as ‘Tenant Credentials’ irrespective of the webhook authentication method configured in the published workflow. You can optionally change the webhook authentication method as per your requirements while configuring the deployed workflow.
      • If the deployed workflow contains a webhook, its associated payload data will not be retained. You will need to add the webhook payload data while configuring the deployed workflow.
  5. Manage subsequent deployments

    Each time the source environment publishes a new version of the same project to your environment, a new deployment for the same is made available in your Projects dashboard.

    So, for example, let’s say the source environment adds one more action to the ‘Trello - Send and Email’ and ‘Runflow’ workflow of the Demo Project 1 project and re-publishes the project with the same settings to the same destination environment.

    Note: The process of re-publishing the project remains the same as publishing the project.

    In this case, when you login to the destination environment, you will see the project card similar to the one given below:

    The notification on the card specifies that a new deployment for this project is currently available, which you can configure and deploy to view the latest updates.

    1. Click on the Project card, to start configuring the latest deployment. You will be taken to the project workflows where you will be prompted to confirm whether you want to update the existing project as per the latest deployment.

    2. Click on Yes, to confirm update. This will take you to the Deployments screen from where you can view and manage the deployments associated with this project.

      From here, you can view the details of all existing deployments, along with the option to deploy a specific deployment.

  6. Configure a new deployment of the same project.

    1. To deploy a specific deployment available for a project, click on the Deploy option given against the relevant deployment.

      A new screen will appear where you will be prompted to specify the relevant action/trigger accounts, lookup values, and parameter values based on the changes made in the deployment.

      In our example, we have added a new Slack action to the ‘Trello - Send an Email’ and ‘Runflow’ workflow. Based on this change, when you publish this project to the destination environment, you will be prompted to specify the Slack account to be used to execute the newly added Slack action.

      You can optionally view and change the previously added accounts associated with the workflow actions by clicking the drop down icon given against the previously configured accounts.

    2. Once you have specified the relevant connector account details, click Next.

      If the deployment contains any trigger-related changes, you will be prompted to specify the accounts for triggers and dependent lookup values (as applicable). If it doesn’t, you will see a screen similar to the one shown below:

    3. In such cases, you can optionally change the account associated with the trigger service and then click Next.

    4. Once you have added all the relevant details, click Deploy. This will deploy the specified deployment, by overwriting the changes of the previous deployment.

      The next time, a new deployment for the same project is made available to your tenant, your Deployments screen will look similar to the one given below: