Requirement is to display the search results by group of unique part number, instead of unique part code. In many projects the part code in hybris is the combination of a part number and its relative SBU (business unit code, B2B specific and term largely employed in the world of ERPs e.g SAP). An assumption is made on search results being limited to 10 in this case.
Implications
So each group/result have entries of same part number but different SBUs. Each of this shall still have pricing and add to cart buttons as it is today.
The limit of results should still be 10, but each of those can have x number of parts > increase of end search results and pricing calls. Investigation below was done to give a starting point on how to implement such change. Are we tweaking frontend, are we adding processing logic on results, or are we using solr differently?
Option 1
This approach consists in minimizing the solr changes and ‘manually’ build groups of unique part number on the search results. At the very least though, we will use the sorting in place from solr (by part number, then by sbu) in order manually build those groups. The main impact here would be the processing time of building this map (groups) after we get the results from solr, which is still minor considering the reasonable limits we put in place.
vs LOE: medium, a bit more for developers, but with easy level of complexity.
Guideline steps of implementation (at first glance and high level)
1/ Change the row limit in UtasSolrQueryPostProcessor to 250 this number is chosen to limit as much as possible the backend handling of results for performance purpose, as well as making sure we have enough results to complete a full list of 10 groups. So, knowing that each part number does not belong to more than 20 sales organisations in current system landscape, this should give us plenty margin to even handle exceptions.
2/ Modify SearchPageController to iterate over the results and build a map where each key is a part number and the value is the list of parts (from different SBU’s). Iterate though the results until the first 10 keys are fully populated (so stop when the 11th key is about to build). In average, it should process around 30 results only I would expect, thanks to the solr sorting. One thing to check while implementing this approach and the n2 as well, is the impact on pricing performance, which ‘should’ be ok.
3/ Modify frontend JSP/ productListerItem.tag to display the productData from the newly built map, and with slightly different UI to put in evidence the new grouping experience, yet still display ‘pricing / add to cart’ for each entry.
Option 2
This approach consists of running all the grouping logic in solr itself. This means essentially, that solr would return each result as a group of documents. So each row would be a list of documents, and limiting the rows to 10 would limit the results to 10 list of documents, say 10 groups of unique part numbers.
This removes all the cumbersome logic of estimating after how many results we can fill our first ’10 groups’, and removing processing time as well on the backend to actually build those groups. However, more effort would be spent on the results handling so that we loop over list of documents instead of flat documents (Product Data) directly.
vs LOE: medium, a bit less for developers, but with medium level of complexity (need to understand how the solr results work documents and such).
Guideline steps of implementation (at first glance and high level)
1/ modify the query with raw parameters (key/value pairs). E.g in the UtasSolrQueryPostProcessor we could add “&group=true&group.field=partNumber_string” to the query.
2/ we will need to update the handling of results in the searchPageController, so that we loop over the groups before looping over the flat documents(productData). Currently is as following
final ProductSearchPageData searchPageData = solrProductSearchFacade.textSearch( searchState, pageableData);
for (final ProductData product : searchPageData.getResults())
{…}
3/ Eventually, we may need to implement our own resultPostProcessor to modify the search results returned from solr. This may be part of another alternative option in combination with option 1.
https://wiki.hybris.com/display/release5/Direct+Access+to+the+Solr+Query#DirectAccesstotheSolrQuerySearchResultPostProcessors