A major focus of the release was on Cortex transactional performance, with particular attention on browsing and shopping cart performance. Submit order performance was not addressed specifically but benefitted greatly from the general optimizations that were made.

In our standard Cortex benchmark overall transaction throughput increased by a factor of 2.5 and response times were reduced for all transactions.

When upgrading:

After upgrading you may want to investigate whether there are opportunities to improve the performance of extension functionality.

You now need to use Maven 3.3.9 to build your project.

When upgrading:

In order to optimize Cortex startup behavior it became necessary to distinguish between Cortex resources and RelOS kernel artifacts. To do this, the Maven groupids of all modules in rest-resources were changed from com.elasticpath.rest.resource to com.elasticpath.rest.resource.cortex. The groupids of the RelOS kernel artifacts are untouched.

The source for Cortex rest-resources moduless is now included in the cortex-ep-integration project. The physical layout of the project has been adjusted to accomodate the new modules.

When upgrading:

Cortex Resource implementations that utilized CompositeIdUtils can now skip the Base32 decoding step:

String decodedAssetId = Base32Util.decode(encodedAssetId);
Map<String, String> assetFieldValues = CompositeIdUtil.decodeCompositeId(decodedAssetId);

Map<String, String> assetFieldValues = CompositeIdUtil.decodeCompositeId(encodedAssetId);

Similarly, encoding a composite id has been simplified:

String decodedCompositeId = CompositeIdUtil.encodeCompositeId(assetFieldValues);
String encodedCompositeId = Base32Util.encode(decodedCompositeId);

String encodedCompositeId = CompositeIdUtil.encodeCompositeId(assetFieldValues);

When upgrading:

• Be aware that composite ID encoding and decoding will fail at runtime if the code is not updated.

RelOS' configuration mechanism was updated to utilize Declarative Services instead of Blueprint. As a result some changes to the configuration files were made. Each configuration file change is listed below to aid in upgrading your configuration.

DEFAULT_HOST=http://localhost:9080/cortex/authentication/user
telco=http://localhost:13080/cortex/authentication/user 

mappings=["DEFAULT_HOST\=http://localhost:9080/cortex/authentication/user",
          "telco\=http://localhost:13080/cortex/authentication/user"] 

authClientTrustHeader.config

relos.token.expiry.SECONDS="300" 

seconds=L"300" 

relos.ROLE_HIERARCHY="PUBLIC,REGISTERED" 

roles=["PUBLIC", "REGISTERED"] 

Several changes were made to the Cortex Authentication API:

Several system settings were not being cached for Cortex requests. There was also some confusion regarding the use of refreshStrategyKey in CachedSettingsReader. Currently, the apiRefreshStrategy is the only supported refresh strategy key.

When upgrading:

A major refactoring of the shopping cart was done to adapt it to a sessionless architecture. The cart was originally designed to work with sticky sessions and exhibited a number of undesirable characteristics when used by Cortex in a sessionless environment. The key issues were:

The refactoring separated cart calculations from cart contents, which allowed calculations to be invoked only when required. A ShoppingCartPricingSnapshot is created to get pricing and promotions. A ShoppingCartTaxSnapshot is created to calculate taxes. The creation of these snapshots is tied to the resources requested by Cortex clients.

When upgrading:

Prior to the current release, an item that had been previously added to the cart but is no longer available disappeared silently from the cart without any opportunity to notify the shopper. This was not an ideal user experience and did not provide projects the flexibility to customize the UX.

For example, a frequently implemented experience is that the item is still visible in the cart with message that it is not available. This gives the shopper an opportunity to decide if they want to replace the item with another similar item or to remove it from the cart.

In the current release:

When upgrading:

Determining whether a customer is a first-time buyer required an expensive query on every Cortex request. This query was eliminated by adding a firstTimeBuyer field to the Customer domain object. The corresponding TCUSTOMER column is created and correctly initialized during the upgrade.

An optional <first-time-buyer> field was added to the Import/Export customers.xml schema, with a default value of false if not specified.

When upgrading:

Customizations are required for "Shop on behalf of" functionality to work with CMS front ends. Consequently, this functionality has been disabled by default in the Commerce Manager Client.

When upgrading:

The decision to remove the Velocity Storefront aligns with our strategic direction to provide a front-end agnostic commerce platform that powers content management systems and other touchpoints through the Cortex API. See Announcements and Notices for more information.

A shallow removal of storefront functionality was completed in the current release. This involved removing the ep-storefront module from commerce-engine and the ext-storefront module from commerce-extensions. The storefront webapp was also removed from the deployment package and smoketests.

In future releases a deeper removel of storefront functionality is planned which will cleanup orphaned code that was used only by the storefront.

When upgrading: