This article focuses on how SAP Commerce stores models in memory, which is a vast topic. To begin with, we will explore a relatively simple aspect, such as the unusual structure that appears in the debugger when trying to view the contents of any SAP Commerce model. We will also discuss how to access all the object properties contained within it.
Read More »- stopping support on the previous Spartcus versions (4.x);
- that Version 5 would be only available within an authenticated policy to SAP partners / customers; and
- Spartacus is renamed to Composable Commerce.
Read More »
Many merchants have 3 such environments typically defined as development, staging and production and as time passes by, the production environment receives multiple BAU changes to core data areas such as web content, products/categories/classifications undertaken by merchandising teams or product management and of course a lot of data is generated through customer registrations and orders placed.
However, the non-production environments are frequently not kept in line in terms of web content, product data or representation in terms of quantities of customers or orders. I’m not referring here to the code and core configuration related data that is included in builds.
Read More »
Taking advantage of back-in-stock notifications, customers are informed that a product they were interested in recently has become available again. Alternatively, a customer may want to get subscribed to the product price updates and get notified when the price drops on a product.
As a result, customers are more likely to return to make a purchase. These two features are often considered as must-have for almost any marketplace solution.
Their implementation and design are also considered to be quick and easy. In fact, it is not so — there are many points for consideration easy to miss in the design phase. In this article, I focus on the potential pitfalls and best practices in implementing “Back-in-stock notifications” and “Price drop alerts”. Read More »
There are dozens, even hundreds of test automation frameworks available, and we developed our own. Why? Why? Was it worth the effort?
This article describes our needs and our solution, E2E CLI: the architecture of the API testing tool which has been used by our team for about 2 years. Back in 2020, it was developed by me from scratch over the course of a weekend — In other words, it is a very simple piece based on very simple ideas. That first version was supporting 80% of the functionality available today in the last version (and described below). We don’t add features without good reason.
We use this tool to end-to-end test all our services and integration flows. Whenever we make changes to a software system, we need to ensure that they do not break what was already working.
As the architect and lead developer, I designed and developed it from the ground up, so, of course, I am very proud of my brainchild. But the field cannot be well seen from within the field. You know, reinventing wheels is not always bad. When you build something on your own, you are in full control over what is being built, what its purpose will be, and when it is finally conceived and executed as you wish. It has been two years since I have encountered any alternative to our solution.
To reach a wider audience, I found it beneficial to share key concepts hoping to get some feedback from the community and enhance the product.
Technically, the tool has nothing to do with SAP Commerce; it’s for testing. However, our entire team, which uses this tool daily, is focused mainly on SAP Commerce development. And the tool is tailored to be used with SAP Commerce.
While the client (for whose benefit the tool is being used) has authorized me to share high-level details, I cannot disclose names or code. In spite of this, the conceptual view should be useful on its own and might become a good foundation for your own solution.
Read More »