What's new in Version 10.0.1.5-eus
This page details the enhancements in IBM® API Connect 10.0.1.5-eus.
If you are moving to version 10 from version 5, also see the What's new in version 2018 page for the additional new features since version 5.
Note: You can access the latest files from IBM Fix Central by searching for the API Connect product and
your installed version.
Version 10.0.1.5-eus ifixes
- 10.0.1.5-ifix4-eus
- Version 10.0.1.5-ifix4-eus contains only fixes.
- 10.0.1.5-ifix3-eus
- Version 10.0.1.5-ifix3-eus contains only fixes.
- 10.0.1.5-ifix2-eus
- Version 10.0.1.5-ifix2-eus contains only fixes.
- 10.0.1.5-ifix1-eus
- Version 10.0.1.5-ifix1-eus contains only fixes.
Version 10.0.1.5-eus product release
The following sections detail changes and additions in version 10.0.1.5-eus:
What's new for Developers
- Import a REST API from a URL
- When you create a REST API by importing the YAML file definition, you can specify the URL where the file is hosted. This saves you the intermediate step of downloading the file to your local storage before importing it. For more information, see Adding a REST API by importing an OpenAPI definition file.
- Test tab no longer includes websocket subscription in payload while invoking a GraphQL API when "by URL parameter" option is selected
- When working with GraphQL APIs in the Test tab, invoking a websocket subscription
with "by URL parameters" option will no longer include the subscription in the payload. The
subscription will only be included in the URL parameters, matching the approach used by queries and
mutations.
This change applies only to the Test tab (API Manager, API Designer) and does not affect third-party clients.
- Test and debug support for non-Sandbox catalogs
- You can now choose which catalog an API can be published to, directly from the API editor header. When selecting any catalog, the Test tab is enabled so you can click it to test your API. The test feature is no longer limited to the Sandbox catalog.
What's new for API product managers
- Migrate subscriptions between Plans within a Product
- You can now migrate subscriptions between Plans within a single Product, in addition to migrating them to a Plan within a different Product. When you migrate the subscriptions between Products, the Products can reside in the same Space or in different Spaces.. For more information, see Migrating application subscriptions.
- Apply Catalog actions to Spaces
- Certain Catalog actions can now be applied across Spaces. For example, you can
replace or supersede Products hosted in the same Space, and as well as Products hosted in different
Spaces. Review the following list for a summary of the Catalog actions that can be used when Spaces
are enabled:
- Product gateway update: Space scope only
- Product lifecycle actions:
- Stage/publish from draft or direct stage/publish from multipart Product: Space scope only
- Other lifecycle actions can be at Space or Catalog scope
- Product composite lifecycle actions:
- At the Space scope, both Products must be hosted in the same Space
- At the Catalog scope, Products can be in different Spaces
- API update to online/offline status: Both Space and Catalog scopes are supported
- Ability to select which gateway to publish to is now available in the Product create wizard
- When you create a new draft Product in the API Manager UI, you can now select which gateway to publish your Product to. For more information, see Creating a draft Product.
What's new for Developer Portal administrators
- New api:get-document, product:get-document, drupal-config, site:cache-rebuild, site:state, and twig commands available in the Developer Portal command-line tool
- The following commands are now available in the Developer Portal
command-line tool:
- api:get-document and product:get-document - Get a specific entire document for a given API or product on a specific Developer Portal site. For more information, see Using the api commands and Using the product commands.
- drupal-config - Manage the Drupal configuration objects on your Developer Portal service, for example to disable CSS and JS aggregation. For more information, see Using the drupal-config commands.
- site:cache-rebuild - Rebuild the Drupal cache on your Developer Portal site; see Using the site commands.
- site:state - Obtain the current state of a Developer Portal site, for example to understand the general health of the site. For more information, see Using the site commands.
- twig - Enable, disable and list the state of the twig debugging on a specific Developer Portal site; see Using the twig commands.
What's new for DevOps
- Change your deployment profile after installation
- After API Connect is installed, you can change your deployment profile from
development
toproduction
, or fromproduction
todevelopment
. For more information, see the installation instructions for your environment. - Configure a second network interface card for the Developer Portal on VMware
- You can configure a second network interface card (NIC) for the Developer Portal. Use of a second NIC allows you to separate internal traffic between Developer Portal and APIM from the public network traffic where end users can access the portal web sites. See Configuring two NICs on the Developer Portal.
- Configure appliance boot mode
- You can configure the boot mode for appliance VMs, to specify whether ISO files are required or ignored at boot time. See Appliance boot mode configuration.
- Drupal 9 upgrade compatibility check now added to the Developer Portal upgrade process
- A compatibility check has been added to the Developer Portal upgrade process to verify that any additional contributed modules, or custom modules, or sub-themes, declare that they are compatible with Drupal 9. Any Developer Portal sites that contain modules or sub-themes that don't have this version declaration will fail to upgrade. For information about how to make the Drupal 9 version declaration in custom modules or sub-themes, see Installing Drupal 8 based custom modules or sub-themes into the Drupal 9 based Developer Portal. For more information about Drupal 9, see About Drupal 9 on the drupal.org website.
What's new for security practitioners
- OIDC user registries now support the use of JWT the grant type
- To use the JWT grant type, the UserInfo endpoint and JWKS endpoint values must be specified on the OIDC user registry page. For information on these settings, see Configuring an OIDC user registry.
- Map external LDAP groups to API Connect user roles
- You can configure LDAP group mapping on API Connect user roles to enable more control of user authorization by using the developer toolkit CLI. For more information, see the following topics:
- Override the default token expiration for OIDC providers
- When configuring an OIDC user registry, you can now choose to override the OIDC provider's token expiration setting with the access token and refresh token expiration settings that are configured in API Connect.
- Additional email address settings for all user registries
- The following two new settings are now available on
all user registries to manage the use of email addresses when onboarding new users:
- Email required - Select this checkbox if an email address is required as part of the user onboarding process.
- Unique email address - Select this checkbox if email addresses must be unique within the user registry.
Note:For more information, see User registries overview for the Cloud Manager or Working with user registries in the API Manager, and select the required user registry type.- An email address is not required by default for onboarding to the Cloud Manager or the API Manager, but it is required for onboarding to the Developer Portal.
- Every account in the Developer Portal, including across different user registries for the same site, must have a unique email address, including the site Admin account.
- If Email required is selected, the source identity provider must supply the email address as part of the authentication process, or the user will fail to onboard.
- For new Local User Registries, the Unique email address setting is always selected; so if email addresses are contained in the user record, they must be unique. However, for existing Local User Registries this setting can be edited.