Integration Server 10.15 | Added, Removed, Deprecated, or Changed Items | Release 10.7
 
Release 10.7
Added Items
*New Integration Server Administrator Available through the Try the New Administration Console link at the top of the DSP-based Integration Server Administrator, the new administration console includes:
*Simplified, graphically rich, tab-based interface with improved accessibility, simpler debugging tools, and server controls.
*An interactive Dashboard that provides visually detailed monitor system status, health, usage patterns and overall performance of Integration Server including JVM, Usage, Services, and API-related metrics.
*Alerting and notification framework to notify users about alerts generated in the Integration Server such as password expiry, certificate expiry, and configuration changes that require a server restart.
*TLS v1.3 Integration Server supports TLS v1.3 for secure inbound and outbound connections that use JSSE. Integration Server provides support for TLS v1.3 through use of OpenJSSE.
*Restart notification Integration Server Administrator now displays the message “Restart is required for changes to take effect.” if server configuration changes were made that require a restart to take effect
*SSL support with MQTT server Integration Server now supports SSL for connections to the MQTT server.
*TLS v1.1 and v1.2 support for email ports and outbound SMTP connections Integration Server uses the JSSE library to provide TLS v1.1 and v1.2 support for incoming connections on e-mail ports and outbound SMTP connections. If your Integration Server uses OpenJSSE, TLS v1.3 is also supported.
*Advanced SFTP client in Integration Server Integration Server includes an advanced SFTP client, which provides new configuration properties and additional Key Exchange Algorithms, Machine Access Code (MAC) algorithms, and Ciphers. This enhanced support is available as a new version (version 2) along with the previous version (version 1) in the SFTP Server Alias settings screen. The preferred key exchange algorithms, ciphers, and MAC algorithms can be configured from the Integration Server Administrator UI.
*Support for OAuth 2.0 compliant IMAP e-mail port in Integration Server.To support OAuth 2.0 for IMAP e-mail ports, the Email Client Listener Configuration includes fields that allow you to enter the OAuth credentials issued by the OAuth Server to Integration Server. With these credentials, you can get the authorization code, which in turn is used by Integration Server to obtain the Access Token that is required to access the mailbox on the configured mail server.
*Support for users’ email address in LDAP directory configuration for Integration Server. The “User Email” field is added to the LDAP Directory Settings page, which allows you to specify the name of the attribute that is used to store users' email addresses.
*Logging for JNDI New Trace level logging messages for the JNDI objects returned from the JNDI provider, including messages that provide the returned object, object type, and whether the object was retrieved from the JNDI provider or from cache. The new log messages are visible when the logging level of the facility code 0135 JNDI client configuration is set to Trace.
*Retention of the protocol buffer definition for a publishable document type that uses protocol buffer encoding. When you save a publishable document type for which protocol buffers is the encoding type, Integration Server creates a protocol buffer definition. The protocol buffer definition represents the structure and content of the document type as a protocol buffer, including the names, types, and attributes for the fields. Integration Server saves the human-readable protocol definition file named pdt.proto in the same location as the node.ndf for the publishable document type. Previously, Integration Server did not retain the protocol buffer definition.
*Default HTTPS port Integration Server now includes a default HTTPS port with the port alias DefaultSecure. During installation and instance creation, Integration Server automatically creates the diagnostic secure port at 5543. However, you can specify a different value during installation and instance creation.
*Truststore alias for JVM truststore Integration Server includes a default truststore alias named DEFAULT_JVM_TRUSTSTORE for the JVM's default truststore <JVM>/lib/security/cacerts
*Secondary truststore alias Integration Server now allows specifying secondary truststore as part of the truststore alias definition.
*JVM Settings on the Server > Certificates page Keystore alias and truststore alias to use with javax.net.ssl properties can be set on the Server > Certificates page instead of via the watt.server.ssl.keyStoreAlias and watt.server.ssl.trustStoreAlias parameters.
*XML Schema Definition Language 1.1 support Integration Server now provides support for many of the features introduced in XML Schema 1.1. A detailed list of supported features and unsupported features can be found in the webMethods Service Development Help.
*Prefetch cache support for JMS triggers JMS triggers that receive messages from Universal Messaging can now use a prefetch, or consumer, cache. Each time the JMS trigger requests more messages from Universal Messaging, the JMS trigger can retrieve multiple messages which are then placed in a cache. The JMS trigger processes messages from the cache instead of requesting messages from Universal Messaging.
*New flag, recordIdentifierPre105Version, added in the WmFlatFile package recordIdentifierPre105Version: Determines whether the pub.flatFile:convertToString service exhibits the same behavior as the version before the 10.5 release when recordIdentifierCheck is set to true.
*Integration Server provides the configurations to make a REST API descriptor as a deployable asset in a cloud environment. Integration Server provides the following hidden configurations parameters. You can use these parameters on an Integration Server that is running on a cloud environment, to configure the host address while building Swagger or WSDL URLs.
watt.server.host.protocol: Specifies the communication protocol used by the Integration Server.
watt.server.host.virtualHost: Specifies the target host machine where the asset is deployed.
watt.server.host.port: Specifies the port of the host machine where the asset is deployed.
watt.server.host.prefix: Specifies the URL prefix that is used to access the asset.
*HTTP HEAD method support Integration Server now supports HTTP HEAD method for the REST V2 resources.
*Support for selection of REST operations for Swagger based consumer REST API descriptors Integration Server supports to choose REST operations while creating a consumer REST API descriptor using a Swagger document.
*Two-way SSL communication support Integration Server supports two-way SSL communication between the on-premise Integration Server and webMethods Cloud.
*Support for OpenAPI based provider REST API descriptors Integration Server supports to create a REST API descriptor using an OpenAPI document that conforms to the OpenAPI specification 3.0.x.
*MySQL community edition 8.x version support Integration Server supports to use MySQL community edition 8.x database driver.
*PostgreSQL 10.11 database support Integration Server supports to use PostgreSQL database 10.11 version.
*Tibero database support Integration Server supports the use of the Tibero JDBC driver to connect to a Tibero database instance.
*Caching of well-known DTDs for XHTML When an XML file references the W3C definition for the XHTML DTD, Integration Server encountered a delay and overhead for accessing a W3C server. To avoid delays encountered while accessing the W3C definition for the XHTML DTD, Integration Server now caches the definitions for the well-known XHTML DTDs.
*Custom property named $coderType for a publishable document type For instances of a publishable document type configured to publish IData-encoded documents to Universal Messaging, when this property is set to idata_xml_bytes, instructs the publishing Integration Server to encode the IData message as XML using IDataXMLCoder. The same property also instructs the receiving Integration Server (that is, the server on which the webMethods messaging trigger resides) to decode the message as XML to IData.
*Custom property named $coderType for JMSMessage/properties When using pub.jms:send to send a message to Universal Messaging, Integration Server includes a custom property to indicate that the message should be encoded as XML and decoded from XML instead of as a byte array. When invoking the pub.jms:send add the following custom property and value to the JMSMessage/properties document in the pipeline: $coderType = idata_xml_bytes. The presence of the custom property $coderType and the value " idata_xml_bytes" instructs the sending Integration Server to encode the IData message as XML using IDataXMLCoder. The same property and value also instruct the receiving Integration Server to decode the JMS message as XML to IData.
*Environment variables can be used as values of substitution variables during ACDL- based deployment. When deploying to Cloud Container or any other ACDL-based deployment, the value of an environment variable can be used as the substitution value.
*New statistic on Server > Statistics page The Server > Statistics page in Integration Server Administrator includes Started Requests statistic which displays the number of started services requests during the last polling interval.
*Kerberos authentication for outbound connections to a database through JDBC connection pools. Integration Server supports the use of Kerberos authentication for outbound connections to a database through JDBC connection pools. Integration Server provides support for using the driver's Kerberos re-authentication feature with any supported database. This feature introduces the new database URL parameter to the JDBC connection pool: ReAuthenticateUser=<username>.
*Sending of pub.publish.notification:error messages can be suppressed. Integration Server generates pub.publish.notification:error messages (documents) when a webMethods messaging trigger encounters an error or exception condition during processing. In turn the pub.publish.notification:error messages generate Adapter::Error events. These messages and events may be unwanted and can now be suppressed using the watt.server.messaging.deliverNotificationErrors server configuration parameter.
*JSON primitive type support JSON can represent four primitive types (strings, numbers, Booleans, and null) at the root level. Integration Server now supports these types a valid JSON when converting to and from JSON.
*Parquet support Integration Server provides the WmParquet package which contains built-in services for reading Apache Parquet files and converting them to IData as well as writing IData to a Parquet file.
*pub.mime services support large payloads The pub.mime services have been enhanced to support large payloads and to ensure that large payloads work. This enables the services to process data that exceeds the heap size.
Changed Items
*A web service connector for a web service descriptor that uses the current web services stack now supports the use of a custom HTTP Host header. Previously, a web service connector that is part of a consumer web service descriptor that used the current web services stack (that is, the Pre8.2 compatibility mode property is set to false) could not use a custom Host header. Integration Server would overwrite any value supplied for Host in the transportHeaders input parameter for the web service connector. Now, a custom Host header value can be supplied to the transportHeaders input parameter for the web service connector and Integration Server will not overwrite it.
*Suspending a webMethods messaging trigger that receives documents from Universal Messaging is now a pause in the subscription. Prior to Integration Server version 10.7, suspending a webMethods messaging trigger that received messages from Universal Messaging resulted in Integration Server stopping and closing the subscription. Integration Server rolled back all of the documents that had been retrieved but not acknowledged to Universal Messaging, including unprocessed documents in the trigger queue and documents currently being processed. This led to duplicates. Pausing the subscription will not cause any documents to be rolled back, thus introducing duplicates. Any messages already received by the trigger will be processed as long as the trigger is enabled and processing is not suspended.
*How Integration Server chooses a media type for a response when the request Accept header with multiple media types and none of the media types has a "q" parameter. Previously, when a request included an Accept header with multiple media types and none of the media types had a factor weighting ("q" parameter), Integration Server attempted to return the response using the last media type in the Accept header. The HTTP standard does not specify how to handle multiple media types with no "q" parameter, so this not incorrect. However, it is intuitive to assume that in this scenario, the first media type in the Accept header is the preferred one. Now, when a request includes an Accept header with multiple media types and none of the media types has a "q" parameter, Integration Server now attempts to respond with the first media type in the Accept header. If there is no content handler defined for the first media type, it attempts to respond with the second media type from the Accept header. This repeats until Integration Server finds a media type with which it can respond in the Accept header. If none are found, that is, there is not a content handler registered for any of the media types in the Accept header, Integration Server will respond with the text/html media type.
*Exception handling during an implicit or explicit transaction. If an error occurs during a transaction, Integration Server propagates an exception for this local transaction and does not proceed with service execution. Previously, Integration Server ignored the exception and executed the next step in the flow service. While the new behavior is the correct behavior, in some circumstances the proper handling of the exception for the transaction service may be undesirable. Integration Serve provides the watt.server.transaction.ignore.exception parameter to control this behavior.
*The addition of the ‘$httpMethod’ variable to the input pipeline of a service signature is configurable Previously, by default, Integration Server adds the ‘$httpMethod’ variable to the input pipeline of a service signature while processing REST requests. Now, you can configure the addition of this property to the input pipeline using the “watt.server.rest.addHTTPMethodToInputPipeline” server configuration parameter. If you set this parameter to 'true', Integration Server adds the '$httpMethod' input variable with the requested HTTP method in the input pipeline while processing a REST request. The default value is 'false’.
*Statistics log format The default format of the statistics log is now csv (comma-separated values). To change the format to hexadecimal, the previous default format, set watt.server.stats.logfile.csv to false.
*Changed statistic names on Server > Statistics page Names of statistics on the Server > Statistics page in Integration Server Administrator have been changed as follows:
Completed Req’s is now Completed Requests
Req’s per minute is now Requests in last polling interval
The Ended column is now named Completed.
*Debug logging for 0088 SOAP facility In the server log, SOAP request, SOAP response, and SOAP exception related log entries include the Thread Id and Session Age. This can help with debugging.
*webMethods messaging trigger thread usage The thread used for running the webMethods messaging trigger and listening for messages from Universal Messaging is not considered to be a document processing thread. That is, the thread that runs the trigger does not count towards the usage limit set by the Maximum Threads for document processing. Previously, the thread used to run the trigger and listen for messages counted toward the thread usage limit set by the Maximum Threads for document processing.
*Improved debug logging for OAuth authorization problems. When an access token from an external authorization server is rejected, information about the rejection is written to the server log. Set the OAuth logging facility (0010) to Debug to see the messages in the server log.
*Docker images created for Microservices Runtime or Integration Sever can be deployed to OpenShift. A Docker image for Microservices Runtime or Integration Server created with the is_container.bat/sh script can be used with OpenShift by setting the -Dtarget.configuration parameter to OpenShift when executing the createDockerfile, createPackageDockerfile or createLeanDockerfile command.
*Server log messages include thread ID To improve troubleshooting, especially under heavy load, server log messages include the ID of the thread performing the activity that generated the log message.
*Security log enhancements Integration Server now includes the following changes for the security log:
*Logging anonymous authentication requests.
*Logging the IP address of the client that initiated the request instead of the proxy server address.
*The -Dimage.name parameter now required when creating a Dockerfile for an Integration Server that runs on Windows When the is_container.bat script is being used to create a Dockerfile for an Integration Server that runs on Windows the createDockerfile command must specify the -Dimage.name parameter. This is because Microsoft now provides Windows image tags per OS version instead of a "latest" base image.
*TLSv1.0 TLSv1.0 is no longer a default enabled protocol for inbound or outbound connections.
*JSON Schema enhancements The enhanced JSON schema feature provides lucid and easy to understand message while creating and validating JSON documents using the built-in json schema services. With the enhanced support, JSON document types can be validated when used in the flow service signature at runtime.