It would be nice to have some best practices, documentation and examples how the Emporix-way of implementing Hybris-things like validation of attribute values or modifying values in interceptors (especially before saving) would look like.
Hey Georg,
we have two content pieces for the SAP end of life. One that is a bit “older” but more technical and a second one that is more strategical and really fresh from this year.
You can download them here:
Hope that helps! If you need more support, feel free to reach out!
Cheers
Sebastian
Hi Sebastian,
thanks for the links to the documents.
I’m thinking of a collection / knowledge base of very specific implementations in Hybris and their corresponding implementations in Emporix.
Examples:
- Complex validations for MD: e.g. different checks for combination of attributes (attribute1 valueX makes attribute2 a required attribute)
- Emporix implementation might be a MD extension with a custom implementation for maintaining product data that does the validations
- Prepare Interceptor: some logic that manipulates values before saving e.g. a product in MD (e.g. normalizing a product code to upper case or set some default values based on custom logic and existing values)
- Emporix implementation might be a cloud function or middle ware that manipulates data before sending to Emporix API - open: what’s the best way to integrate this in MD, e.g. for product?
- Dynamic Attribute
- Emporix implementation might be also a cloud function or middle ware
- …
Best Regards
Georg
It is a great idea to map specific SAP Hybris implementation patterns to Emporix concepts. Because Emporix is built on a composable, MACH-based architecture (Microservices, API-first, Cloud-native, Headless), many of the monolithic concepts from Hybris translate into decentralized, API-driven, or event-driven solutions,.
Here is how your specific Hybris examples map to the Emporix platform:
1. Complex Validations for MD (Management Dashboard)
Your assumption about using an MD extension is absolutely correct. Emporix supports Management Dashboard Extensions using a React-based micro-frontend framework,. This allows you to build custom UI components to handle complex, cross-attribute validation logic on the frontend before any data is sent,.
Additionally, you can handle many validations natively without custom code:
- Mixin Schemas: Emporix uses a schema-less JSON architecture where you can extend standard entities (like products, customers, and orders) using Mixin Schemas,. Because these are defined by uploading a JSON schema file, the system natively validates the payload against your schema during creation or updates,.
- Classification Categories: If your validation relates to product data, you can assign products to Classification Categories. These categories enforce required attribute schemas (Classification Mixins), and the system will natively validate that products include values for all required fields when they are updated or created,.
2. Prepare Interceptor (Data manipulation before saving to the DB)
Your idea of using a Cloud Function or middleware is the standard approach in a composable architecture. Emporix provides built-in Cloud Function Hosting (supporting Node.js and Python) so you can deploy serverless custom logic directly within the Emporix infrastructure,.
How to best integrate this with MD for a product?
Since the core Emporix APIs cannot be directly modified, the most effective way to intercept and manipulate MD inputs before they hit the Emporix API is to combine your Cloud Function with a custom MD Extension. You can build a custom MD module that captures the user’s input and invokes your hosted Cloud Function,. The Cloud Function then normalizes the data (e.g., changing product codes to uppercase or setting defaults) and makes the final, sanitized API call to the Emporix Commerce Engine,.
Alternatively, if the manipulation does not strictly need to happen before the save, you can use Webhook Event Publishing combined with the Orchestration Engine. When the product is saved, an event is emitted, triggering an automated workflow to immediately normalize the newly saved data,.
3. Dynamic Attributes
In Emporix, adding fields on the fly is primarily handled by the Mixin Schemas mentioned above, which allow you to extend the data model at runtime without database migrations.
However, if by “dynamic” you mean attributes that are calculated on the fly (e.g., real-time pricing, availability, or custom fees), this maps to Emporix’s Extensibility Cases (API Breakouts). Instead of customizing the core data model, you configure Emporix to make synchronous API calls to external services (like an ERP, a middleware layer, or a Cloud Function) to fetch dynamically calculated values during processes like cart calculation or checkout,. For instance, the Backend-for-Frontend (BFF) layer can simulate an order in SAP S/4HANA to retrieve real-time pricing and conditions, then inject those dynamic values directly into the Emporix cart,.
General Best Practice for Hybris Migrations:
When moving away from a monolithic backend, the best practice in Emporix is to use the Value Stream Modeller and Orchestration Engine (OE) to replace custom backend logic and cron jobs,. Instead of writing hardcoded interceptors or scheduled tasks, you can visually map out event-driven workflows that respond to real-time triggers across your entire tech stack.