A Dashboard (control plane) that allows you to manage your entire integration platform regardless of where the different runtimes are hosted, be it in your IBM webMethods Integration tenant, your own private cloud, or dedicated data centers hosted anywhere across the globe. For ease of use, the control plane is managed and maintained by IBM as part of your SaaS platform.
The Integration Runtime Dashboard provides details about the key system and server metrics, logs, and projects in an easy-to-read format in the following pages:
Overview
Analytics
Service usage
APIs
Ports
Capabilities
Projects
Packages
Connections
Security
Key/Certificate stores
Allowed services
Properties
Global variables
Messaging
Logs
About
Accessing Integration Runtime Details
To view the details of a runtime, click the corresponding runtime card on the Integration Runtimes 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.
The Overview page provides a summary of potential security risks and weaknesses within the selected runtime. It allows you to quickly identify and assess vulnerabilities across your services, applications, and infrastructure, helping you stay proactive in managing security. The dashboard highlights key areas such as misconfigurations, exposed services, insufficient access controls, and insecure APIs, offering insights into the severity and impact of each issue. With these insights you can focus on fixing the issues and ensure critical vulnerabilities are resolved quickly, improving the overall security of your runtime environment.
The vulnerabilities across your runtime are grouped and displayed on various cards as follows:
Current profile
Allowed services
APIs
Key/Certificate stores
Ports
Current Profile
The Current profile card shows the profile applied to a runtime. There are two profiles:
Developer
Production
The current profile is displayed as Developer if no profile has been defined.
Profile refers to a set of configurations and parameters that define the environment in which applications or services run in a cloud platform. It includes settings related to compute resources, network configurations, security policies, and service integrations, helping to optimize the performance, scalability, and security of applications within that cloud environment.
If you have not applied a correct profile to a runtime, unauthorized users or applications can access sensitive resources leading to data breaches or privilege escalation attacks.
Allowed services
The Allowed services card shows the number of custom packages and a set of services that are allowed to be exposed outside of the runtime environment. Services are reusable units of functionality that define specific business processes or tasks within an integration environment. If you have exposed any services to the outside world, this may allow attackers to connect to cloud instances that should not be publicly accessible.
The numbers on the Allowed services card are hyperlinks that open the detailed Packages and Allowed services pages.
Packages
The Packages page lists the custom package details, such as version and whether each package is enabled and loaded. To view details on all packages that are included in the runtime, select the Include system packages checkbox.
Allowed Services
The Allowed services page shows the exposed services that can be invoked from a custom package and run on runtime. It consists of the following sections:
Allowed services - Lists the services that are allowed and the package name in which each service is used.
Restricted custom Java services - Lists the custom Java services that are restricted with the following messages:
Green icon and a note - Indicates that custom Java services are not allowed. This means there is no security threat to the runtime.
Yellow icon and a note - Lists the Java services that are exposed and can be invoked from a custom package. These services are a potential security threat to the runtime.
Red icon and a note - Indicates that all custom Java services are allowed. This means that every custom Java service is exposed, and this might pose a serious security threat.
APIs
The APIs card shows the list of APIs used in a runtime. Cloud services often rely on APIs to interact with different components. If these APIs are insecure, attackers can exploit vulnerabilities like improper authentication, inadequate encryption, or the exposure of sensitive data through API endpoints. Endpoints are the logical access points into the runtime that could expose potential security vulnerability.
The number under APIs indicates the API count, that is the total number of APIs exposed in the runtime.
Note
If a question mark appears in the Security type, this indicates that all services are exposed posing potential security threat.
By clicking the number hyperlink under APIs, you can open the API list page and view a list of the APIs, their types, the packages in which each API is used, and the endpoint URLs.
To view details on all APIs, select the Include system packages checkbox.
Key/Certificate Stores
The Key/Certificate Stores card shows the number of keystores and truststores referenced in the runtime.
If these stores are misconfigured, expired, improperly secured, or accessible to unauthorized users, attackers could gain access to critical data or compromise the integrity of encrypted communications.
By clicking the number hyperlinks adjacent to Identify and Trust, you can open the Key/Certificate Stores page with more details.
Ports
The Ports card shows the number and type of ports used in the selected runtime.
By clicking the number hyperlink in the card, you can open the Ports page. The page lists details about each port, such as protocol, alias, and package that maintains the configuration for the port.
On the Ports page, a green or red arrow in front of each port number indicates whether the port is enabled or disabled.
A warning icon in the Allow column indicates that the access mode for the corresponding port is set to “allow”, and this might pose a security threat.
To view details on all ports, select the Include system packages checkbox.
The Analytics page displays a dashboard that shows the key system properties for the current runtime. This helps you monitor system status, usage patterns, and overall performance of a runtime. You can select to view data for one of the predefined time periods that are displayed at the top of the dashboard.
The Analytics page consists of four graphs divided into two sections as:
JVM metrics
Server usage statistics
JVM metrics
The top two graphs in the Analytics page are the Java Virtual Machine (JVM) metrics. They allow 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:
Memory usage (MB)
Heap used: Displays the amount of memory (in Megabytes) used in the heap.
Non heap used: Displays the amount of non-heap memory (in Megabytes) used by the JVM. The non-heap memory is where the JVM stores class-level information such as the fields and methods of a class, method code, runtime constant pool and internalized strings.
CPU usage (%)
System CPU: Displays the CPU usage for the whole system. This metric is displayed as a percentage value. A value of 0% means that all CPUs are idle, and a value of 100% means that all CPUs are running during the observation interval.
Process CPU: Displays the CPU usage of the JVM process. This metric is displayed as a percentage value. A value of 0% means that all CPUs are idle, and a value of 100% means that all CPUs are running during the observation interval.
Server usage metrics
The server usage statistics are the lower two graphs in the Analytics page. These charts provide a view of the consolidated sessions and requests from all the cluster nodes of the runtime.
Sessions: Displays data from all nodes in the cluster if the runtime is part of a cluster.
Note
The sessions data includes sessions started by users and runtime internally.
Stateful: Number of stateful sessions started in the polling interval.
Stateless: Number of stateless sessions started in the polling interval.
Licensed: Number of licensed sessions started in the polling interval.
Total: Number of total sessions started in the polling interval.
Requests: Displays data from all nodes in the cluster if the runtime is part of a cluster. Request metrics relate to invocations of only the top-level services. Requests for other services by the top-level services are not included.
Successful: Number of requests successfully completed in the time interval.
Error: Number of failed requests in the time interval.
Total: Total number of requests completed in the time interval. Total requests are equal to the sum of Successful and Error requests.
The Service usage 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. Metrics on the Service usage page include services at all levels.
The Service usage page shows the following graphs:
Top 5 slow Services by response time: The top 5 services that have the longest average response time over the time range (excludes system services).
Top 5 services by request count: The top 5 services that have the most request count over the time range (excludes system services).
The Service usage page also shows the following data related to Service instances, Cache and prefetch information, and Circuit breaker information:
Search: Filter the content of the table in the Services page using the Search option. It also enables you to exclude system services and services that are not running currently from the view.
Settings(): Set the table display settings as one of the following values:
Enable Zebra stripes if you want to display alternate rows with different background colors.
Select which columns you want to display in the table using the Show Columns menu option.
Reset server cache: Resets the runtime cache to clear the count and restart the data collection timers for all services.
Service instances
The Service instances tab displays information about all past and current running services. The data is for all instances in the same environment.
Package: Package that contains the service.
Note
The Package column is not displayed by default. Click > Show Columns to view this column.
Name: Full qualified name of the service that is running or has run.
Available threads: Threads that are currently running.
Running services: Number of instances of the service that is currently running.
Count: Number of instances of this service that ran in the specified time.
Success: Number of successful runs of the service.
Failure: Number of runs of this service that ended in failure.
Last ran: Date and time the service is last run.
Response time (ms): Average time of all responses within a given sampling interval, such as 60 seconds.
Minimum: Minimum time, in milliseconds, that the service took to run in the selected period.
Average: Average time, in milliseconds, that the service took to run in the selected period.
Maximum: Maximum time, in milliseconds, that the service took to run in the selected period.
Cache, prefetch, circuit breaker: Indicates whether the service’s caching option or prefetch option is enabled, or whether the service is a circuit breaker. Accordingly, one or more icons are displayed as follows:
: Indicates Cache is enabled.
: Indicates Prefetch is enabled.
: Indicates the service is a Circuit Breaker.
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:
Package: Package that contains the service.
Note
This column is not displayed by default. Click Show Columns to view this column.
Name: Full qualified name of the service that is running or has run.
Last cache hit: Date and time that a cached result for this service was last accessed.
Cache hits: Total number of times that a cached result for this service has been accessed.
Cache hits/Total count: Percentage of requests for this service that have been fulfilled by retrieving the results from cache.
Cache entries: Number of active cache entries for the service.
Cache expires: Time when the cache expires for the service.
Last prefetch: Date and time that the runtime is last prefetched and cached the results for the service.
Note
The cache may not be refreshed at the exact time specified in Cache expires. It may vary from zero to 15 seconds, according to the cache sweeper thread.
Total prefetches: Total number of times the runtime has prefetched and cached the results for the service in the last poll interval (the poll interval is set to 10 minutes on most servers).
Recent prefetch: Total number of times the runtime has prefetched and cached the results for the service in the last poll interval (the poll interval is set to 10 minutes on most servers).
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:
Package: Package that contains the service.
Note
This column is not displayed by default. Click Show Columns to view this column.
Name: Full qualified name of the service that is running or has run.
State: State of the circuit can be one of the following:
Closed: Service executes.
Open: Service does not execute. Instead, depending on the circuit breaker configuration, the service returns an exception or executes an alternative service.
Half-open: First request for this service since the circuit state changes to half-open results in service execution. All other requests await. If the service executes successfully, the circuit is closed, and the waiting requests execute. If the service ends with a failure exception, the circuit is re-opened.
Open time: Time when circuit was opened.
Open time: Time when an action was performed to close the circuit, that is, to retry the execute call.
Half-open time: Time when the execution of the actual service attempts was made. If successful, the circuit is Closed; if unsuccessful, the circuit is Opened.
Closed time: Time when the circuit was last closed. Time here represents the last successful execution of the service.
Open count: Number of times the circuit was opened since the runtime started.
Request count: Number of incoming requests since the circuit was last opened.
Projects
No subtopics in this section
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 delete projects, if the runtime is mutable.
You must have administrator privileges to delete projects.
You cannot delete projects from cloud runtime.
You can resynchronize the project by clicking the icon.
Projects can be resynchronized, if the runtime is mutable.
The project failures in the edge runtime can often be attributed to outdated assets. In such instances, deleting and resynchronizing the project ensures that the project’s latest assets are used.
The products that run on IBM webMethods Integration connects to database components (grouping of database objects) in an external RDBMS using the following types:
JDBC connection pools: Specify the parameters needed for establishing a connection between IBM webMethods Integration and the database components hosted on database servers. At run time, IBM webMethods Integration creates a separate instance of the connection pool for each database component.
Direct Functions: Write to the database components by pointing each function to the connection pool for the database component. For example, point the ISInternal function to the connection pool for the ISInternal and DistributedLocking database component, the Xref function at the connection pool for the CrossReference database component, and so on. IBM webMethods Integration provides predefined functions for each type of data that can be written to a database component.
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
In the Integration Runtimes page, click the runtime card for which you want to view connections.
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.
[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.
In the Integration Runtimes page, click the runtime card for which you want to view connections.
Click Connections.
In the Connections page, click Configure database.
In the Configure webMethods database connection page, select the icon > Edit for the function you want to associate with a different JDBC pool.
Update the fields.
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.
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
In the Integration Runtimes page, click the runtime card for which you want to view connections.
Click Connections.
In the Connections page, click Configure database.
In the Configure webMethods connection pool alias page, click the icon.
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 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.
Click Save.
Viewing Adapter Connections
In the Integration Runtimes page, click the runtime card for which you want to view connections.
Click Connections.
In the Connections page you can view the following:
Name : Adapter connection name.
Adapter type : Adapter type. For example: JDBCAdapter, SAPAdapter.
Enabled : Indicates whether the connection is enabled or disabled.
Status : Indicates the status of an enabled adapter connection.
Green icon (Enabled) : There are no issues with the connection.
Red icon (Suspended) : There is an issue with the connection, for example wrong credentials or a disconnected server. Click the icon to update the connection details and then reenable the connection.
Go to Integration Runtimes > Runtime Name > Connections.
Click the v icon prior to Adapter connections to view the connections.
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.
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:
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.
Truststore Alias/File Path: Alias of the truststore configuration. The truststore contains trusted certificates that are used to determine the trust for the remote server peer certificates. The mandatory value for the field is DEFAULT_ IS_TRUSTSTORE.
Truststore Password: Password for the truststore configuration. You must copy the password from the Key/Certificate tab in User Profile > Settings > Key/Certificate > Runtimes page.
Keystore Alias/File Path: Alias for the keystore configuration. The mandatory value for the field is DEFAULT_ IS_KEYSTORE.
Keystore Password: Password for the keystore configuration. You must copy the password from the Key/Certificate tab in User Profile > Settings > Key/Certificate > Runtimes page. For more information about configuring and using the truststore and keystore in SSL accounts imported from Git, see Setup Secured Communication for Integration Runtimes, and Use Certificates in Deploy Anywhere Assets.
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.
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.
Click Save connection.
Viewing CloudStreams Connections
Go to Integration Runtimes > Select a runtime > Connections.
Click the icon prior to CloudStreams connections to view the CloudStreams connections. The following details are displayed:
Name: Account name.
Application: Connector name and version.
Status: State indicating whether the account is enabled or disabled.
You cannot create a new CloudStreams connector or delete an existing CloudStreams connector from this page.
Editing a CloudStreams Connector
Go to Integration Runtimes > Select a runtime > Connections.
Click the icon prior to CloudStreams connections to view the CloudStreams connections.
Click the radio button in the Status field corresponding to the connection you want to edit to disable the account if enabled.
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.
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.
The Global variables page lists the global variables that are part of the imported packages.
Global variables are key/value pairs that can be accessed in flow services in the imported packages. Global variables provide a way to avoid hardcoding values, making it easier to manage and update information consistently. Thus, global variables enable flexibility and reusability by allowing you to reference common values without needing to redefine them in multiple places.
You can update the global variables for runtime-specific values. However, you cannot create a new or delete an existing global variable from the Global variables page.
Updating Global variables
Go to Integration Runtimes > <Select a runtime> > Global variables.
Click the icon prior to Global variables to view the global variables configured in the runtime. The following details are displayed:
Package name : Package in which the global variable is configured.
Key : Name of the variable. For example, RDSUserName.
Value : Value of the variable. For example, the value of the global variable RDSUserName is configured as root.
Actions : Lists all actions you can perform on a connection. You can edit the value of the variable by clicking the (Edit) icon. Update the value as per your needs and click Save.
Enterprise applications use messaging to allow independent applications to work together to accomplish some common tasks by means of exchanging messages without requiring direct connections. Messaging is also known as message-oriented middleware (MOM). You can implement the send/receive (publish/subscribe) or point-to-point messaging styles using the JMS-based messaging capabilities.
You can use a JNDI provider to look up administered objects when connecting to a JMS provider or specifying a destination for sending or receiving messages. Most JMS connection aliases require a JNDI provider alias to create connections and look up destinations.
The following predefined connections are available to start with messaging:
JMS aliases:
DEFAULT_IS_JMS_CONNECTION
PE_NONTRANSACTIONAL_ALIAS
JNDI aliases:
DEFAULT_IS_JNDI_PROVIDER
You cannot create a new JMS/JNDI connection or delete an existing JMS/JNDI connection from the Messaging page. However, you can create new JMS and JNDI aliases using the runtime configuration APIs. For more information, see Runtime Configuration APIs.
You can update only a disabled JMS connection.
JMS connections
Go to Integration Runtimes > <Select a runtime> > Messaging.
Click the icon prior to JMS connections to view the JMS connection. The following details are displayed:
Name : JMS alias.
Type : JMS connection type. For example: JMS.
Description : Description of the JMS alias.
Transaction type : Indicates if the sessions that use this JMS connection alias will be transacted. Possible values are:
NO TRANSACTION to indicate that the sessions that use this JMS connection alias are not transacted.
LOCAL TRANSACTION to indicate that the sessions that use this JMS connection alias are part of a local transaction.
XA TRANSACTION to indicate that the sessions that use this JMS connection alias are part of an XA transaction.
Status : State indicating whether the connection is enabled or disabled.
Go to Integration Runtimes > <Select a runtime> > Messaging.
Click the icon prior to JNDI connections to view the JNDI connections. The following details are displayed:
Name: JNDI alias.
Description : Description of the JNDI connection.
Actions : Lists all actions you can perform on a connection. You can edit the JNDI connection by clicking the (Edit) icon. Update the required fields as per your needs and click Save. For more details about the fields in each section, see the documentation for the Cloud Messaging and Cloud Solutions.
The logs contain important information that is necessary for monitoring the activity of a runtime and resolving any issues that may arise. For each runtime instance, you can view logs in the Server, Error, and Service pages.
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.
In the Integration Runtimes page, click a runtime card for which you want to view logs.
On the left of your screen click Logs and select the log type you want to view.
Note
You can also select a different log type from the drop-down menu on each log page.
[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.
[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.
Version: Displays the complete version of the runtime.
Server Name: Displays the name of the runtime.
Uptime: Displays the time (in hours and minutes) since the current runtime is started.
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
In the Integration Runtimes page, click a runtime card for which you want to view diagnostics.
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.