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:

Environments - Tenants from which and to which the projects are published.

Publishes - Projects published by the source environment

Deployments - Projects made available in the destination environment

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:

List of linked environments and their assigned stage

In the first section, you will see the names of all environments linked with your current environment and the stage assigned to them. You can click an environment name in this list to navigate to that environment.
Option(s) to manage environments

In the second section, you will see the following options to manage your environments:
- Manage Environments: To manage recently registered environments.
- Manage Legacy Environments: To view and manage previously registered environments in IBM webMethods Integration tenant.

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:

Open user environment: Click this icon to navigate to the selected environment in the current tab.
Delete environment: Click this icon to delete the selected environment.
Edit environment: Click this icon to modify the details of the selected 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:

Click on the Stages tab.

Here you can see the list of existing stages along with their description.

To add a new stage, click the Add stage button and enter the following details in the window that appears:
- Stage Name:Name of the stage you want to add.
- Description: Description for the stage you want to add.

Once this is done, click Save.

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:

Click the Register Environment button.

Note

Only pre-existing tenants can be created as environments for your default environment. So ensure that you create a tenant first (sign up for one here) before starting the environment creation process.

Enter the following details in the window that pops-up:
- Name:Enter a display name for the tenant you want to register as the environment.
- Tenant URL: Enter tenant URL of the tenant you want to register as environment.
  For example, https://sample.int-aws-us.webmethods.io
- Username: Enter the username associated with the tenant you want to register as environment.

Once you have added the details, click Save.

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:

Name:Name of the environment.
URL:URL associated with the environment.
Username:Username associated with the environment.
Action(s):Control options to modify or delete the environments
- Edit: Edit the configuration settings associated with the environment.
- Delete: Delete the selected environment.

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:

You can publish your integration projects, making them available to other users who need to view, use, or further develop the solutions. This is particularly useful for team collaboration and multi-departmental projects.
Published projects can be easily deployed across different environments, such as development, testing, and production. This simplifies the process of moving projects through various stages of the lifecycle.

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
Confirm dependencies
Publish settings

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:

Assets that contain errors are not listed as they cannot be published to another environment.
Assets are listed based on the user’s access privileges. For example, User A selects workflow A as an asset and publishes a project. User B selects workflow B as an asset and publishes the same project. The next time they try to republish the project, on the Select Assets page, only workflow A appears as a preselected asset for user A, and only workflow B appears as a preselected asset for user B.

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

Ensure that the project is ready to publish.
- Verify the configuration and correctness of the integrations.
- Ensure all required resources (like API endpoints, connectors, and services) are properly set up.
- Test the integrations to ensure they work as intended.
Ensure you have the destination environment details such as username and password.

Basic Flow

Log in to your tenant.
Go to the Projects dashboard and locate the project you want to publish.
Click the vertical ellipsis icon available in the bottom right of the project card. A menu appears.
Select Publish Project. The Publish Project wizard appears.
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.
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.
Click Next. The Publish settings page appears.
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.
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:

Publishing: Taking the current state of the project (including all configurations, settings, and assets) from one environment.
Deploying: Moving this published project into another environment, like testing or production.
Activation: Ensuring that all the necessary services, APIs, and workflows are active and operational in the new environment.

Key considerations post deployment include:

Environment-specific Configurations: Adjusting configurations that might differ between environments, for example, database connections, API keys, or endpoint URLs.
Testing and Validation: Re-testing the project in the new environment to ensure that it works as expected.
Monitoring and Logging: Setting up monitoring to track the performance and operation of the deployed integration.

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.
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:

Deployment versions: Lists all deployments that were published to this environment from other environments in a tabular format. The Deploy button appears in the Actions column if that specific deployment is not yet deployed. Clicking on the Deploy button launches the Deployment wizard, which guides you through the process of deploying the project.
Publish history: Lists all deployments created under this environment and published to other environments.

Note

Only the most recent 50 publish history records are listed.

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
Triggers
Parameters

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
Previously Configured Accounts

Accounts to be Updated

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

You are deploying the workflow or flow service for the first time.
The connector action is newly added to the already deployed workflow or flow service.
If some configuration changes are made to the connector account at source after the initial deployment.

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
Previously Configured Triggered

Triggers to be Updated

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

You are deploying the workflow or Flow service for the first time.
The connector trigger is newly added to the already deployed workflow or Flow service.
If some configuration changes are made to the trigger account at source after the initial deployment.

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
Previously Configured Parameters

Parameters to be Updated

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

You are deploying the workflow or Flow service for the first time.
The parameter is newly added to the already deployed workflow or Flow service.
If changes are made to the parameter value at source before redeployment.

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

Log in to your tenant (destination).
Go to Projects dashboard. If a new deployment is available for a project, then a message appears on the project card.
Click the project card that has the deployment message. A confirmation messages appears.
Click Yes. The Deployments page appears listing all deployments.
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.
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.
Click Next. The Triggers page appears.

Note

You must configure all triggers displayed on this page to proceed to the next step.
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.
Click Next. The Parameters page appears.
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.
Click the View icon to view the masked value.
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.
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.

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

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.
In the Deployments page, you can view the details of all existing deployments, along with the option to deploy a specific deployment.
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: