Service fails to run automatically after the cache expires when the Prefetch parameter is set to True. When the Prefetch parameter is set to True and the cache expires, the service fails to run automatically. The following exception is displayed in the server logs. "[ISS.0086.9249] Missing Parameter:num1" .

This issue is resolved.

Integration Server logs contain duplicate entries after a port is enabled and disabled.

When a port is enabled and disabled, Integration Server creates two entries for each action in the server logs. This issue occurs if the logging level is set to Debug. Integration Server logs the same information in the Debug log and the Info log which causes duplicates.

This issue is resolved. Now, if the logging level is set to Debug Integration Server logs information related to enabling and disabling of ports in the Info log.

An additional prefix is included in an XML document input when restored from the pipeline. Integration Server includes an additional prefix dx: at the root of an XML document instance.

This issue occurs when the XML document is updated as specified in the following sequence of steps:

The issue is now resolved.

Discrepancy in session count on Server > Statistics page and Server > Statistics > Session page.

In Integration Server Administrator, the current total sessions displayed on the Server > Statistics page does not match the number of rows for Current Sessions displayed on the Server > Statistics > Sessions page.

This issue is now resolved.

The threads waiting for the connection and the threads releasing the connection from the connectionPool are blocked in the ConnectionPool.

When the connection creation thread acquires a lock on the ConnectionPool, the thread goes to the wait state and the state of this thread does not change. This prevents the connection from being released.

To resolve this issue, Integration Sever now includes the following server configuration parameter:

watt.server.jca.connectionPool.createConnection.interrupt.waitTime Specifies the wait time, measured in milliseconds, that elapses before Integration Server interrupts a connection creation thread that is in a wait state. There is no default value. You must restart Integration Sever for changes to this parameter to take effect.

Integration Server does not indicate when it is disconnected from a cluster.

Integration Server does not log an error message when it is disconnected from a cluster, preventing automatic detection of the situation.

Now, Integration Server logs the following error message when it is disconnected from the cluster. [ISS.0033.151] The cluster is now not operational.

Additionally, Integration Server logs the following error message when it rejoins the cluster. [ISS.0033.152] The cluster is now operational.

Addition of CDATA block support to outbound SOAP processing.When processing an outbound SOAP message, Integration Server ignores CDATA delimiters in String fields.

If a String field contained text in a CDATA block, Integration Server treats the text as regular text instead of character text and url-encodes special characters in the delimiters and in the text block. Integration Server now provides CDATA block support for processing of outbound SOAP messages only when Integration Server hosts the web service provider. When a service used as an operation in a web service provider returns String values containing CDATA blocks, when encoding the IData into a SOAP message, Integration Server places the CDATA text in the outbound SOAP message in a CDATA section and does not url-encode special characters in the delimiters or text block.

Keep the following information in mind:

Note: When Integration Server is acting as the web service client, Integration Server does not provide CDATA block support when processing outbound SOAP messages. If a String value containing the request is passed to the web service connector and the string contains CDATA, the contents of CDATA block will be treated as regular text and special characters in the delimiters and text block will be url-encoded in the outbound SOAP request.

Changes to Integration Server to address the security vulnerabilities identified during internal security testing.This fix resolves the security issues found during internal security testing.

A NullPointerException occurs when modifying or saving a flow service if dependency checking features are disabled.

A NullPointerException occurs in Software AG Designer when modifying or saving a flow service if the server configuration parameter watt.server.ns.dependencyManager is set to false.

This issue is resolved.

PIE-38649 (IS_9.8_Core_Fix5)

Host name of an email port is displayed incorrectly in the View Email Client Details page in Integration Server Administrator.

The host name of an email port is incorrect and contains garbled characters when the email port is viewed in the Security > Ports > View Email Client Details page in Integration Server Administrator.

This issue is resolved. The host name is now displayed correctly in the Ports > View Email Client Details page in Integration Server Administrator.

Certification of Integration Server with MySQL version 5.6.Integration Server 9.8 is now certified for use with MySQL version 5.6

PIE-39009 (IS_9.9_Core_Fix2)

Messages are rolled back to Universal Messaging incorrectly if the webMethods messaging trigger is configured to Suspend and Retry Later.

If a webMethods messaging trigger specifies Suspend and Retry Later for On Retry Failure, Integration Server rolls back a message to Universal Messaging if a transient error causes the trigger to fail.

However, instead of rolling back a single message, Integration Server rolls back all of the received but unacknowledged messages for the trigger. For concurrent triggers, this can cause messages to be reprocessed. For serial triggers, this can cause messages to be lost.

Now, when a webMethods messaging trigger specifies Suspend and Retry Later and a transient error prevents the trigger from executing successfully, Integration Server rolls back a single message at a time to Universal Messaging. Additionally, Integration Server clears the trigger queue on the Integration Server immediately after suspending the trigger. Clearing the queue removes any messages that the trigger received but did not process. These messages will be redelivered.

Integration Server displays the predefined Client Prefix instead of the user-defined Client Prefix after a restart.

After restarting Integration Server, the user-defined Client Prefix for a new Broker Connection Alias is replaced with the predefined Client Prefix that Integration Server creates.

This issue is resolved. Now, Integration Server displays the user-defined Client Prefix correctly after a restart.

An attempt to create a web service descriptor form a WSDL document fails with a NullPointerException if the WSDL document contains multiple services but the services are not associated with all of the binding and portType definitions in the WSDL document.Creating a consumer web service descriptor or a WSDL first provider web service descriptor from a WSDL document fails with a NullPointerException if the WSDL document defines multiple services and every service is not associated with every binding and portType defined in the WSDL document.

This issue is resolved. Each web service descriptor generated from a service in a WSDL document exposes only the binding and portTypes associated with the service.

Correction to a spelling error in Queue Provider field.On the Settings > Logging > Edit <loggerName> Details page, Integration Server Administrator lists Universal Messaging instead of Universal Messaging as one of the Queue Provider values.The spelling error is now corrected.

Deadlock among threads in XA recovery store prevents XA transactions from completing.

The XA recovery store contains information about each XA transaction, including the transaction ID (XID), the global state of the transaction at each point in the transaction, and the state of each resources participating in the transaction. During an XA transaction, a deadlock between threads accessing the XA recovery store occurred because an exception occurred after a thread acquired a lock. The exception prevented the release of the lock.

This issue is now resolved. In addition to resolving the issue described above, Integration Server now includes server configuration parameters to control recovery logging.

watt.server.transaction.xastore.performXALoggingSpecifies whether Integration Server writes transaction information to the XA recovery store. Set to true to instruct Integration Server to log information about the state and progress of each XA transaction. Set to false to instruct Integration Server to skip logging XA transaction information. The default is true.

Important! If you set watt.server.transaction.xastore.performXALogging to false, Integration Server does not log any information to the XA recovery story while processing a transaction, making transaction recovery impossible. If you want Integration Server to automatically resolve incomplete transactions or you want to manually resolve incomplete transactions, Integration Server must perform XA logging.

You must restart Integration Server for changes to this parameter to take effect.

watt.server.transaction.xastore.maxTxnPerFileSpecifies the maximum number of unique XA transactions in an XA recovery log file. When the XA recovery log file reaches the maximum number of transactions, Integration Server creates a new file. The default is 2000 transactions.

Consider increasing the maximum number of unique XA transactions for the XA recovery log file if there are more than 2000 active XA transactions and Integration Server exhibits a performance delay due to input/output. Increasing the number of unique XA transactions allowed per file decreases the number of files used for the XA recovery log, which, in turn, may result in fewer files for Integration Server to search when performing XA recovery.

Decreasing the number of unique XA transactions stored in file may help during transaction recovery as it might decrease the time to read and consolidate open transactions.

Executing anonymous services creates persistent sessions.Some anonymous services in the WmRoot package create persistent sessions. Repeated execution of these services can consume all of Integration Server's licensed sessions.

This has been fixed. Anonymous services in WmRoot are now stateless which means that Integration Server creates sessions to execute these services and discards the sessions immediately

Integration Server does not restart after improper shut down.If Integration Server does not shut down properly, which can be caused by a JVM crash or a machine crash, configuration files such as acls*.cnf become corrupted or are reduced to a size of zero. In turn, this causes a restart of Integration Server to fail. To recover, data must be restored manually from a backup directory.

This issue results from how Integration Server persists data into the file system. Prior to this fix, Integration Server tried to overwrite the existing file in the file system. If Integration Server shut down improperly right after the file was recreated but before the new content was written to the file system, the file content became corrupted or the file was reduced to a size of zero.

With this fix, Integration Server changes how it saves changes to configuration files. When saving changes to configuration files, Integration Server first saves the configuration changes in a temporary file in the IntegrationServer_directory/instances/instanceName/config/work directory. After saving the changes in a temporary file, Integration Server moves the temporary file to the actual configuration file.

This ensures that if unexpected behavior occurs before the configuration changes are initially saved to the temporary file, only the temporary file is impacted. The actual configuration file is not corrupted. At start up, if Integration Server detects files in in the IntegrationServer_directory/instances/instanceName/config/work, it suggests that changes to a configuration file were not saved to the temporary file and that, therefore, the changes were not made to the actual configuration file. Use the contents of the IntegrationServer_directory/instances/instanceName/config/work directory to determine which configuration files were in the process of being changed. Decide whether you want to redo the changes to the configuration files. Delete the files under the directory and redo the configuration change if you so choose.

The xsd:any element and attributes are not generated for a web service descriptor when the Allow Unspecified Fields property is true.The WSDL document for a web service descriptor does not include the xsd:any element and attributes when the web service descriptor uses a Document variable for which the Allow unspecified fields property is set to true. This issue occurs even when the server configuration parameter watt.core.schema.createSchema.omitXSDAny is set to false.

To address this issue, the web service descriptor now includes a property, Omit xsd:any from WSDL. When set to false, the WSDL document generated by Integration Server includes an xsd:any element. When set to true, the WSDL document does not include the xsd:any element. The default value is true. For changes to this property to take effect, after saving the change to the property, either refresh the web service descriptor or reload the package that contains the web service descriptor.

When a client sends multiple HTTP PUT requests to Integration Server, every second request fails with a 400 Bad Request response.

Now, alternating HTTP PUT requests from the same client will not fail. Integration Server handles multiple HTTP PUT request from the same client correctly.

GET request mandatorily adds a default value to the Content-Type header.

If Content-Type header is not specified in a GET request, the pub.client.http service adds a default Content-Type:"application/x-www-form-urlencoded". According to HTTP 1.1, it is not mandatory to specify the Content-Type header. If the Content-Type header is not specified, the pub.client.http service should not add a default Content-Type.

Now, if no Content-Type header is specified, pub.client.http service does not add a default Content-Type to the request. However, if you pass the data using 'args' or 'table' keys, default Content-Type:

"application/x-www-form-urlencoded" is added.

In Integration Server, sometimes publishing a guaranteed document to Universal Messaging server fails due to transaction failure.

This issue occurs when the Universal Messaging server does not respond to the transaction within the specified EvenTimeout.

This issue is resolved. A new server configuration property, watt.server.um.producer.transaction.commitRetryCount is introduced in the server configuration file. This property specifies the number of retry attempts Integration Server makes to publish the message to the Universal Messaging server. The maximum number of retries is 9. If you try to assign a value greater than 9, Integration Server automatically sets the value of the property to 9. The default is 0. When setting a retry value, you must ensure that the total transaction time does not exceed the MaxTransactionTime. The total transaction time is calculated by multiplying the total number of attempts with the EvenTimeout. For example, if the retry value is set to 9, and the EvenTimeout is set to 60s, the total transaction time is 60,000(9+1) = 600s.

Integration Server loads a package more than once during deployment.

During deployment of multiple packages at the same time, Integration Server reloads the packages more than once.

Now, when a deployment operation includes multiple packages, Integration Server loads each package only once.

In a clustered environment, Integration Server sometimes does not create child tasks when a new server is added to the cluster or when an existing server is restarted.

When a task is scheduled to run on all servers in a clustered environment, Integration Server creates a parent task and a child task for each server in the cluster. When a new server is added to the cluster or when an existing server in the cluster is restarted, Integration Server creates a corresponding child task upon server restart. However, Integration Server sometimes does not create the child task for the newly added server or for the server that was restarted. As a result, the complete information for all servers in the cluster is not available on the Scheduler screen.

This issue is resolved.

SSL handshake fails as no client certificate is sent when a new connection is opened through proxy. When Integration Server tries to open a connection to web server that requires client certificate through proxy, the SSL handshake using JSSE fails as no client certificate is sent. This happens only when the keyStoreAlias and keyAlias parameters are set using pub.security.keystore:setKeyAndChain service and not when they are set using the Integration Server Administrator (Security > Certificates). This issue occurred because the client certificate attachment was missing in the request.

This issue is now resolved. Now, client certificate is sent to web server when a connection is opened through proxy.

Repository-based deployment fails when deploying locally publishable documents on the target Integration Server.

When deploying locally publishable documents on the target Integration Server using a repository-based deployment, Integration Server cannot find a messaging connection alias for the locally publishable document. This causes the deployment to fail. When the publishable document type is set to locally only, there is no messaging connection alias attached to it.

This issue is resolved. Now, Integration Server does not check for a messaging connection alias during deployment when the publishable document type in Integration Server is set to locally only.

Integration Server experiences memory leak due to orphaned entries of type com.wm.app.b2b.server.ostore.FileCache$InvokeCounter located in com.wm.app.b2b.server.ostore.FileCache.

This issue is now resolved.

Enhancement to Integration Server to use a file for specifying allowed cipher suites.

The following server configuration properties identify the list of cipher suites for use with inbound and outbound SSL connections.watt.net.ssl.client.cipherSuiteListwatt.net.ssl.server.cipherSuiteListwatt.net.jsse.client.enabledCipherSuiteListwatt.net.jsse.server.enabledCipherSuiteList

Prior to this enhancement, the properties accepted a comma-separated list of cipher suites. However, specifying a long list of cipher suites can be cumbersome. To make it easier to specify a long list of cipher suites, Integration Server now allows specifying a file as the value for the cipher suite server configuration properties. In the file, specify each cipher suite on a different line. For each cipher suite server configuration property for which you want to specify a file instead of a list of cipher suites, specify the following as the value of the property: file:directoryName\filename For example:

watt.net.jsse.server.enabledCipherSuiteList=file:c:\ssl\ciphers.txt.

Note: You can set the value of a cipher suite server configuration property to a comma-separated list, default, or the absolute path to a file. You cannot specify a combination of these. Integration Server loads the file and its list of supported cipher suites at start up. Changes to the contents of the file that are made after Integration Server starts will not take effect until the next time Integration Server starts. Integration Server throws the following exception if it cannot find the specified file: ISS.0070.9048E Integration Server cannot find the file {0} specified for the server configuration parameter {1}.

Cause The specified server configuration parameter uses a file to identify the allowed cipher suites; however, Integration Server cannot find the file.

Action Make sure the server configuration parameter specifies the correct location of an existing file.

Message not found for messageKey 68.29 and 68.30.

If an email port has "Log out after each mail check=Yes" , Integration Server fails to retrieve the error messages for messageKey 68.28 and messageKey 68.30.

Following messages appear in the server log:

For IMAP: ISP.0068.0029I] Message not found for messageKey 68.29. For POP3: ISP.0068.0029I] Message not found for messageKey 68.30.

This issue is now resolved. Now, correct messages are displayed for messageKey 68.28 and messageKey 68.30.

Error in getting SFTP server host key, if a key exchange algorithm is not supported by SFTP server. Jsch has a default key exchange algorithm order.

During the handshake, jsch checks the client key exchange algorithms one by one with SFTP server key-exchange algorithms. The first matching algorithm is used as the key-exchange algorithm between SFTP client and SFTP server. However, Jsch does not support 2048-bit keys for diffie-hellman-group-exchange-sha256 and diffie-hellman-group-exchange-sha1 key exchange algorithms in Java 1.7 and earlier versions. Consequently, if the Integration Server runs with Java 1.7 or earlier version and SFTP server expects 2048-bit keys for these algorithms, then the handshake between SFTP server and SFTP client fails.

To avoid this issue, the order of these key exchange can be changed using the watt.ssh.jsch.kex parameter so that, any other matching key exchange algorithm can be selected as the key exchange algorithm between the SFTP client and SFTP server.

To address this issue, Integration Server now include a server configuration parameter to change the order of the key exchange algorithm.

watt.ssh.jsch.kex Specifies the order of the key exchange algorithm for Jsch. The specified order overrides the default key exchange algorithms order supported by Jsch.

For example: watt.ssh.jsch.kex=diffie-hellman-group-exchange-sha1, diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 If the SFTP server expects 2048-bit keys for diffie-hellman-group-exchange-sha1, then the order of this algorithm can be changed so that, any other matching algorithm can be selected as key exchange algorithm between the SFTP client and SFTP server.

watt.ssh.jsch.kex=diffie-hellman-group1-sha1, diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1

Integration Server must be restarted for changes to this parameter to take effect.

Integration Server fails to retrieve the SFTP Get Host Key during the SFTP Server Alias creation. SFTP Server Alias creation fails with 'Auth Cancel' exception, as Integration Server fails to retrieve the SFTP Get Host Key.

The issue is now resolved.

Integration Server issues an Access Denied error message during the logon process and logs an authentication exception in the server log.

Integration Server issues the following error message during the logon process and logs the exception in the server log:

Access to Integration Server is denied because of the following authentication exception: LoginModule "com.wm.app.b2b.server.auth.jaas.X509LoginModule" unavailable.

The issue is now resolved.

Web service connector does not capture all the Set-Cookie HTTP response headers sent back by the web service provider.

When a web service connector sends a request to a web service provider that sends back multiple Set-Cookie response headers, the connector captures only one Set-Cookie response header.

This issue is resolved. Now, if the web service provider sends back multiple Set-Cookie HTTP response headers, the connector returns all of the headers in its output.

Missing fields in an IS document type generated from an XML Schema Definition (XSD) that has complex type definitions referring to group elements defined later in the schema.

When an Integration Server document type is generated from an XSD where the complex type definitions contain references to group elements defined later in the schema, the generated document type does not contain the fields corresponding to such references.

This issue is now resolved.

Integration Server migration utility reports an exception during migration of Trading Networks package.

During migration of Integration Server, if the source Integration Server contains a Trading Networks package, the migration utility throws an exception if JDBC pool information was not selected during migration of configuration files and JDBC pool information was specified during installation of Trading Networks.

Trading Networks data and configuration file Migrator : Unable to locate the database configuration information. File <IntegrationServer_installDirectory>\bin\migrate\..\..\instances\default\config\jdbc\pool\<poolName>.xml does not exist. Where poolName refers to the pool name specified for the Trading Networks functional alias.

This issue is now resolved. Integration Server migration utility correctly migrates Trading Networks data.

Synchronization of publishable documents with the messaging provider fails when using a startup service to run pub.publish:syncToProvider.

When the pub.publish:syncToProvider service runs as part of a startup service, Integration Server reloads the webMethods messaging triggers but fails to update the state of the triggers.

This issue is resolved.

REST API descriptor treats parameter of type byte[] as byte.

When creating a REST API descriptor, if a selected REST resource contains a service with byte[] in the service signature, the REST API descriptor treats the parameter as a byte instead of byte[].

This issue is now resolved.

An error occurs when you create or edit a file polling port if the path to the monitoring directory contains a backslash '\'.

When you create or edit a file polling port and the path to the monitoring directory contains a backslash '\', the following error message is displayed. "No listener defined with the specified key:

FilePollingListener: c: mp" This issue occurs because the Integration Server Administrator uses the wrong encodingType.

This issue is resolved.

A synchronous or asynchronous publish and wait does not receive a reply.

If a publishable document type is empty, that is, it does not contain any fields besides the _env field, and values are mapped to fields the _env field before publishing the document using pub.publish:publishAndWait, Integration Server does not receive a reply to the published request. This occurs for synchronous and asynchronous publish and wait requests.

This issue is now resolved.

Universal Messaging does not reuse the session on Integration Server even though watt.server.trigger.reuseSession is set to true.

When the server configuration property, watt.server.trigger.reuseSession is set to true and Broker is the messaging provider, Broker reuses the session on Integration Server.

Whereas, Universal Messaging as the messaging provider does not reuse the session.

This issue is resolved.

JDBC connection pools are blocked after the database restarts.

After the database used by a JDBC pool restarts, Integration Server does not release connections from the pool because of an unexpected exception thrown by the JDBC driver.

Now, Integration Server exception handling prevents the exception thrown by the JDBC driver from blocking the release of connections from the JDBC pool.

After migrating to Integration Server 9.5 or later, Integration Server displays an exception when calling a web service and using MTOM streaming.

After migrating 2 to Integration Server 9.5 or later, sending a web service request that uses MTOM streaming for which more than one chunk is sent, the following exception occurs: "Exception --> org.apache.axis2.AxisFault: Connection reset by peer: socket write error"

This issue is now resolved.

Unable to view assigned input values for services in Integration Server Administrator when the server configuration property watt.server.disableXSSFilter=true.

When creating a scheduled task, assigning input values using the "Assign Inputs" button displays an empty input field even though the assigned value is saved in the input field. Since the XSS filter is disabled by setting the server configuration property watt.server.disableXSSFilter=true, Integration Server in unable to encrypt quotation marks (") in the input values. Therefore, the assigned input values are not displayed in the input field in Integration Server Administrator.

This issue is resolved. Integration Server is now able to encrypt quotation marks (") in input values when the server configuration property watt.server.disableXSSFilter=true.

Swagger document generated by Integration Server does not represent REST resources with required list parameters correctly.

If a REST API descriptor contains REST resources that refer to a list parameter, such as String list, Document list, Document Reference list, and Object list, and the list parameter is required, the definitions section of the generated Swagger document does not indicate that the parameter is required.

This issue is now resolved.

If a REST API descriptor contains a REST resource that refers to a parameter of type String table, the generated Swagger document does not indicate the type of the parameter as "array".

This issue is now resolved.

Reliable messaging sequences on Integration Server are timed out when the inactivity timeout interval is set to a value of -1.

This issue is now resolved. The reliable messaging sequences do not get timed out when the inactivity timeout interval is set to -1 in the Integration Server Administrator (Settings > Web Services > Reliable Messaging > Edit Configuration).

Service error statistics counter causes memory leak.

An internal mechanism used to report the last 60 seconds worth of service failures has a memory leak. The memory leak occurs when a steady stream of exceptions, at least one every 60 seconds, are thrown without interruption.

To resolve the memory leak, Integration Server clears the service error statistics counter when new entries are added.

Selected Authentication Type does not get populated under HTTP Transport Properties in consumer web service descriptor endpoint alias.

When creating a consumer web service descriptor endpoint alias, the selected Authentication Type is not populated under HTTP Transport Properties.

The issue is now resolved.

Integration Server logs the wrong message when it cannot find the encoder "esapi".

When Integration Server cannot find the encoder "esapi", it logs the following wrong error message:

[ISC.0072.0023E] Couldnt initialize encoder "{0}".

Whereas, Integration Server should log the following message:

ISC.0072.0023E] Failed to initialize the bundle for encoder 'esapi'.

This issue is resolved now.

In the Service Usage screen, some of the values are displayed as   instead of the actual value. In the Service Usage screen of Integration Server Administrator, some of the values in the Count and Last Run columns are displayed as   instead of the actual value. This issue occurs because of encoding issues in Integration Server.

This issue is resolved. Now, the values in the Count and Last Run columns are displayed correctly.

The pub.xml:getNextXMLNode service incorrectly returns a NullPointerException when the NodeIterator does not have XML nodes to return.

This issue is resolved. The pub.xml:getNextXMLNode service returns null when there are no XML nodes to return.

Results window does not show parameter names when using Natural CALC subprogram.

From the Natural CALC subprogram, the IDL and IS connection are created. When using Integration Server and Adapter 9.9, and running the example CALC flow service in Software Designer from the Service Development perspective, the results window does not show the parameter names. The field name abbreviator (as used for XmlData) truncates field names that start or end with #.

With this fix, the Field name abbreviator no longer truncates field names that start or end with #.

Integration Server becomes unresponsive due to an OutOfMemoryError caused by lack of PermGen space. A memory leak in the package classloader may result in a java.lang.OutOfMemoryError: PermGen space, which causes Integration Server to become unresponsive.The memory leak in the package classloader is now repaired.

The pub.event.routing* services are not working properly in Integration Server .

The pub.event.routing* services of send, subscribe, and unsubscribe are not working properly. For example, the send service throws the following ServiceException:

Could not run 'send' com.wm.app.b2b.server.ServiceException: com.wm.app.b2b.server.ServiceException: Event Routing service not available.

This issue is resolved now.

Different error messages for primary and regular HTTP ports.

When Integration Server receives a client request for a web service that does not exist, it returns different error messages depending on whether the request was received through the primary port or an HTTP port.

Now, Integration Server returns the same error message regardless of the port through which it receives the request.

Missing schema definition for the envelope (_env) field in the WSDL document when a service containing reference to a publishable document type is exposed as a web service.

When a service containing reference to a publishable document type is exposed as a web service, the resulting WSDL document does not contain the schema definition for the envelope (_env) field.

This issue is now resolved.

A webMethods messaging trigger that receives messages from a Universal Messaging cluster becomes disconnected and does not reconnect.

When a Universal Messaging connection alias that specifies a cluster of Universal Messaging servers and the network between the Universal Messaging servers fails, one or more webMethods messaging triggers that use the alias might disconnect and then not reconnect. This might happen even if the trigger can successfully connect to one of the Universal Messaging servers but not the other servers in the cluster.

Now, if a webMethods messaging trigger becomes disconnected from a cluster of Universal Messaging servers, the trigger reconnects only when the cluster has a quorum. In addition to resolving the issue described above, Integration Server now redirects the Universal Messaging client log entries from the default stdout to the Integration Server’s log directory, Integration Server_directory/instances/instanceName/logs/umClient.log. The umClient.log file can be used when debugging Universal Messaging issues.

Integration Server does not validate a Kerberos ticket sent by an Internet browser.

If Integration Server receives a request on a port configured to accept Kerberos tickets, Integration Server returns a 401 status code with a “Negotiate” header challenge to the Internet browser. Upon receiving the Negotiate header challenge, a properly configured Internet browser generates a Kerberos ticket and sends the request, along with the Kerberos ticket, to Integration Server. Integration Server should validate the Kerberos ticket and either allow or deny the client request based on the ACL settings. However, Integration Server could not process the Kerberos ticket because a Kerberos ticket sent by an Internet browser is structurally different from tickets generated by a Java client. Because Integration Server could not process the ticket, Integration Serer could not validate the Kerberos ticket. Instead, Integration Server returned a 401 status code and prompted the client for username and password credentials.

Integration Server can now process a Kerberos ticket generated by an Internet browser.

JDBC connection pool for ISInternal functional alias is blocked.Integration Server does not release connections from the JDBC connection pool used by the ISInternal functional alias because of an unexpected exception thrown by the JDBC driver.

Now, Integration Server exception handling prevents the exception thrown by the JDBC driver from blocking the release of connections from the JDBC connection pool.

Enhancement for using a public cache, including a distributed cache, for service results caching. Previously, Integration Server stored cached service results in the ServiceResults system cache which is part of the SoftwareAG.IS.Services system cache manager.

With this enhancement, a local or distributed public cache can now be used for service results caching. By using a distributed cache as the service results cache, multiple Integration Servers can access cached service results.

Keep the following information in mind when using a public cache for service results caching:

For detailed information about creating a public cache, public cache manager, and a distributed cache, see the webMethods Integration Server Administrator’s Guide.

Note: In Integration Server Administrator, the Server > Service Usage page displays statistics about service results. For a distributed cache, this statistics corresponds to the current Integration Server instance only. Integration Server Administrator does not provide aggregated statistics for all the Integration Servers using the same distributed cache for service results caching.

To configure Integration Server to use a public cache for service results caching, you specify the name of the cache and cache manager in the server configuration parameters

watt.server.serviceResults.cache and watt.server.serviceResults.cacheManger, respectively. watt.server.serviceResults.cache

Specifies the name of the public cache to use for service results caching. If no value is specified for the watt.server.serviceResults.cache parameter, Integration Server uses the ServiceResults cache in the cache manger specified in the watt.server.serviceResults.cacheManager parameter as the service results cache. If the cache manager in the watt.server.serviceResults.cacheManager parameter does not contain a cache named ServiceResults, Integration Server throws an error at start up and does not cache service results. You must restart Integration Server for changes to this parameter to take effect.

watt.server.serviceResults.cacheManager

Specifies the name of the public cache manager that contains the public cache to use for service results caching. If no value is specified for this parameter, Integration Server uses the SoftwareAG.IS.Services system cache manager as the service results cache manager. If the SoftwareAG.IS.Services system cache does not contain a cache with a name that matches the value of the watt.server.serviceResults cache, Integration Server throws an error at startup and does not cache service results. You must restart Integration Server for changes to this parameter to take effect.

Note: To use the ServiceResults system cache located in the SoftwareAG.IS.Services system cache manager as the service results cache, do not specify a value for watt.server.serviceResults.cache or watt.server.serviceResults.cacheManager.

The pub.client:soapClient service does not use the private key and certificate chain set using the pub.security.keystore:setKeyAndChain.

This issue is now resolved.

Using the delete icon to delete an OpenID Provider on the Security > OpenID page does not delete the OpenID Provider.

In the Security > OpenID page of Integration Server Administrator, clicking the delete icon in the Delete Provider column invokes an unknown service, resulting in the display of the following message:

[ISC.0072.9001] Unknown service: wm.server.security.openid:deleteProvider

Furthermore, the OpenID Provider is not deleted.

Now, clicking the delete icon in the Delete Provider column on the Security > OpenID page results in Integration Server deleting the OpenID Provider.

Use JSSE option is missing on external port if the internal port is set to HTTP.

On Integration Server Administrator, when you view a port for which the Enterprise Gateway External Port is set to HTTPS and Enterprise Gateway Registration Port is set to HTTP, the "Use JSSE" option does not appear. The "Use JSSE" option appears only if the Enterprise Gateway Registration Port is set to HTTPS.

This issue is now resolved.

Enhancement to allow the default locale for pub.date* services to be the server locale instead of the client locale.

When executing a pub.date* service with a locale input parameter for which no locale is specified Integration Server uses the locale from the session used by the client that invoked the service.

Integration Server now includes a server configuration parameter that you can use to specify that the default locale for pub.date* services should be the server locale.

watt.server.session.locale.ignoreSpecifies whether the default locale for the pub.date* services is the server locale or the locale from the session used by the client that invoked the service. When set to true, when executing a pub.date* service for which a locale input parameter value is not specified, Integration Server uses the server locale as the value of the locale parameter. When set to false, when executing a pub.date* service for which a locale input parameter value is not specified, Integration Server uses the locale from the session used by the client that invoked the service. The default is false.

You do not need to restart Integration Server for changes to this parameter to take effect.

Under heavy load, Integration Server might generate duplicate contextIDs for audit log messages resulting in an AuditLogManagerException.

Under heavy load, Integration Server might generate duplicate contextIDs for audit log messages, causing Integration Server to write the following AuditLogManagerException to the server.log:

[ISS.0095.9998] AuditLogManager Exception: com.webmethods.sc.auditing.api.logger.WmAuditLoggerException: Null or duplicate context given to logger 'Error Logger'

Now Integration Server generates unique contextIDs even under heavy load.

Integration Server throws an error when an incoming message contains a pre-populated contextID and audit contextID.

Integration Server writes the following error to the server.log when an incoming message contains a pre-populated context ID and audit contextID.

[BAA.0000.0061] This context has already been used in the current context stack.

Integration Server now handles a message with a pre-populated contextIDs and audit contextID and no longer logs the above error.

Unable to publish a package to multiple subscribers.

When publishing a package to multiple subscribers, clicking the 'Send Release' button in Integration Server Administrator prompts you to select a subscriber even though subscribers are selected.

This issue is resolved.

UserInfo service does not receive error information.

If an OpenID Provider's UserInfo Endpoint returns an error, information about the error should be passed to the userInfoError input variable in the UserInfo service registered for the OpenID Provider. This is not happening.

This issue is now resolved.

Note: Previously, the userInfoError input variable was named error.

Reply messages are sometimes not received with asynchronous request-reply using webMethods messaging and Universal Messaging as the messaging provider.

In an asynchronous request-reply for webMethods messaging, the pub.publish:publishAndWait service is first invoked followed by the pub.publish:waitForReply. When the messaging provider is Universal Messaging, some reply messages are not received if Integration Server receives the reply message before invocation of the pub.publish:waitForReply service.

This issue is now resolved.

Enhancements for managing a service results cache. Integration Server now includes built-in services that you can use to manage a service results cache, including:

pub.cache.serviceResults:resetServerCache resets the entire cache.

pub.cache.serviceResults:resetServiceCache resets the cache for a particular service. pub.cache.serviceResults:listServiceCache lists the cached results for a particular service.

In addition to the above services, Integration Server Administrator now includes a way to view the cached service results for a particular service. To use Integration Server Administrator to view the cached service results, do the following:

Notes:

- You can also access the Packages > Management > packageName > Services > serviceName page in the following way: Under Server, click Service Usage. On the Server > Service Usage page, click the name of the service for which you want to list cached results.

- To return a list of cached result for a service, the services results must be searchable and that the cache allows automatic indexing for keys. That is, for the service results cache, the Searchable check box must be selected and the Key check box next to Allow Automatic Indexing must be selected. Note that exposing the contents of the service results cache may represent a security risk.

- You can view cached service results for a public service results cache only. You cannot view cached service results in the ServiceResults system cache.

Below is more information about each of the new built-in services. pub.cache.serviceResults:listServiceCache WmPublic.

Returns a list of the cached service results for a particular service.

Input Parameters

serviceName String. Name of the service for which you want to view the cached service results. Output Parameters elements Document List. Conditional. A document list (IData ) containing the cached service results for the specified service. The pub.cache.serviceResults:listServiceCache service returns the elements output only if the service results cache contains cached results for the specified service. For each set of cached service results, the pub.cache.serviceResults:listServiceCache returns the following information:

key String. Optional. Key for the cached element containing the service results.

input. Document. Optional. An IData containing the key/value pairs for the cached service input. output Document. Optional. An IData containing the key/value pairs for the cached service output Usage Notes:

- If serviceName specifies a service that does not exist or a service for which Integration Server does not cache service results, Integration Server returns an empty elements output parameter.

- You can use the pub.cache.serviceResults:listServiceCache with a public service results cache only. You cannot use the pub.cache.serviceResults:listServiceCache with the ServiceResults system cache. - For the pub.cache.serviceResults:listServiceCache service to return results, make sure that the service results cache is searchable and that the cache allows automatic indexing for keys.

That is, for the service results cache, the Searchable check box must be selected and the Key check box next to Allow Automatic Indexing must be selected.

- Exposing the contents of the service results cache via the listCacheService may represent a security risk.

pub.cache.serviceResults:resetServerCache

WmPublic. Resets the cache for all services in the service results cache, resulting in the removal of all cached service results for all services from the service results cache.

Input Parameters None.

Output Parameters message String. Message indicating whether or not Integration Server cleared the service results cache successfully.

- “Cache reset successfully” indicates that Integration Server cleared the entire service results cache successfully.

- “Error resetting cache!” indicates that Integration Server did not clear the entire service results cache successfully. Review the sever log and error log to determine why Integration Server did not clear the service results cache successfully.

pub.cache.serviceResults:resetServiceCache

WmPublic. Resets the cache for specific service, resulting in the removal of cached service results for the service.

Input Parameters serviceName String. Fully qualified name of the service in the format folder.subfolder:serviceName for which you want to remove cached service results.

Output Parameters message String. Message indicating whether or not Integration Server cleared the service results cache for the specified service successfully.

- “Cache reset successfully” indicates that Integration Server cleared the cached service results for the specified service successfully.

- “Error resetting cache!” indicates that Integration Server did not clear the cached service results for the specified service successfully. Review the sever log and error log to determine why Integration Server did not clear the service results cache successfully.

Note: To avoid revealing whether or not a service exists, if serviceName specifies a service that does not exist, the message output parameter returns the message “Cache reset successfully”

Integration Server grants access to a user account disabled by the external user manager. Integration Server caches information for users who provide valid credentials. If the user later provides invalid credentials, Integration Server denies access but does not remove the cached information about the user. Consequently, if the user later provides valid credentials, Integration Server grants access even if an external user manager disabled the user account.

Now, when a user provides invalid credentials, Integration Server removes the user information from the cache.

The pub.storage:get service fails in a cluster.

Integration Server improves the performance of the pub.storage* services by caching the DATASTORE_ID values from the IS_DATASTORE table. However, in a cluster, a cached DATASTORE_ID value might become stale due to actions taken by other Integration Servers in the cluster. A pub.storage* service fails when it attempts to use a stale DATASTORE_ID.

Now, when a pub.storage* service attempts to use a stale DATASTORE_ID, Integration Server replaces it with the current DATASTORE_ID.

Corrections for cosmetic issues in Integration Server Administrator.

Integration Server Administrator displays some cosmetic issues, such as empty cells, deeply nested tables, and missing graphics, that are now repaired.

When restarting Integration Server fix after applying a fix, expected changes are not made to the embedded database.

If the ISInternal functional alias uses the embedded, internal database and application of an Integration Server fix made changes made to the database structure, Integration Server should perform some database updates upon restart of Integration Server. However, this was not happening.

This issue is now resolved.

A NullPointerException occurs when Integration Server enters quiesce mode and the JMS subsystem has not been initialized.

This issue is resolved. Integration Server can now enter quiesce mode even if the JMS subsystem has not been initialized.

Memory leak when invoking pub.jms:reply Integration Server did not correctly release JMS Session and MessageProducer objects when invoking the pub.jms:reply service, resulting in a memory leak.

The issue is now resolved.

In a cluster of Integration Servers, the scheduled task for which the target node is set to "Any Node" and "Repeat After Completion" executes the same service simultaneously on different cluster nodes when the Terracotta Server Array becomes unavailable.

This issue is now resolved. Now, in a cluster of Integration Servers, a scheduled task with target node set to "Any Node" and "Repeat After Completion", executes the service only on one of the cluster nodes at a time when the Terracotta Server Array becomes unavailable.

Specifying a value of true for the watt.net.ssl.client.useJSSE server configuration property does not use JSSE for all of the outbound HTTPS connections from Integration Server.

After applying a fix or upgrading to a release that includes PIE-38599, Integration Server no longer honors the value of watt.net.ssl.client.useJSSE for outbound HTTPS connections. This occurs because PIE-38599 changed the default value of the useJSSE input parameter in the pub.client:http service to “no” from a null value. A value of “yes” or “no” for the useJSSE input parameter overrides the value of the watt.net.ssl.client.useJSSE server configuration property. A null value for the useJSSE input parameter causes the service to defer to the value of the watt.net.ssl.client.useJSSE server configuration property.

Now, the default value of the useJSSE input parameter for the pub.client:http service is null, which allows the watt.net.ssl.client.useJSSE server configuration property to determine the default behavior for outbound HTTPS connections.

Performance degradation observed in Integration Server.

Integration Server exhibits performance degradation in the GA versions 9.8, 9.9, and 9.10. Integration Server versions 9.6 and 9.7 exhibit a similar performance degradation after applying the latest fix.

The cause of the apparent performance degradation is now resolved.

During the migration of Integration Server from 9.0 to a later release, the migration utility also migrates the server configuration parameters watt.core.schema.validateIncomingXSDUsingXerces and watt.server.wsdl.validateWSDLSchemaUsingXerces.

The migration utility need not migrate these server configuration parameters during the migration of Integration Server from 9.0 to a later release because the functionalities provided by the two parameters are replaced in releases starting with 9.0.

- The 'Validate schemas using Xerces' option in the New Web Service Descriptor wizard replaces the functionality of the watt.core.schema.validateIncomingXSDUsingXerces parameter.

- The value of the 'Validate schemas using Xerces' option is stored as the web service descriptor property 'validateSchemaUsingXerces’ (which replaces the functionality of the watt.server.wsdl.validateWSDLSchemaUsingXerces parameter).

The issue is resolved. The specified server configuration parameters are removed from Integration Server starting with release 9.0.

Integration Server logs a message about JDBC connection pool waiting threads threshold count being exceeding erroneously.

Integration Server should log the following message only when a thread is waiting for the JDBC connection pool to have an available connection.

[ISS.0096.0009I] JDBC Connection pool waiting threads threshold exceeded, <number> threads waiting for connection for pool <JDBCPoolName> Integration Server should not log the above message if the JDBC pool is empty or the JDBC driver threw an exception when Integration Server attempts to create a connection. In these cases, there is not actually a waiting thread.

This issue is now resolved.

SFTP transfers fail due to timestamp parsing failure.

A change in the Log Timestamp Format (Settings > Logging > View Server Logger Details > Log Timestamp Format) changes the timestamp format returned by pub.client.sftp:ls service. This causes the SFTP transfers to fail due to the timestamp parsing failure.

To address this issue, Integration Server now includes a server configuration parameter which specifies the timestamp format for SFTP client public services.

watt.server.sftp.dateStampFmt

Specifies the format of date to be used in the SFTP client public services.

To specify the date format to use, you can use any format that is supported by the Java class java.text.SimpleDateFormat. For example, to display the date with the format 08-12-02 14:44:33:1235, specify dd-MM-yy HH:mm:ss:SSSS. The default format for watt.server.sftp.dateStampFmt property is yyyy -MM -dd HH:mm:ss z.

It is not necessary to restart Integration Server after you change the value of this parameter.

Reloading the Packages > Management page in Integration Server Administrator results in a re-execution of the last command on the page.

The Packages > Management page in Integration Server Administrator encodes the last action as part of the URL. Web browsers remember the last action as part of the history, resulting in the re-execution of the last action when reloading the frame.

To resolve this issue, for HTML5-compatible browsers, Integration Server alters the browser history so that that the URL for the Packages > Management page does not include the last action as part of the URL. As a result, when reloading the frame, the last action will not be re-executed.

A concurrent webMethods messaging trigger may not utilize all available threads.

When a concurrent webMethods messaging trigger uses the maximum available threads for message processing, the next request for a thread must wait for a thread to be returned to the thread pool before another message can be processed. Integration Server returns a thread to the thread pool once message processing completes. When a thread becomes available, the waiting request should begin executing. However, instead of the request using a thread as soon as it becomes available, the request waits until the number of threads used by the trigger reaches 0 (zero). This results in periods of time when the trigger is not using all the available threads.

Note: A trigger uses the maximum available threads when the number of messages being processed by the trigger equals the Max execution threads property value. For example, if Max execution threads is set to 10, the trigger uses the maximum available threads when it is processing 10 messages.

Now, a concurrent webMethods messaging trigger will not wait for the number of the threads used by the trigger reaches zero before processing a waiting request. Instead, the trigger begins processing the waiting request as soon as a thread becomes available.

The JSSE-enabled HTTPS ports fail to use the updated certificate.

After adding a new certificate to the truststore and then reloading the truststore using the Integration Server Administrator (Security > Keystore), the JSSE-enabled ports do not use the added certificate.

This issue is now resolved. The JSSE-enabled HTTPS ports now use the updated certificate after the corresponding truststore is reloaded using Integration Server Administrator.

Integration Server Administrator sometimes displays two scrollbars right next to each other instead of a single scrollbar.

This issue is now resolved.

Display non-ASCII Unicode characters in the body of a Java service.

When you persist Java services, Integration Server encodes non-ASCII Unicode characters as ASCII Unicode escape sequences (for example, the Korean character '?' is saved as '\uD55C'). By default, Integration Server does not decode the escape sequences. Therefore, when Integration Server sends Java service code to Software AG Designer, escape sequences appear in Designer instead of the original Unicode characters.

This fix lets you configure Integration Server to decode the escape sequences. In Integration Server Administrator, go to Extended Settings and add "watt.server.ns.decodeJavaService=true." The change will take effect immediately (no server restart necessary).

Note: After this change, Unicode escape sequences will no longer display in the Java service code in Integration Server. For example, if you use the string "\uD55C" in Java service code, the string will save correctly, but the editor will display it as "?".

Invoking pub.storage:get causes a pub.storage lock to be released immediately.

When using pub.storage:get to retrieve an item, Integration Server released the lock on the item immediately. However, when using pub.storage:get to retrieve an item, the lock on the item should remain until the lock is removed by a call to pub.storage:unlock, a call to pub.storage:put, or the lock expires.

This issue is now resolved.

Slow file transfer speed using pub.client.ftp:put.

While transferring files with large size (around 1 GB) using pub.client.ftp:put service, the file transfer speed is observed to be slow. Hence, it takes longer to complete the file transfer. This issue was due to the buffer limit in the amount of data that can be read and written to the stream (1KB).

This issue is now resolved. Now, the buffer size is increased (32 KB) and hence, the transfer time for large files is less and is comparable with the FTP client on Microsoft Windows.

Change to Integration Server to address security vulnerability.

A certain form of URL, if executed, can cause a redirection that allows for the possibility of credential theft. The form of URL no longer causes a redirection. Instead, the Integration Server user receives an HTTP 404 response.

Package deployment fails because some packages are partially loaded.

When using Deployer to deploy IS packages, some packages only partially load. This causes deployment to fail.

This issue is now resolved. Packages are no longer partially loaded.

Modification to Integration Server to control the logging of messages about duplicate universal names for document types.

Whenever Integration Server loads a document type with an explicit universal name (such as when a package is loaded), Integration Server registers the universal name. If Integration Server loads a document type whose explicit universal name is a duplicate of one that is already registered, Integration Server logs the following error message:

"[ISC.0081.0002E] Error registering universal name <universal_name>, already registered to <document_type>" filling the IS logs

A user cannot use Designer or Developer to assign the same universal name to a document type. However, if the same WSDL document is used to generate multiple consumer Web service descriptors and/or multiple WSDL first provider Web service descriptors, Integration Server creates multiple document types with the same universal name explicit. When loading a package containing these document types, Integration Server logs the error message mentioned above multiple times which can clutter the log file. To suppress the error message about registering a duplicate universal name, add the following to extended settings on the Settings > Extended > Edit Extended Settings page watt.server.ns.logErrorsOnRegisteringMultipleDocTypesForAUniversalName=false

After you save your changes, you do need to restart Integration Server for these changes to take effect. If you want Integration Server to resume logging message about registering duplicate universal names, set watt.server.ns.logErrorsOnRegisteringMultipleDocTypesForAUniversalName to true. The default value is true.

Note: Setting watt.server.ns.logErrorsOnRegisteringMultipleDocTypesForAUniversalName to false suppresses the error messages about duplicate universal names only. It does not resolve the duplicate names.

OAuth authentication is not disabled for requests that contain an Auhorization header with a Bearer access token even after setting the watt.server.auth.oauth.accessToken.useHeaderFields parameter to false.

When watt.server.auth.oauth.accessToken.useHeaderFields is set to false, Integration Server should not perform OAuth authentication if Authorization header field contains an access_token. However, if the Authorization header field of an incoming request contains a Bearer access token and the watt.server.auth.oauth.accessToken.useHeaderFields is set to false. Integration Server writes the following messages to the server log:

[ISS.0012.0012W] Authentication of user "bearer" failed with exception: [ISS.0010.8044] Integration Server rejected the request to access this resource. The access token is either invalid or expired. [ISS.0053.0002C] Access denied for user bearer on port 5555 -> ...

This issue is now resolved. If watt.server.auth.oauth.accessToken.useHeaderFields is set to false and a request contains an Authorization header field with a Bearer access token, Integration Server disables OAuth authentication for the request.

Failure to close JSSE SSL connections after handling stateless requests may negatively impact performance.

When Integration Server finishes handling a stateless request received on a port that uses JSSE for SSL, Integration Server does not close the SSL connection. This causes Integration Server to build up stale connections and slows down port allocation, which affects performance.

This issue is now resolved.

The encode method of IDataXMLCoder class closes the OutputStream after encoding the IData object.

The encode method of IDataXMLCoder class, encode(java.io.OutputStream os, IData data) encodes the IData object and closes the OutputStream even though the OutputStream is created by the caller.

This issue is resolved.

Configuration property to determine whether missing SOAP headers result in an error message.

Prior to Integration Server version 9.0, when processing a SOAP received by a web service descriptor, Integration Server did not properly validate that all of the SOAP headers were present. As a result, Integration Server did not throw an error when a SOAP response was missing a SOAP header. Note that all headers in a web service descriptor, whether generated from the original WSDL document or added to the web service descriptor, are treated as required. This is an application of the WS-I basic profile rules declaring that all headers in a WSDL be treated as required.

Beginning in Integration Server version 9.0, Integration Server properly validates SOAP responses for required headers. If a required header is not present, Integration Server throws the following error: [ISS.0088.9443] One or more required Headers <headerName> are not present in the SOAP response."

After upgrading to Integration Server 9.0 or higher from an earlier version, web service connectors that previously succeeded when a required header was missing from a SOAP response now fail. While failure when a required header is missing is the correct and documented behavior, Integration Server now provides a configuration property to control whether missing required headers in a SOAP response results in an error. This can be useful in migration situations.

When watt.server.SOAP.ignoreMissingResponseHeader is set to true, a SOAP response that does not contain a required header will not result in an error. The default is false, a SOAP response that does not contain a required header results in an error. Integration Server restart is not required for changes to take effect.

SOAP web service fixes for backward compatibility.

This fix bundles four separate fixes relating to upgrade and migration of web services. The fixes allow backward compatibility of behavior that has since been prohibited through stricter validation in newer releases.

A range of fix levels in 7.1.3 allowed web service providers to process SOAP requests with a SOAP version that did not match the SOAP version that was declared in the WSDL binding. This fix adds a new extended server setting to emulate the old, less strict behavior so that consumers will not have to update their SOAP requests. The setting only affects web service providers that were created in releases older than 8.2.2 and for which the property "Pre-8.2 compatibility mode"=true. The new parameter is watt.server.SOAP.pre82WSD.ignoreVersionMismatch. By default, this parameter is set to false. To use the parameter to emulate the old behavior, go to Integration Server Administrator and add watt.server.SOAP.pre82WSD.ignoreVersionMismatch=true to the extended settings.

Starting with release 8.2.2, any document type field that contains a namespace must have a namespace prefix in its name in order to be used with web services. In 7.1.x, this prefix was not required. With this fix, document types migrated from 7.1.x that do not meet the 8.2.2 and later IS web service requirements will match the decoded IData representations of SOAP messages as they did in 7.1.x. Specifically, this issue applies in cases where the Decoder needs to choose between converting a simple type value into a string field or into a mixed content DocType with a *body field.

A validation error occurred in some 9.x releases during decoding of mixed content elements that have an enumeration restriction. The error occurred when optional missed content was absent, because an empty value was not listed as an option in the enumeration set for the *body field. This fix adds an extended setting to skip this validation and treat the *body as completely optional.

The new parameter is watt.core.validation.skipAbsentStarBody. By default, this parameter is set to false.

To use the parameter to skip the new validation, go to Integration Server Administrator and add watt.core.validation.skipAbsentStarBody=true to the extended settings. (4) Process one-way SOAP request without a Null Pointer Exception. After receiving a SOAP request, some one-way web service providers return an error containing a Null Pointer Exception. This fix handles the condition that resulted in an error when processing the SOAP request.

When executing the pub.soap.wsrm:createSequence service without specifying the value of the sequenceKey input parameter, Integration Server incorrectly reports the messaging sequence as null.

This issue is now resolved. When the pub.soap.wsrm:createSequence service is executed without specifying the value of the sequenceKey input parameter, Integration Server returns the server Sequence ID associated with the messaging sequence.

Enhancement to Integration Server to use regular expressions for specifying the URIs for allowed origin servers.

When CORS is enabled, the watt.server.cors.allowedOrigins server configuration parameter indicates the origin servers from which Integration Server will accept requests. The watt.server.cors.allowedOrigins value can be a comma-separated list identifying the specific origin servers or a "*", meaning any origin server is allowed. A comma-separated list can become long and difficult to maintain.

To make the list of origin servers easier to maintain, Integration Server now supports the use of regular expressions in the comma-separated list of allowed origin servers. Integration Server treats any value in the comma-separated list that begins with "r:" as a regular expression. Integration Server treats any value that does not begin with "r:" as a simple string. The server configuration parameter uses the Java regular expression syntax, as documented at https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html. A regular expression value must match the entire value of the Origin header in the HTTP request for it to be considered a match.

Example:

watt.server.cors.allowedOrigins=http://test1.domain.com,r:https?://.*.test2.domain.com:[0-9]+,r:.+\.[a-zA-Z]*-int.domain.com

Integration Server treats the first value, "http://test1.domain.com", as a simple string. If an Origin header contains this value, it will be allowed.

The second value, "r:https?://.*.test2.domain.com:[0-9]+", contains a regular expression. The "r:" is not part of the regular expression. The actual regular expression used to match supplied Origin headers is "https?://.*.test2.domain.com:[0-9]+".

The third value, "r:.+\.[a-zA-Z]*-int.domain.com", contains a regular expression. The "r:" is not part of the regular expression. The actual regular expression used to match supplied Origin headers is ".+\.[a-zA-Z]*-int.domain.com".

"Origin: http://test1.domain.com" will be allowed because it is equal to the first value.

"Origin: http://my.test2.domain.com:8080" will be allowed because it matches the second value. "Origin: https://my.test2.domain.com:8088" will be allowed because it matches the second value. "Origin: http://my.test2.domain.com" will not be allowed. If it had a port number, it would match the second value.

"Origin: nbps://example.prod-int.domain.com" will be allowed because it matches the third value. "Origin: example.qa.staging-int.domain.com" will be allowed because it matches the third value. "Origin: example.dev1-int.domain.com" will not be allowed. If the second token of the host name did not include any digits, it would have matched the third value. watt.server.cors.allowedOrigins=*

The simple wildcard "*" continues to work as before. It indicates that any origin server will be allowed.

Regular expressions that match any host name, IP address and port (e.g. "r:.+" and "r:.*") will have the same effect as "*".

Note that when CORS is enabled, Integration Server evaluates the list of regular expressions in watt.server.cors.allowedOrigins sequentially for every request. Integration Server performs a regular expression match operation on each regular expression until a match is found or all regular expressions in the list have been evaluated. Software AG recommends that you put the more frequently matched regular expressions at the beginning of the comma-separated list.

Swagger document and REST Resources tab for REST API descriptor does not represent service input correctly when the service signature includes one or more Document, Document List, Document Reference, or Document Reference List field and another type of field.

The Swagger document and REST Resources tab for a REST API descriptor that includes a REST resource (service) whose service signature includes one or more Document, Document List, Document Reference, or Document Reference List fields in addition to another type of field does not correctly represent the service signature.

Integration Server places all of the input parameters for that resource into a REST Definition and sets the source to Body which is incorrect. Integration Server should place the Document, Document List, Document Reference, or Document Reference List fields in the REST Operation as Body parameters that reference the REST Definitions and place the parameters that are not documents in the REST Operation as Header parameters.

This issue is now resolved.

Integration Server does not show reliable messaging sequence reports in certain situations.

When Integration Server exchanges messages with a reliable messaging client where the web service operation uses In-Only Message Exchange Pattern (MEP), the reliable messaging sequence reports are not displayed on Integration Server.

The issue is now resolved. The reliable messaging sequence reports specifying the Server Sequence ID are displayed on Integration Server in situations where the web service operation uses In-Only MEP.

Integration Server Administrator returns a blank page when you run the wm.server.query:getSettings service from the WmRoot package.

This issue is resolved.

When watt.net.http401.throwException is set to false and the pub.client:http service receives a 401 error, the service does not include the body of the response in the output.

If the watt.net.http401.throwException server configuration property is set to false, when the pub.client:http service receives a 401 error response, the service places the HTTP response header and body in the output pipeline. However, the pub.client:http service was not placing the response body in the output pipeline.

This issue is now resolved.

Integration Server fails to act as an FTP server. An attempt by an FTP client to connect to an FTP port on Integration Server fails with a NullPointerException.

This issue is now resolved.

Web service fails with a RampartException while handling a holder-of-key SAML 2.0 assertion. When handling a holder-of-key SAML 2.0 assertion, a web service fails with the following exception: RampartException: No crypto property file supplied for decryption.

This issue is now resolved.

Integration Server Administrator displays incorrect values for fields in Security > Ports.

Integration Server Administrator displays incorrect values (default values) for "Use JSSE" and "Client Authentication" fields in the Security Configurations section of Security > Ports.

This issue is now resolved.

When Integration Server receives a request with a REST-style URL and an OAuth Bearer token, Integration Server rejects the request with a 403 HTTP status code.

This issue is now resolved. An OAuth Bearer token can be used to access a REST resource that is in the scope for which the token was issued.

Note: Because the service name does not appear in a REST-style URL, do not include the service name when defining the OAuth scope. A scope for an Integration Server REST resource must include the full name of the resource but not the name of the service.

Memory leak in transaction manager.

Transaction manager retains an association to com.wm.app.b2b.server.ServerThread which is not being removed during transaction manager cleanup. Consequently, the association between the transaction and the server thread is not being cleaned up, which prevents the transaction manager entry from being removed.

This issue is now resolved.

Integration Server Administrator displays a Package Load Error loading a package created on Integration Server 7.x or earlier.

Using Integration Server Administrator to load a package created on Integration Server 7.x might result in a Package Load Error caused by a NullPointerException.

This issue was originally resolved in fixes that included PIE-33326. Unfortunately, recent revisions of some Integration Server fixes introduced a regression that allowed the problem to reappear.

This fix resolves the regression.

The pub.utils.messaging:migrateDocTypesTriggersToUM service does not migrate filters with parentheses properly.

When migrating a trigger filter condition that contains parentheses, the pub.utils.messaging:migrateDocTypesTriggersToUM service removes the parentheses from the filter. The pub.utils.messaging:migrateDocTypesTriggersToUM service now preserves parenthesis when migrating trigger filter conditions.

Integration Server does not indicate when it is disconnected from a cluster.

Integration Server does not log an error message when it is disconnected from a cluster, preventing automatic detection of the situation. Now, Integration Server logs the following error message when it is disconnected from the cluster.

[ISS.0033.151] The cluster is now not operational.

Additionally, Integration Server logs the following error message when it rejoins the cluster.

[ISS.0033.152]

The cluster is now operational.

Integration Server throws a NullPointerException instead of logging trace level information when the HTTP Header (0038) server log facility is set to Trace and an incoming request does not contain any credentials.

This issue is now resolved.

Exception handling for the pub.client:smtp service results in a ClassCastException being thrown for a SocketTimeoutException or a ConnectException.

The pub.client:smtp incorrectly handles the exceptions java.net.SocketTimeoutException and java.net.ConnectException by throwing them as a java.lang.ClassCastException.

This issue is now resolved.

A request that includes a URL alias for a REST resource and includes an OAuth access token fails. When a URL alias exists for a REST resource and partial matching is enabled for URL aliases (watt.server.url.alias.partialMatching=true), the URL alias can be used with variable trailing tokens to create a request URL that invokes services for the REST resource and passes the $resourceID, $path, and custom variables to the services. (With the Bearer authorization scheme, the Authorization request header includes an OAuth access token instead of username and password.) However, if the request URL uses the Bearer authorization scheme, the request fails and Integration Server returns an HTTP 401 status code.

This issue is now resolved. A request that uses the Bearer authorization scheme can also use a URL alias to request a REST resource.

When acting as a web service client, Integration Server displays an error if the response from a web service provider contains the value of the content-encoding header as identity.

When acting as a web service client, Integration Server displays the following error when the response from a web service provider contains the value of the content-encoding header as identity: "Received unsupported content-encoding: identity"

This issue is now resolved.

Info message is logged continuously in the server log.

If you configure the email port to IMAP email server and select "Log out after each mail check" functionality, then the following Info message is continuously logged in the server log:

"[ISP.0068.0029I]Logging out of IMAP Server"

This issue is now resolved. Now, this message is moved to DEBUG level.

Integration Server Administrator does not allow Username/Password as the Client Authentication method if Realm URL specifies nsps or nhps as the protocol.

When creating a Universal Messaging Connection Alias, Integration Server Administrator performs a UI validation to check if Realm URL specifies nsps or nhps as the protocol. Integration Server Administrator displays the following message when you select Username/Password as the Client Authentication method. "Client authentication must be set to SSL if Realm URL specifies includes nsps or nhps."

This issue is resolved. The UI validation is now disabled which allows you to select Username/Password as the Client Authentication method if Realm URL specifies nsps or nhps as the protocol.

Client side queue for webMethods messaging does not drain completely.

When Integration Server drains the client side queue by publishing or delivering messages from the client side queue to the webMethods messaging provider, some failures may occur. Integration Server handles the failures based on the exception type. If the exception type is fatal, Integration Server writes the message to the audit log and removes it from the client side queue. If the exception type is transient, Integration Server retries publishing or delivering the message. However, if the client side queue contains published and delivered messages and fatal exception occurs during publish or delivery of a message, Integration Server might add the message back to the client side queue instead of writing it to the audit log.

This prevents the client side queue from fully draining and may cause the queue to drain slowly.

This issue is now resolved.

Integration Server fails to clear the connections of failed remote service executions that were invoked using the pub.remote:invoke service.

This issue is now resolved. Now, if a remote service execution fails, then the connection to remote server is closed completely.

No option to select Java Secure Socket Extension (JSSE) socket factory for HTTPS outbound connections.

When accessing a web service through HTTPS protocol using the pub.client:soapClient service, there is no option to select JSSE for HTTPS outbound connections. The server configuration property "watt.net.ssl.client:useJSSE" applies to all outbound HTTPS connections and hence, user cannot select JSSE for individual web services call.

This issue is now resolved. Now, an optional input parameter "useJSSE" is added to the pub.client:soapClient service.

If the value of "useJSSE" field is left empty or unspecified, then Integration Server uses JSSE for outbound web service call based on the server configuration property "watt.net.ssl.client.useJSSE". If the value of "useJSSE" field is set to "yes", then the Integration Server uses JSSE for the outbound web services call.

If the value of "useJSSE" field is set to "no", then the Integration Server uses Entrust IAIK library for the outbound web services call.

Changes to Integration Server to notify a caller that provides an expired session id.

After applying a fix or installing a release that includes PIE-37166, Integration Server prompts users for credentials if no matching session object can be found for a given session ID stored in a cookie. This behavior is controlled by the watt.security.session.forceReauthOnExpiration server configuration property. When set to true, the more secure behavior, Integration Server rejects requests that include a session id mapped to an expired or invalid session object and prompts the user for credentials. Setting the server configuration property to false instructs Integration Server to create a new session object, assuming the session id is valid and trusted. In case of the server configuration property value set to true (the default), Integration Server does not notify the caller that a valid session object no longer exists. Nor does Integration Server request that the caller deletes the cookie with the expired session.

Now, when Integration Server receives a request with a session id mapped to a session object that no longer exists, Integration Server notifies the caller and requests that the cookie containing the expired session id be deleted. It is then up to the caller, usually a browser, to react to the notification.

Enhancement to allow loggers on multiple Integration Servers to share a Universal Messaging queue for logging across a Universal Messaging realm.

The naming convention for the Universal Messaging queue used by a logger now includes the client prefix if the Share Client Prefix check box is selected for the Universal Messaging connection alias used by the logger. By including the client prefix in the namespace of the queue name, loggers for Integration Servers in a stateless or stateful cluster can share same Universal Messaging queue across a Universal Messaging realm. That is, loggers on multiple Integration Servers can write log entries to and read log entries from one Universal Messaging queue shared across a Universal Messaging realm.

Previously, the Universal Messaging queue name did not include the client prefix as part of the queue namespace regardless of the state of the Share Client Prefix check box. If the Share Client Prefix check box is selected for the Universal Messaging connection alias, the Universal Messaging queue name uses the naming convention:

wm/is/audit/clientPrefix/logger_nameQueue (for example, wm/is/audit/myClientPrefix/SessionQueue).

If the Share Client Prefix check box is not selected for the Universal Messaging connection alias, the Universal Messaging queue name uses the naming convention: wm/is/audit/logger_nameQueue (for example, wm/is/audit/SessionQueue).

If you change the state of the Share Client Prefix check box on the Universal Messaging connection alias is used by loggers, you must restart Integration Server for changes to the queue name to take effect. Additionally, you must make the same changes to other Integration Severs in the cluster that use the alias.

Cookies not included in some HTTP requests.

When the pub.client:http service is used to send requests to a remote server, and the server returns a cookie, in some cases the cookie is not included in subsequent calls to the server.

With this fix, the cookies are used on subsequent calls.

webMethods Messaging triggers do not recognize nested documents in a filter when parent and child documents have the same name.

The name of inline document fields are represented as "Message" names in the protobuf descriptors used by Universal Messaging filters. Because of the message name conflict, the filters are never satisfied and the triggers do not fire.

This fix corrects the problem by using the name of the parent plus the actual field as the protobuf message name. After you install this fix, edit and save the root document type, then sync it with the UM Provider. The filters will begin to work properly.

The pub.client.http fails to set the auth token.

If the 'auth' type is set to Bearer, then the pub.client.http service fails to set the auth token into the Authorization header while sending a request to the HTTP server.

This issue is now resolved.

After installing a fix or a release that includes PIE-37166, a dynamic server page (DSP) request that includes a service invoke of a stateless service prompts for credentials even though the service and DSP are secured with the Anonymous ACL.

The resolution for PIE-37166 introduced the server configuration parameter watt.security.session.forceReauthOnExpiration, which, when set to true, causes Integration Server to reject any request that includes a cookie identifying an expired or invalid session even if the request includes valid user credentials. That is, when set to true, Integration Server does not implicitly create a new session for an expired session and Integration Server deletes the session object for the expired session. A result of this change is that a sequence a DSP requests that includes a service invoke of a stateless service prompts for credentials even though the service and DSP are secured with the Anonymous ACL.

Note: This issue does not occur when watt.security.session.forceReauthOnExpiration is set to false. Keep in mind that setting watt.security.session.forceReauthOnExpiration to true, the default value, offers more secure behavior.

Now, Integration Server preserves the session object.

Enhancement to limit the number of server log files that Integration Server keeps on the file system. Integration Server writes its server log to a file named server.log. When this file is rotated, the existing contents of server.log are saved to a new file named server.log_<current-date>_<current-time>. Over time, the number of archived server log files increases and may consume large amounts of disk space.

To address this issue, Integration Server provides the watt.server.serverlogFilesToKeep server configuration parameter to control the number of server log files that Integration Server maintains on the file system, including the current server log file.

When Integration Server reaches the limit for the number of server log files, Integration Server deletes the oldest archived server log file each time Integration Server rotates the server log.

If the parameter value is 30, for example, Integration Server keeps the current server log file and up to 29 previous server log files.

If the parameter value is less than 1, Integration Server keeps an unlimited number of server log files.

If the parameter value is 1, Integration Server keeps the current server log file (server.log) and no previous (archived) server logs.

The default for watt.server.serverlogFilesToKeep is -1, which places no limit on the number of server log files kept on the file system.

You must restart Integration Server for changes to this parameter to take effect.

New parameter for existing service pub.cache.serviceResults:resetServiceCache and new service pub.cache.serviceResults:addCacheEntry are added to Integration Server as part of this fix. pub.cache.serviceResults:addCacheEntry

WmPublic. Adds cached entry into service results for the service without executing the actual service. This service can be useful to perform bulk load of service results at Integration Server startup.

Input Parameters <serviceName> String Required. Name of the service for which to add the cache entry into cached service results.

<input> Document Required. An IData containing the key/value pairs for the cached service input. <output> Document Required. An IData containing the key/value pairs for the cached service output.

Output Parameters None.

Usage Notes If <serviceName> does not exist in Integration Server, or it is not enabled to cache service results, Integration Server throws an exception.

pub.cache.serviceResults:resetServiceCache An optional input parameter is added to delete specific cached elements for a particular service.

<input> Document Optional. An IData containing key/value pairs that indicate the cached elements to remove.

Support for session caching for transacted JMS connection aliases.

Previously, Integration Server provided session caching for non-transacted JMS connection aliases. Now, Integration Server provides support for session caching for transacted JMS connection aliases when the JMS provider is Universal Messaging 9.10 or WebSphere MQ 7.5. The following paragraphs provide more information about this feature.

When sending a JMS message, Integration Server creates and closes a new JMS session object and a JMS MessageProducer object for each message. This can introduce overhead for some JMS providers. To improve performance when sending JMS messages using a transacted JMS connection alias, you can configure session caching for a JMS connection alias.

For each JMS connection alias, Integration Server can create the following session pools:

- A default session pool containing JMS Session objects. When a default session pool is defined for a JMS connection alias, Integration Server draws from a pool of open JMS Sessions for sending a JMS message instead of opening and closing a JMS Session for each JMS message. Integration Server uses the default session pool only when sending a message to a destination that does not have its own pool. Integration Server creates a new MessageProducer each time it sends a JMS message.

- Destination-specific session pools containing JMS Session objects for sending JMS messages to identified destinations. Integration Server creates a pool for each specified destination. When sending a JMS message to one of the specified destinations, Integration Server uses a Session object from the pool instead of creating and closing a Session object for each JMS message. Integration Server creates a new MessageProducer each time it sends a JMS message.

Note: When using destination-specific session pools for a transacted JMS connection alias, Integration Server creates a new MessageProducer each time it sends a JMS message. This is different from the destination pools that Integration Server creates for a non-transacted JMS connection alias where each entry in the destination-specific pools contains a Session object and a Message Producer object.

Note: A transacted JMS connection alias specifies LOCAL_TRANSACTION or XA_TRANSACTION for the Transaction Type.

To configure session caching for a transacted JMS connection alias, do the following:

In the Destination Lookup Name List, specify a semicolon-delimited list of the lookup names for the destinations for which you want Integration Server to create separate session pools for this alias. 5. Click Save Changes.

This issue is now resolved.

The threads which creates the connection and the threads which ends the connection from the connectionPool can go to blocked state.

To recover from such a situation, Connection pool now has a monitor thread which is a pool interrupter thread, to interrupt the server threads which are in blocked state while creating or ending the connection.

The following properties are introduced to configure the connection time outs:

You must restart Integration Sever for changes to this parameter to take effect.

Use the following service to manage the connections which are hung:

pub.art.connection:getInterruptedThreadStatus.

This service takes the connection alias name as input and lists the connection threads which are not responding even after interrupting by the connection pool interrupter. We recommend a manual intervention for the server threads which gets hung while creating or destroying the connections and also not responding to the interrupt mechanism.