Integration Runtimes Dashboard

The Integration Runtimes Dashboard contains all information that administrators need to monitor and manage the runtimes. The details include key system and server metrics, logs, and projects in an easy-to-read format.

The Integration Runtime Dashboard contains the following pages:

  • Overview

  • Projects

  • Logs

  • Services

  • Connections

To view the details of a runtime, click the corresponding runtime card on the Integration Runtimes page.
To view the details of a runtime instance, click the instance on the Instance Listing page.

Note
In case of multiple instances, only the details of the selected instance are displayed. The consolidated details of all instances of an edge runtime are currently not supported.

Overview

The Overview page displays a dashboard that shows key system properties for the current runtime.

The comprehensive dashboard helps you monitor system status, health, usage patterns, and overall performance of a runtime. The data on this dashboard is for the time that you select. You can select from one of the predefined time periods that are displayed at the top of the dashboard or set your own using the Custom command.

Server info summary

The top-most section of the dashboard provides a top-level summary using information boxes and charts:

Uptime summary

The Uptime summary is a linear chart with color-coded metrics of a runtime availability from the time it is started.

Runtime summary

The Runtime section consists of four graphs divided into two sections as:

JVM metrics

The top two graphs in the Runtime section are the Java Virtual Machine (JVM) metrics. It allows you to view the operating system resource information, such as CPU and Memory usage in time series.

Note
The JVM data is only for the current runtime. This data is the data reported by the java.lang.management.MemoryPoolMXBean class.

JVM metrics are displayed using the following graphs:

Server usage metrics

The server usage statistics are the lower two graphs in the Runtime section. These charts provide a view of the consolidated sessions and requests from all the cluster nodes of the runtime.

Diagnostic data

You can download configuration, operation, and logging data for the runtime by using the Diagnostics button in the server summary section of the Server Info dashboard. Only Administrators can access the diagnostic data.

Using this diagnostic data cloud administrators and cloud service providers can monitor the health and performance of cloud instances, troubleshoot issues, optimize resource allocation, and ensure the overall reliability and availability of cloud-based services. Additionally, they can use the data for capacity planning and cost optimization, as it provides insights into how resources are being utilized.

Downloading diagnostic data

  1. In the Integration Runtimes page, click a runtime card for which you want to view diagnostics.

  2. In the Server Info page, click the Diagnostics button.

    The diagnostics data is downloaded in a zip file and the file name format is Diagnosticsruntime name yyyy-MM-dd-TO MM-dd Z.zip. For example, Diagnostics_Cloud Execution_2022-08-12T06_14_46.812Z.zip.

    The extracted contents of the zip file are available in the following folders:

Note
If there are problems creating the .zip file due to insufficient space on your machine, the data is downloaded into a text file. In the text file, the configuration and operation data are separated into distinct sections for easier reading. Unlike the zip file, the text file does not contain logging data.

Projects

The Projects page in the runtime view provides a list of all projects associated with this runtime. You can navigate to the Projects page by selecting a runtime card in the Integration Runtimes page and then clicking Projects.

The basic project details such as name, version, and owner are displayed in a tabular format. You can click on any project and go to that project directory. Additionally, you can perform a resynchronize operation to retrieve the latest information of all assets.

You can delete the project by clicking the icon.

You can resynchronize the project by clicking the icon.

Logs

The logs contain important information that is necessary for monitoring the activity of a runtime and resolving any issues that may arise. The logs are limited to server, error, and service logs.

The logs are available in the Logs page of the runtime instance view.

Logging, Data Protection, and Privacy

The logs include personally identifiable information (PII) such as usernames, email addresses, and client IP addresses. Runtimes include PII in logs for purposes of auditing, monitoring activity with the server, and diagnosing and correcting problems. The duration that the runtime stores log data depends on the log.

Viewing Runtime Logs

Tip
Click the Table Settings ( ) icon to customize the table look.

  1. In the Integration Runtimes page, click a runtime card for which you want to view logs.

  2. Click Logs. A list of all logs appears by default.

  3. [Optional] If you want to view errors or service logs, select the required Log type from the list.

  4. [Optional] Enter the following details:

    • First line to display: Log entry that must be displayed on the first row. For example, if you enter 25, the 25th entry is displayed on the first row. To display all entries as logged, specify zero. By default, the most recent log is displayed on the first row.

    • Number of entries to display: Number of log entries that must be displayed per page.

  5. [Optional] Click > Export as CSV. The logs are exported and saved as a csv file on your system. The default name of the file is server_logs.csv.

Services

The Services page provides a list of all services associated with the runtime in a tabular format.

The service graphs show the top services sorted by response time and the request counts in descending order. Unlike request metrics on the Usages page, metrics on the Services page include services at all levels.

The Services page shows the following graphs:

The Services page also shows the following data related to Service instances, Cache and prefetch information, and Circuit breaker information:

Service instances

The Service instances tab displays information about all past and current running services. The data is for all instances in the same cluster.

Cancel or Terminate Threads Associated with a Service

If you suspect that a Flow anywhere service is unresponsive either because the service is waiting for an external resource or is in an infinite loop, you can stop the execution of one or more threads associated with the service. You have two options:

The runtime requires you to first cancel a thread before it allows you to terminate the thread. Once you successfully cancel a thread, you no longer have the option of terminating it.

When you cancel or terminate a thread, the runtime returns a thread to the global, trigger, scheduler, or circuit breaker thread pool, depending on the function being performed. The runtime identifies the threads, and you can cancel or terminate threads by flagging them on the service thread page as follows:

Restrictions on Canceling or Terminating a Thread

Before canceling or terminating a thread, keep the following restrictions in mind:

Caution
Be careful when canceling or terminating threads. Canceling a thread might not free up resources being held by the service. Terminating a thread might put your resources in an unstable state.

Canceling or Terminating Service Threads

Prerequisites:

To cancel or terminate a service thread:

  1. In the Integration Runtimes page, click a runtime card for which you want to cancel or terminate a service thread.

  2. Go to the Services page.

  3. In the services table, click on the running thread count in the Running services column. The service instances page appears.

  4. Click to cancel a service. If cancel is successful, runtime removes the thread from the display. However, if cancel is unsuccessful, runtime enables the button for the thread.

  5. Click to terminate the service thread. The runtime removes the thread from the display. If the terminate action is not successful, the thread remains in the display.

Generating an Individual Thread Dump for a Service

A thread dump can help you locate and diagnose thread contention issues that can cause thread blocks or deadlocks.

Typically, you might want to view the thread dump for an individual service thread because the service has been running for a very long time without completing it or is running in a loop. You suspect the service is in an infinite loop or is waiting for external resources that are not available. Based on the information you obtain from these thread dumps, you might be able to correct the problem. If you detect a problem with a thread that is associated with a user-written Java service or a flow service, you have the option of canceling or terminating the thread to allow the service to complete.

For information on how to cancel or terminate a service thread, see Cancel or Terminate Threads Associated with a Service.

To view information about an individual thread:

  1. In the Integration Runtimes page, click card of the runtime where the thread you are inspecting is located.

  2. Go to the Services page.

  3. In the services table, click on the running thread count in the Running services column. The service instances running appear.

  4. Click the thread name to view the thread dump.

  5. If you want to copy the thread dump, click and paste the content to any document.

  6. Click Close to close the thread dump page.

Cache and Prefetch Information

The Cache and prefetch information tab displays cache utilization information for only those services that are currently using cache.

The Cache and prefetch information tab displays the following information:

Circuit Breaker Information

The Circuit breaker information tab displays circuit breaker statistics for each service with a configured circuit breaker. Runtimes gather the circuit breaker statistics.

The circuit breaker feature is available by default for a service that resides on a Microservices Runtime instance. To use the circuit breaker feature with runtimes, you must have additional licensing.

If a circuit breaker is not configured for any service, the Circuit breaker information table displays the message No Services with a circuit breaker enabled.

The Circuit breaker information tab displays the following information:

Connections

The products that run on IBM webMethods Integration connects to database components (grouping of database objects) in an external RDBMS using the following types:

When you use an external database for IBM webMethods Integration, one JDBC connection pool is created from the supplied parameters and the predefined functions are configured to write to their database components using that pool.

The following table provides the predefined functions and their database components that are included with IBM webMethods Integration.

Function Name Database Component
ISInternal ISInternal and DistributedLocking
ISCoreAudit ISCoreAuditLog
ISDashboardStats ISInternal
Xref CrossReference
DocumentHistory DocumentHistory
ProcessAudit ProcessAudit
Process Engine ProcessEngine
Note
  • You cannot add or delete functions.
  • You can create and delete a connection pool and point a function to the new pool.

Viewing JDBC Pools

  1. In the Integration Runtimes page, click the runtime card for which you want to view connections.

  2. Click Connections. The Connections page appears listing the following details:

    • Name: Function alias that directs IBM webMethods Integration and products that run on IBM webMethods Integration to write data to a particular database component. IBM webMethods Integration provides predefined functions for each type of data that can be written to a database component.

    • Associated pool alias: JDBC connection pool used by the function to write data to the database component. JDBC connection pool specifies the parameters needed for establishing a connection.

    • Description: Function alias description.

    • Actions: List of actions you can perform on the JDBC Pool. You can perform the following actions:

      • : Test the database connection.
      • : Restart the database connection. The runtime needs to be restarted in the following scenarios:
        • Association of a function with JDBC pool alias is updated.
        • A new JDBC Pool Alias is created. An alert message appears, and the icon is enabled for administrators. This functionality is not available on Default cloud.
      • : Additional actions such as Edit to update the associated pool alias and Remove to delete the associated pool alias. Only the owner or administrator of the Integration Runtime can perform the additional actions such as Edit and Remove.

  3. [Optional] Click the icon to associate a function with a pool alias. For more information associating with JDBC pool alias, see Associating a function with JDBC pool alias.

Associating a function with JDBC pool alias

Associating a function with a JDBC pool alias, ensures that the function can efficiently and consistently access database connections when needed. You get the benefits of connection pooling, such as connection reuse, connection validation, and automatic connection recovery. This helps improve the overall performance of your application by reducing the overhead of establishing new database connections for each function call, as well as more reliable and responsive database interactions.

  1. In the Integration Runtimes page, click the runtime card for which you want to view connections.

  2. Click Connections.

  3. In the Connections page, click Configure database.

  4. In the Configure webMethods database connection page, select the icon > Edit for the function you want to associate with a different JDBC pool.

  5. Update the fields.

  6. Click Save to save the changes.

    • Function name : Predefined functions provided by IBM webMethods Integration for each type of data that can be written to a database component.
    • Function description : Disabled. Function alias description.
    • Associated pool alias : JDBC Connection Pool that must be used by the function to write data to the database component.
    • Fail-Fast mode-enabled : Transient errors caused by an unavailable database can prevent a connection pool from connecting to its database. You can configure a function to enter fail-fast mode to handle this situation. In fail-fast mode, all attempts by the function to get a database connection immediately return an SQL exception; this saves time by preventing retry attempts. When database connectivity is restored, the function exits fail-fast mode and returns to normal operation. Fail-fast mode can improve performance when you are using synchronous audit logging.

  7. You can perform the following:

    • Click the icon to add a new JDBC pool alias.

    • Click the icon to update or delete the selected JDBC pool alias.

    • Click the icon to test the selected JDBC pool alias connection.

Creating a New JDBC Pool Alias

  1. In the Integration Runtimes page, click the runtime card for which you want to view connections.

  2. Click Connections.

  3. In the Connections page, click Configure database.

  4. In the Configure webMethods connection pool alias page, click the icon.

  5. In the Add webMethods database connection page, enter the following details:

    • Alias name: Name to use for the JDBC connection pool. The name can include any characters that are valid for a file name.

    • Alias description: Brief description of the JDBC connection pool.

    • Driver: Database driver for IBM webMethods Integration to use to connect to the JDBC connection pool.

    • Database URL: URL for the database server.

    • Sample database URL: Sample URL formats for the DataDirect Connect JDBC 5.1 driver are displayed.

      Note
      • Use the DataDirect Connect connection option MaxPooledStatements=35 on all database URLs except those for Trading Networks. This connection option improves performance by caching prepared statements. (Trading Networks caches its prepared statements using its own pooling mechanism).
      • For DB2, if IBM webMethods Integration connects to a schema other than the default schema for the specified database user, you must specify these connection options in the URL: 
        ;AlternateId=schema;“InitializationString=(SET CURRENT PATH=current_path,schema)“;MaxPooledStatements=35
      • AlternateID is the name of the default schema that is used to qualify unqualified database objects in dynamically prepared SQL statements.

    • Spy: When selected, enables the DataDirect Spy diagnostic feature for DataDirect Connect JDBC drivers. DataDirect Spy logs JDBC calls and SQL statement interactions between IBM webMethods Integration and an external RDBMS. This checkbox is cleared by default.

      Note
      This option is for use with an external RDBMS only. It is not for use with the embedded IS internal database.

    • Snoop: When selected, IBM webMethods Integration enables the DataDirect Snoop tool for DataDirect Connect JDBC drivers. The DataDirect Snoop tool logs network packets between IBM webMethods Integration and an external RDBMS. You can use the resulting log file for tracing and diagnostic purposes. This check box is cleared by default.

      Note
      This option is for use with an external RDBMS only. It is not for use with the embedded IS internal database.

    • Spy attributes: Defines the name and location of the log file where IBM webMethods Integration logs diagnostic data collected by the DataDirect Spy diagnostic feature. This value also defines DataDirect Spy attributes. Where alias_name is the name of the JDBC connection pool alias. Typically, you do not need to change the default value. However, if the attributes do not meet the needs of your system, enter a new value in the Spy Attributes field.

      Note
      If you specify your own value, be aware that the diagnostic tool collects data from the IBM webMethods Integration_directory /instances/instance_name/logs/spy directory. If you change the log file location, the diagnostic utility might not import the data logged by DataDirect Spy. For more information about setting DataDirect Spy attributes, consult the documentation on the DataDirect website.

    • Snoop logging parameters: Defines the name and location of the log file where IBM webMethods Integration logs diagnostic data collected by the DataDirect Snoop tool. This parameter also defines DataDirect Snoop tool attributes.

      Note
      • For DB2, you must include the following command at the end of the value: 
        ddtdbg.ProtocolTraceEBCDIC=true

        Typically, you do not need to change the default value. However, if the attributes do not meet the needs of your system, enter a new value in the Snoop Logging Parameters field.
      • If you specify your own value, be aware that the diagnostic tool collects data from the IBM webMethods Integration_directory /instances/instance_name/logs/snoop directory. If you change the log file location, the diagnostic utility might not import the data logged by the DataDirect Snoop tool. For more information about setting the DataDirect Snoop tool attributes, consult the documentation on the DataDirect website.

    • User: Database user for IBM webMethods Integration to use to connect to the database.

    • Password: Password for IBM webMethods Integration to use to connect to the database. If a password is not required, leave this field blank.

    • Minimum connections: Minimum number of connections the pool must keep open at all times. If you use this pool alias for more than one function, each pool instance keeps the specified number of connections open. For example, if you specify keeping at least 3 connections open, and the IS Core Audit Log and the Document History database components both use this pool, the pool keeps a total of 6 connections open - 3 for the IS Core Audit Log pool instance and 3 for the Document History pool instance. If your logging volume has sudden spikes, you can improve performance by making sure the connections needed to handle the increased volume open quickly. You can minimize connection startup time during spikes by setting this value higher, so that more connections remain open at all times.

    • Maximum connections: Maximum number of connections the pools can have open at one time. When the number of connection requests reaches this value, IBM webMethods Integration blocks the requests. Calculate this value as part of the total possible number of connections that could be opened simultaneously by all functions and applications that write to the database. Ensure that the total number does not exceed the connection limit of the database. If one of the applications opens more connections than the database allows, the database will reject subsequent requests for connections from any application. To continue the previous example, if Trading Networks also writes to the database and has a pool that could open up to 5 connections, you could specify only 17 as the maximum number of connections for the current pool. The IS Core Audit Log pool instance could use up to 17 connections, and the Document History pool instance could use the remaining 5 connections.

    • Available connections warning threshold(%): Number of connections, expressed as a percentage of Maximum Connections, that should be available in the pool at all times. When the number of connections falls to or is below this number, IBM webMethods Integration logs a message to the server log. If the number of connections later rises above this number, IBM webMethods Integration logs another message to the server log stating that the connection pool threshold has been cleared. To disable this threshold, set the value to 0.

    • Waiting thread threshold count: Maximum number of requests for connection that can be waiting at one time. When this number is exceeded, IBM webMethods Integration logs a message to the server log and starts a 5-minute interval timer. If the number of requests still exceeds this number at the end of the interval, IBM webMethods Integration logs another message to the server log. To disable this threshold, set the value to 0.

    • Idle Timeout(milliseconds): Period of time, in milliseconds, the pool can keep an unused connection open. After the specified period of time, the pool closes unused connections that are not needed to satisfy the Minimum connections value. The default expiration time is 60000 milliseconds.

  6. Click Save.

Viewing Adapter Connections

  1. In the Integration Runtimes page, click the runtime card for which you want to view connections.

  2. Click Connections.

  3. In the Connections page, click Configure database.

    • Name : Adapter connection name.
    • Adapter type : Adapter type. For example: JDBCAdapter, SAPAdapter.
    • Status : Adapter connection state indicating whether the connection is enabled or disabled.
    • Actions : List of actions you can perform on the adapter connection. Actions are:
Note
  • You cannot create a new adapter connection.
  • You cannot delete an existing adapter connection.
  • You can edit an existing adapter connection.

Editing an Adapter Connection

  1. Go to Integration Runtimes > Runtime Name > Connections.

  2. Click the v icon prior to Adapter connections to view the connections.

  3. In the Adapter connections section, click the icon corresponding to the connection you want to edit. The Adapter Type - Adapter Name page appears listing all the set configurations.

    Note
    You must disable the connection before editing.

  4. Edit the required fields as per your needs in the Connection properties section.

    • Database: List of supported databases.

    • Driver Group: Driver group used to connect to the database. This lists the pre-bundled drivers available and the drivers uploaded in the Database Application. For more information, see Certified Databases and JDBC Driver Jars.

    • Transaction Type: Type of transaction supported by the account. The supported transaction types are:

      • NO_TRANSACTION: Connection automatically commits operations.

      • LOCAL_TRANSACTION: Connection uses local transactions. With this transaction type, all operations performed on the same account within a single transaction boundary are either committed or rolled back together.

      • XA_TRANSACTION: Supports two-phase transactions executed across multiple databases. In one transaction boundary, all operations performed on multiple connections are committed or rolled back together. A transaction boundary means the scope of the transaction, from the beginning to the end of a transaction. The transaction can be in one adapter service, one flow service, one Java service, or several steps in a flow service.

      Note
      All the connections involved in a two-phase transaction must support the XA_TRANSACTION transaction type.

    • DataSource Class: Name of the JDBC driver’s DataSource class.

    • Server Name: Name of the server that hosts the database.

      Note
      If the tenant cannot connect to the cloud database, then check the security settings of the cloud database.

    • User: Username that the connection uses to connect to the database.

    • Password: Password for the username specified in the User field.

    • Database Name: Database name to which the connection connects.

    • Port Number: Port number that the connection uses to connect to the database.

    • Network Protocol: Network protocol that the connection uses when connecting to the database. Type TCP or TCPS to indicate the network protocol.

    • Other Properties: Other driver-dependent properties in the form of propertyName1=propertyValue1; propertyName2=propertyValue2;. You can add multiple properties separated by (;).

      • By default, the loginTimeout is set to 60. This value specifies the login timeout in seconds that a connection waits while attempting to connect to a database.

      • The <current catalog> represents the default catalog associated with an account.

      • The <current schema> represents the default schema associated with an account.

      Some examples of other properties are:

      • Use this field to choose a property such as TableFilter. You can either select or type the TableFilter property in the dropdown list and enter the ‘’.‘Accounting’ in the input text field.

      • Use {} to configure a combination of multiple key-value pairs. 

        connectionProperties={oracle.jdbc.V8Compatible=true,includeSynonymns=true }.

  5. Edit the required fields as per your needs in the Connection manage properties section.

    • Enable Connection Pooling: Enable or disable the connection to use connection pooling. Supported values are:

      • True. Set to True to enable connection pooling if connection must use pooling.

      • False. Set to False to disable connection pooling.

    • Minimum Pool Size: Minimum number of connections to create if connection pooling is enabled. The number of connections you configure here are kept open regardless of whether these connections become idle.

    • Maximum Pool Size: Maximum number of connections that can exist at one time in the connection pool if connection pooling is enabled. For example, if you have a pool with Maximum Pool Size of 20 and you receive 30 simultaneous requests for a connection, then 10 requests will wait for a connection from the pool.

    • Pool Increment Size: Number of connections by which the pool is incremented if connections are needed, up to the maximum pool size. This is applicable if connection pooling is enabled.

    • Block Timeout (msec): Number of milliseconds that IBM webMethods Integration waits to obtain a connection with the database before it times out and returns an error. This is applicable if connection pooling is enabled. For example, if you set the Block Timeout to 5000, then 10 requests will wait for a connection for 5 seconds before they time out and return an error. If the services using the connections require 10 seconds to complete and return connections to the pool, the pending requests will fail and return an error message stating that no connections are available.

      Note
      If you set the Block Timeout value too high, you may encounter problems during error conditions. If a request contains errors that delay the response, other requests will not be sent. This setting must be tuned in conjunction with the Maximum Pool Size to accommodate such bursts in processing.

    • Expire Timeout (msec): Number of milliseconds that an inactive connection can remain in the pool before it is closed and removed from the pool. This is applicable if connection pooling is enabled. The connection pool will remove inactive connections until the number of connections in the pool is equal to the Minimum Pool Size. The inactivity timer for a connection is reset when the connection is used by the Database.

      Note
      • If you set the Expire Timeout value too high, you may have a number of unused inactive connections in the pool. This consumes local memory and a connection on your backend resource. This could have an adverse effect if your resource has a limited number of connections.
      • If you set the Expire Timeout value too low, performance could degrade because of the increased activity of creating and closing connections. This setting must be tuned in conjunction with the Minimum Pool Size to avoid excessive opening/closing of connections during normal processing.

    • Startup Retry Count: Number of times that the system must attempt to initialize the connection pool at startup if the initial attempt fails. The default value is 0.

    • Startup Backoff Timeout: Number of seconds that the system must wait between attempts to initialize the connection pool.

  6. Click Save connection.

Viewing CloudStreams Connections

  1. Go to Integration Runtimes > Select a runtime > Connections.

  2. Click the icon prior to CloudStreams connections to view the CloudStreams connections. The following details are displayed:

Editing a CloudStreams Connector

  1. Go to Integration Runtimes > Select a runtime > Connections.

  2. Click the icon prior to CloudStreams connections to view the CloudStreams connections.

  3. Click the radio button in the Status field corresponding to the connection you want to edit to disable the account if enabled.

  4. In the CloudStreams connections section, click the Edit icon, corresponding to the connection you want to edit. The Edit connection properties - Account Name page appears listing all the set configurations. You can view the editable properties and the default cloud runtime properties for each field.

  5. Edit the required fields as per your needs in the Credentials, Connection Manager Properties, and Connection section.
    For more details about the fields in each section, see the documentation for the respective Connectors.

    Sample of editing a CloudStreams connector:

  6. Click Save.