Want to learn about SAP Commerce, and see which updates were released earlier this month? Lets take a look at the most interesting features and improvements and what is in them for you.
Last year SAP announced it would switch from a quarterly to a yearly release strategy for SAP Commerce Cloud. So, almost one year after its predecessor 1905 we now have the latest version 2005, where - you guessed it - 20 refers to 2020 (YY) and 05 to May (MM) -so nothing to do with the year 2005.
With this new release SAP also announced it will extend support for previous versions as per the table below:
The SAP Commerce Cloud solution does not live in a vacuum. It will always need access to an extensive set of data sources to obtain for example customer, product, availability and pricing data. And it needs to connect with other applications to process orders, payments, reviews, complaints, etc. The types of integrations can vary and each solution you wish to integrate can have one or more ways to create that connection.
Release 2005 clearly revolves around more and easier integration with a double focus:
Access to the SAP Commerce Cloud platform is provided through a set of APIs [ 1 - What are APIs? ], which SAP has named Omni-Commerce Connect or OCC. And with release 2005 this collection of APIs is further extended and enhanced. Most notably:
• New APIs were added for order cancellations and order returns - allowing customers to initiate and follow-up these processes in a self-service mode on the website front-end.
• SAP (finally) started adding APIs that support the typical B2B functionality - though a lot remains to be done. These B2B APIs can be used in parallel with the B2C (Core) Apis, on the same instance. New APIs include:
This focus on APIs and connectivity is primarily driven by SAP's ambition/need to support a strategic market evolution to go for 'headless' ecommerce platforms [ 2 - What is headless commerce? ], where the back-end ecommerce application (the engine or 'body') is clearly separated from the front-end (the user interface or 'head').
Obviously SAP is making sure that its commerce platform can easily and efficiently exchange data with its other key solutions and therefore provides a set of integration APIs.
SAP Commerce integration APIs allow other applications to access data within the platform (such as products, customers, etc.) by passing data in so-called 'integration objects' (OData). The data is exposed though a set of interfaces (REST APIs) that can be easily connected with a middle-ware solution such as SAP Cloud Platform Integration (SCPI or simply CPI).
These so-called SAP Commerce integration APIs are further extended and improved in v2005. Here's a non-exhaustive list but you can always find the complete overview in the official SAP documentation if you like:
The workflow functionality that already existed in the Backoffice Collaboration Center is now extended with a new visual workflow template designer. So, you (or any Backoffice user that are authorized) can now design workflow templates in a more intuitive way, using a visual 'drag & drop' tool that validates user input during designing as well as saving.
Users can now easily and effectively create product bundles in the Product Cockpit (the user interface for the Product Information Management (PIM) tool in SAP Commerce). These bundles either be proposed as predefined packages on the storefront or even provided with a guided selling approach that allows customers to select and combine components from a given bundle set.
This new feature has great potential since users can not only define (or disallow) product combinations directly in the Backoffice (and manage dependencies for more complex product combinations) but also manage rules for product prices and discounts within a bundle. Bundles have their own perspective in the cockpit that displays bundles with their components in a convenient tree structure.
Note: although this is a very interesting and versatile feature, the possibilities of product bundling within SAP Commerce should not be confused with the dedicated and much more powerful solution called Configure Price Quote (CPQ) that is available as part of SAP Sales Cloud.
Context Driven Services (CDS) is the latest star product within SAP Commerce Cloud. It basically allows you to personalize the storefront based on real-time contextual data. This personalization can go from changing content components, over adapting search results, all the way to pushing more relevant products forward - a functionality known as 'merchandising'.
CDS now integrates with SAP Marketing Cloud and the Spartacus storefront.
The functionality for setting up merchandising strategies (used to define which products are selected/displayed in a given scenario) is extended and improved with:
Since the headless SAP Commerce storefront, called Spartacus, heavily depends on the available APIs, the new functionalities in the OCC APIs are now also supported in Spartacus, incl. order cancellation and returns. On top of that, Spartacus now supports the use of CDS.
The latest release also included some other updates to existing functionality, including but not limited to:
E-Commerce Manager, SQLI Belgium
An API (Application Programming Interface) is a set of functions and procedures (routines and protocols) that allows one application to talk to another and exchange information or access functionality. You could consider it as a facilitator for a dialog, where one party asks something (the API request or call) and the other party replies (the API response). The API defines and governs which requests each party can make and how to make them (using specific communication styles, formats and protocols) so both parties can understand each other.
Most APIs (just like the SAP Omni-Commerce Connect APIs) use commonly known communication standards, which makes it easier to use them since the both party don't need to learn each others language to send requests or decipher responses.
A simplified example: a product API
A product API would allow an external application, for example the website storefront, to ask the Commerce application for a specific product and then use the API response to display the retrieved product details on a website product page.
When using or providing an API (whether you're creating a custom API or activating a standard API) you need to consider many different aspects such as scope (how much data do you want to expose?), security (who is allowed to send requests? maybe you want some applications to have more privileges than others?), frequency and performance (how often can a request be made? how quickly will you be able to respond considering the scope?), etc.
What about webservices?
In fact, webservices are a specific subset of APIs specifically used when applications are communicating over a network (whereas an API is a more generic term which is also used for offline integrations that don't necessarily require a network).
Note: There is some disagreement among developers on what exactly defines a web service or API, and how the two differ but I tried to keep it simple ;-)
The term headless refers to a clear separation (de-coupling) of the back-end ecommerce application (the engine or 'body') and the front-end module (the user interface or 'head'). In other words, the ecommerce platform operates independently and can support different heads such as websites (possiblly maintained with a different CMS or on a different platform), mobile apps, wearables, IOT devices, etc.
As you can guess, companies prefer this degree of flexibility over a traditional ecommerce platform with its head screwed on tight (which implies a predefined front-end that is tightly coupled with the back-end).
SAP Commerce Cloud supports both models:
Note: The new Spartacus storefront still doesn't offer all functionality available in the Accelerators. Full feature parity is expected later this year (2020) since Spartacus releases are more frequent than SAP Commerce releases.