2026.2.0 STS

July 9, 2026

In this release:

Key Features: 2026.2.0

Observability Enhancements

This release has further enhanced observability capabilities for Akana Platform to improve log analysis, monitoring, and integration with modern observability platforms.

Extended Access Log Capture for API Observability–The structured JSON format access log now captures richer runtime detail to improve API observability and troubleshooting. Each log entry includes the client ID, end user ID (both derived from the token subject), request path, service name, request and response sizes, and downstream time.

Benefits

  • Accurate performance attribution — Separate capture of downstream hop time vs. gateway processing time lets teams distinguish latency introduced by the gateway from that introduced by backend services.

  • Better API consumer visibility — Client ID and end user ID in every log entry enables per-consumer usage analysis, anomaly detection, and audit-readiness without additional instrumentation.

  • Right-sized payload insight — Request and response size capture supports capacity planning, SLA enforcement, and detection of abnormally large payloads.

Please refer to the Observability documentation to get started using JSON format Access Logging and Container Logs.

Case number: No associated case

Enhancements: 2026.2.0

GW containers to use the WSMEX-configured hostname for all GW-PM communication

To communicate with all the Policy Manager (PM) services, Gateway (GW) containers will now use the host names configured as part of WS-MetadataExchange configuration. The configuration can be found on Admin Console under Configurations> Configure WS-MetadataExchange Options > WS-MetadataExchange Options > URL.

Before this enhancement WS-MetadataExchange configuration was used only for MetadataExchange service (/wsmex). This change will eliminate the unintended cross-endpoint communication in the following scenarios:

  • In a PMCM + PM + GW deployment, the GW communicated with both the PMCM and PM endpoints

  • When PM exposed both HTTP and HTTPS listeners, the Gateway communicated with both, even if only the HTTPS endpoint was configured.

Please note that no change is required in the existing WS-MetadataExchange configuration.

However, to revert to the behavior before change, set the property enabled=false on the GW containers Admin Console configuration under com.soa.http.route> com.soa.http.route.<UID>.

For more information, see Admin Console PID documentation.

Case number: 01543335

Microsoft SQL 2022 Support

Akana now supports Microsoft SQL 2022 version, allowing you to leverage this database version’s features and optimizations.

For detailed instructions, see System Requirements for Akana Platform.

Case number: 01540538

Microsoft SQL 13.4.0 JDBC Driver Support

Akana now supports deployment using the Microsoft SQL Server 13.4.0 JDBC driver.

For detailed instructions, see Microsoft SQL Server Database Installation and Configuration.

Case number: No associated case

Operation-Level Throughput Quota Policy Support

Akana extends Throughput Quota Policy enforcement to the operation level, giving API product teams finer-grained control over rate limiting across individual API operations.

Previous Behavior

Throughput Quota Policy was supported at the service, contract, and license levels only. All operations within a service shared the same quota envelope, making it impossible to apply differentiated rate limits to individual operations — such as restricting a high-cost search operation independently from a lightweight lookup operation.

Enhancement

Throughput Quota Policy can now be configured and enforced at the operation level. The policy is evaluated and applied at runtime by the Gateway and configured via Community Manager or Policy Manager portal, consistent with existing quota policy behavior.

How It Works

Quota Level

Use Case

Service

Rate limit entire API

Contract

Rate limit per app across all operations

License

Rate limit per app per operation

Operation (new)

Rate limit all traffic per operation regardless of app
Operation-level Throughput Quota Policy applies rate limits per operation across all apps. To enforce rate limits per app, per operation, use License-level Throughput Quota Policy configuration instead.

For more information, please refer the Throughput Quota Policy documentation.

Case number: 01511089

Default value for trusted certificate refresh period setting changed to -1

The default value for the trusted certificate refresh interval (trusted.ca.cert.keystore.spi.expireIntervalMillis under PID com.soa.mp.core.client) has been changed from 60000 (1 minute) to -1 (disabled).

This reduces unnecessary load on Policy Manager and eliminates performance overhead on the Gateway caused by frequent periodic refreshes.

Newly added trusted certificates continue to be propagated automatically from Policy Manager to the Gateway — this change does not affect certificate delivery.

No action is required for most customer deployments. Customers who update container or trusted certificates frequently can choose to set an appropriate refresh interval based on their operational needs.

For configurations details, please refer to the configuration documentation.

Case number: No associated case

Bug Fixes: 2026.2.0

Gateway Throughput Drop During Pod Autoscaling in EKS

In Kubernetes (EKS) deployments, adding a new Gateway pod during autoscaling caused a sudden throughput drop across all running Gateway pods, impacting API traffic during scale-out events.

Gateway pods communication with Policy Manager to fetch API configurations is now optimized. Scale-out events no longer cause cascading performance degradation across the Gateway cluster.

Case Number: 01569407

Log Alert toggle would not work for certain alert categories

Previously, disabling the Log Alert option in PM Console (Alerts > Alert Codes) did not prevent logging for certain alert categories, including QoS Quota, SLA, and contract-level alerts. As a result, alerts continued to be logged even when the option was not selected.

Starting with release 2026.2.0, the Log Alert setting is now enforced consistently across all alert categories.

Case number: 01566877

SAML Web SSO Key Pair Update Not Applied in OAuth Token Flow

When the Akana SAML Web SSO (SP) key pair is updated, the updated key is not picked up. Akana as SP continues to sign SAML requests using the original private key created at the time of domain creation, while the Identity Provider (IdP) validates the signature against the newly configured public key. Since the signing and verification keys no longer match, signature validation fails and the OAuth token cannot be retrieved.

Case number: 01510989

Community Manager container would face Garbage Collection (GC) and Memory issues in certain scenarios

When the data in certain tables related to Board Items grew above 12 million records, Community Manager (CM) portal would experience heap and GC issues due to unbounded memory cache growth.

As part of the fix, Board Items related caching is improved to avoid the GC pressure and improved CM dashboard responsiveness in environments with multi-million-row DN and Board-Item tables. Also, the cache refresh intervals have been increased from 1 minute to 15–20 minutes, and refresh jobs now use incremental, timestamp-based loading instead of full table reloads.

Case number: 01564007

JAVA_OPTS specified in Akana startup scripts were ignored

Akana container startup scripts (startup.sh, docker-start.sh, startup.bat) were ignoring the JAVA_OPTS or AKANA_OPTS environment variables, including variables set through setDEMSEnv.sh such as heap size, garbage collection. Revised version of the scripts is included to cover various scenarios.

Case number: No associated case

Bugs: Security Vulnerability Fixes

Third-party libraries updated to mitigate vulnerabilities

Several third-party libraries have been updated to mitigate critical, high, and some medium priority vulnerabilities. See Using the Third-Party Libraries in the Akana documentation.

Case number: No associated case

Breaking changes: 2026.2.0

Action Required: Custom Policy Update for Commons Lang Library Change

Applies to

Customers with custom policies referencing Apache Commons Lang

Akana 2026.2.0 ships with an updated Apache Commons Lang library. Customers with custom policies built against the older library must update and redeploy their policies before upgrading.

What Is Changing

The bundled Apache Commons Lang library older version commons-lang-2.6.jar has been replaced with the latest version commons-lang3-3.18.0.jar.

Customer Impact

Custom policies that import classes from org.apache.commons.lang.* will fail to resolve at runtime after upgrading to 2026.2.0. This affects only customers who have developed and deployed custom policy bundles referencing the old library.

Incremental Gateway container Upgrade with Live Traffic

Customers performing a rolling upgrade of Gateway containers can continue serving live traffic during the upgrade:

  • Old GW containers (2026.1.0 or older version) can continue to serve live traffic with the existing custom policy bundle — no changes are required on old nodes.

  • New ND containers (2026.2.0) require the updated custom policy bundle (built against commons-lang3) to be installed before or at the time of deployment.

  • Since custom policy bundles are deployed per GW container, old and new containers can run simultaneously during the rolling upgrade window without impacting each other.

Recommended Upgrade Sequence

  1. Update all Java import statements from org.apache.commons.lang.* to org.apache.commons.lang3.*

  2. Update OSGi bundle manifests (Import-Package) to reference org.apache.commons.lang3 instead of org.apache.commons.lang

  3. Rebuild and redeploy the updated custom policy bundle

Out-of-the-box Akana policies are unaffected. This action is only required for customers with custom-developed policy bundles.

Case number: No associated case

Fresh Installation Required for Akana 2026.2.0 and Later Releases

Akana 2026.2.0 introduces significant platform modernization changes that require a fresh installation. As a result, in-place upgrades from Akana 2026.1.x to Akana 2026.2.0 are not supported.

Customer Impact

If you are currently running Akana 2026.1.x, you must deploy new Akana 2026.2.0 containers and migrate your existing configuration and data. Attempting an in-place upgrade to 2026.2.0 will not succeed.

Recommended Upgrade Process

  1. Deploy new Akana 2026.2.0 containers.

  2. Migrate configuration and data from your existing Akana 2026.1.x environment.

Patch or Hot fixes Deployment Process

Patches or Hot fixes on 2026.x.x releases can be installed using in-place upgrade process and will not require felix TUI bundle installation.

Case Number: No associated case