webMethods Cloud Accounts

An account specifies the connection parameters that are 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 that are sent from IBM webMethods Integration times out depending on the time that is 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:

Enable: Enables or disables the webMethods Cloud account. When an account is enabled, Integration Server automatically establishes connectivity with IBM webMethods Integration at startup and is ready to serve any requests originating from IBM webMethods Integration. When an account is disabled, the on-premises Integration Server does not use the account to listen for requests from IBM webMethods Integration. Only an enabled account can listen for requests from IBM webMethods Integration to run services on the on-premises Integration Server. When an account is disabled, requests sent to the on-premises Integration Server remain in the queue until they are read or expire.
Alias Name: A unique name for the account.
Description: Description of the account.
Tenant Alias: The tenant used with the account. The tenant alias specifies the credentials that are used to connect to IBM webMethods Integration. Disabling a tenant alias does not effectively disable the accounts that are associated with the alias. An account can still receive, process, and reply to requests for on-premises services from IBM webMethods Integration when the tenant alias associated with the account is disabled. If you changed the webMethods Cloud URL for a tenant alias since the account was uploaded or since you started Integration Server, you must disable and then re-enable the accounts that use the tenant alias to ensure that information is sent to and received from the new destination.
Stage: The IBM webMethods Integration environment from which the on-premises Integration Server receives requests. The list is populated by the environments that are defined on IBM webMethods Integration.
Maximum Reconnection Attempts: Specify the maximum number of reconnection attempts that Integration Server should make if the connection to IBM webMethods Integration fails. When the connection between IBM webMethods Integration and on-premises Integration Server is down, Integration Server reconnects to IBM webMethods Integration with a random interval between 100 milliseconds to 10 seconds for the first two minutes and then waits for 30 to 60 seconds before attempting to retry the connection. The on-premises Integration Server continues in this manner until connectivity to IBM webMethods Integration is restored.
Request Timeout: Maximum amount of time (in milliseconds) that IBM webMethods Integration waits for the on-premises Integration Server to process a request. If the on-premises Integration Server is not listening for a request or if it takes longer to process the request than the specified time, IBM webMethods Integration issues an error and stops listening for a response. The default is 60000 milliseconds (1 minute). When the request timeout expires, IBM webMethods Integration shows the exception Error occurred while running service with request ID. The on-premises Integration Server did not respond within the configured request timeout of milliseconds. Check on-premises logs. If the started on-premises service takes more time to run than the Request Timeout value, Integration Server writes the following error message to the serverlog: Error occurred while running service with request ID. Service execution took milliseconds, which is more than the configured request timeout of milliseconds. When responding to a request from IBM webMethods Integration, the on-premises Integration Server adds a time-to-live (TTL) property to the response. The on-premises Integration Server uses the Request Timeout value set for the IBM webMethods Integration account as the TTL value for the response. If the on-premises Integration Server sends the response after the timeout value for the request elapses on IBM webMethods Integration, the response remains on IBM webMethods Integration only until the response expires (that is, only until the TTL in the response elapses).
Time to Live: If you are batching the data from the on-premises Integration Server, this is the length of time in seconds that the execution results remain in the cache of the on-premises Integration Server. The value must be greater than 0. The default is 60 seconds.
Enable Compression: Specify whether on-premises Integration Server and IBM webMethods Integration must compress the request and response payloads during hybrid messaging.

Note: Selecting the Enable Compression checkbox enables compression only if both the on-premises Integration Server and IBM webMethods Integration installations are configured to use the compression function. The compression process starts at IBM webMethods Integration. If IBM webMethods Integration compresses the request payload, on-premises Integration Server decompresses, processes, and compresses the payload in the response to IBM webMethods Integration. However, if IBM webMethods Integration does not perform compression, then on-premises Integration Server returns the payload in its original, uncompressed form.

Allowed On-Premise Hosts: The on-premises Integration Server might use multiple addresses, depending on which network or proxy it uses to access IBM webMethods Integration. Specify a comma-separated list of IP addresses that can receive requests from IBM webMethods Integration. Only those IP addresses specified can receive requests. If no value is specified, IBM webMethods Integration derives the IP address of the on-premises Integration Server that uploads the account to IBM webMethods Integration and allows only that IP address to receive requests from IBM webMethods Integration.
Run As User: Specify the username that you want the on-premises Integration Server to use when running the service. You can select users from the local or central directory. The on-premises Integration Server runs the service as if the user you specify is the authenticated user who started the service. If the service is governed by an ACL, ensure that you specify a user who is allowed to start the service.
Test Account Settings: Click to test the account settings. Integration Server Administrator displays a status line that indicates whether the account is valid or not. The status line is displayed at the top of the screen.

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.

Uploading on-premises accounts to IBM webMethods Integration

After an account is created, you upload it to IBM webMethods Integration so that it can be used to run 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 that is 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 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 run services on the on-premises Integration Server. After the account is enabled, Integration Server automatically establishes connectivity with IBM webMethods Integration at start 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.

Monitoring on-premises listeners for accounts

Each enabled webMethods Cloud account should have an active listener on the on-premises Integration Server. The listener listens for requests from IBM webMethods Integration to run services on the on-premises Integration Server. To ensure that each enabled account has an active listener, Integration Server uses a monitoring thread that runs 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 runs. 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.

Note: The monitoring thread exists only if the on-premises Integration Server has at least one enabled account.

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-premises 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 by using the watt.server.hybridConnectivityAlert.notifications server configuration parameter and the recipients of the notification emails by using the watt.server.hybridConnectivityAlert.toMailList server configuration parameter. Integration Server uses the email notification settings that are configured in Integration Server Administrator > Settings > Resources. For more information, see the webMethods Integration Server Administrator’s Guide.

Configuring sessions for use by accounts

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 more 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 more. 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 more than the minimum session pool size.

For more information about these parameters, see the webMethods Integration Server Administrator’s Guide.