A Look Into The v2005 SAP Commerce Cloud Release
It’s been a year since the last major SAP Commerce Cloud release. However, on May 14th, 2020, SAP released v2005 of their SAP Commerce Cloud platform with the tagline, “Embed Commerce Everywhere”. What new and exciting innovation does this release hold? Was this release worth the 1-year wait? Let’s take a look at a few features on offer, based on the v2005 release notes. I’ll share some of my thoughts; you draw your own conclusions.
APIs APIs Everywhere
Practically speaking, this release appears to be primarily about API enablement. There are a slew of new APIs on offer, primarily in the B2B space. This includes APIs for the following functionality:
- B2B Commerce Organization
- B2B Scheduled Order Replenishment
- B2B Reorder
- B2B Inventory Display
Furthermore, there are a few other new APIs to mention:
- Cancellation & Returns
- Configurator Complex Products
- For variant configurations & associated pricing
What is driving this?
Well, the much anticipated Spartacus v2.0 release was on June 3, 2020. Spartacus v2.0 breaks a bunch of backward compatibility, upgrades to Angular 9, and introduces a number of other “foundational” elements (eg. keyboarding, event services) that will enable SAP to realize the real prize – Spartacus v2.1 and (finally!) the introduction of Spartacus’ B2B storefront. That release is targeted for “Q2 2020” (with more Spartacus B2B features to be released in Q3 2020), so basically by the end of June we should have all the initial pieces in place for an SAP-built headless B2B e-commerce solution. If you’re a B2B solution and have been itching to go headless or otherwise covert over Spartacus, now is your time to upgrade to v2005 to ensure you’re ready to go once Spartacus catches up.
More on the Spartacus headless storefront here:
- Spartacus v2.0 – https://sap.github.io/spartacus-docs/release-information/
- Roadmap – https://sap.github.io/spartacus-docs/spartacus-roadmap/
B2B & B2C APIs Under One Roof
Aside from the sheer number of APIs introduced is one additional but key change – B2B & B2C API co-existence. Previously, the B2B and B2C APIs competed for the same set of endpoints, meaning you could only use one or the other at any given time. This forced companies with both B2B and B2C solutions to run B2B and B2C on separate environments, or to somehow shoehorn/customize either the B2B or B2C OmniChannel Connect (OCC) layer to accommodate the other one. With this change, this artificial point of contention has been removed, meaning SAP Commerce Cloud is better able to compete on its strength as a top tier platform solution for both B2B and B2C.
Take note of the occ.rewrite.overlapping.paths.enabled property, which is used to flip between backward compatibility with the old (conflicting) endpoints and the new ‘work together’ endpoints.
Bundles of Joy
Where APIs steal the show in terms of practical enhancements, the “sexy” stuff starts with the new Backoffice bundling perspective.
Bundling has historically been associated with the Telco Accelerator. In my experience, it has been the defining feature of the Telco Accelerator (more so than the “Telco” part). The popularity of this feature has seen “non-Telco” clients bootstrap their e-commerce solutions on the Telco Accelerator simply to gain access to this bundling functionality, or otherwise “pillage it for parts” and shoehorn Telco functionality into the B2C (or B2B) accelerator. Its move to the core platform is therefore a joyous occasion, as it means a Telco licence from SAP will no longer be necessary to access this highly useful piece of e-commerce functionality.
It looks like the functionality for this new feature is solid out of the gate. With the new bundling perspective, you can define the criteria that will be used to select products that can be included in the bundle, and any dependency rules between those products. (eg. Pick any two of products A, B, C & D, but not A and C together.) With the product selection criteria in place, you can set rules around pricing. Optionally, discounts can also be applied to make the bundle more attractive to prospective customers.
The bundling perspective/feature has great potential for upselling. Think of things like warranties or auxiliary services (like a maintenance/care package). And of course it’s just plain sensible if you’re trying make buying easier by associating must-need products together. For example, an “add-on” component that needs a base product to be useful, or a kit of commonly purchased items.
I should also note that this functionality does not replace what I like to call “hard bundles”. Hard bundles are groups of products that are fixed in their grouping, and for all intents and purposes are sold together as a single SKU like a regular product. “Soft bundles” on the other hand, are more of the “mix-and-match” and “build your own” variety, and this is what this new bundling capability is really targeted to.
Visual Workflow Designer
Despite all the enhancements to SAP Commerce Cloud over the years, its UI is still rooted in the underlying data model, exposed. That’s why I’m typically excited whenever SAP releases UI elements that get away from the “fill in the attributes of this data model” feel. SmartEdit would be an example.
Since v6.6 we have been pampered with the “Workflow Visualization” feature, which allowed for workflows to be represented visually within the backoffice. However, this was a read-only feature. While useful – it, for example, let you see the current task and currently assigned user – it did not address the creation or modification of said workflows.
Historically, workflows have typically been a pain, with the need to create a bunch of actions and decisions and assemble them together into a workflow bit by bit. It’s clunky. Workflows in general have always been better expressed visually – it’s why Microsoft made so much money off of Visio. Finally we can do the same in the backoffice perspective.
With v2005 we get a new toy – the (Visual) Workflow Designer. Using the new (Visual) Workflow Designer, you can drag and drop new actions, decisions, etc. and link them together in an intuitive way. Each action, decision, etc. can be assigned to individual users or groups. This includes both the creation and modification of the workflows. You can then step back and (visually) appreciate your overall workflow as one, comprehensive diagram to ensure you got it right. Overall, this should lower the pain involved in creating and modifying workflows, thereby lowering the cost and time associated with changing them as your business needs evolve.
Let’s be honest – security is not sexy. No one buys a commerce platform because it has the “best security”. But security is important, and leaving your system vulnerable will undermine the trust your customers put in your solution that makes them willing to transact in the first place. (Those in excess of a certain age will remember how freaky it once was to enter your credit card information online.)
In 2020, we find ourselves in a new era where consent and privacy legislation is rising up all around us – GDPR in Europe, CCPA in California, and other related legislation in China, Russia, and Brazil, to name a few. These laws have teeth – up to 4% of annual revenues in the case of GDPR, for example.
The reputation of an e-commerce platform matters, and SAP does not want to find itself in the same situation as Adobe did with recent Magento security breaches. (Read: ZDNet from November 27, 2019 or ThreatPost from January 29, 2020 as examples, or Google more.)
As a consequence of all points above, as of v2005, SAP has removed a “creature comfort” of us developers. As of this release, all users except the initial administrative user will be disabled out of the box. Those users will furthermore not come preconfigured with “known” (to developers at least) default passwords. And the administrator password will need to be set at initialization.
All in all, it will be much more inconvenient to use a “plain initialized” Hybris instance going forward. Likely many development teams will resort to a “standard impex” for their non-production environments to re-enable those default accounts and set them with “known” passwords for development and testing purposes. A word of advice though – do not use the default passwords of old. It’s too easy for an administrator/developer/tester/etc. to accidently run such an impex in a production environment, and it may not be noticed right away. So give yourself an extra layer of protection by using passwords known only to your specific project team. That way you ensure that you need at least two failures – account enablement and password breach – to introduce a security problem.
1 Step Forward, 2 Steps Back?
Usually, release notes are all about cool new features and enhancements. V2005 came with two surprising “anti-features” though:
- Reintroduction of the WCMS Cockpit, and
- Extending the end-of-life timeframe of previous releases.
Reintroduction of the WCMS Cockpit
As part of the v2005 release, SAP reintroduced the WCMS cockpit of old. In all my years as a Hybris / SAP Commerce Cloud practitioner, I cannot recollect a feature being reintroduced as such. So why now?
The answer likely lies in SAP’s current strategy and emphasis on migrating is current SAP Commerce and SAP Commerce Cloud “v1” install base to SAP Commerce Cloud “v2” (CCv2) build on Microsoft Azure. Bare with me as I lay it out.
SAP is putting a lot of emphasis on their CCv2 offering, including a significant portion of their R&D investments into the Hybris platform. And for those solution owners who do not have robust CI/CD or DevOps infrastructure, and/or those who lack the scalability of hosting their solution on AWS/GCP/Azure/Aliababa/Rackspace/etc. already, CCv2 is a good option for you and you should consider migrating. But let’s not forget that there is also a financial incentive here for SAP. CCv2 comes with a revenue share based licence model, either:
- the total quantity of orders transacted through the platform, or
- the total gross merchandize value of the orders transacted through the system
At least in my experiences to date, most (not all) of those licence conversions have resulted in a net increase in licence costs. (Note that this is offset in part by a reduction in infrastructure costs if converting from an on-premise licence.) Thus, the SAP sales team is incentivized to convert solution owners to the cloud. However, even if CCv2 is a “perfect” fit for you, there is still the reality of the “lift and shift” necessary to migrate. Currently, that means being on v6.7+ (soon v1808+, once v6.7 goes out of support in August), which means that the majority of solutions owners need to do a version upgrade first before migrating.
Before v2005, that upgrade – which I would typically advise solution owners to upgrade to the latest version, so v1905 prior to this release – meant that you had to invest into SmartEdit, as the WCMS cockpit was removed in the v1808 release in Q4 2018. Now, SmartEdit is superior to the WCMS cockpit, but converting to it means that the upgrade necessary for migration is that much more expensive, that much more lengthy, and that much more disruptive to established customizations, workflows, backoffice user training/habits, etc. All that to say that by including the WCMS cockpit back into v2005, SAP has removed a major barrier preventing its customers from moving to their latest and greatest CCv2 cloud offering, and taking away customer excuses to “only” upgrade to v6.7 or v1808, thereby leaving them ~2 years out of date with respect to SAP investments into innovation on the platform. A win for SAP; a win for customers that wanted to move to CCV2.
But don’t be fooled. The WCMS cockpit remains on the chopping block and SmartEdit should still be on your solution roadmap if you’re not using it already. The WCMS cockpit was originally deprecated in the v6.6 release of Hybris. Since then there have been WCMS cockpit related entries in the “deprecated module” tables SAP maintains from version to version, tracking when various extensions/modules will be sunset (ie. removed) from future versions. If we look at the entry for “cmscockpit” in this table, we see that in fact the entry has not been removed, but rather the date has simply been extended from Q2 2019 (per v1905 deprecation release notes) to Q2 2021 (per v2005 deprecation release notes). The implication here is that the “re-introduction” of the WCMS cockpit is a “one time deal”, and that it may very well be removed again from the platform come the (hypothetical at this point) v2105 release of SAP Commerce Cloud in May 2021.
As part of the v2005 release, SAP changed the end-of-life dates for v1808, v1811, and v1905 per the table below:
August 8, 2018
December 12, 2020
August 29, 2021
December 12, 2018
May 29, 2021
August 29, 2021
May 29, 2019
May 29, 2021
August 29, 2021
You can read my thoughts about the new end-of-life dates and why SAP might be doing that in my earlier article, “What Does History Tell Us About The Upgrade Potential Of The Pending SAP Commerce Cloud v2005 Release? — Part 2”. Though you should probably read part 1 beforehand to ensure you have the complete picture I paint.
For reference, v2005’s end-of-life date is August 13th, 2022.
But What About…?
There is of course more to this release, and unfortunately I cannot cover it all. Still, make note of these other interesting features areas and check them out for yourself:
- Assisted Service Module
- Autocomplete suggestions lists for customer lookup
- Ability for an ASM agent to bind an anonymous cart to a customer
- Media container management for banner components in SmartEdit
- Solr search improvements for large catalogs
- A/B testing with Context-Driven Services
Back to SAP’s own marketing tagline, “Embed Commerce Everywhere.”
Time to draw your own conclusions. Agree? Disagree? Maybe something I didn’t cover? Was this release worth the 1 year wait?
Leave a comment below with your thoughts. And as always, be bold. ?
P.Eng., SAP Customer Experience Competency Center Head, EPAM