Projects

A project corresponds to a folder or a container for organizing your assets. They hold all the assets created by the user, along with the configurations associated with the workflows and flow services inside a tenant. It comes second (after the tenant) in the hierarchy of entities in IBM webMethods Integration.

Know how to create and manage projects, add Workflows and Flow services to projects, work with APIs, connectors, and recipes, and how to manage project-level authorizations, connections, webhooks, triggers, and parameters.

Create a project

A project corresponds to a folder or a container for organizing your workflows and Flow services. They hold all the assets created by the user, along with the configurations associated with the workflows and Flow services inside a tenant. It comes second (after tenant) in the hierarchy of entities in IBM webMethods Integration.

Once you log in to your tenant or IBM webMethods Integration account, click on + to create a new project. In the dialog box that appears, enter a suitable name for the project that you want to create, and then click on Create. This will create a new project. You can now start creating workflows and Flow services inside this project.
You can create as many projects as you want. IBM webMethods Integration also provides a system-generated Default project in your tenant. You cannot edit or delete this Default project.

Note

Click here for information on how to manage roles and project permissions.

Edit a project

To edit a project, locate the project that you want to edit. Now, click on the vertical ellipsis icon (or three tiny dots) in the top-right corner of your project, and click on Edit. You can edit the name of the project from here.

Delete a project

To delete a project, locate the project that you want to delete. Now, click on the vertical ellipsis icon (or three tiny dots) in the top-right corner of your project, and click on Delete. Confirm delete action to permanently delete the project.

Publish a project

You can easily publish a project to a specified environment (tenant). Click here for information on how to publish projects.

Work with projects

Projects are categorized into the following sections:

Let us now understand these sections:

Integrations

This section offers access to two subsections, Workflows and Flow services, located on the left side of the screen. These subsections allow you to create, customize, and manage Workflows and Flow services.

Workflows

Projects contain workflows. You can autogenerate workflows using prompts, create workflows manually, or import workflows from Recipes.

Creating workflows using prompts

You can create a workflow by providing a relevant prompt. This feature is in beta phase and changes might be made to it in the future releases.

Enter the necessary prompt and click the View integration ideas button.

Add or modify description and click Get Suggestion.

Based on the provided description, IBM webMethods Integration suggests connector actions that can be used to create the required workflow.

Select the relevant connectors and click Create Workflow.

This creates the workflow structure on canvas. You can now configure, modify, and run the workflow as you would normally do.

Learn more about configuring workflows.

Creating new workflows

Select the Create Blank Flow option to create a workflow using the ready-to-use actions and triggers supported by IBM webMethods Integration. Read more on creating first workflow.

Adding workflows from recipes

Recipes include several pre-configured, ready-to-use workflows. Some of these workflows are added to the Recipes by IBM webMethods Integration developers, while others are added by the IBM webMethods Integration users. You need to import them to your IBM webMethods Integration account to start using them. Imported workflows are added to the Default project of your account or tenant.

Cloning workflows

You can clone a workflow and save it within the same project or to another project.

To do so, go to the project and click the vertical ellipsis icon on the relevant workflow card.

Click the Clone option from the list of options that appear.

A dialog box will appear on screen where you will be prompted to (optionally) rename the cloned workflow and select the destination project where you want to clone it.

Once you have specified the necessary details, click Clone. This will clone the selected workflow to the specified project.

Important

You can create a clone of a cloned workflow.
Editing a cloned workflow will not affect the original workflow from which it was cloned.
A cloned workflow, containing the Messaging action, placed within the same project will inherit all assets, configurations, and authorizations of the original workflow. However, cloning a workflow to a different project will copy items of the original workflow but not retain assets, configurations, and authorizations. You will need to configure the workflow for it to run successfully.
A cloned workflow, containing the Messaging trigger, placed within the same project or a different project will not retain any existing trigger configurations of the original workflow. You will need to provide the trigger configuration as well as authorizations for all relevant actions inside a cloned workflow for it to run successfully.
While a cloned workflow retains all the actions and configurations of the original workflow, it does not retain any existing trigger configurations or authorizations. You will need to provide trigger configuration as well as authorizations for all relevant actions inside a cloned workflow for it to be executed successfully.
To ensure data security, all cloned workflows containing a webhook will by default have the webhook authentication method as ‘Tenant Credentials’ irrespective of the webhook authentication method configured in the source workflow. You can optionally change the webhook authentication method as per your requirements while configuring the cloned workflow.
If the cloned workflow contains a webhook, its associated payload data will not be retained. You will need to add the webhook payload data while configuring the cloned workflow.
If your workflow contains a Flow service, it will also be automatically cloned along with the rest of the assets of the cloned workflow.
If you clone workflow A which calls workflow B, then workflow B (and all its assets) will also be automatically cloned along with workflow A.

Exporting workflows

You can export a workflow within same project or another project.

To do so, navigate to the project of which workflow you want to export, click the vertical ellipsis icon on the relevant workflow card, and then click Export option from the list of options that appear.

This will redirect you to a new screen where you will be prompted to provide the necessary details to export the workflow.

Once you have entered the relevant details, click Export. This will export the workflow to your local machine.

To import the exported workflow to any project, navigate to the project where you want to import the workflow and click Import button located at the top.

Provide the path for the exported file in the dialog box that appears, and click Open.

Enter the necessary details required to import the workflow in the next screen that appears and click Import.

Note

For exported workflows containing a Messaging connector, you will see only the Authorize Messaging field in the Import screen. The option to configure destinations or Messaging triggers will not appear in the Import screen. Continue importing the workflow and after importing, configure the Messaging trigger and destinations for the Messaging action in the canvas.

This will import the workflow to the specified project.

Note

All imported workflows are active by default in the destination project, irrespective of their original status in the source project. The only exception is when the trigger import fails or if the trigger is unconfigured. In such a scenario, the imported workflow stays inactive.

You can alternatively import the workflow to My recipes section of your tenant.

To do so, navigate to the Recipes tab, click the Filter icon, and choose My recipes. Here you will see the list of recipes imported to your tenant.

Click the Import button to import the intended workflow.

Provide the path for the exported file in the dialog box that appears, and click Open.

This will import the workflow to My recipes section. You can now import this recipe to the project of your choice by clicking the vertical ellipsis icon and selecting the Use Recipe option.

You will be prompted to specify the project to which you want to import the workflow. Select the project from the drop down list and click Done.

This will redirect you to a new screen where you will be prompted to provide the details such as authorizations and lookup values which are necessary to configure the workflow.

Once you are done, click Import. This will import the workflow to the specified project.

Important

To ensure data security, all imported workflows containing a webhook will by default have the webhook authentication method as ‘Tenant Credentials’ irrespective of the webhook authentication method configured in the source workflow. You can optionally change the webhook authentication method as per your requirements while configuring the imported workflow.
If the imported workflow contains a webhook, its associated payload data will not be retained. You will need to add the webhook payload data while configuring the imported workflow.
If your workflow contains a Flow service, it will also be automatically imported along with the rest of the assets of the imported workflow.
If you import workflow A which calls workflow B, then workflow B (and all its assets) will also be automatically imported along with workflow A.

Workflow versioning

Whenever you make changes to your workflow and save it, a new version of your workflow is created. IBM webMethods Integration maintains all the versions of your workflow, which allows you to view all the changes made to your workflow over time. You can also restore previous versions, making it the latest version. The workflow versions maintain the timestamp and the name of the account user, that is, when the workflow was edited by the account user.

View Version History

To view a previous version, open the required workflow on the canvas and click the Version History (clock) icon located at the bottom right corner. A new window will appear on your screen where you can see the list of all the previous versions with the timestamp when the workflow was created.

Rename or Delete Version History

To rename the version, hover on the version associated with the workflow that you want to rename, and click on the Edit icon. You can then rename the version as per your choice.

To delete a specific version, click on the Delete icon. You will be prompted to confirm your action. Click Yes. This will delete the specified version of the selected workflow.

Note

You cannot delete the current version.

Restore Version History

From the list of versions that appear, click on a timestamp to restore an earlier version of the workflow, and click on the Restore This Version button. This will restore the version of your workflow without changing the current configuration of the workflow.

Note

Every version that is restored is saved as a new version.

Flow services

You can now use Flow services to encapsulate a sequence of services within a single service and manage the flow of data among them, and create complex, advanced integration scenarios involving multiple application endpoints.

See Flow services to know more.

APIs

IBM webMethods Integration allows you to write integration logic to integrate different types of connectors. This logic can be exposed to the external world using REST APIs and SOAP APIs.

Events

This section showcases the supported event types available for your tenant. See Events to know more.

Connectors

Connectors are pre-built integrations that allow you to connect and interact with various third-party applications, databases, and services. These connectors enable seamless data exchange and workflow automation between IBM webMethods Integration and other systems. As part of the integration solution development, you must use and configure various connectors for data exchange between IBM webMethods Integration and other systems.

The connectors are categorized as follows:

Predefined: IBM webMethods Integration provides a set of predefined and configurable connectors, allowing you to connect to a particular SaaS provider.
REST: You can define REST Resources and Methods and create custom REST connectors. You can invoke a REST API in a flow service by using a REST Connector.
SOAP: Custom SOAP connectors enable you to access third-party web services hosted in the cloud or on-premises environment. You can also invoke a SOAP API in a flow service by using a SOAP Connector.
On-Premises: On-Premises applications uploaded from on-premises systems are listed in the On-Premises Connectors page.
Flat File: Flat File connectors created in IBM webMethods Integration.

The Connectors page under Projects displays all connectors used in a project’s integrations. You can manage these connections directly from the Connectors page without needing to open the integration to update the details. Thus, there are two ways to configure your connectors as follows:

Add and configure the connector directly while creating an integration.
Configure the connection in the Connectors page and use the connection details in an integration.

Configurations

You can manage your workflow and Flow service configurations through the Configuration section. This section has three subsections on the left side of the screen:

General

This subsection contains a Certificate page to add a new Keystore and Truststore.

Certificates

Keystores and truststores are files that function as repositories for storage of keys and certificates necessary for SSL authentication, encryption/decryption, and digital signing/verification services. Keystores and truststores provide added layers of security and ease of administration, compared to maintaining the keys and certificates in separate files.

Keystore and truststore files exist within the file system of your operating system, and since these are critically important files, you want to maintain them in a secure directory path. If either of these files cannot be located, authentication will be disabled and no connection with the server can be made. It is recommended that only users serving as administrators have access to these certificate files.

IBM webMethods Integration enables you to manage keys and certificates and stores its private keys and SSL certificates in keystore files and the trusted roots for the certificates in truststore files. Keystores and truststores are secure files with industry-standard file formats.

If you want to run services that submit HTTPS requests to other resources on the Internet, your server will be acting as a client and will receive certificates from these resources. In order for these transactions to work, your server must have copies of their public keys and signing CA certificates.

To identify a particular keystore or truststore file, or private key within a keystore, IBM webMethods Integration uses aliases. The use of aliases simplifies keystore and truststore management, because you do not need to enter the path information when specifying a keystore, truststore, or the private key.

For a IBM webMethods Integration component to be SSL authenticated, it must have a valid, authorized X.509 certificate installed in a keystore file and the private key and signing certificate for the certificate issuer (CA) installed in a truststore file.
The following figure illustrates these requirements and the relationship between the two files.

As shown in the above figure, the same truststore file can contain multiple trusted root certificates (public keys for the signing CAs). These trusted roots might be associated with numerous keystore files. A keystore file can contain the key pairs for multiple IBM webMethods Integration components, and the entire certificate chain required for a component’s authentication.

With a certificate chain, it is necessary to validate each subsequent signature in the list until a trusted CA certificate is reached. For IBM webMethods Integration, you must include the entire chain of certificates in a keystore and truststore. Also, any root CA certificates in use by clients must be in a IBM webMethods Integration truststore.

You can add, edit, delete, or view keystore and truststore aliases from the Certificates page (Projects > Select a Project > Configurations > General > Certificates) and can use them to secure your Accounts. See Accounts to learn what is an account, how it works, and how to create accounts for external web services.

To add a Keystore, from the IBM webMethods Integration navigation bar, click Projects > Select a Project > Configurations > General > Certificates > New Certificate > Keystore.

To add a Truststore, from the IBM webMethods Integration navigation bar, click Projects > Select a Project > Configurations > General > Certificates > New Certificate > Truststore.

Keystore

IBM webMethods Integration uses a special file called a keystore to store SSL certificates and keys. A keystore file contains one or more pairs of a private key and signed certificate for its corresponding public key. The keystore should be strongly protected with a password, and stored (either on the file system or elsewhere) so that it is accessible only to administrators.

You can upload a Keystore file to store SSL certificates and keys. From the Add Keystore Certificate window, you can create aliases for the Keystore, so that they can be referenced while creating an Account in IBM webMethods Integration.

The default, certificate file format for the IBM webMethods Integration keystore is JKS (Java keystore), the proprietary keystore implementation provided by Oracle. You can also use PKCS12, a commonly used and standardized certificate file format that provides a high degree of portability. Other keystore types can be made available by loading additional security providers.

You can create IBM webMethods Integration keystores at the command line using keytool, the Oracle Java certificate editor. You can also use other standard tools such as OpenSSL and Portecle. IBM does not provide its own set of keystore utilities for creating keystore files. For more information, see how to generate private and public key using Open SSL.

To add a Keystore

From the navigation bar, click Projects > Select a Project > Configurations > General > Certificates > New Certificate > Keystore.
Provide a name and description for the Keystore file.
In the Type field, select the Keystore file format. This is the certificate file format of the keystore file, which by default is JKS for keystores. You can also use PKCS12 format for a keystore.
In the Provider field, select the provider from the list of available providers. This is the provider that is used for the keystore type. The corresponding provider will be available in the provider list.
Click Browse to select the Keystore file.
In the Passphrase field, enter the passphrase for the Keystore file. The passphrase must have been defined at the time the Keystore was created.
Click Next to protect the Key Aliases with passphrases. A key alias is a label for a specific key within a Keystore. Enter a passphrase for each Key Alias found in the Keystore file, and then click Finish to upload the Keystore file. The uploaded Keystore file can be used while creating an Account. See Accounts to learn what is an account, how it works, and how to create accounts for external web services.

Truststore

IBM webMethods Integration uses a truststore to store its trusted root certificates, which are the public keys for the signing CAs. Although a truststore can contain the trusted roots for entire certificate chains, there is no requirement for the organization of certificates within a truststore. It simply functions as a database containing all the public keys for CAs within a specified trusted directory.

The default format for a truststore is JKS. You can create and manage JKS truststores at the command line using keytool, the Oracle Java certificate editor.

IBM webMethods Integration allows you to upload a Truststore file, which contains the trusted root of the certificate or signing authority (CA). From this screen, you can create aliases for the Truststore, so that they can be referenced while creating an Account for an Application.

To add a Truststore

From the navigation bar, click Projects > Select a Project > Configurations > General > Certificates > New Certificate > Truststore.
Provide a name and description for the Truststore file.
In the Type field, select the Truststore file format. This is the certificate file format of the truststore, which by default is JKS.
In the Provider field, select the provider from the list of available providers. This is the provider that is used for the truststore type.
Click Browse to select the Truststore file.
In the Passphrase field, enter the passphrase for the Truststore file. The passphrase must have been defined at the time the Truststore was created and is used to protect the contents of the Truststore.
Click Save to upload the Truststore file. The uploaded Truststore file can be used while creating an Account. See Accounts to learn what is an account, how it works, and how to create accounts for external web services.

Partner Certificate

IBM webMethods Integration allows you to add a certificate of a trusted partner. The Partner’s certificate contains a public key which is required to encrypt outbound request messages and verify the signature of inbound messages.

The certificate received by your trusted partner can be used while configuring accounts for certain connectors (currently only supported in AS2) to securely send and receive business data across the communication protocol.

To add a Partner Certificate

From the homescreen, click Projects > Select a Project > Configurations > General > Certificates > New Certificate > Partner certificate.
In the ‘Add partner certificate’ window that pops up, enter the following details:

Name: Provide a unique name for the Partner Certificate file. This field is only available on the Add Partner Certificate window. The value for this field cannot be edited through the Edit Partner Certificate page.
Description: Provide a summary of the Partner Certificate file.
Certificate: Click Browse to select the Partner Certificate file. The supported certificate formats are: .der, .cert, .cer, .crt

Once you have added the details, click Save to upload the Partner Certificate file. With this, the Partner Certificate file will be successfully created and added to the list of partner certificates in the Certificates screen.

The added Partner Certificate can be used while creating an account for an application. See Accounts to learn what an account is, how it works, and how to create accounts for external web services.

To edit a Partner Certificate

Navigate to the Certificates screen. On the Certificates screen, you will see a list of existing certificates.
Click on the vertical ellipsis icon given against the certificate you want to edit. From the options that appear, select Edit Partner.
You can now update relevant details in the Edit Partner Certificate window that appears. The Name field is only available on the Add Partner Certificate window. The value for this field cannot be edited through the Edit Partner Certificate window.

To delete a Partner Certificate

Navigate to the Certificates screen. On the Certificates screen, you will see a list of existing certificates.
Click on the vertical ellipsis icon given against the certificate you want to delete. From the options that appear, select Delete.
You will be prompted to confirm the delete action. Click Delete to permanently delete the selected Partner Certificate from the list.

Workflow

This subsection contains the following options:

Connections

The Connections tab houses the details of all application accounts being used in the workflows of your project. Using this tab, you can determine which application account is being used in an action of a particular workflow.

From here, you can also create new accounts, or edit or delete the existing ones. To do so, click on the arrow located at the left of the connector icon. To know more on how to create, edit, or delete accounts, click here.

Triggers

Through the Triggers tab, you can view the list of all triggers being used in your project workflows. It includes details such as, trigger application name, trigger name, trigger event name, and the workflow in which the trigger is being used. You can also edit and delete your existing triggers from this tab. Know more about Triggers.

Parameters

The Parameters tab lets you view, create, and modify the project-level parameters. When you create a parameter through this tab, it automatically becomes available in all workflows of the project. Similarly, if you modify a parameter, the changes are automatically reflected in all workflows. Know more about Parameters.

Flow service

This subsection contains the following options:

Reference Data

Reference data is data that defines the set of permissible values to be used by other data fields. It is a collection of key-value pairs, which can be used to determine the value of a data field based on the value of another data field.

See Reference Data to know more.

Document Types

A document type contains a set of fields used to define the structure and type of data in a document. You can use a document type to specify the input or output parameters for a Flow service.

See Document Types to know more.

Deployments

Projects published to your environment are called Deployments. This section houses all the details of the deployed projects.