Introduction

Search is one of the most important features in an e-commerce application.

Imagine an online store containing hundreds of thousands or millions of products. When a customer searches for:

Nike Running Shoes

the application needs to quickly return relevant products and allow the customer to narrow the results using filters such as:

Brand
Category
Size
Color
Price
Availability
Rating

Executing a complex database query for every customer search can become expensive.

This is where Apache Solr comes into the SAP Commerce architecture.

SAP Commerce uses the solrfacetsearch functionality to provide search and faceted navigation over indexed Commerce data. SAP documentation describes it as supporting faceted search over items such as products and WCMS content.

In this article, we will understand Solr from both a developer and SAP Commerce interview perspective.

1. What Is Solr?

Apache Solr is a search platform designed for fast searching and indexing of large amounts of data.

Instead of searching the Commerce database directly for every customer request, SAP Commerce can index relevant product information into Solr.

Conceptually:

SAP Commerce Database
        |
        | Indexing
        v
      Solr
        |
        | Search
        v
Customer Search Request

For example, your database may contain:

Product
---------------------------------
code
name
description
price
brand
category
color
size
stock

During indexing, selected information is transformed into a Solr document.

Conceptually:

{
  "code": "NIKE-001",
  "name": "Nike Running Shoes",
  "brand": "Nike",
  "category": "Running Shoes",
  "color": "Black",
  "price": 5999
}

The important point is that not every database attribute automatically becomes searchable.

The attributes that should be indexed have to be configured as indexed properties.

2. Solr in SAP Commerce Architecture

A simplified architecture looks like this:

                Customer
                   |
                   v
             Storefront/OCC
                   |
                   v
             Search Service
                   |
                   v
              Solr Server
                   |
          +--------+--------+
          |                 |
          v                 v
    Search Results       Facets
          |
          v
      Product PKs
          |
          v
     SAP Commerce
       Product

The major components include:

SAP Commerce
solrfacetsearch
Solr server
Indexed Types
Indexed Properties
Search configuration
Indexer
Search services
Facet configuration

SAP's documentation separates search configuration, indexed types, indexed properties, and server configuration as core parts of the Search and Navigation functionality.

3. Why Does SAP Commerce Need Solr?

Consider a catalog containing:

2,000,000 Products

A customer enters:

laptop

and expects results within a fraction of a second.

A database query may have to perform complex operations involving:

Product
Category
Price
Inventory
Brand
Classification
Language
Catalog Version

and potentially large text-search operations.

Solr is optimized specifically for search workloads.

The advantages include:

Fast text search

Search terms can be matched across indexed fields efficiently.

Full-text search

For example:

running shoes

can search relevant product text.

Fuzzy search

A misspelled term such as:

nik

can potentially return:

Nike

depending on the configured query behavior.

Faceted search

Customers can narrow results by:

Brand
Color
Size
Price Range
Category

Sorting

Results can be sorted by:

Price
Name
Relevance
Rating
Stock

4. What Is Solr Indexing?

Indexing is the process of taking data from SAP Commerce and creating searchable Solr documents.

For example:

ProductModel
     |
     v
Indexer
     |
     v
Value Providers / Resolvers
     |
     v
Solr Document
     |
     v
Solr Index

Suppose we have:

ProductModel product

with:

code = IPHONE-001
name = iPhone 17
price = 79999
brand = Apple

The indexing process converts relevant information into Solr fields.

Conceptually:

ProductModel
      |
      +---- code ------> code_string
      |
      +---- name ------> name_text
      |
      +---- price -----> price_double
      |
      +---- brand -----> brand_string

5. What Is an Indexed Type?

An Indexed Type defines what type of Commerce data is going to be indexed.

A common example is:

Product

The Indexed Type identifies the Commerce item being indexed and is associated with indexer/search configuration.

You can think of it as:

Indexed Type
      |
      +---- Product
      |
      +---- Indexed Properties
      |
      +---- Indexer Configuration
      |
      +---- Search Configuration

6. What Are Indexed Properties?

An Indexed Property represents a property of the indexed type that should be available in Solr.

For example:

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

The property configuration determines how the value should be indexed and potentially searched, filtered, faceted, or returned.

SAP Commerce documentation provides different configurations for strings, dates, numbers, enums, localized values and other types.

7. Example of an Indexed Property

A simplified ImpEx-style example might look like:

INSERT_UPDATE SolrIndexedProperty;
name[unique=true];
solrIndexedType(identifier)[unique=true];
type(code);
localized[default=false];
facet[default=false]

;name;Product;TEXT;true;false
;code;Product;TEXT;false;false
;brand;Product;STRING;false;true
;price;Product;DOUBLE;false;true

The exact configuration can vary by SAP Commerce version and project.

The important concept is:

Commerce Attribute
        |
        v
SolrIndexedProperty
        |
        v
Solr Field

8. Text vs String in Solr

This is an important interview topic.

Suppose you have:

Product Name = Nike Running Shoes

If you want full-text search behavior, the property typically needs to be configured appropriately as a text-search field.

For example:

name → text

A string field behaves differently from a text field because text processing/analyzers can be applied to searchable text.

SAP's documentation specifically notes that string indexing can behave differently with filters and may result in case-sensitive searching compared with appropriately configured text fields.

9. Free-Text Search

Free-text search allows users to enter search terms without explicitly specifying a field.

Example:

red nike shoes

The search engine attempts to identify matching indexed content.

Typical searchable properties might include:

name
description
code
brand
category

SAP Commerce search property configuration supports different query behaviors, including free-text, fuzzy, wildcard, and phrase queries.

10. Fuzzy Search

Customers frequently make spelling mistakes.

For example:

runing shoes

instead of:

running shoes

Fuzzy search can help identify terms that are similar.

Conceptually:

runing
  |
  v
running

This can improve the customer's search experience.

However, fuzzy searching should be used carefully because aggressive fuzzy queries can increase search cost and return less precise results.

11. Wildcard Search

Wildcard search allows partial matching.

Example:

nik*

could potentially match:

nike
nikon

Depending on the configured search behavior.

Wildcard queries should be used carefully, especially with leading wildcards such as:

*shoe

because they can be expensive depending on the Solr/query configuration.

12. Phrase Search

Suppose the customer enters:

running shoes

A phrase-oriented search can treat the complete phrase as a meaningful sequence rather than simply searching the individual words independently.

This can improve relevance for certain use cases.

13. What Are Facets?

Facets are filters that allow customers to narrow search results.

Suppose a customer searches:

shoes

The application might display:

Brand
----------------
Nike (120)
Adidas (90)
Puma (50)

Color
----------------
Black (100)
White (75)
Red (40)

Price
----------------
₹0 - ₹2,000
₹2,000 - ₹5,000
₹5,000+

These are facets.

The customer can select:

Brand = Nike
Color = Black

and the results become narrower.

SAP Commerce's search configuration supports facet settings on indexed properties.

14. Facet Example

Consider:

Product
-------------------
Brand
Color
Size
Price
Category

Configure:

brand → facet
color → facet
size → facet
price → facet/range

Then the search UI could display:

Brand

Nike       120
Adidas      90
Puma        50

and:

Color

Black      100
White       80
Blue        40

15. Range Facets

Some values are better represented as ranges.

Price is the most common example.

Instead of:

the customer can see:

₹0 - ₹2,000
₹2,000 - ₹5,000
₹5,000 - ₹10,000
₹10,000+

These are range facets.

They are especially useful for:

Price
Age
Weight
Rating
Size
Numeric attributes

16. Full Index vs Incremental/Partial Updates

This is one of the most important Solr interview questions.

Full Index

A full index rebuild processes the complete dataset configured for the index.

Conceptually:

All Products
     |
     v
Indexer
     |
     v
New Solr Index

Full indexing may be used after:

major configuration changes
new indexed properties
catalog changes
initial setup
index corruption
significant data/configuration changes

Partial or Incremental Update

A partial update updates only the required information rather than rebuilding an entire document.

For example:

Product 1001

Old:
price = 5000
stock = 20

New:
stock = 5

Instead of rebuilding everything, the update process can target the necessary change.

SAP documents partial updates as a way to update a subset of Solr document attributes rather than rebuilding the entire document, which is useful for large catalogs.

17. When Should You Run a Full Index?

A common scenario:

You add a new indexed property:

material

The existing Solr index doesn't automatically contain the new field for every existing product simply because you changed the configuration.

A full indexing operation is commonly required so the existing dataset gets indexed according to the new configuration.

Typical flow:

Change Indexed Property
          |
          v
Update Configuration
          |
          v
Run Full Index
          |
          v
Validate Search

18. Solr Indexer CronJob

SAP Commerce provides indexing functionality that can be executed through CronJobs.

For example:

System
  |
  +-- Background Processes
        |
        +-- CronJobs
              |
              +-- Solr Indexer

You can configure execution schedules and indexing operations through the administration tooling. SAP documentation also describes configuring Solr index update CronJobs and their operation settings.

19. Why Is My Product Available in the Database but Not in Search?

This is one of the most common production issues.

You execute:

SELECT * FROM Product

and find:

Product exists

but searching through storefront/OCC doesn't return it.

Do not immediately assume FlexibleSearch is the problem.

The product may not be correctly represented in the Solr index.

Check:

1. Product exists
2. Correct catalog
3. Correct catalog version
4. Product is indexed
5. Indexed property configuration
6. Indexing job status
7. Solr configuration
8. Query configuration
9. Search restrictions
10. Facet/search configuration

20. Troubleshooting: Product Not Showing in Solr

A practical troubleshooting sequence is:

Step 1: Check the Product

Verify:

code
catalog
catalogVersion
approvalStatus
onlineDate
offlineDate

Step 2: Check Indexed Type

Confirm that the relevant product type is included in the indexed type configuration.

Step 3: Check Indexed Properties

If you're searching:

brand = Nike

verify that:

brand

is configured as an indexed property.

Step 4: Check Indexing Job

Look for indexing errors in:

Backoffice
HAC
logs
CronJobs

Step 5: Run a Full Index

When configuration changes or stale index data is suspected, run the appropriate full indexing operation.

Step 6: Validate Solr

Confirm that the expected Solr document exists and contains the expected fields.

21. Database Data vs Solr Data

A very important concept:

Database ≠ Solr Index

The database contains the source Commerce data.

Solr contains the indexed/search-oriented representation.

Therefore:

Product exists in DB

does not necessarily mean:

Product exists correctly in Solr

This distinction is extremely important when debugging production search problems.

22. What Is a Value Provider?

During indexing, SAP Commerce needs to determine where an indexed value comes from.

For example:

Product.price

may be directly available from the Product model.

But a complex property could require custom logic.

Conceptually:

ProductModel
     |
     v
Value Provider
     |
     v
Solr Field

A custom value provider may be appropriate when the indexed value must be calculated or assembled from multiple sources.

For example:

Product
  |
  +-- Brand
  +-- Category
  +-- Classification
  |
  v
Custom Calculated Search Value

23. Example Custom Value Provider Concept

Suppose the business wants a searchable field:

searchKeywords

generated from:

product name
brand
category
classification

A custom provider could conceptually do:

public class CustomSearchValueProvider
{
    public Object getFieldValue(ProductModel product)
    {
        StringBuilder value = new StringBuilder();

        value.append(product.getName());

        if (product.getManufacturerName() != null)
        {
            value.append(" ");
            value.append(product.getManufacturerName());
        }

        return value.toString();
    }
}

The exact SAP Commerce interface and method signature depend on the platform/version and project setup, so the implementation should follow the corresponding version's Solr indexing API.

24. Localized Indexed Properties

E-commerce applications are often multilingual.

For example:

English:
Running Shoes

German:
Laufschuhe

French:
Chaussures de course

Product names can therefore require localized indexing.

The indexing configuration needs to account for localization.

This is especially important when troubleshooting a problem such as:

Search works in English
Search fails in German

Check whether the property is configured correctly as localized and whether the required language data was indexed.

SAP's Solr property configuration explicitly supports localized properties.

25. Currency-Dependent Properties

Price is another special case.

Consider:

India   → INR 79,999
USA     → USD 999
Europe  → EUR 949

Search/index configuration needs to account for currency where relevant.

A price field should not simply be treated like an ordinary string.

This is why SAP Commerce Solr indexed properties support currency-specific configuration.

26. Search Restrictions and Solr

Another tricky area is Search Restrictions.

A product may exist in the Solr index, but additional Commerce-side restrictions can still affect what a particular user sees.

This can produce confusing behavior such as:

Solr contains product
        +
Search restriction applies
        =
Product not visible to user

SAP documentation also notes that search restrictions can affect Solr result counts in some situations.

27. Solr and OCC

In a headless SAP Commerce implementation, OCC APIs may expose search functionality.

A conceptual request might look like:

GET /occ/v2/{baseSiteId}/products/search?query=shoes

The flow can be represented as:

Mobile/Web Client
       |
       v
OCC Controller
       |
       v
Facade
       |
       v
Search Service
       |
       v
Solr
       |
       v
Search Results
       |
       v
Product Data / DTO

This is an important connection between your OCC knowledge and Solr knowledge.

28. Pagination in Solr Search

Suppose there are:

50,000 products

The API should not return all of them.

Instead:

Page 0
size = 20

returns:

Products 1 - 20

and:

Page 1
size = 20

returns:

Products 21 - 40

Pagination helps reduce:

response size
network traffic
memory usage
rendering time

29. Sorting Search Results

Customers may want:

Relevance
Price Low → High
Price High → Low
Newest
Name

Solr can support configured sorting behavior.

For example:

search=shoes
sort=price-asc

The exact OCC query parameters depend on your API/version/customization, but the important architectural concept is:

Customer Sort Selection
        |
        v
Search Query
        |
        v
Solr Sorting

30. Solr Performance Optimization

Solr performance becomes increasingly important as catalog size grows.

1. Index only required data

Do not blindly index every Product attribute.

More indexed data can mean:

larger index
more storage
more processing
more indexing time

SAP also recommends avoiding sensitive/confidential data in Solr indexing because indexed data can introduce information disclosure risks.

2. Avoid unnecessary facets

Do not make every property a facet.

For example, these may not make sense as customer-facing facets:

internalCreationTimestamp
internalERPFlag
internalProcessingStatus

Use facets where customers actually need filtering.

3. Optimize indexed properties

Only index fields that have a business/search purpose.

Ask:

Do customers search this?
Do customers filter by this?
Does sorting need this?
Does the response require this?

If the answer is no, reconsider indexing it.

4. Use pagination

Avoid returning huge result sets.

Prefer:

pageSize = 20

or another business-appropriate value instead of thousands of results.

5. Avoid unnecessary full indexing

For a large catalog:

Full Index

can be expensive.

Use the appropriate update strategy for smaller changes where supported.

SAP documents partial updates specifically as a way to avoid rebuilding complete documents for small changes.

31. A Common Production Scenario

Imagine you receive this incident:

"Customer updated the product price, but the storefront still shows the old price."

The database shows:

Product Price = ₹4,999

But storefront shows:

₹5,499

What do you check?

Step 1

Verify the database:

Product price = ₹4,999

Step 2

Check whether the price is Solr-driven for the particular storefront/search response.

Step 3

Check the relevant Solr document.

Step 4

Check the indexing/update process.

Step 5

Check whether the update job executed successfully.

Step 6

Check whether a cache is contributing to the stale result.

Step 7

If necessary, trigger the appropriate index update/full index according to the project's configuration.

The important debugging principle is:

Database
   ↓
Indexing
   ↓
Solr
   ↓
Search Service
   ↓
Cache/API
   ↓
Storefront

Find where the stale value first appears.

32. Another Real-World Scenario

Problem

The product exists in Backoffice.

FlexibleSearch returns it.

But:

/search?query=ABC

returns no result.

Investigation

Check:

Product
   ↓
Catalog Version
   ↓
Indexed Type
   ↓
Indexed Property
   ↓
Solr Index
   ↓
Search Query

Possible root causes:

Product wasn't indexed

or:

Product property isn't indexed

or:

Index is stale

or:

Search configuration doesn't use that property

or:

Search restriction/filter removes it

This type of scenario is excellent for senior SAP Commerce interviews.

33. Full Index vs Partial Update — Interview Answer

Question

What is the difference between full indexing and partial indexing/update in SAP Commerce?

Answer

Full indexing processes the complete set of configured data and creates/updates the Solr index according to the indexing configuration.

Partial updates can update only selected portions of an existing Solr document, avoiding unnecessary processing for unchanged attributes.

Use full indexing for major configuration/data changes, while partial updates can be useful for targeted changes in large catalogs.

SAP specifically documents partial updates as a way to update only a subset of document attributes.

34. Interview Question: Why Is Solr Faster Than Database Search?

Answer

Solr is specifically designed and optimized for search workloads.

It provides capabilities such as:

Inverted indexing
Full-text search
Faceting
Relevance
Fuzzy matching
Sorting
Filtering

A relational database can certainly perform search operations, but Solr is purpose-built for large-scale search and navigation use cases.

35. Interview Question: Product Exists in DB but Not in Solr. Why?

Strong Senior-Level Answer

I would check the complete indexing pipeline:

Product data
→ Indexed Type
→ Indexed Properties
→ Value Providers
→ Indexer
→ Solr document
→ Search query

Then I would check:

Catalog Version
Approval Status
Online/Offline Dates
Indexing CronJob
Indexer logs
Solr configuration
Search configuration
Search restrictions

I would also compare the Commerce database representation with the actual Solr document rather than assuming the database is the source of the search response.

36. Interview Question: What Is a Facet?

Answer

A facet is a search-navigation mechanism that allows users to filter search results based on indexed properties.

For example:

Search: Shoes

Brand:
Nike
Adidas

Color:
Black
White

Price:
₹0-₹2,000
₹2,000-₹5,000

Facets improve product discovery and allow customers to progressively narrow search results.

37. Interview Question: Why Would You Avoid Making Every Property a Facet?

Answer

Because unnecessary facets increase search complexity and can increase index/query overhead.

I would create facets only for business-relevant customer filtering requirements.

For example:

brand → Yes
color → Yes
size → Yes
internalERPCode → No
internalProcessingFlag → No

38. Interview Question: What Happens When You Add a New Indexed Property?

A good answer is:

1. Define the indexed property
2. Configure its type
3. Configure its provider/resolver if needed
4. Update search configuration if needed
5. Build/deploy changes
6. Reindex existing data
7. Validate the Solr document
8. Test search/OCC/storefront

The exact deployment/reindex procedure depends on the Commerce version and project architecture.

39. Interview Question: How Do You Troubleshoot Solr Issues?

My preferred troubleshooting flow is:

                    Issue
                      |
                      v
               Is product in DB?
                 /         \
               No           Yes
               |             |
        Fix source data   Is it indexed?
                            /      \
                          No        Yes
                          |          |
                     Check index   Check query
                     process       config
                                   |
                                   v
                         Check restrictions
                                   |
                                   v
                            Check response
                                   |
                                   v
                               Cache/API

This avoids randomly triggering full indexes without understanding the problem.

40. Important Solr Best Practices

Keep these principles in mind when working on SAP Commerce projects:

Do not index everything.

Index only what is required.

Do not make everything a facet.

Create meaningful customer-facing filters.

Understand the difference between DB and Solr.

They are different representations of the data.

Always check indexing after configuration changes.

A configuration change doesn't automatically guarantee that all existing Solr documents reflect the new structure.

Monitor indexing jobs.

An apparently successful deployment can still have failed indexing.

Be careful with custom value providers.

Poorly designed providers can make indexing expensive.

Avoid sensitive information in Solr.

SAP explicitly warns against indexing confidential data because it can create information disclosure risks.

41. SAP Commerce Solr Architecture — Quick Revision

Remember this flow:

                 SAP Commerce
                      |
                      v
                Product Data
                      |
                      v
                  Indexer
                      |
          +-----------+-----------+
          |                       |
          v                       v
 Indexed Properties          Value Providers
          |                       |
          +-----------+-----------+
                      |
                      v
                 Solr Index
                      |
                      v
                Search Query
                      |
        +-------------+-------------+
        |             |             |
        v             v             v
     Results        Facets        Sorting
        |
        v
      OCC / Storefront

This diagram is worth remembering for SAP Commerce interviews.

42. Key Terms You Should Know

Term	Meaning
Solr	Search platform
Indexed Type	Type of Commerce data being indexed
Indexed Property	Attribute indexed in Solr
Indexer	Process that creates/updates index data
Facet	Customer-facing search filter
Value Provider	Provides/calculates indexed values
Full Index	Indexes the complete configured dataset
Partial Update	Updates part of an existing Solr document
Free-Text Search	Search using general text terms
Fuzzy Search	Search tolerant of spelling differences
Range Facet	Facet based on numeric ranges
Search Configuration	Configuration controlling search behavior
Search Restriction	Restriction affecting what data a user can access

43. Final Takeaway

Solr is a fundamental part of SAP Commerce search architecture.

The most important relationship to remember is:

Commerce Database
       ↓
   Indexer
       ↓
Indexed Properties
       ↓
    Solr Index
       ↓
 Search Query
       ↓
Results + Facets
       ↓
OCC / Storefront

When debugging search issues, don't stop at FlexibleSearch.

A product can exist correctly in the Commerce database and still be missing or incorrect in Solr.

For senior SAP Commerce developers, understanding indexing, indexed properties, value providers, facets, search configuration, full vs partial updates, search restrictions, and Solr troubleshooting is essential.

Friday, September 11, 2026

SAP Commerce Solr Search Explained: Indexing, Facets, Filters, Search & Performance

Introduction

1. What Is Solr?

2. Solr in SAP Commerce Architecture

3. Why Does SAP Commerce Need Solr?

Fast text search

Full-text search

Fuzzy search

Faceted search

Sorting

4. What Is Solr Indexing?

5. What Is an Indexed Type?

6. What Are Indexed Properties?

7. Example of an Indexed Property

8. Text vs String in Solr

9. Free-Text Search

10. Fuzzy Search

11. Wildcard Search

12. Phrase Search

13. What Are Facets?

14. Facet Example

15. Range Facets

16. Full Index vs Incremental/Partial Updates

Full Index

Partial or Incremental Update

17. When Should You Run a Full Index?

18. Solr Indexer CronJob

19. Why Is My Product Available in the Database but Not in Search?

20. Troubleshooting: Product Not Showing in Solr

Step 1: Check the Product

Step 2: Check Indexed Type

Step 3: Check Indexed Properties

Step 4: Check Indexing Job

Step 5: Run a Full Index

Step 6: Validate Solr

21. Database Data vs Solr Data

22. What Is a Value Provider?

23. Example Custom Value Provider Concept

24. Localized Indexed Properties

25. Currency-Dependent Properties

26. Search Restrictions and Solr

27. Solr and OCC

28. Pagination in Solr Search

29. Sorting Search Results

30. Solr Performance Optimization

1. Index only required data

2. Avoid unnecessary facets

3. Optimize indexed properties

4. Use pagination

5. Avoid unnecessary full indexing

31. A Common Production Scenario

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

32. Another Real-World Scenario

Problem

Investigation

33. Full Index vs Partial Update — Interview Answer

Question

Answer

34. Interview Question: Why Is Solr Faster Than Database Search?

Answer

35. Interview Question: Product Exists in DB but Not in Solr. Why?

Strong Senior-Level Answer

36. Interview Question: What Is a Facet?

Answer

37. Interview Question: Why Would You Avoid Making Every Property a Facet?

Answer

38. Interview Question: What Happens When You Add a New Indexed Property?

39. Interview Question: How Do You Troubleshoot Solr Issues?

40. Important Solr Best Practices

41. SAP Commerce Solr Architecture — Quick Revision

42. Key Terms You Should Know

43. Final Takeaway

No comments: