Environments

The Environments 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 environment 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 environment management works:

    • Each IBM webMethods Integration tenant comes with a Default environment, which can be used to create projects and add flowservices/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 flowservices/workflows within.

      Note
      Any user who intends to perform asset promotion from one IBM webMethods iPaaS 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 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
  • If the Environments option is enabled for you by your tenant administrator in IBM webMethods iPaaS, you are directed to the Environment screen in IBM webMethods iPaaS where you can manage environments.


    Otherwise, you are directed to the Manage Envioronments screen within the IBM webMethods Integration tenant from where you can register and manage environments.

Managing environments from IBM webMethods iPaaS

If the Environments option is enabled for you by your tenant administrator in IBM Portal, then clicking the Manage Environment option, redirects you to the Environment screen in the IBM webMethods iPaaS.

Note
The option to create or link additional environments is available only in the trial accounts.

Update environments

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

Using the action icons you can also perform the following operations on each environment:

Create and manage stages

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

This adds the specified stage for your tenant.

Managing environments from tenant

If the Environments option is disabled for you by your tenant administrator in IBM webMethods iPaaS, then clicking the Manage Environment option, redirects you to the Manage Environments screen in your IBM webMethods Integration tenant.

Register a new environment

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

This registers the specified tenant as an environment in your tenant.

Note
If you have registered the same environment in IBM webMethods iPaaS as well as in your IBM webMethods Integration tenant, then in the Current Environment drop down list, it appears under the stage it is assigned to in IBM webMethods iPaaS and not under the Default environments’ list.

Update environments

On Manage Environments screen, you can see the list of all environments associated with your tenant with 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 IBM webMethods iPaaS, only then you can view the Manage Legacy Environment option under the Current Environment drop down list.

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

Note
If Environments is enabled for you in IBM webMethods iPaaS, then you will not see the Register Environment button on this screen. In such a scenario, you will need to go to IBM webMethods iPaaS to create new environments.

Working with Publishes

The Publish feature allows you to share the integration projects with others within your organization. This feature is designed to streamline collaboration, facilitate deployment, and ensure that integration solutions can be easily accessed and utilized by relevant stakeholders.

The key aspects of the publish feature are:

The publish project feature ensures that your valuable integration solutions can be effectively shared, maintained, and utilized across the organization.

Note
  • You must be an administrator to publish a project.

  • You cannot publish projects if you are logged using an external SSO application.

  • As reference data varies across different environments, you need to reconfigure the reference data as per the respective environment. So, if you are publishing a project that has a flow service with reference data, the reference data is not published along with the flow service. You are required to create the reference data in the destination environment.

Accessing Publish Wizard

You can publish a project using the Publish Project option available in the vertical ellipsis menu on the project card.

On clicking the Publish Project option, the Publish wizard opens that lets you to configure the project before publishing.

Publish Wizard

The Publish wizard contains the following pages:

Select assets

The Select assets page lists all assets that are available in the project. The assets are categorized based on their type such as workflows, flow services, messaging subscribers, or REST APIs. You can select either all or specific assets that must be published. The assets are listed based on the following guidelines:

Confirm dependencies

The Confirm dependencies page lists all dependent assets for the assets that were selected in the Select assets page.

Dependent asset is the asset that is being used by your asset (main) that is selected for publishing. For example, if workflow A (main) calls workflow B during its execution, this means that the workflow A is dependent on workflow B. Hence, workflow B is considered as dependent. So, even if you have not selected assets in the Select assets page, all dependent assets are considered by default for publishing along with the main asset. Thus, the Confirm dependencies page provides a complete view of all assets you intend to publish in one place.

Publish settings

The Publish settings page allows you to provide details about the publish action such as name, description, and the environment on which you want to publish. These details can be helpful for your future references.

Note
  • Only the environments that you have registered with your tenant are listed in the Publish settings page.

  • The destination environment must be on the same or higher version as compared to the source environment. If the destination environment is on a lower version than the source environment, an error appears.

  • To publish projects across regions, both the source and destination regions must be on the version 11.0.5.

Publishing Projects

Example

Assume that there is a Demo Project 1 in your tenant that you want to publish to another tenant. This project contains the following integrations as follows:

Assume, that the Webhook - Send an Email workflow contains errors while the rest of the integrations are configured correctly.

Before you Begin

Basic Flow

  1. Log in to your tenant.

  2. Go to the Projects dashboard and locate the project you want to publish.

  3. Click the vertical ellipsis icon available in the bottom right of the project card. A menu appears.

  4. Select Publish Project. The Publish Project wizard appears.

  5. Do the following in the Select Assets page to select the assets that must be published:

    a. Click the drop-down icon given beside the asset type. In this example, the drop-down icon beside the workflows is clicked.

    All workflows available under the selected project are listed. The Webhook - Send an Email is not listed as the workflow contains errors.

    b. Select the workflows you want to publish. You can select specific workflows by checking respective checkboxes, or all workflows by selecting the Workflows checkbox.

    c. Click Next. The Confirm dependencies page appears listing all selected assets along with their types and dependencies.

  6. Verify the assets and their dependencies.

    In this example, the Runflow workflow calls the subflow Box workflow during its execution, which means that the Subflow Box workflow is dependent on the Runflow workflow. Previously, while selecting assets though the Subflow Box workflow was not selected for publishing, but as it is dependent on the Runflow workflow which is selected for publishing, the Subflow Box workflow is published by default.

  7. Click Next. The Publish settings page appears.

  8. Enter the following details in the Publish settings page:

    a. Publish name: Name of the publish action.

    b. Description: Short description about the publish action.

    c. Select Environment: Destination environment on which you want to publish. The username and password fields appear.

    d. Password: Password that is associated with the user name.

    If the environment to which you want to publish a project has been already added under > Environments > Allow users in IBM webMethods iPaaS, then the password prompt does not appear.

  9. Click Publish. The project is successfully published to the specified environment. Now, if you check the destination environment, you can see the published project listed in the Projects dashboard.

You can publish the same project to your destination environment any number of times.

Working with Deployments

Deployment is the process of moving your integration solution from one environment to another environment. For example, from your development environment to test environment or production environment.

Projects published to your environment are called Deployments. Deployment ensures that the integration project is available in the specified environment and ready for actual use. Deployment includes:

Key considerations post deployment include:

Note
  • Deploying a SOAP connector with around 100 operations takes about 3 minutes. If there are many operations or the SOAP configurations are complex, it is recommended to plan the deployment in multiple phases, to ensure a smooth process.
  • For projects involving custom connectors, the connector must be deployed using CLI (command line interface) to the target environment and then the integration must be deployed.
  • All applications used in an integration must be configured in the target environment and then the assets must be deployed from the existing environment to the target environment.
  • Assets like reference data, project variables, vault variables, and certificates are not automatically deployed with the associated deployment. You must manually add these assets to the target environment.
  • On-premise connector must be deployed from the on-premise server and configured with the account name and other details in the target environment as in source environment.
  • Workflows using flow services cannot be deployed directly. The flow service references must be removed from the workflow and assets must be deployed. After deployment, references must be added to connect the flow service to the workflow.
  • The production systems can have more than one instances serving requests for high availability. Any deployment or editing in the production system can impact running workflows, flow services, APIs, and so on. Execution failures may occur when instances are updated with these latest changes. The system tries to detect and minimize these failures as much as possible; however, failures can still occur, especially with long-running executions under certain circumstances.

    For optimal system performance, perform any publish-deploy and design-time activities in the production tenant during low-traffic time intervals and in a planned way to avoid any disruptions. Additionally, conduct original development, which requires frequent changes in the flow, in lower tenants (development tenant), and then promote them to the production tenant after thorough testing. This approach lets you minimize editing of assets on production, preventing the system from entering the scenario described above.

Accessing Deployments Tab

When any project is published to your tenant for the first time, you can see a project card associated with the deployment as follows:

Open the project that must be deployed, and the Deployments tab appears that lets you to complete the deployment process.

Deployments Tab

The Deployments tab consists of the following main sections:

Clicking the View assets link under the Actions column lets you view the list of assets, asset type, and their dependencies for each version.

Clicking the Publish project button launches the Publish project wizard, which guides you through the process of publishing the project.

Deployment Wizard

The Deployment wizard appears when you click the Deploy button under the Project > Deployments page. The Deployment wizard contains the following pages:

Accounts

The Accounts page lists the connectors being used in the integrations for the current deployment. You can configure the relevant accounts so that the integrations run without any errors. Otherwise, the integrations might fail due to accessibility or authentication failure issues.

There are two sections on the Accounts page as follows:

Accounts to be Updated

A connector is listed under Accounts to be Updated section for one of the following reasons:

You can create a new account or use an existing account for the specified connector and provide values for any dependent lookup fields to execute the relevant action.

Previously Configured Accounts

A connector is listed under Previously Configured Accounts section if it is part of an already deployed workflow or flow service and no configuration changes are made to the connector account prior to redeployment.

You can keep the previous account configurations as they are or specify a different account and provide dependent lookup field values to execute the relevant action.

Note
  • You are not prompted to configure accounts for the following connector types. These connector account configurations are required to be done after the deployment.

    • SFTP Connector
    • FTP Connector
    • SMTP Connector
    • SOAP Connector
    • REST Connector


  • You can publish a flow service that has a custom connector (SOAP or REST) if that connector does not exist in the destination environment. However, after deployment, you need to create an account and then reconfigure the flow service.

Triggers

The Triggers page lists the connectors that have been configured with triggers for the current deployment. You can configure the relevant accounts so that the integrations run without any errors. Otherwise, the integrations might fail due to accessibility or authentication failure issues.

There are two sections on the Triggers page as follows:

Triggers to be Updated

A connector is listed under this section for one of the following reasons:

Previously Configured Triggers

A connector is listed under this section if it is part of an already deployed workflow or Flow service and no configuration changes are made to the connector account prior to redeployment.

Parameters

The Parameters page lists all parameters that are used in the project. There are two sections on the Parameters page as follows:

Parameters to be Updated

A parameter is listed under this section for one of the following reasons:

Previously Configured Parameters

A parameter is listed under this section if it is part of an already deployed workflow or Flow service and no changes are made to the parameter value at source prior to redeployment.

Deploying Projects

  1. Log in to your tenant (destination).

  2. Go to Projects dashboard. If a new deployment is available for a project, then a message appears on the project card.

  3. Click the project card that has the deployment message. A confirmation messages appears.

  4. Click Yes. The Deployments page appears listing all deployments.

  5. Click Deploy. The Configure Accounts page appears.

    Note
    You can optionally skip this step by clicking Next. If you do so, you must manually configure the relevant accounts before running the workflow or flow service.
  6. Select an account from the existing accounts for the specified connector and provide values for any dependent lookup fields to run the relevant actions. Or,

    You can keep the previous account configurations as they are or specify a different account and provide dependent lookup field values to execute the relevant action.

    You can create a new account by clicking the + icon.

  7. Click Next. The Triggers page appears.

    Note
    You must configure all triggers displayed on this page to proceed to the next step.

  8. Select an account from the existing accounts for the specified connector and provide values for any dependent lookup fields to run the relevant actions. Or,

    You can keep the previous account configurations as they are or specify a different account and provide dependent lookup field values to execute the relevant action.

    You can create a new account by clicking the + icon.

  9. Click Next. The Parameters page appears.

  10. Click the Edit icon to provide a parameter value.

    If the parameter value is changed at source before redeployment, it appears as a masked value.

  11. Click the View icon to view the masked value.

  12. If you want to change the parameter value, click the Edit icon to enter a new value and if you want to preserve the existing value, select the Overwrite parameter with source value checkbox.

  13. Click Deploy. The project published by another tenant is successfully deployed in your tenant. Now, if you check your Projects dashboard, you can see the project card associated with the deployed project and you can use the integrations as you would normally do.

Note
  • To ensure data security, by default, all deployed workflows containing a webhook includes 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 is not retained. You must add the webhook payload data while configuring the deployed workflow.

Manage subsequent deployments

You can publish a project to your destination environment any number of times. The process of re-publishing the project remains the same as publishing the project. For more information about publishing project, see Working with Publishes.

Each time you publish a project, a new version of the same project is published to your source environment. At the same time, a new deployment for the published version of the project is made available in your Projects dashboard as follows:

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.

For example, let us say that you have an integration Trello - Send and Email workflow in the Demo project. You have added one more action and republished the project with the same settings to the same destination environment.

  1. Click the new deployment project card. The Projects page appears, and you can see an information message stating about new deployment.

  2. Do one of the following actions:

    • Click Yes to confirm the update and proceed to step 3.

    • Click No to abort the deployment and continue with the existing deployment.

  3. In the Deployments page, you can view the details of all existing deployments, along with the option to deploy a specific deployment.

  4. Deploy the project. For more information about how to deploy, see Deploying Projects.

Configuring a new deployment of the same project

Let us say that you have integrations, Trello - Send and Email and Runflow, in the Demo project. You have added one Slack action and republished the project with the same settings to the same destination environment. Based on this change, when you publish the Demo project to the destination environment, a prompt provides the Slack account details that must be used to run the newly added action.

You can specify the relevant details and proceed with the next deployment steps. For more information about how to deploy, see Deploying Projects.

Similarly, if the deployment contains any trigger or parameter related changes, you are prompted to specify the details and dependent lookup values as applicable.

After you have added all the relevant details and deployed the project, the new deployment changes are considered, and the previous deployment values are overwritten.

Next time a new deployment for the same project is made available to your tenant, your deployments screen look similar as follows: