Learn how to configure and manage on-premises Integration Servers and create services that will be accessed through webMethods Cloud. Pass data easily from a Workflow or a Flow service to an on-premises application and get processed data back to the Workflow or Flow service.
Hybrid connectivity allows you to establish a secure connection between IBM webMethods 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 Flow service. In hybrid integration, an on-premises Integration Server uses a tenant connection to share account and application information with IBM webMethods Integration. Specifically, the tenant connection enables communication between the on-premises Integration Server and the tenant in IBM webMethods Integration.
This section describes how to configure Integration Server as an on-premises server for use with IBM webMethods 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 IBM webMethods Integration.
An on-premises Integration Server is any Integration Server that is configured to share service metadata with IBM webMethods Integration and enables the execution of those services by integrations defined in IBM webMethods Integration. The service metadata uploaded from an on-premises Integration Server provides the accounts and applications required to create integrations in IBM webMethods Integration.
IBM webMethods Integration has environments and each environment has a different endpoint. You can configure one on-premises Integration Server to an environment.
A group of services that you share with IBM webMethods Integration is called an application. Applications are created on the on-premises Integration Server and uploaded to IBM webMethods Integration. IBM webMethods Integration can execute 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. Users of IBM webMethods Integration can then create integrations that invoke services defined in the applications.
The maximum size limit of an encoded service output to be transported over Hybrid Integration is 50 MB.
The following encoding limits are enforced:
java.lang.String uses a fixed width encoding of 2 bytes per java.lang.Character. In general, all data types excluding java.lang.Integer and java.lang.Byte are converted to java.lang.String before encoding. For example, a java.lang.String must be less than 25 MB, however, a byte[] must be less than 50 MB.
Each field or value within the Service Output is framed with metadata during encoding, and this is added to the encoded data.
The Service Output being transported is encoded into a single cumulative piece, so consideration for the number of fields and their cumulative sizes are needed.
Multiple on-premises Integration Servers can receive and process requests from IBM webMethods Integration. The on-premises Integration Servers can be in a clustered environment (stateful or stateless) or in a non-clustered environment. When multiple Integration Servers are configured to receive and process requests from IBM webMethods Integration, requests are distributed to each Integration Server in a round-robin fashion.
To use multiple on-premises Integration Servers to process requests from IBM webMethods Integration, the following conditions must be true for all the on-premises Integration Servers:
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.
In hybrid integration, an on-premises Integration Server uses a tenant connection to share account and application information with IBM webMethods Integration. Specifically, the tenant connection enables communication between the on-premises Integration Server and the tenant in IBM webMethods Integration.
A tenant alias contains the location and login details needed for the on-premises Integration Server to establish a connection with IBM webMethods Integration. An on-premises Integration Server can have multiple tenant aliases.
Each account on an on-premises Integration Server is associated with one tenant alias. A single tenant alias can be associated with multiple accounts. An on-premises Integration Server contains a pre-defined tenant alias named default. The default tenant alias can be edited to specify different credentials and a different URL for IBM webMethods Integration. However, the default tenant alias cannot be deleted. Note that when an on-premises Integration Server is registered as a webMethods Edge Runtime, IBM webMethods Integration creates a tenant alias named EdgeRuntime_EdgeRuntimeName on the on-premises Integration Server.
The tenant alias specifies the credentials used to listen for requests and the URL for IBM webMethods Integration with which the on-premises Integration Server shares applications and accounts.
To create a tenant alias, open Integration Server Administrator, go to webMethods Cloud > Tenant connections, and click Create Tenant Connection.
Under Settings, enable the tenant, provide a name for the tenant, specify the user name for the user account on IBM webMethods Integration, the password identified in the user account for the user name, and the URL of IBM webMethods 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. To set up a 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 only if you want to set up a two-way SSL communication with IBM webMethods Integration. If you do not configure certificate settings, at a minimum, Integration Server uses one-way SSL communication with IBM webMethods Integration. Integration Server relies on the truststore information in the JVM truststore to establish a connection. Ensure that the JVM truststore contains the CA certificates needed to establish a connection to IBM webMethods Integration. If the JVM is configured to use a keystore and key alias, then Integration Server attempts to establish two-way SSL with IBM webMethods Integration.
If you click Update Settings, Integration Server connects to IBM webMethods Integration specified in the webMethods Cloud URL and downloads the configuration information that is required to receive any incoming requests.
You can update the IBM webMethods Integration Server’s password using one of the following approaches:
Approach 1: Pausing IBM webMethods Integration Flow services
Approach 2: Without pausing IBM webMethods Integration Flow services
Software AG recommends using Approach 1 to ensure that the running Flow services do not encounter an error.
Suspend the running IBM webMethods Integration Flow services.
Update the tenant password in IBM webMethods Integration.
Update the on-premises server tenant password (tenant configuration under WmCloud in Integration Server Admin portal) to match with the new IBM webMethods 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 IBM webMethods Integration Flow services.Â
You must perform all of these steps immediately before the current running service calls to the on-premises server times out. The default timeout value is 60 seconds. Otherwise, there is a chance that the IBM webMethods Integration Flow services may encounter errors due to service timeout.
Disable the cloud accounts used in IBM webMethods Integration to prevent Flow services from using on-premises services. The accounts are configured in the WmCloud configuration menu for each on-premises server that connects to IBM webMethods Integration.
Update the tenant password in IBM webMethods Integration.
Update the on-premises server tenant password (tenant configuration under WmCloud in Integration Server Admin portal) to match with the new IBM webMethods Integration server’s password. This step must be repeated for every affected on-premises server.
Re-enable the cloud accounts.
An account specifies the connection parameters needed to access IBM webMethods Integration. Each account on an on-premises Integration Server is associated with a single tenant alias, however, you can choose which tenant alias the account uses.
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 IBM webMethods Integration. For each account, you specify a tenant alias that communicates with the on-premises Integration Server. Each account can be associated with a different tenant alias.
You create accounts on the on-premises Integration Server to allow them to serve any requests that originate from IBM webMethods Integration.
If an account is disabled on the on-premises Integration Server, any requests sent from IBM webMethods Integration will time out depending on the time specified in the Request Timeout field.
The Accounts screen lists all the accounts that reside on your on-premises Integration Server. It also displays whether each account is enabled.
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 creating an account, you can edit the details. The tenant, alias, and stage of an account cannot be changed. If you edit an account, you must upload the account for the changes to take effect on IBM webMethods Integration.
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 IBM webMethods 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 IBM webMethods Integration and later change the account details. This way, you can change the account details without having to upload the entire application.
After an account is created, you upload it to IBM webMethods 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 IBM webMethods 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 IBM webMethods 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.
| Icon | Description |
|---|---|
 |
New or has been edited since the last time it was uploaded to IBM webMethods Integration. For a new account, the icon indicates that the account has not been uploaded to IBM webMethods Integration. For an account that already exists on IBM webMethods Integration, the icon indicates that the account on the on-premises Integration Server is not synchronized with the one on IBM webMethods Integration. |
 |
Synchronized with the account that has already been uploaded to IBM webMethods Integration. |
When you upload the account, Integration Server Administrator displays a status line that indicates whether the account has been uploaded successfully. The status line is displayed at the top of the screen. Integration Server Administrator also updates the Last Uploaded Time field to indicate the time that the account was uploaded and displays the icon to indicate that the account on IBM webMethods Integration is synchronized with the one on the on-premises Integration Server.
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 IBM webMethods Integration. When accounts are disabled, IBM webMethods Integration cannot execute services on the on-premises Integration Server. After the account is enabled, Integration Server automatically establishes connectivity with IBM webMethods Integration at start up and is ready to serve any requests originating from IBM webMethods 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 IBM webMethods Integration if the tenant is enabled. If the account is in use by any of the integrations in IBM webMethods Integration, the delete operation fails. To delete an on-premises account, click Accounts and then click the delete 
icon.
Each enabled webMethods Cloud account should have an active listener on the on-premise Integration Server. The listener listens for requests from IBM webMethods 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. The watt.wmcloud.listeners.monitoringInterval server configuration parameter determines the interval at which the monitoring thread executes. The default value of the parameter is 300000 milliseconds (5 minutes).
Integration Server stops and restarts all on-premises account listeners whenever you click the Update Settings option on the Tenant connections page.
When an account connection is disconnected or restored, Integration Server notifies the user through a notification in Integration Server Administrator followed by an email. Integration Server generates notifications for an active listener.
When you create an account, the on-premise Integration Server creates two listeners (request and response) for the account. Therefore, if an account is disconnected or reconnected, Integration Server generates two notifications per listener. Configure the hybrid activity notifications using the watt.server.hybridConnectivityAlert.notifications server configuration parameter and the recipients of the notification emails using the watt.server.hybridConnectivityAlert.toMailList server configuration parameter. Integration Server uses the email notification settings configured in Integration Server Administrator > Settings > Resources.
For more information, see the webMethods Integration Server Administrator’s Guide.
For each account, the on-premises Integration Server maintains a session pool to send responses to the Cloud. Integration Server provides server configuration parameters
to set the pool size and the interval at which Integration Server sweeps for unused sessions.
Integration Server starts with a minimum number of sessions for each account. The watt.wmcloud.sessionPool.minCount controls the minimum pool size. When the minimum number of sessions are in use, Integration Server creates new sessions to handle additional
requests. Integration Server continues to create new sessions until it handles all the requests for the account or it reaches the maximum size of the session pool.
The
watt.wmcloud.sessionPool.maxCount value determines the maximum size of the session pool for the account. After the session pool reaches the maximum size, Integration Server reuses sessions in a round-robin fashion. As the load reduces, sessions become unused. Integration Server uses a background thread to sweep for and remove unused “extra” sessions. For example, if watt.wmcloud.sessionPool.minCount is set to 3 and an account session pool contains 10 sessions, 7 of those sessions are “extra” or “additional”. If 8 of the 10 sessions are unused, Integration Server removes only 7 of the unused sessions to keep the minimum number of sessions in the pool.
The interval at which the sweeper runs is controlled by the watt.wmcloud.sessionPool.sweeperInterval parameter.
watt.wmcloud.sessionPool.maxCount: The maximum number of sessions in the session pool that is used to send responses to the Cloud.
watt.wmcloud.sessionPool.minCount: The minimum number of sessions in the session pool that is used to send responses to the Cloud.
watt.wmcloud.sessionPool.sweeperInterval: The interval at which Integration Server removes unused sessions in session pools for the accounts. Integration Server removes only the number of unused sessions in excess of the minimum session pool size.
For more information about these parameters, see the webMethods Integration Server Administrator’s Guide.
A group of services that you share with IBM webMethods Integration is called an application. On-premises applications are created on the on-premises Integration Server and uploaded to IBM webMethods Integration. IBM webMethods 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 IBM webMethods Integration that invoke services defined in the applications. When IBM webMethods Integration executes a service, the on-premises Integration Server returns all the results to IBM webMethods Integration. You can batch the results to limit the number of results returned to IBM webMethods Integration.
After you create applications, you upload them to IBM webMethods Integration. If the application changes on the on-premises Integration Server, you must upload the application again for the changes to be replicated on IBM webMethods Integration.
When you upload applications to IBM webMethods 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 IBM webMethods Integration without having to upload the application.
To define an on-premises application to share with IBM webMethods Integration, in the webMethods Cloud menu, click Applications > Define webMethods Cloud Application and under webMethods Cloud Application, complete the following fields.
After you define an on-premises application, you must upload the application to IBM webMethods 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.
| Icon | Description |
|---|---|
|
New or has been edited since the last time it was uploaded to IBM webMethods Integration. For a new application, the icon indicates that the application has not been uploaded to IBM webMethods Integration. For an application that already exists on IBM webMethods Integration, the icon indicates that the application on the on-premises Integration Server is not synchronized with the one on IBM webMethods Integration. |
|
Synchronized with the application that has already been uploaded to IBM webMethods 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 IBM webMethods 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 IBM webMethods 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 IBM webMethods 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.
When you no longer want to share on-premises applications with IBM webMethods Integration, you can delete them. Deleting an application from the on-premises Integration Server also deletes the application and its corresponding operations from IBM webMethods 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 IBM webMethods 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 IBM webMethods Integration.
If your on-premises Integration Server is to connect to IBM webMethods 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 External Servers > Proxy Servers page in Integration Server Administrator. For detailed information about proxy servers and how to configure a proxy server, see the webMethods Integration Server Administrator’s Guide.
When creating a proxy server alias for use for connection to IBM webMethods 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 IBM webMethods 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 like 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, 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 IBM webMethods Integration, you may need to configure the following on the proxy server:
The IBM webMethods 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 IBM webMethods Integration tenant, you need to allow relevant IP addresses to establish the connectivity between IBM webMethods 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.
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 IBM webMethods Integration.
Upload the application on IBM webMethods 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 Tenant connections.
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 IBM webMethods Integration. So when you execute the application uploaded on IBM webMethods 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 IBM webMethods 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. Click on Save Changes to save the account settings.
You need to create the applications you want to execute using IBM webMethods Integration on the Integration Server. Once created, these applications can then be uploaded to IBM webMethods Integration where they can be used in the workflows and Flow services.
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 IBM webMethods Integration in order to use it in your workflow or Flow service. When you upload an application to IBM webMethods Integration, the metadata of its services such as name, description, and Input/Output signature is also uploaded to that 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 Upload.
With this, you have successfully created the application in your webMethods Integration Server, which you can use in your IBM webMethods Integration workflows and Flow services.
Let us see how to use this application in a workflow.
Log in to IBM webMethods 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 IBM webMethods 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 run the workflow, IBM webMethods Integration sends the request to Integration Server to execute the added application and Integration Server in turn sends back the execution response to IBM webMethods Integration. This data can then be used to execute the rest of the workflow.
Click here to see an example on how to invoke Flow services for on-premises connectors.
Performance, scalability, and availability of on-premises connectivity for hybrid integration scenarios have been enhanced by having dedicated Universal Messaging (UM) nodes for each tenant.
A tenant can be configured with dedicated UMs based on the license. Contact IBM support for assistance in setting up the dedicated hybrid infrastructure.
If dedicated UMs are provisioned 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, IBM webMethods 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 click the Update Settings option 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 |
webMethods Integration Server 10.7 and later versions support two-way SSL communication between the on-premises Integration Server and IBM webMethods 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 IBM webMethods Integration that acts as a server.
In two-way SSL communication, both the on-premises Integration Server and IBM webMethods Integration validate each other’s certificate. 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 IBM webMethods Integration.
Go to IBM webMethods 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.
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.
In Integration Server Administrator, click webMethods Cloud > Tenant connections (Settings) and specify the details.
| Field | Description |
|---|---|
| User Name | User name for an account on IBM webMethods Integration. |
| Password | Password identified in the user account for User Name. |
| webMethods Cloud URL | The URL of IBM webMethods 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 IBM webMethods Integration. If you do not configure these settings, Integration Server uses one-way SSL communication with IBM webMethods 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 IBM webMethods Integration. Select the same keystore alias that you have created in Integration Server. A keystore alias is required for two-way SSL. If the JVM is not configured to have a keystore and key alias or you do not want to use the JVM keystore, you must specify a value for Keystore Alias. |
| 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. A key alias is required for two-way SSL. If the JVM is not configured to have a keystore and key alias or you do not want to use the JVM keystore, you must specify a value for Key Alias. |
| Truststore Alias | The alias for the truststore that contains the CA certificates accepted by the IBM webMethods Integration endpoint and any intermediate endpoints or proxies. Select Default_JVM_Truststore. The truststore must contain 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. Note
If the connection to IBM webMethods Integration involves intermediate endpoints that use certificates signed by private CAs, the selected truststore alias must be for a truststore that contains the CA certificates for the private CA. This truststore might also include the certificates for the JVM.
|
Click Update Settings. Integration Server connects to IBM webMethods 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 IBM webMethods Integration.
The application is listed on the On-Premises Connectors page in IBM webMethods Integration.
When an application developed on IBM webMethods Integration invokes a service on an on-premise Integration Server, the on-premise Integration Server uses a thread from the server thread pool to process the service request. The processing thread invokes the service, posts the response, and then terminates, which frees up the thread to process other requests. The on-premises Integration Server can process multiple service requests from IBM webMethods Integration simultaneously.
The watt.server.threadPool.cloudRequests specifies the maximum percentage of the server thread pool that can be used for processing IBM webMethods Integration requests. The default is 5 which means that if the maximum size of the server thread pool is 1000, up to 50 server threads at a time can be used to process cloud requests. If the watt.server.threadPool.cloudRequests value is either undefined or configured to generate fewer than 25 threads, Integration Server automatically adjusts the thread count to a minimum of 25 to handle IBM webMethods Integration requests effectively.
At start up, Integration Server uses the specified percentage to calculate the number of threads that can be used and logs a message with that information to the server.log. At run-time, when Integration Server reaches the maximum number of threads that can be used to process requests from IBM webMethods Integration, Integration Server writes the following message and blocks new server requests from IBM webMethods Integration until a thread becomes available: [ISS.0021.8040W] Server thread pool is using the maximum number of threads allowed for processing requests from webMethods Cloud. Requests from webMethods Cloud will block until a thread becomes available.
To help ensure that an on-premises Integration Server processes an optimal number of hybrid requests based on the available server capacity, Integration Server sets the number of concurrent hybrid requests it can handle to the lesser of the following:
The number of threads in the server thread pool that can be used for processing cloud requests as determined by the watt.server.threadPool.cloudRequests value.
100 requests.
For example, if the watt.server.threadPool.cloudRequests value indicates that 45 threads in the server thread pool can be used for processing cloud requests, the on-premises Integration Server ensures that it handles 45 hybrid requests concurrently, if there are 45 or more hybrid requests that need to be processed.
Integration Server uses a transactional publish when sending responses to IBM webMethods Integration. The transactional publish includes a built-in mechanism to recover from intermittent network errors, which can help mitigate the impacts of timeout errors and connection leaks. Integration Server automatically retries any failed transactional publish.
Use the following server configuration parameters to configure the retry functionality for publishing responses to IBM webMethods Integration.
If the maximum retry attempts have been made and publishing a response to IBM webMethods Integration still fails, the on-premises Integration Server writes an error to the server log. However, if a response payload exceeds the configured maximum buffer size, then Integration Server does not retry publishing the response to IBM webMethods Integration, but sends an exception to IBM webMethods Integration.
The wm.client.integrationlive.admin:scheduleTenantMonitoringTask task runs in Integration Server at the specified interval of 10 minutes to monitor the tenant connections. If a tenant connection fails, Integration Server notifies the user through a notification in Integration Server Administrator followed by an email. Configure the hybrid activity notifications using the watt.wmcloud.hybridConnectivityAlert.notifications server configuration parameter and the recipients of the notification emails using the watt.wmcloud.hybridConnectivityAlert.mail server configuration parameter. Integration Server uses the email notification settings configured in Integration Server Administrator > Settings > Resources . For more information, see the webMethods Integration Server Administrator’s Guide.