Axway Interchange 5.12 SP3 Release Notes

Document version: August 10, 2015

Product version requirements

Optional Axway products for Interchange 5.12 require the following versions:

Axway product Version Service Pack
Sentinel 4.1.0 2
PassPort 4.6.0 6
Axway Database 4.6.0 2
Composer 3.4.2 2, Patch 1

For service pack installation procedures, see the "Apply service packs and patches" section of the Interchange Installation Guide.

New features and enhancements

REST APIs: Interchange is now delivered with a set of REST APIs for accessing configuration resources through a fixed set of operations.

Swagger client REST API: The Swagger REST API client is now delivered by default with the Interchange installation. For details about using Swagger with the the Interchange REST API, see the Interchange Developer Guide.

Acceptance of email sender by domain: Email pickups now include an option for accepting inbound emails via POP3/SMTP based on a list of authorized domains. This enables multiple individuals within a partner organization to send messages to Interchange. Wildcard characters are supported for defining groups of accepted email sending addresses.

Sequencing of consumed messages by destination delivery exchange: Interchange now offers an option (set at the level of the pickup exchange) that enables the processing of consumed messages in the order in which they are consumed, and additionally orders the processing of messages per their resolved delivery exchange.

Sentinel tracking of FTP/SFTP customer download events: When a remote partner accesses the embedded FTP/SFTP server to download a file, Interchange now generates and sends an event to Sentinel that indicates one of the following new STATES:

  • Downloading
  • Downloaded
  • Interrupted
  • Removed

For additional information about Sentinel tracking of embedded FTP/SFTP server event states, see the Interchange Administrator Guide, XFBTransfer topic.

Visibility - Sentinel performance and exchange monitoring:

  • More detailed reporting to Sentinel
  • HeartBeat node monitoring - Interchange now delivers the Interchange and Secure Relay (DMZ) node status reporting in Sentinel
  • Improved installation and configuration, including configuration of the backup Sentinel server for notifications
  • Sentinel server connection configuration from the Interchange user interface
  • Sentinel tracking of WebTrader events - Sentinel now collects information about WebTrader user and administrator actions
  • Sentinel Tracked Object evolutions - The number of events reported by the Sentinel Tracked Object for Interchange has been reduced to limit processing load

Admin user password change requirement: To enhance product security, when logging into the Interchange user interface for the first time as the admin user, the interface requires you to change the default admin password. The REST APIs will also reject an authentication request if the user (admin or other) is in this same state where a password change is required. This new validation does not apply to updated systems where the user (admin or other) already has access.

Security improvements:

  • Access control enhancements - more permissions, controls, and restrictions
  • Broader support for encryption and TLS/SSL everywhere
  • Broader configuration of encryption on partner and transaction type levels
  • PGP enhancements

Security Governance: Enhanced fine-grained roles and access controls ensure a comprehensive approach to user level permissions and restrictions. Complete support for encryption and TLS/SSL is supported throughout the product, as well as password credential encryption. Additionally, EDI transaction-type level encryption and signing validation is supported.

Windows 2012 platform support: Interchange 5.12 has been tested and validated on Windows Server 2012 R2 and SMB3 platforms. Axway confirms that Interchange additionally supports Windows Server 2012 RI with SMB3. See the Interchange 5.12 Installation Guide for specific Windows configuration requirements.

Web Services SOAP header metadata: You can now configure Interchange to generate metadata attributes from the SOAP headers of inbound Web Services messages. The metadata can be used in ways similar to other Interchange-handled metadata.

FTP message processing can now be set to the order of oldest to newest: FTP external pickup configuration now enables you to use the consumption order (consumption timestamp) to determine the message processing order.

New database / version support: Interchange now supports:

  • DB2 10.5
  • The use of DB2 HADR in cluster environments
  • Oracle 12c

Axway DB 4.6.0 support: Interchange now supports the use of Axway Database 4.6.0. To use this database, it must be installed using the dedicated Axway Database Installer.

Audit logging: Axway Interchange can now generate detailed CVS and XML formatted logs of the changes that users perform to common objects in the user interface.

Enhanced operational management: Axway Interchange now has the ability to "pause" the consumption of new messages manually. This can be helpful to "drain" the system and to complete the processing of all currently active messages before shutting it down.

MLLP transport support: Interchange now supports the exchange of messages using MLLP.

Other enhanced transports: Adapter enhancements have been made to multiple communication protocols including Email (APOP support), WebSphere MQ (V8/SSL, Multi-Instance), FTP (SAPPEND/SUNIQUE), and PeSIT.

AS4 support: Interchange provides full and certified support for the two AS4 conformance profiles: AS4 ebHandler Conformance Profile and AS4 Light Client Conformance Profile. The AS4 conformance policy is a subset of the ebMS specification. AS4 provides an entry-level on-ramp for business-to-business web services based messaging. The message packaging is governed by ebMS 3.0 and provides support for push and pull message exchange patterns.

Specifically, support is provided for:

  • One-way message push exchanges
  • One-way message pull exchanges
  • Server-mode AS4 message queuing
  • Client-mode polling of remote AS4 server queues
  • Large message splitting and joining
  • Duplicate message detection
  • Message retry and resending
  • UserNameToken and X509 user authentication

User interface enhancements:

  • Enhanced search tools including more granularity for searches of unpackaged protocols
  • Improved display controls - Pagination / scalability for displays of thousands of configuration objects
  • Updated navigation and help links
  • Permission-driven control of users' rights to change/delete all objects
  • Flexible trading partner management, with user-defined attributes

AS4 support: Interchange provides full and certified support for the two AS4 conformance profiles: AS4 ebHandler Conformance Profile and AS4 Light Client Conformance Profile. The AS4 conformance policy is a subset of the ebMS specification. AS4 provides an entry-level on-ramp for business-to-business web services based messaging. The message packaging is governed by ebMS 3.0 and provides support for push and pull message exchange patterns.

Specifically, support is provided for:

  • One-way message push exchanges
  • One-way message pull exchanges
  • Server-mode AS4 message queuing
  • Client-mode polling of remote AS4 server queues
  • Large message splitting and joining
  • Duplicate message detection
  • Message retry and resending
  • UserNameToken and X509 user authentication

User interface enhancements:

  • Enhanced search tools including more granularity for searches of unpackaged protocols
  • Improved display controls - Pagination / scalability for displays of thousands of configuration objects
  • Updated navigation and help links
  • Permission-driven control of users' rights to change/delete all objects
  • Flexible trading partner management, with user-defined attributes

WebSphere MQ 8.x support: Interchange now provides JARs in support of WebSphere MQ 8.x

CRL retrieval using HTTPS URLs: You can now configure automated CRL checking and downloading using HTTPS URLs, in addition to the HTTP and LDAP URLs that were already supported.

Documentation updates: The following documents have been updated to take into account new product features and enhancements:

  • Interchange online help
  • Interchange Administrator Guide
  • Interchange Installation Guide
  • Interchange Developer Guide
  • Interchange Security Guide

Discontinued functionality

The following features have been discontinued in Interchange 5.12:

  • Platforms
  • Interchange 5.12 is only supported on Windows, Linux, AIX, and Solaris. See the Interchange Installation Guide for more details.
  • 32-bit support
  • From this release, Interchange is installed only in 64-bit mode.
  • EBICS
  • Interchange 5.12 does not support EBICS.
  • ePedigree
  • ePedigree is not embedded in Interchange 5.12.
  • Transaction Director
  • As of this release, Transaction Director is no longer delivered. End-to-end visibility is now provided by Sentinel.
  • Synchrony Database 4.4
  • Synchrony Database 4.4.0 is not supported with Interchange 5.12. Users must upgrade to Axway Database 4.6.0.
  • Anonymous user for staged HTTP discontinued
  • Interchange 5.12 no longer supports anonymous user feature. Instead, there is now a default remote user included with the deployment.
  • Persistable event queue discontinued
  • The persistable event queue for Sentinel is no longer supported.

Virtualization support for x86/x64 based systems

Axway generally supports product installation and operation on VMware virtual machine platforms. For Interchange support cases, Axway will investigate and troubleshoot a problem until it is determined that the problem is due to virtualization. If Axway suspects that a specific defect occurs because the system is virtualized and we cannot reproduce the problem in a non-virtualized environment, we will request you to either reproduce the defect on a non-virtualized environment and to contact the virtualization vendor for a resolution, or to switch to a non-virtualized platform.

Important note for FIPS implementations

This announcement applies to all Interchange implementations that adhere to the Federal Information Processing Standards (FIPS). In Interchange, FIPS is a license key-enabled option that turns on FIPS-compliant implementations of certain cryptographic algorithms. 

The security provider libraries for FIPS have been updated in Interchange 5.12. There is now stricter enforcement of the allowable key lengths in RSA Key Pair Generation, aligned with the following excerpt of the requirement. Full NIST requirements are available at:
http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf.

"This Standard specifies three choices for the length of the modulus (i.e., nlen): 1024, 2048 and 3072 bits. Federal Government entities shall generate digital signatures using one or more of these choices."

As a result, cryptographic functions that use alternate key lengths (for example 512 or 4096) will be blocked while in FIPS mode. This could render trading with existing certificates inoperable, including certificates imported from trading partners. Administrators of existing Interchange installations who upgrade to Interchange 5.12, and who have keys of alternate lengths (512 and 4096 are most common) must either:

  • Update (import new, or re-generate) any certificates that are not compatible (those not of a 1024, 2048, or 3072 length)

- or -

  • Disable the key length enforcement. See Override FIPS key length validation.
    Caution: Disabling key length validation will make your environment non-FIPS compliant, and non-compliant with the Federal standard. It should only be used as a temporary measure.

Known issues

Interchange 5.12 known issues

  • Sentinel displays incorrect order for XFBTransfer events
  • Issue: Depending on the version of the XFBTransfer tracked object you are using, Sentinel may incorrectly record and display the order of events tracked by this tracked object.
  • Workaround:
    1. Unzip the contents of interchange.zip, located at Components\_<version>\extras\sentinel, and import the XFB_ALL_EN.xml file into Composer.
    2. In Composer, go to the General subtab and expand the Tracked Object node.
    3. Double-click the XFBTransfer Tracked Object in the list of installed Tracked Objects.
    4. Select the Advanced tab.
    5. In the Event display order section, select the State order option, and in the "State order" field add the following states:
      [TO_EXECUTE],[SUPPLIED],[CONSUMING],[CREATED],[RETRY], [RESEND],[REPROCESS],[PENDING],[APPROVED],[UNPACK],[PACK], [SUSPENDED],[AVAILABLE],[PRODUCING],[SENDING],[VERIFIED],[RECEIVING], [INTERRUPTED],[REJECTED],[CANCELED],[SENT],[RECEIVED],[TERMINATED], [DELIVERED],[ROUTED],[ENDED_TO_ACK],[TO_ACK],[ACK_COMPLETE], [ACKED],[NACKED],[DOWNLOADING],[DOWNLOADED],[ACCESSED],[REMOVED],[PURGED]
    6. Deploy the modified tracked object from Composer to your runtime server.
  • Details cannot be seen for a CSOS user created through PassPort AM integrated with an external LDAP
  • Issue: A CSOS user mapped with a role created in an external LDAP integrated with PassPort, and logged in to Interchange with the permissions of View trading configuration, Manage community configuration, and Approve CSOS orders, does not see the User / My Profile link in the upper right-hand corner and cannot add a personal certificate.
  • Workaround: Re-configure PassPort with the following steps:
    1. Go to PassPort > Administration > Identity Store > [your LDAP name].
    2. Go to 5. User Mapping.
    3. Set the getUserFilter value to objectClass=organizationalPerson.
    4. Set the remaining six fields to the value cn.
    5. Save the changes.
    6. Log in to Interchange using your CSOS LDAP user login.
    7. You should now be able to see the User / My Profile link and be able to add a personal CSOS certificate.
  • Partner profile import: Slow or blocking import process when auto-importing 20 or more partner profiles to a two-cluster environment
  • This issue is under investigation and is scheduled for resolution in a future Interchange release.
  • Swagger API client: User can continue to execute operations after logout
  • When using Chrome and Firefox browsers, after logging out of a Swagger session, a user can call operations as though they had not logged out. This problem occurs because these browsers remember and automatically provide the login credentials. Credentials are cleared from memory when the browser window is closed.
  • Swagger API client: User cannot log in using the login method
  • Issue: The REST login method asks for the authorization header, which is a single string composed of a hash of the username and password. In most cases, the user will only know the username and password.
  • Workaround: The user can directly call the desired operation. This triggers the login, causing the browser to display a user-friendly prompt for the username and password.
  • Swagger API client: User cannot import or export certificates
  • When a user accesses the import operation, it is not possible to specify the path to the certificate to be imported. For the export operation, it is not possible to specify where the exported file is to be saved. This is because the Swagger client does not support the “application/octet-stream” content type used by the import/export operations in the Interchange REST API.
  • SSO: SSO is not supported for this release.
  • Interchange installer offers non-functioning "cluster node" option
  • When installing Interchange, select the Single (install on a single machine) option whether installing on a single machine or on a cluter node. Selecting the Cluster (install on a cluster node) option will not work and may cause errors.
  • Interchange clustered implementations with X.400 subsystems: Starting any trading engine temporarily stops the X.400 subsystem
  • In Interchange active/active clustered configurations with an X.400 delivery exchange configured, when stopping and then restarting any trading engine in the environment, the X.400 subsystem is temporarily suspended for a period of approximately 15 seconds, which causes a temporary suspension of X.400 services.
  • The resolution of this defect is being studied for a future release.
  • Peer Network: Trusted root certificate is not deleted from backup peer
  • If a user creates a MLLP with TLS application pickup and adds a trusted root certificate in the MLLP embedded server's "trusted root certificates" tab, then the certificate is correctly cloned to the backup machine. However, if a user then performs an untrust action on the trusted root certificate of the main network, the untrusted status is not propagated to the backup peer network, and the certificate is still available.
  • Peer Network: When Peer Network messages fail due to transport errors, the messages are resent.
  • Peer Messages are a instantaneous snapshot of network status and have no value when resent later.
  • Work around:Work around: Reset Reliable Messaging resend attempts to "0". To do this:
    • In the Interchange UI, select Trading configuration > Manage trading configuration.
    • Select Change default collaboration settings.
    • Select the Reliable messaging tab.
    • In the "Resend attempts" field, enter the value 0.
    • Click Save changes.
  • messagePurgeTool does not complete purge action
  • The entire cluster must be stopped when purging all messages using messagePurgeTool with the -deleteAll or -deleteAllSkipFiles options.
  • With ebXML intermediary (SMTP), message cannot be delivered to external SMTP server
  • When setting up an ebXML intermediary (SMTP), an embedded SMTP server must be used for the receiver. If the external SMTP server is used, the trading to the receiver fails.
  • FTPS outbound transfer fails when Secure Relay Routing Agent runs on AIX
  • For Interchange installations with Secure Relay, when the Secure Relay Routing Agent (RA) runs on an AIX machine, FTPS outbound transfers fail when any of the following cipher suites are used as overrides on the partner delivery:
    • SSL_RSA_WITH_DES_CBC_SHA
    • SSL_DHE_RSA_WITH_DES_CBC_SHA
    • SSL_RSA_EXPORT_WITH_RC4_40_MD5
    • SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
    • SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA.
  • Workaround: Select an alternate cipher suite on the partner delivery.
  • WebTrader password policy is reset to the default values after upgrading from Interchange 5.10/5.10.1 to 5.12
  • WebTrader password policy values are not preserved on upgrade to Interchange 5.12 and need to be manually re-entered.
  • MQ/SSL - Cipher SSL_RSA_WITH_RC4_128_SHA does not work with 8.0 server/jars
  • Using MQ 8.0 forces the support of a new cipher spec/cipher suite combination (TLS_RSA_WITH_RCA_128_SHA256/SSL_RSA_WITH_RC4_128_SHA) from the unsupported combination (RC4_SHA_US/SSL_RSA_WITH_RC4_128_SHA). This change by IBM is documented and can be accessed from the following link: http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q113220_.htm
  • AS4: SoapHeaderAndBody packaging method is not supported
  • Messages that are sent over AS4 can be packaged using the BodyOnly method only. SOAPHeaderAndBody is not currently supported. This issue will be fixed in a future release.
  • AS4: Incorrect receipt linking
  • A receipt for a failed receipt is not linked with the initial receipt on the receiver, when the first receipt is signed with a certificate belonging to another partner.
  • AS4: Incorrectly signed synchronous push receipts are not rejected
  • If an AS4 message push sender is configured to expect synchronous receipts for sent messages that are signed with the SHA 256 algorithm, and the returned receipt is signed with SHA1, then the original push sender does not reject the incorrectly signed receipt.
  • AS4: Wrong signature generated when using SOAP body with CDATA and MTOM in combination
  • When "Sign Message" and "Use MTOM" are enabled in collaboration settings, and a SOAP body payload has both CDATA and base64 encoded content, the wrong signature value is generated. When the receiver receives this message, it incorrectly fails the message and generates a "The signature or decryption was invalid" SOAP fault.
  • AS4: Username tokens are not encrypted for asynchronous automatically-generated receipts in response to pulled user messages
  • Automatically-generated receipts contain an unencrypted username token in the following scenario:
    • User messages are consumed by a client in Pull mode where (a) "generate receipts" is enabled by the AS4 pulling client, and (b) both "encrypt" and "usernameToken" are enabled in the server's AS4 collaboration settings.
  • The same behavior occurs when asynchronous receipts are generated in push mode for successfully-processed split messages.
  • AS4: Reconstructed (split and rejoined) messages fail if the rejoined packaged size exceeds the maximum configured message size
  • Although the individual elements of a split message do not exceed the "Restrict maximum file size for this transport" setting, if the rejoined message exceeds the maximum size, the message fails.
  • AS4: No negative response receipt is returned when the splitting fragment numbering is incorrect
  • If the splitting fragment number is set to a valid value, but that value corresponds to another fragment, no negative response receipt is returned. The reconstructed message fails with the reason: "Failure: java.io.IOException: End of Stream, but boundary not found". No negative response receipt is generated.

  • AS4: Unable to specialize the as4.fragmentSize value for inbound fragments at trading pickup level
  • When consuming split message fragments on an AS4 community trading pickup, it is not possible to specialize the as4.fragmentSize restriction on the trading pickup. Currently as4.fragmentSize is a global system property and applies to both outbound and inbound flows.
  • AS4: Unable to configure a partner-specific fragment size in collaboration settings
  • Currently, metadata can be added only in the message attributes section of the polling client and AS4 protocol exchange.
  • AS4: Split compression algorithm is set to "gzip" on the first fragment and to "application/gzip" on the original message and other fragments
  • When a file is split into multiple fragments, if the MIME/GZIP algorithm was selected for the MIME envelope compression under AS4 collaboration settings/split messages, then on the sender side in Message Tracker, "Split Compression Algorithm metadata" is set to "gzip" on the first fragment and to "application/gzip" on the original message and other fragments. The expected behavior is for the algorithm to be the same for all fragments and for the original payload.
  • AS4: Upgrades from earlier implementations
  • Interchange offers native AS4 support as a license-enabled feature from version 5.12 only. In earlier versions, it was possible to implement AS4 trading through Web Services features combined with custom plug-in code. The migration of these custom AS4 implementations to 5.12 native features is not supported by the upgrade code, and must be handled through manual reconfiguration.
  • System import fails in update mode
  • When importing a saved (exported) system backup in update mode, if some objects of the backed up system have already been imported, the imported system may fail to import all objects. This issue will be fixed in a future release.
  • Axway Database support
  • Axway Database is ONLY supported on Linux, Windows, and Solaris. For all other operating systems, you must use another supported database or change to another operating system when upgrading to Interchange 5.12.
  • To enable recovery freom possible uninstall issues, make a bakcup of the system and the database prior to the update to 5.12
  • Upgrade limitation: Message Tracker fails to display message details
  • After upgrading a Interchange 5.10 implementation to Interchange 5.12, Message Tracker no longer displays message-processing details of messages that were processed prior to the Interchange 5.12 upgrade.
  • Upgrade limitation: Recreate Secure Relay DMZ nodes
  • After upgrading from Interchange 5.10 to Interchange 5.12, you must remove all DMZ nodes and then recreate and redeploy them in your DMZ. DMZ zones do not need to be recreated.
  • For a detailed description of how to add Secure Relay DMZ nodes, see the Interchange Administrator Guide.
  • REST API - Unable to add partner with name that contains non-ASCII character
  • Problem: By default, Interchange does not support the use of non-ASCII characters in partner names when adding partners through the REST API.
  • Workaround: Go to Interchange_install_directory]/conf/jvmArguments.xml, and add the property:
  • <Property key="file.encoding">UTF-8</Property>
  • Cipher suites fail with secure protocols (FTPS, HTTPS, ...)
  • The following cipher suites do not function in support of secure protocol connections in Interchange 5.12:
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    • TLS_RSA_WITH_AES_256_CBC_SHA256
    • TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
    • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
    • TLS_RSA_WITH_NULL_SHA256
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    • TLS_RSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
    • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
    • TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
    • TLS_ECDH_RSA_WITH_RC4_128_SHA
    • TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
    • TLS_ECDH_RSA_WITH_NULL_SHA
  • This issue will be fixed in an upcoming service pack.
  • RHEL 6 / 7 requirement for X.400 support
  • By default, the Red Hat Enterprise Linux 6 and 7 x86_64 operating systems install without installing the 32-bit library (/lib/ld-linux.so.2) needed by the trading engine X.400 subsystem. To enable Interchange with X.400 installed on RHEL 6 or 7, install the package glibc.i686 from the RHEL installation media.
  • Passive FTP data connections directed by Secure Relay to wrong trading engine
  • This issue can be due to the following reasons:
    1. A trading engine starts on an existing cluster, after trading engines have been added or removed from the UI configuration. In this case, the sub-range of passive ports defined for the new trading engine's embedded FTP server may not be available on the Secure Relay Router Agent.
    2. The workaround is to restart all running trading engine nodes that host the embedded FTP server, on each machine in the cluster. This forces removal of listen ports, and frees the ports in the passive FTP range on the Secure Relay Router Agent machine.
    3. The embedded FTP server port ranges of two trading engine nodes overlap.
      Important: Do not overlap port ranges on more than one embedded server.
  • System import limitation: Processing fails on messages that were in "Retry Scheduled" state
  • In cases where you stop the trading engine node and import a system backup and then restart the node, any messages that were in "Retry Scheduled" state will fail on send attempts after restart. This is because the system import logic modifies the outbound ID of the target exchange partner. These in-process messages that are failed and any existing messages already in a "Failed" or "Delivered" state are now not possible to Resend or Reprocess.
  • System import limitation: Directory path folders of SFTP/FTP missing after system import in update mode
  • Issue: If you have any application pickups or community-owned trading pickups that are of the type FTP or SFTP, and you create a system export, when you import the system profile in "update mode" the directory paths are deleted and are not recreated.
  • Resolution: After system import, manually recreate directory paths. FTP and SFTP paths have the following structures:
    • FTP trading -
    • [shared]/common/data/ftp/users/trading/[ftp_username]/[dir_from_dir_tab_in_trading_pickup]
    • SFTP trading -
    • [shared]/common/data/ssh/users/trading/[sftp_username]/[dir_from_dir_tab_in_trading_pickup]
  • MQSeries 7.x server access
  • Interchange 5.12 installs updated WebSphere MQ jars. You may need to modify the MQSeries configuration in order to enable an existing MQ 7.x configuration to work after upgrading to Interchange 5.12.
  • In some cases, the MQ jars that are updated in Interchange 5.12 enable additional MQ 7.x security features. Depending on your configuration, you may need to do one or more of the following:
  • Update channel authentication records
  • Add or update authentication or object authorities
  • Add an MQ user to an Interchange MQ exchange point that formerly worked anonymously
  • We recommend that you contact your MQ administrator if problems are noted.
  • MQ/SSL cipher suite selection – In the Interchange user interface, when configuring an IBM WebSphere MQ pickup or delivery exchange with SSL, it is necessary to select the SSL cipher suite to use. The cipher suite that you select must correspond to a specific cipher specification that the IBM server supports. The following table indicates the correct relationship between specification and cipher suite. Additionally, cipher suites preceded by an asterisk (*) are used to connect to a FIPS provider and, although they are displayed, they are not currently supported in Interchange:
  • Cipher specification (MQSeries name) Interchange JSSE cipher suite
    DES_SHA_EXPORT1024 *SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
    RC4_56_SHA_EXPORT1024 *SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
    RC4_MD5_EXPORT SSL_RSA_EXPORT_WITH_RC4_40_MD5
    RC2_MD5_EXPORT *SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
    FIPS_WITH_3DES_EDE_CBC_SHA *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
    TLS_RSA_WITH_3DES_EDE_CBC_SHA *SSL_RSA_WITH_3DES_EDE_CBC_SHA
    TLS_RSA_WITH_AES_128_CBC_SHA *SSL_RSA_WITH_AES_128_CBC_SHA
    TLS_RSA_WITH_AES_256_CBC_SHA *SSL_RSA_WITH_AES_256_CBC_SHA
    DES_SHA_EXPORT SSL_RSA_WITH_DES_CBC_SHA
    NULL_MD5 SSL_RSA_WITH_NULL_MD5
    NULL_SHA SSL_RSA_WITH_NULL_SHA
    RC4_MD5_US SSL_RSA_WITH_RC4_128_MD5
    RC4_SHA_US SSL_RSA_WITH_RC4_128_SHA
  • * Not currently supported. Do not select this cipher suite.
  • Failover and sequential delivery – The ability to deliver messages in sequence in the case of a failover is not always guaranteed. This issue will be resolved in a future release.
  • General Web Services limitations:
    • Interchange 5.12 supports Web Services on the trading (partner side), but not on the application side.
    • By default, WS-Addressing must be used in provider mode. To disable the need for WS-addressing, refer to the alternate axis2NoWSAddressing.xml file in your WS pickup configuration.
    • The Interchange WSDL wizard currently only supports the generation of WSDL definitions. These definitions cannot be edited afterwards. To change the WS interface, you must either regenerate a new WSDL using the wizard, or edit the WSDL manually.
  • Web Services provider mode HTTP connection fails to close – When configuring Web Services provider mode for one-way communication with faults returned to client, on the Web Service trading pickup you must normally select the option "Synchronous response generated in backend" in order to enable sending of the fault file to the requesting service consumer. However, if the incoming request message does not trigger a fault and is correctly delivered to the back end, the HTTP connection is kept open until timeout on the client side.
  • Workaround – For a one-way Web Service provider configuration, do not select the option "Synchronous response generated in backend". This prevents the provider from sending a fault message, but allows the connection to close normally after receiving the client request message.
  • Uninstalling Interchange in Windows non-service mode – All Interchange servers must be stopped before Interchange can be properly uninstalled. In Windows environments when Interchange components are installed in Windows Service mode, the uninstaller automatically stops all servers before proceeding with the uninstall. However, if you installed the components in manual start mode, you must be sure to manually stop all components before uninstalling.
  • EBICS - EBICS is not supported in Interchange 5.12.
  • Secure Relay restrictions:
    • Handshake fails in the DMZ with Security Termination enabled, when the Java version on the receiving DMZ is 1.7.0_71 or higher, and when using any of the following cipher suites:
      • TLS_RSA_WITH_AES_256_CBC_SHA256
      • TLS_RSA_WITH_AES_128_CBC_SHA256
      • TLS_RSA_WITH_NULL_SHA256
    • Note: When the Java version is jre1.7.0_45, jre1.7.0_60 or jre1.7.0_60, the transfer is successful with all TLSv1.2 ciphers.
    • The use of the "TLS_RSA_WITH_NULL_SHA256" cipher is not recommended.
    • Inbound FTPS active in the DMZ with Security Termination enabled is not supported.
  • MQ JAR version conflicts block trading - You cannot have multiple versions of JMS provider JAR files in the ...Interchange/site/jars or ...Interchange/corelib/db/ directories. For example, if you already have v7.5 IBM MQ JARs and then add V8.0 JARs, you must remove the older JARS to avoid conflicts.
  • Cannot create an embedded WebDAV SSL partner delivery - When defining a WebDav embedded SSL server to support a WebDav type partner delivery, you cannot successfully add a trusted SSL root certificate linked to the partner. This prevents the creation of a valid WebDav delivery.
  • FTPS outbound transfer fails when Secure Relay Routing Agent runs on AIX
  • For Interchange installations with Secure Relay, when the Secure Relay Routing Agent (RA) runs on an AIX machine, FTPS outbound transfers fail when any of the following cipher suites are used as overrides on the partner delivery:
    • SSL_RSA_WITH_DES_CBC_SHA
    • SSL_DHE_RSA_WITH_DES_CBC_SHA
    • SSL_RSA_EXPORT_WITH_RC4_40_MD5
    • SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
    • SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA.
  • Work around: Select an alternate cipher suite on the partner delivery.

Related documentation

Axway Interchange is accompanied by a complete set of documentation, covering all aspects of using the product. These documents include the following:

  • Interchange online help
  • Interchange Installation Guide
  • Interchange Administrator Guide
  • Interchange Developer Guide package

All Axway documentation is available from Axway Sphere at support.axway.com.

Support services

The Axway Global Support team provides worldwide support 24/7. You can find all support numbers by country on Axway Sphere at support.axway.com.

In addition, you can download the latest information from Axway Sphere relating to Interchange including:

  • Technical articles
  • Information about supported platforms
  • Service Packs and Patches
  • FAQs

For more information about Axway training services, go to: www.axway.com.


Copyright © Axway Software 2015
All rights reserved

Related Links