Axway API Gateway 7.6.2 Release Notes

Document version: 30 October 2018

Summary

API Gateway is available as a software installation or a virtualized deployment in Docker containers.

The software installation is available on UNIX/Linux. For more details on supported platforms for software installation, see System requirements in the API Gateway Installation Guide.

Docker deployment is supported on UNIX/Linux. For a summary of the system requirements for a Docker deployment, see System requirements in the API Gateway Installation Guide, and for more details see What you need before you start in the API Gateway Container Deployment Guide.

New features and enhancements

The following new features and enhancements are available in this release.

Elastic topology container deployment

The new elastic topology container deployment architecture brings flexibility to capacity planning.

  • Deploy API Gateway in Docker containers and use Kubernetes for container orchestration.
  • Easily scale the capacity of your environment up or down to respond to changes in load.
  • Auto healing to quickly start a new instance in case of a failure.
  • Choose the deployment architecture best suited to your needs: in addition to elastic topology, API Gateway7.6.2 also supports the classic deployment architecture that uses Node Managers.
  • Deploy configuration changes directly from Policy Studio to API Gateway containers for development testing (supported in development environments only).
  • Redirect the trace and traffic logs to stdout instead of to separate files. This allows the logs to be read directly from each container by an external logging service.
  • Use Apache Cassandra as a distributed data store.

For more details, see the API Gateway Container Deployment Guide.

Daily rollover and purging of traffic monitoring data

Traffic monitor settings have been enhanced to include new transaction file management settings including daily rollover and purging options. For more information, see the API Gateway Administrator Guide.

Support for /tmp directory mounted with noexec

Support has been added for installing or running API Gateway on a UNIX/Linux system which has the /tmp directory mounted with noexec. For more information, see the API Gateway Installation Guide.

Visual Mapper support for multiple schema inputs

API Gateway Visual Mapper now includes support for multiple schema inputs:

  • The Create Map dialog has been updated to enable selection of multiple source schemas. The Visual Mapper Data Map Editor has been updated to allow designing a map relationship with multiple input schemas. For more details, see the API Gateway Visual Mapper User Guide.
  • The Execute Data Map filter has been updated to support visual maps with multiple schema inputs. This provides for the mapping of message attributes to the inputs defined by the visual map. Previously, only the content body of a message was provided to the visual map for conversion. For more details, see the API Gateway Policy Developer Filter Reference.

kpsadmin diagnostics

A new diagnostics option has been added to the kpsadmin command to help diagnose common KPS and Apache Cassandra configuration issues. For more details, run kpsadmin --help or see the API Gateway Key Property Store User Guide.

OAuth configuration in Policy Studio

Use Policy Studio to easily configure API Gateway as an OAuth authorization server and OAuth resource server instead of using the deployOAuthConfig script. For more details, see Deploy OAuth configuration in the API Gateway OAuth User Guide.

Smooth rate limiting

The enhanced Throttling filter strictly enforces high volume over short interval rate limits with near zero error rate even under extremely high volumes.

  • Use the new smoothing rate limiting algorithm with elastic topology deployment where the number of API Gateway instances handling requests can scale in and out very quickly.
  • Match the rate limits with your load balancing strategy, and distribute them among the running instances equally (round robin).

For more details, see Configure rate limiting in the API Gateway Policy Developer Guide and Throttling in the API Gateway Policy Developer Filter Reference.

Axway AMPLIFY menu

You can now connect to Axway services and Axway AMPLIFY platform straight from the API Gateway Manager UI. For more details, see Axway AMPLIFY™ Platform.

Improved threat reporting

When ModSecurity blocks incoming requests, the threat report is saved in a message attribute that can, for example, be forwarded to third-party monitoring systems. For more details, see Manage API firewalling in the API Gateway Administrator Guide.

Policy Studio filter enhancements

This release contains several other filter enhancements:

  • The OCSP Client filter has been enhanced to use improved time validation logic when validating OCSP responses.
  • The Connect to URL filter has been enhanced with new fields that allow reading the response message body into API Gateway memory and releasing previously opened connections.

For more details, see the API Gateway Policy Developer Filter Reference.

Third-party library updates

The following third-party libraries have been updated:

  • Apache Cassandra has been upgraded to version 2.2.12
  • Log4j has been upgraded to version 2.8.2.
  • Jython has been upgraded to version 2.7.1.

New documentation

This release contains the following new documentation.

API Gateway Container Deployment Guide

  • This is a new guide that describes how to deploy and run API Gateway and API Manager in containers and elastically scale the capacity up or down as required.

API Gateway Apache Cassandra Administrator Guide

  • This is a new guide that describes how to set up and use the Apache Cassandra database for API Gateway and API Manager. It includes information on best practices and tuning, setting up high availability, and backup and restore.

API Gateway Analytics User Guide

  • This is a new guide that describes how to set up and use API Gateway Analytics to monitor and report on message traffic between API Gateway instances and services, remote hosts, and clients.

Limitations of this release

This release has the following limitations.

Elastic topology container deployment

When using an elastic container deployment:

  • Traffic monitor data for a specific API Gateway instance does not persist in the event of that instance container stopping. However, you can redirect the trace and traffic logs to stdout instead of to separate files, which allows the logs to be read directly from each container by an external logging service.
  • Distributed Ehcache is not supported. However, you can use Apache Cassandra as a distributed data store.
  • To upgrade from an earlier version to 7.6.2, you must first upgrade to a 7.6.2 classic deployment and then migrate to an elastic container deployment.

For more details, see the API Gateway Container Deployment Guide.

Other deployment options

This release is not available as a virtual appliance, or as a managed service on Axway Cloud.

Removed features

In our efforts to continually upgrade our products in response to the needs of our customers’ IT environments, Axway occasionally discontinues support for some capabilities. API Gateway 7.5.3 is the last release that includes the following capabilities, which have been removed from the 7.6.2 release:

  • Axway physical appliance deployment option.
  • API Gateway on Windows servers. Only the following developer tools are available on Windows:
    • Policy Studio
    • Configuration Studio
    • Package and Deployment Tools

The following capabilities have also been removed:

  • The ConnectToUrlFilter.removePreviousConnections=true system property is no longer available. However, you can still configure this feature by enabling the Release previously opened connection option on each Connect to URL filter that requires this behavior.

Known issues

The following are known issues for this release of API Gateway.

Documentation might contain references to removed features

Documentation might contain references to removed features (for example, hardware or virtual appliances, or Windows support). This does not mean that the removed features are still supported, and the references should be ignored.

Team development – Conflicts when adding dependencies between template projects

In Policy Studio, if you create a new common project from the Common Project template and a new API project from the API Project template and you try to add the API project as a dependent project of the common project, a conflict occurs.

This is due to an issue with the Axway PassPort repositories containing conflicting (randomly generated) password fields in the common and API projects.

As a workaround, use the Entity Explorer tool to set the value of the field FIELD_KEYSTORE_PASSWORD to the same value in both the common and API projects. For more information on using the Entity Explorer, see the API Gateway Developer Guide.

Related issues: RDAPI-11159

Upgrade – Changes in order of execution of database statements

If you are upgrading your API Gateway installation, and you are using a Retrieve from or write to database filter with multiple database statements in your old installation, you must review the ordering of the database statements after you upgrade.

In earlier versions of API Gateway multiple database statements were not executed in the order they were listed in the filter. Now, database statements are executed in the order they are listed in the filter. After upgrading you must ensure that multiple database statements are listed in the order they should be executed.

Related issues: RDAPI-11455

TLS for non-default JRE

If you select an alternative JRE instead of the default JRE during the installation and want to enable Cassandra to use TLS, you must install Java Cryptographic Extension (JCE) Unlimited Strength Jurisdiction policies for your JRE.

Save to File filter

The Save to File filter may cause up to 2% of the transactions to fail with the following error:

java.lang.RuntimeException: No such file or directory. cannot remove file '/path/to/filename'

This happens in the following cases:

  • The Save to File filter is pointing to a directory where the number of files has already reached the set Maximum number of files limit.
  • The Save to File filter is part of a policy that is under heavy concurrent load.

If this happens, it is recommended to use a periodic job scheduled at an appropriate frequency for the "housekeeping" of the directory, and not to rely on the Save To File filter to do this.

Related issues: RDAPI-7619

WebSocket protocol

  • If you use %h in the Access Log initial string and your DNS configuration is not correct (for example, a name server configured on /etc/resolv.conf is not reachable), the HTTP Long Polling connections have a time delay at the API Gateway. WebSocket connections are not affected.
  • Adding the same URL for a WebSocket path and a HTTP path is not supported. You get an error message if you try this in Policy Studio.

JWT filters

When you operate in FIPS mode, the implementation from the default, non-FIPS provider is invoked, if any of the following algorithms is selected in the JWT Signing filter:

  • RSASSA-PSS using SHA-256 and MGF1 with SHA-256
  • RSASSA-PSS using SHA-384 and MGF1 with SHA-384
  • RSASSA-PSS using SHA-512 and MGF1 with SHA-512

To avoid this, disable the Bouncy Castle Crypto Provider in the /system/conf/jvm.xml file. When the JWT Signing filter with one of the above algorithms selected is called, the filter fails with the following error:

ERROR 18/Apr/2016:16:24:39.275 [4a48:17e014570200451f205ec316] java exception:

com.vordel.circuit.jwt.JWTException: com.nimbusds.jose.JOSEException: Unsupported RSASSA algorithm: SHA512withRSAandMGF1 Signature not available

For more details, see the API Gateway Policy Developer Guide.

Related issues: RDAPI-3041

Add JSON Node filter displays redacted data in trace

When the Add JSON Node filter is used in an API Gateway policy, and redaction of JSON message content has been configured, sensitive redacted data in the JSON body is still displayed in the API Gateway trace log file. Regardless of the trace level, the redacted data should be hidden in the trace log when the message body has been processed by API Gateway.

Related issues: RDAPI-8227

Tips and tricks

Upgrade

  • If you are upgrading your API Gateway installation, and you are using a Scripting Language filter in your old installation with the Language field set to JavaScript (Rhino engine JRE7 and earlier), you must change the Language of the filter to JavaScript and ensure that the JavaScript syntax in the script conforms with Nashorn engine syntax. If you do not make these changes, the script continues to work in your new installation, but with a severe drop in performance. It is recommended to use Nashorn for all new development.
  • After upgrading your API Gateway installation, it is recommended that you clear your browser cache before using any of the web UIs. See the documentation for your browser for information on how to clear the cache.

High availability

For more information and best practices when setting up a highly available (HA) API Gateway deployment, see the API Gateway Apache Cassandra Administrator Guide.

Multiple datacenters

  • You must add external load balancer hosts to the Node Manager whitelist to ensure that they are accepted in each datacenter.
  • You may need to increase the Node Manager timeout for longer API Gateway startup times in a multi-datacenter environment.
  • You may need to increase the maximum received bytes per transaction to optimize performance in a multi-datacenter environment.

For more details, see Configure API Management in multiple datacenters in the API Gateway Installation Guide.

Performance

For best performance, we recommend:

  • Always install the latest release and service packs to benefit from new improvements and features.
  • Use HTTP 1.1 instead of 1.0 whenever possible to enable persistent connections.
  • Use persistent connections throughout the entire stack, and overwrite the connection type with keep-alive whenever possible to avoid creating and dropping connections for each individual request.
  • In a classic deployment, use Ehcache instead of KPS whenever possible, because data held in process memory is quicker to access. Note that Ehcache is not supported in a container deployment.
  • Keep thread count reasonable. A good starting point to use as a rule of thumb is initial latency(ms)* expected throughput (count) / 1000 ms = the number of threads (count). In HA deployment, you may want to account failure in one node. Note that the ratio of thread count and CPU cores impacts the latency. You may also want to consider horizontal scaling instead of vertical scaling.

Documentation

You can find the latest information and up-to-date user guides at the Axway Documentation portal at https://docs.axway.com.

This section describes documentation enhancements and related documentation.

Documentation enhancements

See What's new in documentation for a summary of the documentation changes in this release.

The AMPLIFY API Management solution enables you to create, publish, promote, and manage Application Programming Interfaces (APIs) in a secure and scalable environment. For more information, see the AMPLIFY API Management Getting Started Guide.

The following reference documents are also available:

  • Supported Platforms
  • Lists the different operating systems, databases, browsers, and thick client platforms supported by each Axway product.
  • Interoperability Matrix
  • Provides product version and interoperability information for Axway products.

Support services

The Axway Global Support team provides worldwide 24 x 7 support for customers with active support agreements.

Email support@axway.com or visit Axway Support at https://support.axway.com.

See Get help with API Gateway in the API Gateway Administrator Guide for the information that you should be prepared to provide when you contact Axway Support.

Related Links