SAP Commerce Cloud began its continuous innovation journey with its 2211 release on November 18, 2022. With this, SAP started to provide monthly update releases of SAP Commerce Cloud 2211 instead of the earlier monthly patches. As the releases prior to 2211 fast approach their End Of Mainstream Maintenance period, it becomes imperative for customers currently using the prior commerce versions to upgrade their ecommerce sites to 2211.x versions.
Through its Help site, SAP provides various instructions and steps to guide customers in upgrading their Commerce sites from older versions to the latest 2211.x. But there are various real time challenges when it comes to custom implementations relying on the older libraries, packages and classes/methods which have been removed/replaced with the latest 2211.x version. There are also few observations/issues which are not explicitly called out in SAP Commerce 2211 upgrade steps or release notes which creates concerns during the upgrades. This blog aims to cover few such challenges which are uncovered during various commerce site real time upgrades.
When upgrading SAP Commerce Cloud system to 2211.x, the following are the main areas of concern.
- The upgrade of the software itself – an immediate version upgrade like from 2205 to 2211 would involve lesser steps when compared to a multi version upgrade like 2011 to 2211
- Compatibility of any custom code which may be leveraging earlier out of box deprecated/replaced/modified libraries/packages/classes/methods for ex., custom SSO
- Current storefront upgrade – If current storefront is a Spartacus storefront which is in a 3.x or 4.x versions, it would also need an upgrade to use the 5.x or 6.x which is the Composable Storefront supported by 2211.x. Even if the current storefront is an accelerator storefront, keeping in alignment with the deprecation of some Accelerator UI and older OCC template extensions as of 2205 release, a migration to Spartacus storefront is suggested for future.
- Migration of any existing data in the current system – There may or may not be any conflicts depending on the variety of data in the current system and there’s a need to plan to address any index errors or data mismatch issues that might popup during data migration step of upgrade deployments in higher environments.
Spartacus Version Compatibility Issues
SAP Commerce Cloud 2211.x comes with Composable Storefront which is a rebranded version of Spartacus angular site. The 2211.x is officially compatible with Composable Storefront aka Spartacus 5.x and above. The 2211.x is expected to be technically backward compatible with 4.x and 3.x too and the older sites developed using 4.x and 3.x have seen to be working with Commerce 2211.
But though the Spa storefronts work well with 2211.x, loading these sites in SmartEdit is seen to throw errors like “Uncaught RangeError: Maximum call stack size exceeded” followed by loading icon. So, customers using SmartEdit for their storefronts, cannot rely on the backward compatibility of Commerce 2211.x with older Spartacus sites in 3.x and 4.x versions and are required to upgrade their angular storefronts to 5.x and above along with the 2211 commerce upgrade.
Custom attribute display issue for B2BCustomer in Backoffice in 2211.3
With Commerce 2211.3 there’s an issue in
customersupportbackoffice extension because of which the applications using this extension have a problem with not being able to view/edit custom attributes of B2BCustomer records in Backoffice . The possible solutions are –
- upgrade to 2211.4 version
- or downgrade to older versions
- or use a workaround logic to override customerTypeFacadeStrategy bean
- or remove loading of customersupportbackoffice extension if not needed by the application
Backoffice Display Discrepancies
With SAP Commerce 2211.3 upgrade, as part of post-upgrade, Backoffice orchestration is essential with selecting the
Reset Everything option to have the new view working as expected with newly updated themes and styles.
There is an issue seen with the default display of Products records in Backoffice post-upgrade where each column data view is cut-short, making the table summary unreadable unlike earlier. You can adjust the display so that the column data is readable with the following steps.
- Click on the Personalization icon of the Products table.
- Click on Save button in the popup (no changes need to be made).
- The display will get adjusted into more readable format.
Impact on Hot Folder imports with error propagations
The
propagateError property of the
headerTaskConfig bean has been made more configurable from 2211.2 release onwards. It can be controlled by
acceleratorservices.batch.impex.propagateError=false, which is expected to be false by default.
This property defines whether to enable or disable propagating error when importing ImpEx files failed with system error. If enabled and an error occurs during the import, the import pipeline will go into ErrorHandler and the imported files will be moved to the error sub-directory, subsequent files will not be imported. If disabled and an error occurs during the import, the import pipeline will go into CleanupTask and the imported files will be moved to the archive sub-directory, subsequent files will continue to be imported.
But with the upgrade, the run time default value in higher deployment environments is seen to be showing up as true instead of the expected false and thus leading to blocking of all subsequent imports when there are errors from any of the import files. This property has to be explicitly set as false for all higher environments like Dev, Stg and Production for the hot folder imports to work as before.
Validate Interceptors blocking the Hot Folder data import
It’s been observed that some of the hot folder import files which need involving custom B2BUnit data slow-down in validate interceptors and do not move out of processing for long hours and get struck there. This calls for an explicit disabling of the validate interceptors for such imports to proceed as expected. The modifier to be added to the import headers in hot folder configuration xml file is
disable.interceptor.types=validate
Vanity Link failures
Ecommerce sites have scenarios where some of its static/media links like material documents etc., are shared as vanity links to customers through other sites or emails or other sources. It is observed that media URLs, such as Product Information documents, after Upgrade, have their generated Context values different from before, because of which the earlier document URLs which were shared by the Business with customers through emails and other means, are not accessible any more after the Upgrade.
All the media created in Hybris have a context parameter (an encrypted string) and this parameter gets modified with Upgrade, as the older hashes were not compatible with new commerce version 2211. Since all the vanity links are setup with these media links, the older context causes an access restriction. To fix this problem one of the solutions is to migrate the documents pointed by vanity links to a static resource location like Akamai Net storage. Another solution is to update all the Vanity links shared through various sources, to reflect the newly generated context parameter values.
Single-Sign-On Upgrade Challenges
With the release of 2211, the samlsinglesignon extension now uses Spring Security as a replacement for the Spring Security SAML library that is no longer maintained. While the samlsinglesignon extension still exposes the legacy endpoints, to use the default endpoints shipped with the spring-security-saml2-service-provider library, the sso.legacy.endpoints.enabled property needs to be set to false. As a result of replacing Spring Security SAML with Spring Security, the OpenSAML library has been upgraded to 4.4.1 and quite many libraries have been removed or modified. The Saml2AuthenticatedPrincipal interface has been replaced with SAMLCredential. The new beans used in Spring Security have the same IDs as the ones used in Spring Security SAML. They aren't, however, compatible with each other as the API has been changed. As the Spring Security library is significantly different from Spring Security SAML, the proposed replacement beans are not fully compatible with the removed beans. Because of these reasons any custom SSO implementation used by the current systems would need a considerable amount of rework to be done, especially in the case of IDP initiated SSO scenarios where there are multiple Identity Providers used by various customers.
To summarize, the complexity of upgrading to SAP Commerce 2211 varies with each ecommerce application depending on the current system version, whether the current storefront is a Spartacus storefront in an older version, if customer uses SmartEdit for content management, if the site has customization on SSO, if there are any SAP integrations like CPI involved and overall extent of customization of the site over out-of-box of SAP Commerce. Various real time challenges like described above are anticipated and need to be planned to be resolved for a successful upgrade.
