What's new in Version 10.0.5.1
This page details the enhancements in IBM® API Connect Version 10.0.5.1 since the previous release.
Version 10.0.5.1 product release
API Connect 10.0.5.1 is now supported to run on VMware. For information about installing and upgrading on VMware, see the VMware section.
What's new for Developers
- The API policy version must match the gateway policy version
- The way that API Connect validates the
API policy version has changed. In earlier releases, API Connect published the
API if its policy version was considered to be compatible with the gateway's version. If no version
was specified, the policy version defaulted to 1.0.0. However, the published API might then fail at
the gateway if the API policy version didn't match the gateway policy version.
Now, API Connect mitigates the problem by validating the API policy version prior to publishing the API. This new behavior means that API Connect only publishes an API to the gateway if the API policy version exactly matches the version that is present on the gateway. In addition, if a policy version isn't specified, it no longer defaults to 1.0.0. If the version is incompatible with the gateway, a validation error is thrown that specifies the available versions.
Note that this change in behavior does not affect APIs that are already published.
- More flexibility when customizing the preflow policies
- You can now use the
modeproperty to control how the preflow policies are applied. For more information, see Customizing the preflow policies.
What's new for API product managers
- Analytics latency charts now show percentile levels
- To assist in the investigation of latency anomalies, the latency charts now include percentile lines.
- Advanced options now available on analytics REST API and toolkit CLI
- Advanced query filters are now available when querying analytics data. See Example toollkit CLI operations and Analytics REST API.
- Configure the visibility of Products at a Catalog or Space level
- You can now modify your Catalog settings to define a visibility property at a Catalog or Space
level. This setting then becomes the maximum level of visibility that is allowed for any Product
that is published to that Catalog or Space. It can also be used as the default visibility setting
for that Catalog or Space. For more information, see Configuring
Product visibility in a Catalog.
Note that this is an additional feature that is disabled by default, so current Product visibility behavior is not affected. The new feature also doesn't affect any Products that are already published.
What's new for Developer Portal administrators
- New commands are available in the Developer Portal command-line tool
- The following commands for managing forums are now available in the Developer Portal
- forums:disable - Deletes any existing forums taxonomy terms, and then disables the Forum module for a given site.
- forums:enable - Enables the Forum module for a given site.
What's new for DevOps
- Upgrade now available for API Connect version 2018.4.1.20 to version 10.0.5.1
- You can upgrade directly to 10.0.5.1 from 2018 FP20 by following the appropriate instructions for your platform:
- API Connect version 2018.4.1.20 to version 10.0.5.1 form factor migration
- You can now migrate from version 2018.4.1.20 or later to a different form factor on version 10.0.5.1 or later. For more information, see: Migrating from v2018 to v10 on a different form factor.
- API Connect 10.0.5.1 uses a new version of cert-manager
- Kubernetes, VMware: cert-manager 1.7.1
There is an additional step to upgrade cert-manager Upgrading subsystems on native Kubernetes. When you refer to cert-manager in your CRs or commands, the following values must be updated to reflect the newer version of cert-manager: In VMware, references to cert-manager in CRs are updated during the upgrade.
- OpenShift, Cloud Pak for Integration: cert-manager 3.21 (provided by Foundational
Services)Upgrade of cert-manager is done automatically during the API Connect upgrade. However, when you refer to cert-manager in your CRs or commands, the following values must be updated to reflect the newer version of cert-manager:
- Kubernetes, VMware: cert-manager 1.7.1
apicupcommands for the rotation of secrets on the Developer Portal subsystem
- The following commands are now available for the rotation of secrets on the Developer Portal
subsystem on VMware:
list-rotate-secrets- to obtain a list of any Developer Portal secret rotations that were created by using the
delete-rotate-secret- to delete any Developer Portal secret rotations that were created by using the
For more information, see Tips and tricks for using APICUP.
- Two site High Availability (HA) feature renamed to two site DR (2DCDR)
- This feature has been renamed to avoid confusion with production HA deployment profiles, and to
recognize the manual intervention required to failover to the passive data center. The passive data
center in a 2DCDR configuration has also been renamed to the warm-standby datacenter. See
center deployment strategy.Note: The terms passive and multiSiteHA are still used in the CR YAML files. This is a documentation change only, and there is no change in the behavior of 2DCDR.
- New installation instructions for 2DCDR on Cloud Pak for Integration
- The steps for installing API Connect on Cloud Pak for Integration in a 2DCDR configuration are now documented. See Installing a two data center deployment on Cloud Pak for Integration.
- New installation instructions for 2DCDR on OpenShift
- 2DCDR installation on OpenShift is now documented in a dedicated topic, instead of sharing the topic with Kubernetes 2DCDR install. See Installing a two data center deployment on OpenShift.
- Reorganization of Kubernetes, OpenShift, and Cloud Pak for Integration installation documentation
- The installation documents for these platforms have been reorganized to provide a more sequential flow for the reader, and reduce the amount of non-applicable information presented to them; see Deploying on Kubernetes and Deploying on OpenShift and Cloud Pak for Integration.
- Mutual TLS support for Management to Gateway communication
- For individual subsystem installations on OpenShift and Kuberenetes, mutual TLS can be enabled
with a new
validateApimClientsetting. See Installing Gateway on Kubernetes, Installing Gateway on OpenShift in a dedicated namespace, or Installing Gateway on OpenShift in a shared namespace depending on your deployment platform and topology.