This concept describes the changes required in an existing project to integrate Sparque into a slightly modified Responsive Starter Store to replace the Solr search.
Although Sparque is an API-based solution and therefore best suited for the Intershop PWA, there may be Intershop customers who still use the Responsive Starter Store but would also like to benefit from the flexibility and versatility of Sparque.
This document was written by our implementation partner Fenego. You can reach out to info@fenego.be for any kind of detail questions.
The result of ViewStandardCatalog still shows in the same viewcontextpage. Also for the other pipelines, the end notes have not changed.
Most of the data that is used in the ISML templates comes from the ListNavigationVO object. By providing this object with Sparque data instead of Solr data or query data, changes to the ISML can be avoided altogether.
Enabling and disabling Sparque can be implemented with the help of a managed service. This allows business users (and developers) to turn Sparque on and off, with Solr serving as the default fallback in the system.
The ISML template only needs to be changed for displaying data if Sparque returns completely different data elements.
The concept assumes that only category IDs (only those with online products) and SKUs are retrieved. The display of elements outside of Intershop is therefore not taken into account.
This document is based on a customer project where the filter function was removed. As it was not a requirement to create filters when using Sparque, this document does not cover how to integrate the Sparque filter logic into the Starter Storefront.
For all Sparque requests, the following query parameter must be added to retrieve an object that can be managed by a normal object mapper:
homogeneousArrays=true
Browse
Refresh
ProductPaging
A check is implemented for all three elements to determine if Sparque is being used.
The pipeline for this check:
ViewStandardCatalogBySparque.pipeline
GetCategoriesTree
A check is implemented to determine whether Sparque is used.
To enable this, the category overview object has already been created including the information for MainNavigationFull.isml. With this information, it is possible to create a different approach for the Sparque template than the default (Solr) template. In the default setup, Solr returns a list of all categories. The logic loops through the different levels of categorization to show all subcategories. This logic is included in the new pipelet to keep the ISML as simple as possible. By using a different include based on Sparque or Solr in the template, it was possible to keep the existing Responsive Starter Store Solr templates while creating a more streamlined template for the Sparque data.
OfferPaging
ProductPaging
Browse
SimpleOfferSearch
ChangePageSize
A check is implemented for all elements to determine whether Sparque is used.
The pipeline for this check:
ViewParametricSearchBySparque.pipeline
The default pipeline was already modified in this project. It was pointing to a pipeline specific for a searchindex. This assignment was changed to a SimpleOfferSearch, but within a not modified Responsive Starter Store, the change will be a bit different.
Logic such as fireEvents can be maintained in the custom Sparque pipelines as usual. A custom CreateSearchResultNavigationList pipeline can be used to create a ListNavigationVO object. The object itself is standard, but the standard pipelines for Solr or queries are too limited for this use case.
As mentioned, filters are out of scope for this document. If filters are required, they should be handled in the ListNavigationVO object.