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 search

or:

Product price changed
        ↓
Database has new price
        ↓
Search still shows old price

or:

New indexed property added
        ↓
Application deployed
        ↓
Search does not return expected results

Understanding 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 Index

For example, a Commerce product might contain:

code = IPHONE-001
name = iPhone
brand = Apple
price = 79999
color = Black

The 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 field

The 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 Index

The database might contain:

Product 1001
price = 4999

while the Solr document may still contain:

price = 5499

until the appropriate indexing/update operation occurs.

Therefore:

Database data ≠ Solr data

This 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
                  Solr

Important 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:

Product

For example:

Indexed Type = Product

Then you configure the properties that need to be indexed:

Product.code
Product.name
Product.description
Product.price
Product.brand
Product.color

The 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
category

Each property can have a specific purpose.

For example:

name
   → searchable

brand
   → filterable/facetable

price
   → sortable/range filtering

code
   → searchable

color
   → facet

This 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 Process

For 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 Text

A 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
DELETE

These 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 index

SAP 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 products

and add:

material

as 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 Index

Running 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 processed

SAP 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 items

13. 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    = 20

Only stock changes:

stock = 5

A 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 Solr

PARTIAL_UPDATE

Conceptually:

Product changed
     |
     v
Only required field changes
     |
     v
Update selected Solr fields

Remember:

UPDATE
    = update document

PARTIAL_UPDATE
    = update selected document fields

15. 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 this

The 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 ABC

is no longer supposed to appear in search.

Conceptually:

Product ABC
     |
     v
DELETE
     |
     v
Removed from Solr

SAP 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 DB

then it is deleted.

However:

Solr document still exists

This 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 search

18. 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          → Remove

19. 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
DELETE

while SolrExtIndexerCronJob supports:

UPDATE
PARTIAL_UPDATE
DELETE

with 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 Documents

For example:

Nightly Full Index
        |
        v
SolrIndexerCronJob
        |
        v
FULL
        |
        v
Products
        |
        v
Solr

21. 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 appropriate

There 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 1002

need 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 Update

23. Hot Update vs Full Index

Full Index

1,000,000 products
       |
       v
Rebuild index

Hot Update

2 products
       |
       v
Update only those products

The 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_PHASE

SAP 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 directly

TWO_PHASE

Existing Live Index
        |
        | remains available
        |
        v

Temporary Index
        |
        v
Build complete
        |
        v
Replace Live Index

This is a useful concept for understanding large production indexing operations.

25. Why Is TWO_PHASE Important?

Imagine:

10 million products

A 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 = 4999

But search returns:

Price = 5499

How 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:

Step 4: Check indexing/update

Determine whether the product update triggered:

UPDATE

or 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/API

This prevents blindly running full indexing when the real problem is elsewhere.

27. Production Scenario: Product Deleted but Still Searchable

Problem:

Product deleted from Commerce

but:

Search → Product still visible

Possible flow:

Database
    ↓
Product removed
    ↓
Delete event/index update?
    ↓
Solr

Check 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:

materialNumber

to the indexing configuration.

But after deployment:

Search material number
       ↓
No results

Do 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 query

A full reindex may be required to populate the new field for existing data.

29. Production Scenario: Indexing Job Failed

Suppose a CronJob reports:

ERROR

The first mistake is to immediately rerun it.

Instead, determine:

What operation?
FULL / UPDATE / PARTIAL_UPDATE / DELETE

Then investigate:

Indexer query
Value provider
Product data
Database connectivity
Solr connectivity
Solr configuration
Memory/resource limits
Custom code

A 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 products

and each product triggers several database/service calls.

You could accidentally create:

1,000,000 × expensive operation

This can make indexing extremely slow.

Therefore, custom indexing logic should be designed carefully.

Avoid unnecessary:

FlexibleSearch inside loops
Repeated database calls
Network calls
Heavy calculations

wherever 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
Errors

Review 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 products

Project B

10,000,000 products

A strategy that works for Project A may be completely inappropriate for Project B.

For example:

Run FULL index every hour

may 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
Languages

Therefore, Solr configuration needs to be considered carefully.

You may have:

Site A
   |
   +---- Catalog A
   |
   +---- Solr configuration A

Site B
   |
   +---- Catalog B
   |
   +---- Solr configuration B

A 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 Provider

When investigating an error, identify:

Product PK/code
Indexed Type
Facet Search Configuration
Operation
CronJob
Exception
Root cause

These 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 update

Partial 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 Query

I would also check:

Indexing CronJob
Indexing errors
Product status
Catalog version
Search configuration
Restrictions
Solr document

This 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 requirements

41. 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 mode

SAP 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 configuration

I 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 + reindex

This approach helps isolate whether the problem is:

Data problem
Indexing problem
Solr problem
Search configuration problem
API problem
Caching problem

45. 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 Query

And these four operations:

FULL
UPDATE
PARTIAL_UPDATE
DELETE

And these two important FULL modes:

DIRECT
TWO_PHASE

46. 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 / Storefront

47. 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 / Storefront

The four operations are:

FULL
UPDATE
PARTIAL_UPDATE
DELETE

Use 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 Index

Troubleshoot the complete pipeline before deciding where the problem exists.

Friday, September 18, 2026

SAP Commerce Solr Indexing Deep Dive: Full Index, Update, Partial Update, CronJobs & Troubleshooting

Introduction

1. What Is Solr Indexing?

2. Database vs Solr Index

3. SAP Commerce Solr Indexing Components

4. What Is an Indexed Type?

5. What Is an Indexed Property?

6. What Is an Indexer Query?

7. What Is a Value Provider?

8. Solr Index Operations

9. FULL Index

10. FULL Indexing Example

11. UPDATE Operation

12. FULL vs UPDATE

What is the difference between FULL and UPDATE?

13. PARTIAL_UPDATE

14. UPDATE vs PARTIAL_UPDATE

UPDATE

PARTIAL_UPDATE

15. Important PARTIAL_UPDATE Limitation

16. DELETE Operation

17. Why Can Deleted Products Remain in Solr?

18. FULL, UPDATE, PARTIAL_UPDATE and DELETE

19. What Is a Solr Indexer CronJob?

20. Typical CronJob Flow

21. When Should You Schedule Indexing?

22. What Is Hot Update?

23. Hot Update vs Full Index

Full Index

Hot Update

24. TWO_PHASE vs DIRECT FULL Indexing

DIRECT

TWO_PHASE

25. Why Is TWO_PHASE Important?

26. Production Scenario: Product Price Is Stale

Step 1: Verify Commerce data

Step 2: Determine where the search response gets its price

Step 3: Check Solr document

Step 4: Check indexing/update

Step 5: Check indexing errors

Step 6: Check caching

27. Production Scenario: Product Deleted but Still Searchable

28. Production Scenario: New Indexed Property Not Working

29. Production Scenario: Indexing Job Failed

30. How Custom Value Providers Can Cause Problems

31. Indexing Performance Optimization

Keep indexed data relevant

Keep custom providers efficient

Avoid unnecessary FULL indexes

Monitor CronJobs

Review Solr configuration

32. Indexing and Catalog Size

Project A

Project B

33. Indexing and Multi-Site Architecture

34. Solr Indexing Troubleshooting Checklist

35. Useful Logs to Check

36. Interview Question: Explain the Complete Solr Indexing Flow

Answer

37. Interview Question: FULL vs UPDATE?

Answer

38. Interview Question: UPDATE vs PARTIAL_UPDATE?

Answer

39. Interview Question: Why Is My Product in FlexibleSearch but Not Solr?

Answer

40. Interview Question: Should You Run FULL Index Every Time a Product Changes?

Answer

41. Interview Question: What Happens During FULL Indexing?

Answer

42. Interview Question: What Is a Hot Update?

Answer

43. Senior-Level Production Question

Question

Answer

44. Real Production Debugging Flow

45. Most Important Concepts to Remember

46. Quick Revision Diagram

47. Final Takeaway

No comments: