Introduction
In the previous article, we discussed how Solr provides search and faceted navigation in SAP Commerce.
Today, we will go one level deeper and understand how SAP Commerce actually puts Commerce data into the Solr index.
This is an especially important topic for senior SAP Commerce developers because many production issues are related to indexing:
Product exists in database
↓
Product does not appear in searchor:
Product price changed
↓
Database has new price
↓
Search still shows old priceor:
New indexed property added
↓
Application deployed
↓
Search does not return expected resultsUnderstanding the indexing pipeline makes these problems much easier to troubleshoot.
1. What Is Solr Indexing?
Solr indexing is the process of converting SAP Commerce data into searchable Solr documents.
At a high level:
SAP Commerce
|
v
Product / Other Indexed Item
|
v
Indexer
|
v
Indexed Properties
|
v
Value Providers
|
v
Solr Document
|
v
Solr IndexFor example, a Commerce product might contain:
code = IPHONE-001
name = iPhone
brand = Apple
price = 79999
color = BlackThe indexing process converts the relevant information into fields that Solr can search.
Conceptually:
ProductModel
|
+---- code -----> Solr field
|
+---- name -----> Solr field
|
+---- brand ----> Solr field
|
+---- price ----> Solr field
|
+---- color ----> Solr fieldThe important point is that the Commerce database and Solr index are separate representations of the data.
2. Database vs Solr Index
This is one of the first concepts you should remember.
Commerce Database
|
| Source data
v
Indexer
|
v
Solr IndexThe database might contain:
Product 1001
price = 4999while the Solr document may still contain:
price = 5499until the appropriate indexing/update operation occurs.
Therefore:
Database data ≠ Solr dataThis explains many "product exists but search is wrong" production incidents.
3. SAP Commerce Solr Indexing Components
A simplified indexing architecture looks like this:
SAP Commerce
|
v
Indexed Type
|
v
Indexed Properties
|
v
Indexer Queries
|
v
Value Providers
|
v
Indexer Service
|
v
SolrImportant concepts include:
- Indexed Type
- Indexed Properties
- Indexer Queries
- Value Providers
- Indexer Service
- Indexer Operations
- CronJobs
- Solr Index
- Search Configuration
4. What Is an Indexed Type?
An Indexed Type identifies the type of Commerce item that should be indexed.
A common example is:
ProductFor example:
Indexed Type = ProductThen you configure the properties that need to be indexed:
Product.code
Product.name
Product.description
Product.price
Product.brand
Product.colorThe exact configuration depends on your Commerce version and project.
5. What Is an Indexed Property?
An Indexed Property represents an attribute that should be available in Solr.
For example:
name
brand
price
color
size
categoryEach property can have a specific purpose.
For example:
name
→ searchable
brand
→ filterable/facetable
price
→ sortable/range filtering
code
→ searchable
color
→ facetThis distinction is important.
Not every property should be configured for every search capability.
6. What Is an Indexer Query?
The indexer needs to know which Commerce items it should process.
Indexer queries determine which items are selected for indexing operations.
Conceptually:
Database
|
v
Indexer Query
|
v
Products to ProcessFor example, an update operation may identify products that have changed since a particular point in time.
The exact query structure depends on the configured indexed type and operation.
7. What Is a Value Provider?
Sometimes the required Solr value isn't simply:
product.getCode()The value may need to be calculated.
For example:
Product
|
+-- Brand
+-- Category
+-- Classification
|
v
Custom Search TextA value provider can be used to produce the value that should be indexed.
Example concept:
public String buildSearchValue(ProductModel product)
{
StringBuilder value = new StringBuilder();
value.append(product.getName());
if (product.getManufacturerName() != null)
{
value.append(" ");
value.append(product.getManufacturerName());
}
return value.toString();
}The actual SAP Commerce interface and implementation should follow the platform version being used.
8. Solr Index Operations
SAP Commerce supports several important indexing operations:
FULL
UPDATE
PARTIAL_UPDATE
DELETEThese operations have different purposes.
9. FULL Index
A FULL operation recreates the index from the complete configured dataset.
Conceptually:
Existing Solr Index
|
v
FULL
|
v
Read all required Commerce items
|
v
Create new Solr indexSAP documentation describes FULL as recreating the index and processing all items selected by the FULL index query.
FULL indexing is commonly required when:
- Setting up a new index
- Major indexing configuration changes are introduced
- New indexed properties are added
- Large amounts of indexed data need rebuilding
- The existing index is suspected to be stale
- Removed database data must be reflected in the index
10. FULL Indexing Example
Suppose you have:
1,000,000 productsand add:
materialas a new indexed property.
Existing Solr documents may not contain the new field.
You may need to rebuild the index:
New Configuration
|
v
FULL Index
|
v
1,000,000 Products
|
v
Updated Solr IndexRunning a full index on a large catalog can be expensive, so it should be planned appropriately.
11. UPDATE Operation
An UPDATE operation updates selected existing indexed items.
Conceptually:
10 products changed
|
v
UPDATE
|
v
Only relevant products processedSAP documentation describes UPDATE as updating selected documents, normally based on an UPDATE query.
This is generally more efficient than rebuilding an entire index when only a subset of data has changed.
12. FULL vs UPDATE
A common interview question is:
What is the difference between FULL and UPDATE?
| FULL | UPDATE |
|---|---|
| Recreates the index | Updates selected documents |
| Processes complete configured data | Processes selected changes |
| More expensive | Usually less expensive |
| Used for rebuilding | Used for normal updates |
| Useful after major configuration changes | Useful for changed items |
A simple way to remember:
FULL → rebuild everything
UPDATE → update selected items13. PARTIAL_UPDATE
PARTIAL_UPDATE is different from a normal UPDATE.
With partial update, only selected fields of an existing Solr document are changed.
For example:
Product
name = Nike Shoes
brand = Nike
price = 4999
stock = 20Only stock changes:
stock = 5A partial update can target the required field instead of reconstructing the entire document.
SAP documents PARTIAL_UPDATE as potentially faster than a normal UPDATE because it can select the fields to change, although it has additional limitations and configuration requirements.
14. UPDATE vs PARTIAL_UPDATE
This is an excellent senior interview question.
UPDATE
Conceptually:
Product changed
|
v
Build updated document
|
v
Update SolrPARTIAL_UPDATE
Conceptually:
Product changed
|
v
Only required field changes
|
v
Update selected Solr fieldsRemember:
UPDATE
= update document
PARTIAL_UPDATE
= update selected document fields15. Important PARTIAL_UPDATE Limitation
Partial updates are not automatically better in every situation.
SAP documentation lists limitations for PARTIAL_UPDATE, including requirements around stored Solr attributes and restrictions for some fields such as those used for spellchecking/suggestions. SAP also notes that continuously refreshing the index can affect search performance.
Therefore:
PARTIAL_UPDATE ≠ always use thisThe correct operation depends on the type of data change and indexing architecture.
16. DELETE Operation
DELETE removes selected documents from the Solr index.
For example:
Product ABCis no longer supposed to appear in search.
Conceptually:
Product ABC
|
v
DELETE
|
v
Removed from SolrSAP documentation describes DELETE as removing selected documents while leaving other indexed documents available.
17. Why Can Deleted Products Remain in Solr?
Consider:
Product exists in DBthen it is deleted.
However:
Solr document still existsThis can happen if the corresponding delete/index synchronization hasn't occurred.
That's one reason SAP documentation recommends regularly using FULL indexing to ensure data removed from the database is also removed from Solr.
This can produce a classic production problem:
Product deleted from Commerce
|
v
Product still appears in search18. FULL, UPDATE, PARTIAL_UPDATE and DELETE
Keep this table for interview revision:
| Operation | Purpose |
|---|---|
| FULL | Recreate the index |
| UPDATE | Update selected documents |
| PARTIAL_UPDATE | Update selected fields of existing documents |
| DELETE | Remove selected documents |
A simple memory trick:
FULL → Everything
UPDATE → Documents
PARTIAL_UPDATE → Fields
DELETE → Remove19. What Is a Solr Indexer CronJob?
Indexing can be triggered through CronJobs.
SAP Commerce provides indexer CronJob types for different use cases.
SAP documentation states that SolrIndexerCronJob supports:
FULL
UPDATE
DELETEwhile SolrExtIndexerCronJob supports:
UPDATE
PARTIAL_UPDATE
DELETEwith different configuration behavior.
This distinction can be useful when troubleshooting why a particular indexing operation isn't available through a given CronJob configuration.
20. Typical CronJob Flow
A simplified flow is:
CronJob
|
v
Indexer Job
|
v
Indexer Service
|
v
Indexer Query
|
v
Commerce Items
|
v
Solr DocumentsFor example:
Nightly Full Index
|
v
SolrIndexerCronJob
|
v
FULL
|
v
Products
|
v
Solr21. When Should You Schedule Indexing?
A project might schedule indexing based on its business needs.
For example:
Nightly
|
+---- Full indexing
Every few minutes
|
+---- Incremental/Update processing
Near real time
|
+---- Hot/partial updates where appropriateThere is no universal schedule.
The correct strategy depends on:
- Catalog size
- Product update frequency
- Search SLA
- Infrastructure capacity
- Business requirements
- Number of indexed properties
- Number of sites/catalogs
22. What Is Hot Update?
A hot update is a selective update of the Solr index for particular items.
SAP Commerce provides an Indexer Hot Update Wizard for ad-hoc updates where only one or a few indexed items need to be updated or removed.
For example:
Product 1001
Product 1002need immediate reindexing.
Instead of rebuilding the complete catalog, a selective operation can update those items.
Conceptually:
1,000,000 products
|
+---- Product 1001
+---- Product 1002
|
v
Hot Update23. Hot Update vs Full Index
Full Index
1,000,000 products
|
v
Rebuild indexHot Update
2 products
|
v
Update only those productsThe important point is:
Use a targeted operation when the change is targeted.However, do not use selective updates blindly. You still need to understand why the index became inconsistent.
24. TWO_PHASE vs DIRECT FULL Indexing
For FULL indexing, SAP Commerce supports different indexing modes.
Two important modes are:
DIRECT
TWO_PHASESAP documentation describes DIRECT as indexing directly against the live index, while TWO_PHASE builds a temporary index and replaces the current live index after successful completion.
Conceptually:
DIRECT
Existing Live Index
|
v
Write changes directlyTWO_PHASE
Existing Live Index
|
| remains available
|
v
Temporary Index
|
v
Build complete
|
v
Replace Live IndexThis is a useful concept for understanding large production indexing operations.
25. Why Is TWO_PHASE Important?
Imagine:
10 million productsA full indexing process can take significant time.
If users must continue searching while a new index is being built, the indexing strategy becomes very important.
A two-phase approach can build the new index separately and switch once the operation succeeds.
This is one reason senior developers should understand not just what indexing does, but how index availability is managed during indexing.
26. Production Scenario: Product Price Is Stale
Suppose:
Database:
Product ABC
Price = 4999But search returns:
Price = 5499How do you investigate?
Step 1: Verify Commerce data
Check the Product/Price information.
Step 2: Determine where the search response gets its price
Is it:
Solr
Commerce service
Cache?
Step 3: Check Solr document
Verify whether Solr still contains:
5499Step 4: Check indexing/update
Determine whether the product update triggered:
UPDATEor an appropriate selective update.
Step 5: Check indexing errors
Review CronJob/indexer logs.
Step 6: Check caching
If Solr is correct but the API still returns the old value, continue downstream:
Solr
↓
Search Service
↓
Facade
↓
DTO
↓
Cache/APIThis prevents blindly running full indexing when the real problem is elsewhere.
27. Production Scenario: Product Deleted but Still Searchable
Problem:
Product deleted from Commercebut:
Search → Product still visiblePossible flow:
Database
↓
Product removed
↓
Delete event/index update?
↓
SolrCheck whether the appropriate delete/index operation occurred.
If stale documents remain, a properly planned FULL indexing operation can also reconcile the index with current database contents. SAP specifically recommends regular FULL indexing for this consistency reason.
28. Production Scenario: New Indexed Property Not Working
Suppose the business asks:
"Customers should search by material number."
You add:
materialNumberto the indexing configuration.
But after deployment:
Search material number
↓
No resultsDo not assume the configuration automatically populated old Solr documents.
Check:
1. Indexed Property
2. Correct Indexed Type
3. Value Provider
4. Search configuration
5. Indexing operation
6. Solr document
7. Search queryA full reindex may be required to populate the new field for existing data.
29. Production Scenario: Indexing Job Failed
Suppose a CronJob reports:
ERRORThe first mistake is to immediately rerun it.
Instead, determine:
What operation?
FULL / UPDATE / PARTIAL_UPDATE / DELETEThen investigate:
Indexer query
Value provider
Product data
Database connectivity
Solr connectivity
Solr configuration
Memory/resource limits
Custom codeA custom value provider is a common place to investigate when a particular product consistently causes indexing failures.
30. How Custom Value Providers Can Cause Problems
Imagine:
public Object getFieldValue(ProductModel product)
{
return someComplexService.loadData(product);
}Now imagine:
1,000,000 productsand each product triggers several database/service calls.
You could accidentally create:
1,000,000 × expensive operationThis can make indexing extremely slow.
Therefore, custom indexing logic should be designed carefully.
Avoid unnecessary:
FlexibleSearch inside loops
Repeated database calls
Network calls
Heavy calculationswherever possible.
31. Indexing Performance Optimization
For large catalogs, indexing performance matters.
Keep indexed data relevant
Do not index unnecessary attributes.
Keep custom providers efficient
Avoid expensive operations per product.
Avoid unnecessary FULL indexes
Use targeted update operations when appropriate.
Monitor CronJobs
Track:
Start time
End time
Status
Processed items
ErrorsReview Solr configuration
Poorly designed search configuration can affect both indexing and search performance.
32. Indexing and Catalog Size
Consider two projects.
Project A
20,000 productsProject B
10,000,000 productsA strategy that works for Project A may be completely inappropriate for Project B.
For example:
Run FULL index every hourmay be acceptable in one environment and operationally expensive in another.
Therefore, indexing strategy should always consider catalog scale.
33. Indexing and Multi-Site Architecture
Many SAP Commerce projects support multiple:
Base Sites
Catalogs
Catalog Versions
Currencies
LanguagesTherefore, Solr configuration needs to be considered carefully.
You may have:
Site A
|
+---- Catalog A
|
+---- Solr configuration A
Site B
|
+---- Catalog B
|
+---- Solr configuration BA search problem may therefore exist only for one site or catalog.
When troubleshooting, always ask:
Which site?
Which catalog?
Which catalog version?
Which language?
Which currency?
Which Solr configuration?34. Solr Indexing Troubleshooting Checklist
When search is not working, follow this sequence.
1. Does the Commerce item exist?
↓
2. Is it in the correct catalog/version?
↓
3. Is the indexed type correct?
↓
4. Is the property configured?
↓
5. Is the value provider returning a value?
↓
6. Did the index operation run?
↓
7. Did the index operation succeed?
↓
8. Does the Solr document contain the value?
↓
9. Is the search query looking at the correct field?
↓
10. Are restrictions/filters removing the result?
↓
11. Is cache returning stale data?This is a much better debugging approach than repeatedly running a full index.
35. Useful Logs to Check
Depending on the SAP Commerce version and project logging configuration, investigate logs related to:
Solr
Indexer
Facet Search
CronJob
Search
Custom Value ProviderWhen investigating an error, identify:
Product PK/code
Indexed Type
Facet Search Configuration
Operation
CronJob
Exception
Root causeThese details make production troubleshooting much faster.
36. Interview Question: Explain the Complete Solr Indexing Flow
Answer
A strong senior-level answer would be:
SAP Commerce takes configured Commerce data through an indexing pipeline. The indexed type defines what is being indexed, indexed properties define the searchable/indexed attributes, and indexer queries determine the items to process. Value providers can supply or calculate values for indexed properties. The indexer service then creates or updates Solr documents using operations such as FULL, UPDATE, PARTIAL_UPDATE, and DELETE. The resulting Solr index is later queried by the Commerce search layer and exposed through the storefront or OCC APIs.
37. Interview Question: FULL vs UPDATE?
Answer
FULL rebuilds the complete index based on the FULL index query.
UPDATE updates selected indexed documents.
Use FULL when rebuilding or reconciling a complete index is required.
Use UPDATE when only selected items have changed.
38. Interview Question: UPDATE vs PARTIAL_UPDATE?
Answer
UPDATE updates selected indexed documents.
PARTIAL_UPDATE can update selected fields of an existing document.
Therefore:
UPDATE
→ document-level update
PARTIAL_UPDATE
→ field-level updatePartial updates can be faster for appropriate use cases, but they have additional limitations and should be used according to the project's indexing design.
39. Interview Question: Why Is My Product in FlexibleSearch but Not Solr?
Answer
I would investigate the complete pipeline:
Product
↓
Catalog
↓
Indexed Type
↓
Indexed Property
↓
Indexer Query
↓
Value Provider
↓
Indexer
↓
Solr Document
↓
Search QueryI would also check:
Indexing CronJob
Indexing errors
Product status
Catalog version
Search configuration
Restrictions
Solr documentThis demonstrates actual production troubleshooting rather than assuming FlexibleSearch and Solr behave the same way.
40. Interview Question: Should You Run FULL Index Every Time a Product Changes?
Answer
No.
Running a full index for every product change can be unnecessarily expensive, especially with a large catalog.
Depending on the architecture, selective UPDATE, PARTIAL_UPDATE, hot updates, or another synchronization mechanism may be more appropriate.
The correct approach depends on:
Catalog size
Update frequency
Search SLA
Infrastructure
Business requirements41. Interview Question: What Happens During FULL Indexing?
Answer
At a high level:
FULL operation
|
v
Select complete configured dataset
|
v
Build Solr documents
|
v
Write index
|
v
Make index available according to the configured indexing modeSAP Commerce supports DIRECT and TWO_PHASE modes for FULL operations.
42. Interview Question: What Is a Hot Update?
Answer
A hot update is a selective Solr update for a limited number of items rather than rebuilding the complete index.
It is useful for ad-hoc or targeted corrections where only a few indexed items need to be updated or deleted. SAP Commerce provides a Hot Update Wizard for this purpose.
43. Senior-Level Production Question
Question
A business user changes a product in Backoffice and immediately sees the new data in one environment, but another environment continues showing the old search result.
How would you investigate?
Answer
I would compare the indexing architecture between environments.
Check:
1. Solr configuration
2. Indexing mode
3. Hot update configuration
4. Background/async indexing
5. CronJob schedules
6. Indexing failures
7. Solr connectivity
8. Cache
9. Catalog/version
10. Search configurationI would also check whether the second environment is intentionally using asynchronous indexing.
SAP's Backoffice documentation notes that background Solr indexing can make updates asynchronous, meaning search results may not immediately reflect the latest data while the background operation is still running.
44. Real Production Debugging Flow
When a search issue reaches production, use:
Search Issue
|
v
Check API response
|
v
Check search service
|
v
Check Solr
|
+--------+--------+
| |
Correct Wrong
| |
v v
Check API/cache Check index
|
v
Check indexing job
|
v
Check Commerce data
|
v
Fix + reindexThis approach helps isolate whether the problem is:
Data problem
Indexing problem
Solr problem
Search configuration problem
API problem
Caching problem45. Most Important Concepts to Remember
For interviews, remember these seven concepts:
1. Indexed Type
2. Indexed Property
3. Indexer Query
4. Value Provider
5. Indexing Operation
6. Solr Document
7. Search QueryAnd these four operations:
FULL
UPDATE
PARTIAL_UPDATE
DELETEAnd these two important FULL modes:
DIRECT
TWO_PHASE46. Quick Revision Diagram
SAP Commerce
|
v
Product / Data
|
v
Indexed Type
|
v
Indexed Properties
|
v
Indexer Queries
|
v
Value Providers
|
v
Indexer Service
|
+----------------+----------------+
| | |
v v v
FULL UPDATE PARTIAL_UPDATE
| | |
+----------------+----------------+
|
v
Solr Index
|
v
Search Service
|
+----------------+----------------+
| | |
v v v
Results Facets Sorting
|
v
OCC / Storefront47. Final Takeaway
SAP Commerce Solr indexing is much more than simply "running a Solr index."
A senior developer should understand the complete lifecycle:
Commerce Data
↓
Indexed Type
↓
Indexed Properties
↓
Indexer Queries
↓
Value Providers
↓
Indexing Operation
↓
Solr Document
↓
Search
↓
OCC / StorefrontThe four operations are:
FULL
UPDATE
PARTIAL_UPDATE
DELETEUse them based on the actual requirement rather than automatically choosing FULL indexing.
Most importantly, when a product exists in Commerce but search is incorrect, remember:
Database ≠ Solr IndexTroubleshoot the complete pipeline before deciding where the problem exists.
