Introduction
Interceptors are one of the most important concepts in SAP Commerce development.
If you have worked with:
ModelService- Model creation
- Model save
- Model update
- Model removal
- Validation
- Business rules
- Custom itemtypes
you have probably encountered interceptors.
A simple operation such as:
modelService.save(productModel);can trigger multiple interceptors before and during persistence.
This makes interceptors extremely useful for enforcing business rules and preparing model data.
However, they can also become a source of difficult production issues when developers don't understand when an interceptor executes and what it should be used for.
SAP Commerce provides different interceptor interfaces for different lifecycle stages. For example, ValidateInterceptor runs after preparation and before the model is persisted, while RemoveInterceptor runs before a model is removed.
In this article, we will cover:
- What interceptors are
- Interceptor lifecycle
- InitDefaultsInterceptor
- PrepareInterceptor
- ValidateInterceptor
- LoadInterceptor
- RemoveInterceptor
- Custom interceptors
- Spring configuration
- Interceptor context
isNew()isModified()- Avoiding recursive saves
- Performance considerations
- Troubleshooting
- Real production scenarios
- Senior-level interview questions
1. What Is an Interceptor?
An interceptor is a mechanism that allows SAP Commerce code to execute logic at specific points in a model's lifecycle.
For example:
Create Model
↓
Initialize Defaults
↓
Prepare
↓
Validate
↓
Save
↓
Load
↓
RemoveInstead of putting all business logic directly inside the model or service, an interceptor can execute logic at the appropriate lifecycle stage.
2. Why Do We Need Interceptors?
Suppose you have a custom item:
<itemtype code="CustOrder">
<attributes>
<attribute qualifier="orderNumber"
type="java.lang.String">
<modifiers read="true"
write="true"
optional="false"/>
</attribute>
</attributes>
</itemtype>The business requirement is:
Every CustOrder must have an order number before it is saved.
You could implement this logic in multiple places.
But then you might have:
OCC
↓
Service
↓
DAO
Backoffice
↓
Service
CronJob
↓
Service
Impex
↓
ModelServiceIf every path needs the same validation, an interceptor can provide a centralized lifecycle-level check.
3. Main SAP Commerce Interceptor Types
The important interceptor types are:
InitDefaultsInterceptor
PrepareInterceptor
ValidateInterceptor
LoadInterceptor
RemoveInterceptorConceptually:
Model Lifecycle
|
v
InitDefaultsInterceptor
|
v
PrepareInterceptor
|
v
ValidateInterceptor
|
v
SAVE
|
v
LoadInterceptor
|
v
REMOVE
|
v
RemoveInterceptorThe exact execution behavior depends on the operation and the configured interceptors.
4. InitDefaultsInterceptor
InitDefaultsInterceptor is used when a model is initialized with default values.
Conceptually:
modelService.create(ProductModel.class);can result in default initialization logic being applied.
A custom interceptor can provide defaults.
Example:
public class CustomOrderInitDefaultsInterceptor
implements InitDefaultsInterceptor
{
@Override
public void onInitDefaults(
Object model,
InterceptorContext ctx)
throws InterceptorException
{
CustOrderModel order = (CustOrderModel) model;
if (order.getStatus() == null)
{
order.setStatus(OrderStatus.NEW);
}
}
}The important concept is:
Create model
↓
Initialize default valuesSAP Commerce's interceptor APIs document onInitDefaults() as being called by ModelService.initDefaults(Object) after a model is instantiated.
5. PrepareInterceptor
PrepareInterceptor is one of the most frequently used interceptors.
It is intended to prepare model data before persistence.
SAP Commerce calls the interceptor's onPrepare() during ModelService.saveAll().
For example:
public class CustOrderPrepareInterceptor
implements PrepareInterceptor<CustOrderModel>
{
@Override
public void onPrepare(
CustOrderModel model,
InterceptorContext ctx)
throws InterceptorException
{
if (model.getOrderNumber() == null)
{
model.setOrderNumber(
UUID.randomUUID().toString()
);
}
}
}The responsibility here is:
Prepare datanot:
Validate data6. PrepareInterceptor Example
Suppose your model has:
firstName
lastName
fullNameBusiness requirement:
fullName = firstName + " " + lastNameA prepare interceptor could do:
public class CustomerPrepareInterceptor
implements PrepareInterceptor<CustomerModel>
{
@Override
public void onPrepare(
CustomerModel customer,
InterceptorContext ctx)
throws InterceptorException
{
if (customer.getFirstName() != null &&
customer.getLastName() != null)
{
customer.setFullName(
customer.getFirstName()
+ " "
+ customer.getLastName()
);
}
}
}Now:
firstName = John
lastName = Smithbecomes:
fullName = John Smithbefore persistence.
7. Prepare vs Validate
This is one of the most common interview questions.
PrepareInterceptor
Purpose:
Prepare / modify / derive dataExample:
Generate code
Set default value
Calculate derived field
Synchronize related model informationValidateInterceptor
Purpose:
Validate dataExample:
Mandatory field check
Business validation
Cross-field validationSAP explicitly describes ValidateInterceptor as being called after required PrepareInterceptors and before saving, and recommends using Prepare for preparation and Validate for validation.
8. ValidateInterceptor
A ValidateInterceptor validates a model before it is saved.
Example:
public class CustOrderValidateInterceptor
implements ValidateInterceptor<CustOrderModel>
{
@Override
public void onValidate(
CustOrderModel model,
InterceptorContext ctx)
throws InterceptorException
{
if (model.getOrderNumber() == null)
{
throw new InterceptorException(
"Order number cannot be null"
);
}
}
}Now:
modelService.save(orderModel);will fail if:
orderNumber == null9. Why Throw InterceptorException?
An interceptor can prevent persistence by throwing an exception.
For example:
throw new InterceptorException(
"Invalid order state"
);The save operation can then fail.
This is useful when the data violates a mandatory business rule.
Conceptually:
ModelService.save()
|
v
Prepare
|
v
Validate
|
+---- Invalid
| |
| v
| Exception
|
+---- Valid
|
v
SAVE10. LoadInterceptor
A LoadInterceptor is associated with model loading.
Conceptually:
Database
↓
ModelService
↓
LoadInterceptor
↓
ModelIt can be used when a model is loaded and additional logic is required.
However, LoadInterceptor should be used carefully.
Loading a model can happen very frequently in a Commerce application.
For example:
ProductModel product =
modelService.get(pk);If your LoadInterceptor performs expensive logic, every load can become expensive.
11. Why LoadInterceptor Can Be Dangerous
Imagine:
public void onLoad(
ProductModel product,
InterceptorContext ctx)
{
// expensive FlexibleSearch
}Now suppose the application loads:
10,000 productsYou could accidentally trigger:
10,000 additional queriesThis can create a serious performance problem.
Therefore:
Avoid expensive database queries and external service calls inside LoadInterceptors.
12. RemoveInterceptor
RemoveInterceptor executes before a model is removed.
SAP Commerce documentation states that RemoveInterceptor is called before the model is removed from the database. It can be used to prevent removal or remove related models.
Example:
public class CustomOrderRemoveInterceptor
implements RemoveInterceptor<CustOrderModel>
{
@Override
public void onRemove(
CustOrderModel model,
InterceptorContext ctx)
throws InterceptorException
{
if (model.isProtectedOrder())
{
throw new InterceptorException(
"Protected order cannot be removed"
);
}
}
}Now:
modelService.remove(order);can be prevented.
13. RemoveInterceptor Use Case
Suppose:
Parent
|
+---- Child
|
+---- Child
|
+---- ChildWhen the parent is removed, business requirements may require related cleanup.
A RemoveInterceptor can participate in that lifecycle.
However, if the relation already has appropriate partof semantics or platform-supported cascading behavior, you should not duplicate that behavior unnecessarily.
14. InterceptorContext
InterceptorContext is extremely important.
The interceptor receives:
InterceptorContext ctxExample:
@Override
public void onPrepare(
ProductModel product,
InterceptorContext ctx)
throws InterceptorException
{
// logic
}The context provides information about the current interceptor operation.
It can help answer questions such as:
Is this model new?
Was this attribute modified?
Is this model being removed?15. Checking Whether a Model Is New
A common pattern is:
if (ctx.isNew(model))
{
// logic for new model
}For example:
public void onPrepare(
CustOrderModel order,
InterceptorContext ctx)
throws InterceptorException
{
if (ctx.isNew(order))
{
order.setStatus(OrderStatus.NEW);
}
}This avoids applying creation-only logic to every update.
16. Checking Whether an Attribute Changed
A very useful pattern is:
ctx.isModified(model, "status")For example:
if (ctx.isModified(order, "status"))
{
// status changed
}This is extremely useful for performance.
Instead of:
Every save
↓
Execute expensive logicyou can use:
Only when relevant attribute changes
↓
Execute logic17. Example: Attribute-Specific Prepare Logic
Suppose an order has:
status
paymentStatus
deliveryStatusYou only want to execute logic when:
paymentStatuschanges.
Use:
@Override
public void onPrepare(
OrderModel order,
InterceptorContext ctx)
throws InterceptorException
{
if (ctx.isModified(order, "paymentStatus"))
{
// Perform payment-related preparation
}
}This is much better than executing the logic on every save.
18. Important Rule: Don't Put Everything in Interceptors
This is a common mistake.
Developers sometimes create:
PrepareInterceptor
↓
100 lines of business logic
↓
FlexibleSearch
↓
External REST call
↓
Multiple model savesThis makes the persistence lifecycle difficult to understand.
A better architecture is:
Interceptor
↓
Small lifecycle-specific logic
↓
Service
↓
Business logicFor example:
if (ctx.isModified(order, "status"))
{
orderStatusService.handleStatusChange(order);
}The interceptor remains small.
19. Interceptor vs Service Layer
This is another important interview topic.
Service Layer
Use for:
Business operations
Workflows
Transactions
Complex business logic
External integrations
Reusable application operationsInterceptor
Use for:
Model lifecycle rules
Preparation
Validation
Load behavior
Remove behaviorFor example:
Good:
PrepareInterceptor
↓
orderService.prepareOrder(order)rather than:
PrepareInterceptor
↓
50 lines of business logic20. Custom Interceptor Configuration
A custom interceptor normally needs Spring configuration.
Conceptually:
<bean id="custOrderPrepareInterceptor"
class="com.example.interceptors.CustOrderPrepareInterceptor"/>Then register it with the appropriate interceptor configuration for the target type.
The exact Spring/Interceptor configuration differs between SAP Commerce versions and project conventions, so use the corresponding platform configuration supported by your version.
The important architecture is:
Spring Bean
↓
Interceptor Registration
↓
Target Item Type
↓
Lifecycle Event
↓
onPrepare/onValidate/etc.21. Generic vs Typed Interceptors
You may see:
PrepareInterceptoror:
PrepareInterceptor<ProductModel>A typed interceptor is preferable when the interceptor is intended for one specific model type.
Example:
public class ProductPrepareInterceptor
implements PrepareInterceptor<ProductModel>This gives you stronger compile-time typing.
22. Example: Custom Product ValidateInterceptor
Suppose the requirement is:
A product cannot be approved unless it has a valid code and name.
Implementation:
public class ProductValidateInterceptor
implements ValidateInterceptor<ProductModel>
{
@Override
public void onValidate(
ProductModel product,
InterceptorContext ctx)
throws InterceptorException
{
if (product.getCode() == null ||
product.getCode().trim().isEmpty())
{
throw new InterceptorException(
"Product code is mandatory"
);
}
if (product.getName() == null ||
product.getName().trim().isEmpty())
{
throw new InterceptorException(
"Product name is mandatory"
);
}
}
}Now validation is centralized.
23. Example: PrepareInterceptor for Generated Identifier
Suppose:
CustSAPCpiInboundOrderneeds a generated identifier if none is supplied.
You could implement:
public class CustInboundOrderPrepareInterceptor
implements PrepareInterceptor<CustSAPCpiInboundOrderModel>
{
@Override
public void onPrepare(
CustSAPCpiInboundOrderModel model,
InterceptorContext ctx)
throws InterceptorException
{
if (ctx.isNew(model) &&
model.getOrderNumber() == null)
{
model.setOrderNumber(
UUID.randomUUID().toString()
);
}
}
}This is a good example of using:
PrepareInterceptor
+
InterceptorContext.isNew()24. Avoid Recursive Save Problems
One of the most important interceptor mistakes is calling:
modelService.save(model);inside an interceptor unnecessarily.
For example:
public void onPrepare(
ProductModel product,
InterceptorContext ctx)
{
product.setName("New Name");
modelService.save(product);
}This can cause:
save
↓
PrepareInterceptor
↓
modelService.save()
↓
PrepareInterceptor
↓
modelService.save()
↓
...Potentially resulting in recursion, repeated interception, performance problems, or unexpected behavior.
Generally, the interceptor should modify the model and let the original persistence operation continue.
For example:
public void onPrepare(
ProductModel product,
InterceptorContext ctx)
{
product.setName("New Name");
}The original ModelService.save() handles persistence.
25. Interceptor Ordering
Multiple interceptors can exist for the same model type and lifecycle.
For example:
Product
|
+---- PrepareInterceptor A
|
+---- PrepareInterceptor B
|
+---- PrepareInterceptor CThe execution order can matter.
If:
Interceptor Asets:
attribute Xand:
Interceptor Bdepends on X, ordering becomes important.
Do not assume the execution order simply because the beans appear in a particular order in a Spring XML file.
Use the supported interceptor ordering mechanism for your SAP Commerce version.
26. Interceptor Exceptions
An interceptor can throw:
InterceptorExceptionExample:
throw new InterceptorException(
"Invalid product state"
);This can propagate back through the save operation.
At an API layer, the exception may eventually become an OCC error response depending on your exception handling configuration.
Therefore, there can be a chain:
Interceptor
↓
InterceptorException
↓
Service Layer
↓
OCC
↓
Error DTO
↓
HTTP ResponseThis connects today's topic directly with the previous OCC error-handling article.
27. Interceptors and Transactions
Interceptors execute as part of model lifecycle operations.
Therefore, you should be careful about performing external operations.
For example:
Save Product
↓
Interceptor
↓
Call external REST APIIf the external API call takes:
5 secondsyour save operation may also be affected.
Worse, if the Commerce transaction later fails, the external system may already have received the request.
This is why external integrations are generally better handled through appropriate service/event/process mechanisms rather than making persistence interceptors perform synchronous external calls.
28. Interceptor Performance
Interceptors execute frequently.
Therefore, performance matters.
Avoid:
FlexibleSearch on every save
External REST call
Large loops
Heavy calculations
Multiple model loads
Repeated savesPrefer:
Check whether relevant attribute changed
↓
Execute only required logicFor example:
if (ctx.isModified(model, "status"))
{
statusService.process(model);
}29. A Bad Interceptor Example
@Override
public void onPrepare(
ProductModel product,
InterceptorContext ctx)
{
List<ProductModel> products =
flexibleSearchService.search(
"SELECT {pk} FROM {Product}"
).getResult();
for (ProductModel p : products)
{
// expensive processing
}
}Imagine this runs every time a Product is saved.
If the system processes thousands of product saves:
Thousands of saves
×
Full product query
=
Performance problemThis is exactly the type of code that can cause production issues.
30. Better Approach
Instead:
@Override
public void onPrepare(
ProductModel product,
InterceptorContext ctx)
throws InterceptorException
{
if (ctx.isModified(product, "price"))
{
productPriceService.handlePriceChange(product);
}
}The interceptor is:
- Small
- Targeted
- Easy to test
- Easier to troubleshoot
31. Interceptor vs Event
Another common interview question:
When should you use an interceptor vs an event?
Use an interceptor when you need to enforce a model lifecycle rule.
Use an event when you want to communicate that something happened and potentially process it asynchronously.
For example:
Product validation
→ ValidateInterceptorwhile:
Order placed
→ EventThe event can then trigger additional processing without putting everything into the model save lifecycle.
32. Interceptor vs CronJob
These are also very different.
Interceptor
Triggered by model lifecycle operations.
save()
↓
interceptorCronJob
Triggered according to a schedule or explicit execution.
11:00 PM
↓
CronJobDon't use an interceptor for large batch processing.
Bad:
Product save
↓
Process 100,000 productsBetter:
CronJob
↓
Process batch33. Real Production Scenario: Save Is Failing
Suppose developers report:
"Product save is failing only in one environment."
The first question should be:
Which interceptor is failing?Check the stack trace.
Look for:
InterceptorException
PrepareInterceptor
ValidateInterceptor
LoadInterceptor
RemoveInterceptorThen identify:
Model type
Interceptor class
Attribute
Root exceptionFor example:
ModelService.save()
↓
ValidateInterceptor
↓
InterceptorException
↓
"Brand is mandatory"This immediately narrows the problem.
34. Real Production Scenario: Works in DEV but Fails Locally
Suppose:
DEV → Save works
QA → Save works
PROD → Save works
LOCAL → Save failsA custom interceptor could be one possible area to investigate.
Check:
1. Extension loaded?
2. Spring bean loaded?
3. Interceptor registration present?
4. Local database data?
5. Local system configuration?
6. Local model state?
7. Local generated classes updated?
8. Local deployment/build complete?This is especially useful when the exception appears during:
modelService.save(model);35. Real Production Scenario: Infinite/Repeated Save
Problem:
StackOverflowErroror repeated interceptor execution.
Check whether an interceptor is doing:
modelService.save(model);inside:
onPrepare()
onValidate()or triggering another save path indirectly.
A safer pattern is usually:
model.setSomething(value);and allow the current persistence operation to continue.
36. Real Production Scenario: Validation Error in OCC
Suppose OCC calls:
POST /ordersand the save triggers:
ValidateInterceptorwhich throws:
InterceptorExceptionThe flow could be:
OCC Controller
↓
Facade
↓
Service
↓
ModelService.save()
↓
ValidateInterceptor
↓
Exception
↓
OCC Error Handling
↓
HTTP Error ResponseThis is why interceptor errors can appear as API errors even though the actual root cause is in the model lifecycle.
37. Interceptor Debugging Checklist
When debugging an interceptor issue:
1. Identify the model type
2. Identify the lifecycle operation
3. Identify the interceptor type
4. Identify the interceptor class
5. Check interceptor registration
6. Check InterceptorContext conditions
7. Check modified attributes
8. Check custom service calls
9. Check recursive save calls
10. Check FlexibleSearch/external calls
11. Check exception root cause
12. Check environment-specific configuration38. Interview Question: What Is a PrepareInterceptor?
Answer
A PrepareInterceptor is used to prepare or modify model data before it is persisted.
For example:
@Override
public void onPrepare(
ProductModel product,
InterceptorContext ctx)
{
if (ctx.isNew(product))
{
product.setCustomFlag(Boolean.TRUE);
}
}SAP Commerce invokes onPrepare() during the save lifecycle.
39. Interview Question: What Is a ValidateInterceptor?
Answer
A ValidateInterceptor validates model values before persistence.
Example:
if (product.getCode() == null)
{
throw new InterceptorException(
"Product code is mandatory"
);
}Validation happens after preparation and before the model is saved.
40. Interview Question: PrepareInterceptor vs ValidateInterceptor?
Answer
PrepareInterceptor
→ Modify / prepare data
ValidateInterceptor
→ Validate dataExample:
Prepare:
Generate order number
Validate:
Order number must not be nullA good rule is:
Prepare the model in PrepareInterceptor; reject invalid data in ValidateInterceptor.
41. Interview Question: When Is RemoveInterceptor Called?
Answer
It is called before a model is removed from the database.
It can be used to:
- Prevent deletion
- Perform removal-related validation
- Clean related data where appropriate
SAP Commerce documents RemoveInterceptor.onRemove() as being called by ModelService.removeAll().
42. Interview Question: Why Should You Avoid Heavy Logic in LoadInterceptor?
Answer
Because model loading can happen very frequently.
If every model load triggers:
FlexibleSearch
REST call
Complex calculationthe application can experience significant performance degradation.
Therefore, LoadInterceptor logic should be lightweight and carefully justified.
43. Interview Question: How Do You Know an Attribute Changed?
Use:
ctx.isModified(model, "attributeQualifier")Example:
if (ctx.isModified(order, "status"))
{
// Process status change
}This avoids unnecessary processing.
44. Interview Question: How Do You Check Whether a Model Is New?
Use:
ctx.isNew(model)Example:
if (ctx.isNew(product))
{
// Creation-specific logic
}This is useful when logic should only run during initial creation.
45. Interview Question: Can You Save a Model Inside a PrepareInterceptor?
Technically, code can invoke ModelService operations, but doing so unnecessarily is dangerous.
A common bad pattern is:
onPrepare()
↓
modelService.save(model)
↓
onPrepare()
↓
modelService.save(model)This can lead to recursive or repeated interceptor execution.
Prefer:
onPrepare()
↓
model.setValue(...)
↓
Current save continues46. Interview Question: Interceptor or Service?
Use an interceptor for lifecycle-specific rules:
"Before this model is persisted, ensure X."Use a service for business operations:
"Perform the complete order cancellation workflow."Don't turn interceptors into giant business-service classes.
47. Senior Interview Scenario
Question
You have this code:
public void onPrepare(
ProductModel product,
InterceptorContext ctx)
{
List<ProductModel> products =
productService.getAllProducts();
for (ProductModel p : products)
{
// processing
}
}The application becomes slow when products are imported.
What is wrong?
Answer
The interceptor is executing expensive batch logic during the model persistence lifecycle.
If thousands of products are imported:
Thousands of model saves
×
Get all products
=
Huge processing overheadThe logic should be moved to an appropriate batch/CronJob/process mechanism, or redesigned so that the interceptor performs only the minimum required lifecycle work.
48. Senior Interview Scenario
Question
A custom ValidateInterceptor works in one environment but not another.
What would you check?
Answer
I would verify:
Spring bean
Interceptor registration
Extension loading
Deployment/build
Generated model classes
Database configuration
Environment-specific properties
Data differences
Interceptor enablement/orderThen reproduce the save operation and inspect the full root cause.
49. Senior Interview Scenario
Question
A product save takes 3 seconds after a new interceptor was introduced.
How would you investigate?
Answer
I would profile the interceptor first.
Look for:
FlexibleSearch
ModelService.get()
External API
Loops
Multiple saves
Large collections
Repeated service callsThen check whether the interceptor executes unnecessarily.
For example:
if (ctx.isModified(product, "price"))
{
// execute only for price changes
}This can significantly reduce unnecessary work.
50. Best Practices
Keep interceptors small
Good:
5-30 linesBad:
300 lines of business logicThe exact size isn't a rule, but complexity should be minimized.
Use the correct interceptor
Default initialization
→ InitDefaultsInterceptor
Prepare data
→ PrepareInterceptor
Validate data
→ ValidateInterceptor
Load-specific behavior
→ LoadInterceptor
Remove-specific behavior
→ RemoveInterceptorCheck changes
Use:
ctx.isModified(model, "attribute")when appropriate.
Check new models
Use:
ctx.isNew(model)when creation-only logic is required.
Avoid recursive saves
Do not unnecessarily call:
modelService.save()from within an interceptor.
Avoid external calls
Don't make persistence depend on slow external systems unless there is a very strong reason and the transaction/error implications are fully understood.
Don't perform batch processing
Use:
CronJob
Business Process
Event
Servicewhen the operation is large or asynchronous in nature.
51. Complete Interceptor Lifecycle
For interview revision:
MODEL LIFECYCLE
|
v
ModelService.create()
|
v
InitDefaultsInterceptor
|
v
Model Changes
|
v
ModelService.save()
|
v
PrepareInterceptor
|
v
ValidateInterceptor
|
+-----+-----+
| |
Invalid Valid
| |
v v
Exception Database
|
v
ModelService.get()
|
v
LoadInterceptor
|
v
ModelService.remove()
|
v
RemoveInterceptorThe exact interceptor chain can vary according to the operation and configured interceptors, but this is a useful conceptual model.
52. Quick Comparison Table
| Interceptor | Main Purpose | Typical Example |
|---|---|---|
| InitDefaultsInterceptor | Set initial defaults | Default status |
| PrepareInterceptor | Prepare/modify model | Generate identifier |
| ValidateInterceptor | Validate data | Mandatory field |
| LoadInterceptor | Logic during model load | Lightweight load-related behavior |
| RemoveInterceptor | Before removal | Prevent deletion/cleanup |
53. Final Takeaway
Interceptors are a core part of SAP Commerce's service-layer architecture.
The most important distinction is:
Prepare
↓
Prepare or modify the model
Validate
↓
Check whether the model is validAnd:
InitDefaults
↓
Set defaults
Load
↓
React to loading
Remove
↓
React before deletionFor senior SAP Commerce development, don't just memorize the interfaces.
Understand when they execute, what they should contain, and what should NOT be placed inside them.
A well-designed interceptor should be:
- Small
- Fast
- Lifecycle-specific
- Easy to test
- Free from unnecessary database calls
- Free from unnecessary external calls
- Careful about recursive saves
The most useful pattern to remember is:
if (ctx.isModified(model, "importantAttribute"))
{
// Do only the required lifecycle logic
}and:
if (ctx.isNew(model))
{
// Creation-specific logic
}These two patterns are particularly useful in real SAP Commerce projects.
