Skip to main content
Back to AutoCore Hub

ProductSolrServices — God Module Analysis

69 edges. 5 Solr cores. Zero fallback. This is the system's single point of failure.

1. What Does It Index?​

ProductSolrServices indexes into 5 distinct Solr cores, not just one:

CoreContentKey Caller
globalproductsFINISHED_GOOD products — brand, category, pricing, images, vehicle applications (YMM)createGlobalProductIndex
memberproductMember-specific product availability and pricing (store-scoped)createMemberProductIndex
partDetailed part metadata for B2B part searchcreatePartIndex
partinterchange / interchangeCross-reference / OE part interchange datacreateInterchangeIndex
oepartOE (Original Equipment) part numberscreateOEPartIndex

Important nuance: Vehicle-to-application fitment (ACES) is denormalized into the globalproducts and part cores as flat fields (Year, Make, Model). There is no separate fitment Solr core.

5 Solr Core Architecture & Caller MapUse mouse wheel to zoom, drag to pan • Pull bottom edge to resize

2. Which Services Call It Most?​

External callers (outside ProductSolrServices):​

CallerMethod invokedTrigger
PIESSAXServicescreateGlobalProductIndex (×2)After SAX parsing of PIES XML, per-product
DataImportServicescreateGlobalProductIndexAfter every product import from CSVs
ProductServicesaddIndexes (globalproducts core)On ad-hoc product updates

Self-callers (inside ProductSolrServices):​

The module is heavily self-referential — bulk re-index methods loop through entity queries and call createGlobalProductIndex or createPartIndex per record via dispatcher.runSync. This is the primary source of its 69-edge count.

Key internal orchestrators:

  • refreshGlobalProductIndex — full catalog rebuild
  • refreshMemberProductIndex — member-scoped rebuild
  • refreshPartIndex — part core rebuild
  • refreshInterchangeIndex — interchange core rebuild

3. What Breaks When ProductSolrServices Is Down?​

🔴 Immediately broken:​

FeatureWhy it breaks
B2C Product SearchAutoCoreB2CProductServices queries globalproducts core for all catalog search
SAYT Part SearchEpicorSearchServices queries saytrecommendations core directly (no service layer fallback)
Interchange LookupProductExportServices queries interchange and partinterchange cores directly
Member Catalogmemberproduct queries fail — store-specific pricing unavailable
OE Part Lookupoepart queries fail
New Product ImportPIES SAX import calls createGlobalProductIndex inline — exceptions propagate back into the import transaction, potentially rolling back the entire product write

🟡 Degraded but not broken:​

FeatureStatus
Opticat Fitment SearchStill works — Opticat is an external HTTP API, not Solr-dependent
Entity DB readsStill works — VCDb, PIES entities, party data all live in the RDBMS
Order managementStill works — OFBiz OMS doesn't depend on these Solr cores

🔴 Critical blast radius: Solr down = B2C storefront is blind.​

Blast Radius: What Goes Dark When Solr Is DownUse mouse wheel to zoom, drag to pan • Pull bottom edge to resize

4. Is EpicorSearchServices an Alternative Search Path?​

No — and yes. It's more nuanced:

EpicorSearchServices.searchEpicorePartsFromSAYT
  └── IndexingServices.getSolrHost(delegator, "saytrecommendations")
  └── HttpSolrClient (direct, no service layer)
  └── Queries: partNumber, description, brandName fields
  • Same Solr infrastructure — getSolrHost resolves from the same IndexingServices config.
  • Different core — saytrecommendations, not globalproducts or part.
  • Different population path — saytrecommendations is populated separately; ProductSolrServices does not write to it.
  • Different purpose — SAYT typeahead only. Not a catalog replacement.

If you lose Solr, both paths fail. There is no fallback to DB for search.

5. Refactoring Flags​

  1. No circuit breaker: Every dispatcher.runSync("createGlobalProductIndex") call during PIES import is inline and blocking. One Solr timeout cascades into import failure.
  2. No async indexing: All 69 edges are synchronous runSync. A bulk re-index of 100k products is single-threaded.
  3. Dual direct-client pattern: PIESSAXServices and EpicorSearchServices bypass ProductSolrServices entirely and open raw HttpSolrClient connections. This means Solr connection pooling config is scattered across 4+ files.
  4. saytrecommendations is an orphan: No Java service indexes into it via the standard service layer. Its write path is either via a separate process or a NiFi flow — verify this.