Know how to create and manage projects, add Workflows and FlowServices to projects, work with APIs, connectors, and recipes, and how to manage project-level authorizations, connections, webhooks, triggers, and parameters.
Create a new project
A project corresponds to a folder or a container for organizing your workflows and FlowServices. They hold all the assets created by the user, along with the configurations associated with the workflows and FlowServices inside a tenant. It comes second (after tenant) in the hierarchy of entities in webMethods.io Integration.
Once you log in to your tenant or webMethods.io 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 FlowServices inside this project.
You can create as many projects as you want. webMethods.io 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.
Working with projects
Projects are divided into six sections such as:
Let’s now understand these sections:
Projects contain workflows. You can either create new workflows or import workflows from Recipes.
1. Creating new workflows
Select the Create Blank Flow option to create a workflow using the ready-to-use actions and triggers supported by webMethods.io Integration. Read more on creating first workflow.
2. Adding workflows from recipes
Recipes include several pre-configured, ready-to-use workflows. Some of these workflows are added to the Recipes by webMethods.io Integration developers, while others are added by the webMethods.io Integration users. You need to import them to your webMethods.io Integration account to start using them. Imported workflows are added to the Default project of your account or tenant.
3. 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.
- 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 FlowService, 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.
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.
Note: Workflows containing custom connectors that are only available in a particular tenant, cannot be exported to other tenants. When you try to export such workflows, you will get the following error:
“Cannot export this workflow as the associated CLI app is not published globally. Please publish the app first, and try again.”
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.
This will import the workflow to the specified project.
You can alternatively import the workflow to My recipes section of your tenant.
To do so, navigate to the Recipes tab and click the filter icon.
Click the My recipes option from the list of options that appear.
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.
- 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 FlowService, 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.
4. Workflow versioning
Whenever you make changes to your workflow and save it, a new version of your workflow is created. webMethods.io 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.
You can now use FlowServices 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 FlowServices to know more.
The Connector section has four subsections located on the left side of the screen. These subsections, namely Predefined Connectors, REST Connectors, SOAP Connectors, On-Premises Connectors and Flat File Connectors, allow you to perform different operations:
Predefined Connectors: webMethods.io Integration provides a set of predefined and configurable connectors, allowing you to connect to a particular SaaS provider.
REST Connectors: You can define REST Resources and Methods and create custom REST connectors. You can invoke a REST API in a FlowService by using a REST Connector.
SOAP Connectors: 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 FlowService by using a SOAP Connector.
On-Premises Connectors: On-Premises applications uploaded from on-premises systems are listed in the On-Premises Connectors page.
Flat File Connectors: Flat File connectors created in webMethods.io Integration.
You can manage your workflow and FlowService configurations through the Configuration section. This section has three subsections on the left side of the screen:
This subsection contains a Certificate page to add a new Keystore and Truststore.
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.
webMethods.io 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, webMethods.io 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 webMethods.io 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 webMethods.io 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 webMethods.io 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 webMethods.io 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 webMethods.io Integration navigation bar, click Projects > Select a Project > Configurations > General > Certificates > New Certificate > New Keystore.
To add a Truststore, from the webMethods.io Integration navigation bar, click Projects > Select a Project > Configurations > General > Certificates > New Certificate > New Truststore.
webMethods.io 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 webMethods.io Integration.
The default, certificate file format for the webMethods.io 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 webMethods.io 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. Software AG does not provide its own set of keystore utilities for creating keystore files.
To add a Keystore
From the webMethods.io Integration navigation bar, click Projects > Select a Project > Configurations > General > Certificates > New Certificate > New 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.
webMethods.io 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.
webMethods.io 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 webMethods.io Integration navigation bar, click Projects > Select a Project > Configurations > General > Certificates > New Certificate > New 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.
This subsection contains the following options:
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.
You can manage the Webhooks being used in your project workflows through the Webhooks tab. To do so, click on Webhooks. Here, you can see the list of each workflow in which webhook is being used, along with its corresponding webhook URL. You can also copy or reset the webhook URL, or add authentication to it by clicking on the corresponding icons. Know more about Webhooks management.
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.
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.
This subsection contains the following two 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.
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 FlowService.
Projects published to your environment are called Deployments. This section houses all the details of the deployed projects.