Creating an account on an on-premises Integration Server

Complete the following fields:

• Enable - Enables or disables the webMethods Cloud account. When an account is enabled, Integration Server automatically establishes connectivity with webMethods Integration at startup and is ready to serve any requests originating from webMethods Integration. When an account is disabled, the on-premises Integration Server does not use the account to listen for requests from webMethods Integration. Only an enabled account can listen for requests from 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 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 webMethods Integration when the tenant alias that is 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 help ensure that information is sent to and received from the new destination.
• Stage - The webMethods Integration environment from which the on-premises Integration Server receives requests. The list is populated by the environments that are defined onwebMethods Integration.
• Maximum Reconnection Attempts - Specify the maximum number of reconnection attempts that Integration Server should make if the connection to webMethods Integration fails. When the connection between webMethods Integration and on-premises Integration Server is down, Integration Server reconnects to 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 webMethods Integration is restored.
• Request timeout - Maximum amount of time (in milliseconds) that 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, webMethods Integration issues an error and stops listening for a response. The default is 60000 milliseconds (1 minute). When the request timeout expires, 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 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 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 webMethods Integration, the response remains on 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 webMethods Integration must compress the request and response payloads during hybrid messaging.

• Allowed On-Premise Hosts - The on-premises Integration Server might use multiple addresses, depending on which network or proxy it uses to access webMethods Integration. Specify a comma-separated list of IP addresses that can receive requests from webMethods Integration. Only those IP addresses specified can receive requests. If no value is specified, webMethods Integration derives the IP address of the on-premises Integration Server that uploads the account to webMethods Integration and allows only that IP address to receive requests from 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 this option 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 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 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 webMethods Integration and later change the account details. This way, you can change the account details without having to upload the entire application.