Access your on-premises applications securely using the webMethods.io Integration platform. Pass data easily from a Workflow or a FlowService to an on-premises application and get processed data back to the Workflow or FlowService.
Hybrid connectivity allows you to establish a secure connection between webMethods.io Integration and your server behind the firewall. As a result, you can consume data from your on-premises applications and use those applications in your Workflow or FlowService.
This section describes how to configure Integration Server as an on-premises server for use with webMethods.io Integration. It contains information for administrators who configure and manage on-premises Integration Servers and for application developers who want to create services that will be accessed through webMethods.io Integration.
An on-premises Integration Server is any Integration Server that is configured to share service metadata and enables the execution of those services by integrations defined in webMethods.io Integration. The service metadata uploaded from an on-premises Integration Server provides the accounts and applications required to create integrations in webMethods.io Integration.
webMethods.io Integration has environments and each environment has a different endpoint. You can configure one on-premises Integration Server to an environment.
Notes
- On-premises Integration Server version 10.3 or later with the latest fix will work with webMethods.io Integration for hybrid connectivity.
- The maximum size limit for hybrid messages that can be transported between on-premises webMethods Integration Server and webMethods.io Integration is 25 MB.
The Integration Server Administrator is an HTML-based utility to administer the webMethods Integration Server. It allows you to monitor server activity, manage user accounts, make performance adjustments, and set operating parameters. You can run the Integration Server Administrator from any browser-equipped workstation on your network. The Integration Server Administrator is a browser-based application that uses services to accomplish its work.
The Settings page under webMethods Cloud in Integration Server Administrator allows you to specify the login and location details of webMethods.io Integration.
Under Settings, specify the user name for the user account on webMethods.io Integration, the password identified in the user account for the user name, and the URL of webMethods.io Integration with which to share accounts and applications created on the on-premises Integration Server.
The URL is of the following format: https://sub-domain.domain-name, for example, https://sample.prod-int-aws-us.webmethods.io.
If you click Update Settings, Integration Server connects to webMethods.io Integration specified in the webMethods Cloud URL and downloads the configuration information that is required to receive any incoming requests.
Notes:
If you are using hybrid connectivity and when you update the on-premises settings for the first time after the webMethods.io Integration upgrade, restart the on-premises webMethods Integration Server. After restart, upload the on-premises account to resume hybrid connectivity. This is applicable for all the on-premises Integration Servers connecting to webMethods.io Integration.
If you have allowed the Cloud Universal Messaging (UM) hostname in the firewall, you have to also allow the new UM hostname along with the old one. For more information on IP addresses, see Software AG Cloud Regions.If Software AG has provisioned dedicated UMs for your tenants, and the shared UM queues, if applicable, are imported to the new dedicated UMs, ensure that you update the settings so that hybrid integrations work with the newly provisioned dedicated UMs.
You can update the webMethods.io Integration Server’s password using one of the following approaches:
Approach 1: Pausing webMethods.io Integration FlowServices
Approach 2: Without Pausing webMethods.io Integration FlowServices
Notes:
Approach 1 is the recommended method.
In both approaches, the on-premise Integration server need not be restarted.
Software AG recommends using Approach 1 to ensure that the running FlowServices do not encounter an error.
Suspend the running webMethods.io integration FlowServices.
Update the tenant password in webMethods.io Integration.
Update the on-premises server tenant password (tenant configuration under WmCloud in Integration Server Admin portal) to match with the new webMethods.io.integration server’s password. This step must be repeated for every affected on-premises server.
Disable and re-enable the cloud accounts for the affected on-premises servers.
Resume webMethods.io Integration FlowServices.
You must perform all of these steps immediately before the current running service calls to on-premises server timeout. The default timeout value is 60 seconds. Otherwise, there is a chance that the webMethods.io Integration FlowServices may encounter errors due to service timeout.
Disable the cloud accounts used in webMethods.io Integration to prevent FlowServices from using on-premises services. The accounts are configured in the WmCloud configuration menu for each on-premises server that connects to webMethods.io Integration.
Update the tenant password in webMethods.io Integration.
Update the on-premises server tenant password (tenant configuration under WmCloud in Integration Server Admin portal) to match with the new webMethods.io.integration server’s password. This step must be repeated for every affected on-premises server.
Re-enable the cloud accounts.
When you create an on-premises account on the on-premises Integration Server, you specify the connection parameters that the on-premises Integration Server uses to access webMethods.io Integration for which you defined the settings. You enable accounts on the on-premises Integration Server to allow them to serve any requests that originate from webMethods.io Integration.
If an account is disabled on the on-premises Integration Server, any requests sent from webMethods.io Integration will time out depending on the time specified in the Request Timeout field in Account Settings.
You can upload accounts in two ways, as part of an application, or individually, separate from applications. In order to upload an account as part of an application, you must first create the account and then associate it with the application when you upload it to webMethods.io Integration.
Upload accounts separately from applications in the event when you need to override the settings of a previously uploaded account. You might do this if you associate an account while uploading an application to webMethods.io Integration and later change the account details. This way, you can change the account details without having to upload the entire application.
To create an account on an on-premises Integration Server, in the webMethods Cloud menu in Integration Server Administrator, click Accounts > Create On-Premise Account.
Complete the following fields:
After an account is created, you upload it to webMethods.io Integration so that it can be used to execute services on the on-premises Integration Server. If you change or edit the account after it is uploaded to webMethods.io Integration, you must upload it again for the changes to become effective. If you want to upload the account as part of an application, use the procedure described in the Uploading Applications section.
To upload accounts to webMethods.io Integration, in the webMethods Cloud menu in Integration Server Administrator, click Accounts.
Click one of the following icons in the Upload column for the account you want to upload.
- New or has been edited since the last time it was uploaded to webMethods.io Integration. For a new account, this icon indicates that the account has not been uploaded to webMethods.io Integration. For an account that already exists on webMethods.io Integration, this icon indicates that the account on the on-premises Integration Server is not synchronized with the one on webMethods.io Integration.
- Synchronized with the account that has already been uploaded to webMethods.io Integration.If an account gets disabled during an upload, Integration Server uploads the account successfully and notifies you to enable the account to serve any requests originating from webMethods.io Integration. When accounts are disabled, webMethods.io Integration cannot execute services on the on-premises Integration Server. After the account is enabled, Integration Server automatically establishes connectivity with webMethods.io Integration at start up and is ready to serve any requests originating from webMethods.io Integration. If you have not enabled an account while creating it, you can enable the account by going to Accounts and clicking No to enable the account under the Enabled column.
When you no longer need an account, you can delete it. Deleting an account from the on-premises Integration Server also deletes the account from webMethods.io Integration. If the account is in use by any of the integrations in webMethods.io Integration, the delete operation fails. To delete an on-premises account, click Accounts and then click the delete 
icon.
Each enabled account has an active listener on the on-premises Integration Server. The listener listens for requests from webMethods.io Integration to execute services on the on-premises Integration Server. To ensure that each enabled account has an active listener, Integration Server uses a monitoring thread that executes at a specified interval. If the monitoring thread finds a listener that is not running, the monitoring thread attempts to start the listener.
Additionally, the monitoring thread looks for listeners that have not processed any requests in a specified period of time and recreates the listeners that have been idle for too long. Integration Server stops and restarts all the on-premises account listeners when you click Update Settings on the webMethods Cloud > Settings page. The monitoring thread exists only if the on-premises Integration Server has at least one enabled account.
A group of services that you share with webMethods.io Integration is called an application. On-premises applications are created on the on-premises Integration Server and uploaded to webMethods.io Integration. webMethods.io Integration executes any service hosted by an on-premises Integration Server.
When you share services in an application, you are sharing the metadata for the service. For Integration Server services, the metadata you share is the service name, service signature, display name, and service comments. You can then create integrations in webMethods.io Integration that invoke services defined in the applications. When webMethods.io Integration executes a service, the on-premises Integration Server returns all the results to webMethods.io Integration. You can batch the results to limit the number of results returned to webMethods.io Integration.
After you create applications, you upload them to webMethods.io Integration. If the application changes on the on-premises Integration Server, you must upload the application again for the changes to be replicated on webMethods.io Integration.
When you upload applications to webMethods.io Integration, you associate one or more accounts that the application can use to access services on the on-premises Integration Server. If the account associated with an application changes, you can upload the account to webMethods.io Integration without having to upload the application.
To define an on-premises application to share with webMethods.io Integration, in the webMethods Cloud menu, click Applications > Define webMethods Cloud Application and under webMethods Cloud Application, complete the following fields.
Assign Services to Application: Specify the services to expose to webMethods.io Integration. Under Package/Services, click the + icon to expand the services available in the package. Select each service that you want to expose to webMethods.io Integration.
If you want the service to return results in batches rather than return the results all at once, click Batch Data. If the top level output signature of the service contains only one field, and the field is a document list or document reference list (both of which are IData arrays), Batch Data is selected by default. Otherwise, it will be cleared.
Under Display Name, specify the name of the service as it should appear in webMethods.io Integration or accept the default. The Display Name field cannot contain reserved words and characters that are used in Java or C/C++ (such as for, while, and if) or the following illegal characters: “#-&@^!%*:$./\`;,~+=)(|}{][><”
Note: Applications are displayed in webMethods.io Integration as on-premises connectors. Operations are named according to the name defined in the Display Name field.
After you define an on-premises application, you must upload the application to webMethods.io Integration before using it. To upload an application, open the Integration Server Administrator and in the webMethods Cloud menu, click Applications.
Click one of the following icons in the row that corresponds to the application you want to upload in the Upload column.
- New or has been edited since the last time it was uploaded to webMethods.io Integration. For a new application, this icon indicates that the application has not been uploaded to webMethods.io Integration. For an application that already exists on webMethods.io Integration, this icon indicates that the application on the on-premises Integration Server is not synchronized with the one on webMethods.io Integration. - Synchronized with the application that has already been uploaded to webMethods.io Integration.When the Upload Application screen appears, in the Select Accounts area, select one or more accounts to associate with the application and then click Upload.
When you upload the on-premises application, the on-premises Integration Server uploads the application to webMethods.io Integration, replacing the existing on-premises connector. It updates the Last Uploaded Time column of the webMethods Cloud Applications screen to indicate that the on-premises connector on webMethods.io Integration is synchronized with the one on the on-premises Integration Server. It also shares the service name, service signature, display name, and service comments with webMethods.io Integration.
If the application has been uploaded earlier, uploading the application again overwrites the existing on-premises connector. Further, if any account associated with an application is disabled during an upload, Integration Server uploads the application successfully and notifies you to enable the account to serve any requests.
Note: Applications uploaded from the on-premises Integration Server are listed in the Connectors > On-Premises Connectors page in webMethods.io Integration.
When you no longer want to share on-premises applications with webMethods.io Integration, you can delete them. Deleting an application from the on-premises Integration Server also deletes the application and its corresponding operations from webMethods.io Integration.
After creating an application, you can edit the application details. If you edit an application, you must upload the application for the changes to take effect on webMethods.io Integration. The updated application is not available for use until you upload it.
You can create on-premises applications on the on-premises Integration Server to share services with webMethods.io Integration.
If your on-premises Integration Server is to connect to webMethods.io Integration through an Internet proxy, you may need to perform additional configurations which fall into the following categories:
If your company requires the use of a proxy server to establish outbound connections to applications located in the cloud, you need to configure a proxy server alias for your on-premises Integration Server. A proxy server alias identifies the proxy server and the port on the proxy server through which you want to route requests and any credentials needed to access the proxy server.
Configure a proxy server alias using the Settings > Proxy Servers page in Integration Server Administrator.
When creating a proxy server alias for use for connection to webMethods.io Integration, do the following:
Depending on your networking and security requirements, you may need to set Java system properties related to proxy servers. As the connection between the on-premises Integration Server and webMethods.io Integration is over HTTPS, you need to set some or all of the following:
As the proxy property values need to be set for the Java Virtual Machine (JVM) in which Integration Server runs, you update the custom_wrapper.conf file to ensure the proxy parameter values are supplied when the JVM launches.
Specifically, you add a wrapper.java.additional.n property that specifies the property name and value that you want to pass to Integration Server, where n is a unique sequence number. The property name must be preceded by -D.
For example, the wrapper.java.additional properties in the custom_wrapper.conf file might look similar to the following:
wrapper.java.additional.204=-Dhttps.proxyHost=YOUR_PROXY_HOST
wrapper.java.additional.205=-Dhttps.proxyPort=YOUR_PROXY_PORT
wrapper.java.additional.206=-Dhttps.proxyUser=YOUR_PROXY_USER
wrapper.java.additional.207=-Dhttps.proxyPassword=YOUR_PROXY_PASSWORD
wrapper.java.additional.208=-Dhttp.nonProxyHosts=localhost|127.0.0.1
wrapper.java.additional.209=-DHPROXY=YOUR_PROXY_HOST:YOUR_PROXY_PORT
wrapper.java.additional.210=-DHAUTH=YOUR_PROXY_USER:YOUR_PROXY_PASSWORDFor instructions about passing the Java system properties to Integration Server and the JVM used by Integration Server, see the webMethods Integration Server Administrator’s Guide.
To pass system properties to Microservices Runtime, you must update the JAVA_CUSTOM_OPTS property in Integration Server_directory /bin/server.bat(sh).
For more information about passing system properties to Microservices Runtime, see the Developing Microservices with webMethods Microservices Runtime document.
If Integration Server uses Java SE Development Kit 8, Update 111 or later and the Internet proxy is configured to enforce HTTPS Basic authentication, you may need to add the following system properties to custom_wrapper.conf:
When using a proxy server for outbound requests from the on-premises Integration Server to webMethods.io Integration, you may need to configure the following on the proxy server:
The webMethods.io Integration platform is available on two Cloud Vendors - Amazon Web Services (AWS) and Microsoft Azure. Based on the vendor and the associated region selected by you at the time of creating your webMethods.io Integration tenant, you need to allow relevant IP addresses to establish the connectivity between webMethods.io Integration and your on-premises Integration Servers.
For more information about the IP categories allowed and the ports that must be configured for cloud connectivity, see Allowed IPs and ports to open for cloud connectivity under Firewall Friendly IPs.
Locate the region your tenant belongs to and allow the relevant IP addresses.
Note: Go to the Software AG Cloud Regions website and click the Show IP option for information on the list of IP addresses. Once you add these addresses to your firewall, you should be able to connect to your resources from webMethods.io Integration. If not, contact Software AG Global Support and the Software AG Cloud Operations teams with the required details.
Do the following checks to troubleshoot hybrid connectivity issues:
Log in to the Integration Server instance.
Create an account on the on-premises Integration Server.
Create the application you want to run on webMethods.io Integration.
Upload the application on webMethods.io Integration.
Use the uploaded application in a Workflow.
Log in to your Integration Server instance, click the webMethods Cloud option listed on the left-side panel, and then click Settings.
Enter the following details on the Settings screen. Once this is done, click Update Settings to save the settings.
An account on the on-premises Integration Server acts as a two-way communication channel for data transfer between the on-premises Integration Server and webMethods.io Integration. So when you execute the application uploaded on webmethods.io Integration, it in turn invokes the application instance deployed on the on-premises Integration Server where the actual execution takes place. The output/response of this execution is then sent back to webMethods.io Integration.
To create a new account, go to webMethods Cloud > Accounts, and click Create On-Premise Account.
On the Create Account configuration screen, enter the following details:
General Settings
Account Settings
Once this is done, click Test Account Settings. This will verify whether the details entered by you are valid or not. If the entered details are valid, you will get a notification message stating so. You can then click on Save Changes to save the account settings.
You need to create the applications you want to execute using webMethods.io Integration on the Integration Server. Once created, these applications can then be uploaded to webMethods.io Integration where they can be used in the workflows and FlowServices.
To create an application, go to webMethods Cloud > Applications and click Define webMethods Cloud Application.
In the Define Application configuration window, enter the following details:
Once this is done, click Save Changes. This will create the specified application.
Once you have created the application, you need to upload it to webMethods.io integration in order to use it in your workflow or FlowService. When you upload an application to webMethods.io integration, the metadata of its services such as name, description, and Input/Output signature is also uploaded to the said application.
To upload the application, go to webMethods Cloud > Applications, locate the application you want to upload in the webMethods Cloud Applications list, and click on the Upload icon.
With this, you have successfully created the application in your webMethods Integration Server, which you can use in your webMethods.io integration workflows and FlowServices.
Let us see how to use this application in a workflow.
Log in to webMethods.io Integration. You will find the uploaded application (onPremise_app) in the Connectors panel on the right-side of the canvas.
You can use this application like any other connector in your workflow.
When you double-click on the application icon (onPremise_app), you can see that the configuration window is same as that of any other connector available in webMethods.io Integration.
Select the action (myService) and click Next.
You will be redirected to the action configuration screen, where you can add the relevant details to execute the action.
You can optionally test the action and then click Done. This will take you back to the canvas. Once you have configured the rest of the workflow, save it.
Whenever you execute the workflow, webMethods.io Integration sends the request to Integration Server to execute the added application and Integration Server in turn sends back the execution response to webMethods.io Integration. This data can then be used to execute the rest of the workflow.
Note: A workflow, which contains an on-premises connector, cannot be cloned.
Click here to see an example on how to invoke FlowServices for on-premises connectors.
Performance, scalability, and availability of on-premises connectivity for hybrid integration scenarios have been enhanced by having dedicated Software AG Universal Messaging (UM) nodes for each tenant.
A tenant can be configured with dedicated UMs based on the license. Contact Software AG Global Support for assistance in setting up the dedicated hybrid infrastructure.
If Software AG has provisioned dedicated UMs for your tenants, and the shared UM queues, if applicable, are imported to the new dedicated UMs, ensure that you update the settings so that hybrid integrations work with the newly provisioned dedicated UMs.
Routing mechanism of the hybrid integration solution is enhanced from the v10.16 release. In the hybrid integration solution, webMethods.io Integration uses Universal Messaging (UM) to route messages to the on-premises applications and vice-versa. While configuring the connectivity (routing) settings, currently the host name is provided in the format, um.int-aws-de.webmethods.io.
In the new approach, the host name format has been changed to *.um.int-aws-de.webmethods.io, where * indicates the tenant-specific identifier.
Example:
To migrate to the new hybrid routing mechanism, it is recommended to perform Update Settings and restart the on-premises Integration Server. On-premises Integration Server remains connected to the old Universal Messaging URL unless the settings are updated and the Integration Server is restarted.
Ensure that you allow the following domains in your firewall or proxy settings:
| Region | Allowed domains |
|---|---|
| US1 Oregon AWS | *.um.int-aws-us.webmethods.io |
| EU2 Frankfurt AWS | *.um.int-aws-de.webmethods.io |
| AU2 Sydney AWS | *.um.int-aws-au.webmethods.io |
| US2 East Azure | *.um.int-az-us.webmethods.io |
| EU3 West Azure | *.um.int-az-eu.webmethods.io |
| AU1 Australia East Azure | *.um.int-az-au.webmethods.io |
Note: For the list of allowed IPs, see the webMethods.io Integration section under Software AG Cloud Regions.
webMethods Integration Server 10.7 and later versions support two-way SSL communication between the on-premises Integration Server and webMethods.io Integration. Integration Server, by default, supports one-way SSL communication in which the on-premises Integration Server acts as a client and validates the certificate issued by webMethods.io Integration that acts as a server.
In two-way SSL communication, both the on-premises Integration Server and webMethods.io Integration validate each other’s certificate using private keys. If you want more secure communication between two business applications, you can set up two-way SSL communication.
Let us see how to set up two-way SSL communication between the on-premises Integration Server and webMethods.io Integration.
Notes:
- Before you set up a two-way SSL communication, you need to download the webMethods.io Integration signed certificate and generate a keystore file. Then use the keystore file to generate a keystore alias on the on-premises Integration Server. When you set up a connection to webMethods.io Integration, you need to use these keystore details so that webMethods.io Integration can validate the certificate.
- Ensure that you have Integration Server 10.7 or any later version installed for two-way SSL communication.
- Further, if you are using on-premises Integration Server v10.15 for hybrid connectivity, and if your hybrid connectivity uses two-way SSL, ensure that you have installed IS_10.15_WmCloud_Fix1 in your environment.
Go to webMethods.io Integration and click Profile > Settings > Client Certificate > Tenant Certificate. Download the webMethods signed certificate file in jks or pkcs12 format, which contains the private key and the certificate. You can also upload your own CA signed certificate. You can either directly generate the jks or pkcs12 file, or if you have generated a text file, use the JKS tools or utilities to generate the JKS file.
Note: webMethods.io Integration does not support uploading self signed certificates.
Go to Integration Server, add the certificate file, and specify the keystore properties in the Security > Keystore > Create Keystore Alias page. Provide the file path in the Location field and specify the keystore password. Click Submit.
Note: The default password is changeit. You should update the password for enhanced security.
In Integration Server Administrator, click webMethods Cloud > Settings and specify the details.
| Field | Description |
|---|---|
| User Name | User name for an account on webMethods.io Integration. |
| Password | Password identified in the user account for User Name. |
| webMethods Cloud URL | The URL of webMethods.io Integration with which to share accounts and applications created on the on-premises Integration Server. The URL format is: https://sub-domain.domain-name, for example, https://sample.int-aws-us.webmethods.io:8443. For two-way SSL communication, add port 8443 in the URL, for example, https://sub-domain.domain-name:8443. |
Under Certificate Settings (optional), complete the fields if you want to set up a two-way SSL communication with webMethods.io Integration. If you do not configure these settings, Integration Server uses one-way SSL communication with webMethods.io Integration.
| Field | Description |
|---|---|
| Keystore Alias | A user-specified, text identifier for the Integration Server keystore. This is the alias for the keystore that contains the client certificates that you want Integration Server to use when connecting to webMethods.io Integration. Select the same keystore alias that you have created in Integration Server. |
| Key Alias | The alias for the private key, which must be stored in the keystore specified by the above keystore alias. This value is automatically selected. |
| Truststore Alias | The alias for the truststore that contains the trusted root certificate for the CA that signed the Integration Server certificate associated with the key alias. The truststore also contains the list of CA certificates that Integration Server uses to validate the trust relationship. Select Default_JVM_Truststore. |
Click Update Settings. Integration Server connects to webMethods.io Integration specified in the webMethods Cloud URL field and downloads the configuration information that is required to receive any incoming requests.
Create an account in Integration Server.
Create the application in Integration Server.
Select the account and upload the application to webMethods.io Integration.
The application is listed on the On-Premises Connectors page in webMethods.io Integration.
