This article continues a series “Takeaways from SAP CX LIVE Barcelona”. This time I share my notes and thoughts based on the great presentation given by Axel Großmann, an enterprise architect for New Commerce Cloud.

In many projects, I hear the same thing: minimize the number of customizations and stick to out-of-the-box. The rationale is clear: the more things you add or change, the more expensive and complex the further support is going to be. Systems are getting bigger, less transparent, comprehensive and changing the default behaviour creates unpredictable, hard-to-detect side effects. The cost of errors is increasing too. However, there is a flip side to that, and that is the lack of flexibility and responsiveness. What is a greater evil?

There is a new feature in hybris 6.6, Generic Audit. The new mechanism keeps track of modifications of attribute values of the auditable set of hybris objects. For this purpose, both the original value of the object and its new value are stored in the database for further inspection, if the needs arise. According to the documentation, you can turn on and off auditing for particular types. For frequently changed objects, there is a risk that the system may consume a lot of database space over time, and the database itself grows to a very large size over time. So if you keep auditing on, you should keep these things under control.

Shortly after SAP hybris 6.6 is released I found that this mechanism doesn’t work well. Specifically, when all the audit.*.enabled=false settings are applied, there are still types that are being audited anyway. The examples are Employee, Customer and Product. Many people observed the same, and the issue was reported to SAP. The bug has already been fixed, and, as to my knowledge, SAP has released a patch. I haven’t received the patch yet.

I decided to investigate the issue in detail. This article reveals the details of the problem.