Release 10.3

Support for using the --time option (-t) with docker stop command. The --time option specifies how long Docker waits before killing a container. Use the --time option to specify a waiting time long enough to allow Integration Server to shut down gracefully.

Custom security area for security logging. The new method com.wm.app.b2b.server.ServerAPI.logSecurity makes it possible for applications to write entries to the security log as logging for the Custom security area.

SAG_IS_AUDIT_STDOUT_LOGGERS environment variable Specifies the audit loggers to write to the console (STDOUT). When an audit logger writes to STDOUT it is considered an auxiliary output which means the logger will still write to the specified log destination of file or database.

EXTERNALIZE_PACKAGES environment variable Instructs the Integration Server running in the Docker container to load the packages located in one of the specified directories at startup.

SAG_IS_LICENSE_FILE environment variable Specifies the license key to be used with an Integration Server running in a Docker container which allows the license key to be changed without rebuilding the Docker image for the Integration Sever.

Support for ICAP preview headers Integration Server now supports an ICAP preview header that allows the ICAP server to scan the preview content instead of scanning the entire request from Enterprise Gateway.

Support for OAuth grant types Resource Owner Password Credentials and Client Credentials Integration Server now supports the Resource Owner Password Credentials and Client Credentials grant types.

JMS trigger restart task If a JMS trigger does not start when a JMS connection alias starts, Integration Server schedules a task to retry starting the JMS triggers and then continues with activities associated with starting the JMS connection alias. The trigger restart task, which runs in its own thread, attempts to restart the failed JMS triggers at a set interval.

Updated messageNumber key for reliableMessagingProperties. Specifies the message number in the message sequence. In cases where there are several message numbers in the message sequence, you can specify a custom message number.

Serial webMethods messaging triggers that receive documents from Universal Messaging now process documents from all publishers in publication order in a load-balanced fashion. Previously, a webMethods messaging trigger with serial processing corresponded to a priority named object on a channel on Universal Messaging server. Now, a serial webMethods messaging trigger corresponds to a serial durable subscription (named objects in Universal Messaging are now called durable subscriptions). This provides processing in publishing order for a serial trigger in a cluster or a non-clustered group of Integration Servers. Over time, it allows for the Integration Server in a cluster or non-clustered group to process messages in a load balanced fashion.

Server log entries written to the console now include the identifier “ISSERVER” To help differentiate server log messages from other messages written to the console, server log entries include the identifier “ISSERVER”. Previously, there was no identifier.

Allowed Grants property for registering clients When registering clients for use with an Integration Server acting as an authorization server for OAuth, you can specify the grant types a client can use. Previously, all registered clients could use the authorization code grant type and the implicit grant type. All registered clients migrated from an earlier version of Integration Server will have the Authorization Code Grant type and Implicit Grant type selected.

Token endpoint authorization property for global OAuth settings Specifies whether the token endpoint accepts an existing session or requires credentials for authentication. Previously, the token endpoint service always accepted requests from clients that had an active session on Integration Server and did not provide an option to require authentication every time the client requests a new access token or refreshes an existing access token

Improved visibility into sending messages from client side queue to Broker. To improve visibility and control of sending messages from the CSQ to the Broker for webMethods messaging, Integration Server introduces the following:

The maximum number of retry attempts that Integration Server makes when publishing a message from the CSQ to Broker is now configurable. Previously, the maximum number of retries was 5 and could not be changed. For details about the server configuration parameter watt.server.publish.maxCSQRedeliveryCount, see below.

At the debug level for facility 0098 Dispatcher, the Integration Server now logs additional messages that indicate why an attempt to send a message from the CSQ to Broker failed.

Existing log entries as well as the newly introduce log entries for facility 0098 Dispatcher now include the message ID and the name of the publishable document type for which the message is an instance document.

Ownership of files in Docker image is changed to non-root user When running the is_container.sh script to create Docker images, ownership of the files is changed to non-root (sagadmin) user. The optional –Dimage.createUser parameter can be passed to the createDockerfile, createLeanDockerfile, or createPackageDockerfile commands to control the ownership of the files in the Docker image.

Client ID for webMethods messaging triggers that receive message from Universal Messaging For webMethods messaging triggers created in Integration Server 10.3, the client ID of the trigger is now the trigger’s shared durable name which is as follows:

Where clientPrefix is the Universal Messaging connection alias used by the trigger, triggerName is the fully qualified name of the trigger where periods and colons are replaced by double underscores. Previously, the client ID naming convention for a trigger that receives message from Broker was the same as the client ID naming convention for a trigger that receives messages from Universal Messaging.

JSON payload for invoking a REST v2 resource Prior to Integration Server 10.3, the JSON payload for a REST request of type POST, PUT, or PATCH needed to include the root element of a document in the service signature. This was necessary even though the Swagger document generated for the REST API descriptor did not include the root document. Beginning with Integration Server 10.3, the request payload should match the Swagger definition – not the service signature. If there is a root element in the service signature input, only the contents of the root element need to be provided in the request payload.