Introduction

In modern e-commerce, providing customers with flexible sorting options is crucial for enhancing user experience and driving sales. While SAP Commerce provides default sorting options like relevance, price, and name, businesses often need custom sorting criteria that align with their specific merchandising strategies. This blog demonstrates how to add a “sold amount” sorting metric to an electronics store, allowing customers to discover popular products based on actual sales performance.

This implementation targets SAP Commerce developers and solution architects who need to extend the platform's search and navigation capabilities. Prerequisites include familiarity with SAP Commerce architecture, Solr configuration, and basic Java development.

Understanding Current Sort Implementation

SAP Commerce provides several out-of-the-box sorting options including relevance (default), top rated, name (ascending/descending), and price (lowest/highest first). The sorting functionality is built on Solr Facet Search, where sort options are configured through SolrSort and SolrSortField entities.

The technical architecture involves:

• SolrIndexedProperty: Defines searchable/sortable product attributes
• SolrSort: Represents the sort option visible to customers
• SolrSortField: Maps sort options to specific Solr fields
• Storefront Integration: Displays sort options in the product listing pages

Sort configurations are typically managed through the Backoffice under System → Search and Navigation → Solr Facet Search Configuration.

Step-by-Step Implementation

Step 1: Define the New Sort Option

First, create the Solr sort configuration using ImpEx. This defines how the “sold amount” sorting will appear to customers:

$solrIndexedType=electronicsProductType

# Define the available sorts
INSERT_UPDATE SolrSort;indexedType(identifier)[unique=true];code[unique=true];useBoost
         ; $solrIndexedType;soldAmount-asc;false
         ; $solrIndexedType;soldAmount-desc;false

# Update the available sorts for i18n
UPDATE SolrSort;indexedType(identifier)[unique=true];code[unique=true];name[lang=en]
               ;$solrIndexedType;soldAmount-asc;”Sold Amount (ascending)”
               ;$solrIndexedType;soldAmount-desc;”Sold Amount (descending)”

# Define the sort fields
INSERT_UPDATE SolrSortField;sort(indexedType(identifier),code)[unique=true];fieldName[unique=true];ascending[unique=true]
            ;$solrIndexedType:soldAmount-asc;soldAmount;true
            ;$solrIndexedType:soldAmount-desc;soldAmount;false

Step 2: Implement Backend Logic

Create a field provide to calculate the sold quantities with a fake algorithm (get the value from product code or PK):

public class SoldAmountProvider extends AbstractPropertyFieldValueProvider implements FieldValueProvider
{
    private FieldNameProvider fieldNameProvider;

    @Override
    public Collection getFieldValues(final IndexConfig indexConfig, final IndexedProperty indexedProperty,
          final Object model) throws FieldValueProviderException
    {
       final ProductModel productModel = (ProductModel)model;
       if (productModel == null)
       {
          return Collections.emptyList();
       }

       final Collection fieldValues = new ArrayList();
       final String code = productModel.getCode();
       long soldAmount = 0;
       try {
          soldAmount = Long.parseLong(code);
       } catch (NumberFormatException nfe) {
          String pkString = productModel.getPk().toString();
          int length = pkString.length();
          soldAmount = Long.parseLong(pkString.substring(length-5));
       }

       fieldValues.addAll(createFieldValue(soldAmount, indexedProperty));
       return fieldValues;
    }

    protected List createFieldValue(final long soldAmount, final IndexedProperty indexedProperty)
    {
       final List fieldValues = new ArrayList();
       final Collection fieldNames = fieldNameProvider.getFieldNames(indexedProperty, null);
       for (final String fieldName : fieldNames)
       {
          fieldValues.add(new FieldValue(fieldName, soldAmount));
       }
       return fieldValues;
    }

    public void setFieldNameProvider(FieldNameProvider fieldNameProvider) {
       this.fieldNameProvider = fieldNameProvider;
    }
}

Step 3: Configure Bean Definition

Configure a bean definition for the above field provider to be used in the Solr indexer property:

      class=”org.training.core.search.solrfacetsearch.provider.impl.SoldAmountProvider”
      parent=”abstractPropertyFieldValueProvider”>
   

Step 4: Configure Solr Indexing

Configure Solr to index the sold quantity data for sorting purposes [1]:

$solrIndexedType=electronicsProductType

INSERT_UPDATE SolrIndexedProperty;solrIndexedType(identifier)[unique=true];name[unique=true];type(code);sortableType(code);currency[default=false];localized[default=false];multiValue[default=false];useForSpellchecking[default=false];useForAutocomplete[default=false];fieldValueProvider
         ;$solrIndexedType; soldAmount                   ;long   ; long ;    ;    ;                                                                       ;   ;   ;soldAmountProvider 

# Declare the indexed type Product
INSERT_UPDATE SolrIndexedType;identifier[unique=true];type(code);variant;sorts(code)
       ;$solrIndexedType;Product;false;relevance,topRated,name-asc,name-desc,price-asc,price-desc,soldAmount-asc,soldAmount-desc

Step 5: Testing and Validation

Implement comprehensive testing to ensure the sorting functionality works correctly:

1. Unit Tests: Verify service layer calculations
2. Integration Tests: Test Solr indexing and search results
3. Performance Tests: Assess impact on page load times
4. User Acceptance Tests: Validate sorting accuracy on storefront

After configuration changes, perform a full Solr reindex to ensure the new sorting data is available.

Troubleshooting Common Issues

Index Rebuild Requirements: After adding new sort fields, always perform a full Solr reindex. Navigate to System → Facet Search → Index Operations in Backoffice.

Cache Invalidation: Clear relevant caches after configuration changes, particularly the search result cache and product catalog cache.

Performance Optimization: For large catalogs, consider implementing incremental updates for sold quantities rather than full recalculation. Use database indexing on the soldQuantity field for better query performance.

Data Accuracy: Implement proper transaction handling when updating sold quantities to ensure data consistency across concurrent operations.

Conclusion

Adding custom sorting metrics like “sold amount” significantly enhances the customer shopping experience by surfacing popular products based on actual sales performance. This implementation demonstrates SAP Commerce's flexibility in extending search and navigation capabilities while maintaining system performance.

The sold amount sorting feature provides immediate business value by helping customers discover trending products and enabling merchandisers to leverage sales data for better product positioning. Consider extending this approach with additional metrics like profit margins, seasonal trends, or customer ratings for even more sophisticated sorting strategies.

For additional guidance on search configuration and custom sorting implementations, refer to the SAP Commerce documentation on Solr Facet Search and explore the SAP Community for advanced use cases and best practices.