Name: Introducing Flexible Search Alternatives in SAP Commerce Cloud
Uploaded: 2024-4-15
Duration: 482 s
Description: In this video, you will learn about some alternatives to flexible search in SAP Commerce Cloud, like GenericSearch and Polyglot Persistence. GenericSearch is an API that allows a developer to compose a query programmatically and dynamically, while Polyglot Persistence allows you to encapsulate an alternative storage mechanism into a generic means of access.

Share feedback

<p>Planned maintenance of Practice Systems</p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Subscribe now

Learn more

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

In this video, you will learn about some alternatives to flexible search in SAP Commerce Cloud, like GenericSearch and Polyglot Persistence. GenericSearch is an API that allows a developer to compose a query programmatically and dynamically, while Polyglot Persistence allows you to encapsulate an alternative storage mechanism into a generic means of access. 

Introducing Flexible Search Alternatives in SAP Commerce Cloud

Welcome. This video introduces you to some alternatives to Flexible Search in SAP Commerce Cloud.   First, let's consider GenericSearch.     Essentially, GenericSearch is an API that allows a developer to compose a query  programmatically and dynamically.   The concept is not new: if you've ever seen HibernateCriteriaSearches, this is similar.   Like FlexibleSearch, GenericSearch allows you to search for whole items as well as raw data fields, and supports any  number of search conditions.   It also supports Inner and Outer joins between item types, and you can incorporate any number of "order by" clauses.   Sub-selects (also known as subqueries) are also supported.   So why not just use FlexibleSearch?   While FlexibleSearch allows us /some/ runtime flexibility, such as using a query string with placeholders (to which we can conveniently  bind data), we still need to supply the query /structure/ and all of its clauses  up front, otherwise we would have to  programmatically piece together the query  string, which is tedious and error prone.   GenericSearch is most useful where the query  structure is unknowable at compile time,  and must be "assembled" at runtime.   The GenericSearch query-builder API allows  you to compose legal query syntax  conditionally and programmatically.     Ultimately, the GenericSearch API generates  an underlying FlexibleSearch query, so it's no better or worse than FlexibleSearch in terms of performance or capabilities.   Here's an example.   We start with an empty GenericQuery object based on the Commerce type, "Car".   Next, we must define a GenericSearchField...    ...to be used in defining a GenericCondition,  which will end up becoming a FlexibleSearch "WHERE clause".      Admittedly, having to "build" a query via so many statements /feels/ somewhat  roundabout, but the big advantage of this  approach is that query clauses (such as a  WHERE clause or its conditions) can be added  or omitted without having to worry about the messy details of query syntax.   For example, no WHERE clause at all, vs. a  WHERE clause with one condition, vs. multiple  conditions joined with ANDs or ORs:  coding for all three possibilities is far messier.   Instead, here, we can add any number of  conditions (or not) without worrying about how  to incorporate it into the rest of the query.   We can add a CLAUSE without worrying about its position in the query.   Eventually, the "genericSearchService" is  used instead of the "flexibleSearchService",  albeit in a very similar way.    Next, we'll take a look at Polyglot Persistence.  It allows you to encapsulate an alternative  storage mechanism (for example, via session  attributes)  into a generic means of access.     It supports Create, Read, Update, and Delete  operations, as well as Search.   It can be used to relieve the load of the main  database, or to make certain kinds of data  retrievable through means other than SQL.     In so doing, you can optimize the structure of  the stored data around one root element,  such as Cart or CartEntry.    But to use Polyglot Persistence,  it must be specially configured.  Let's take a closer look.    To use a specific type in Polyglot Persistence,  you must first configure it in via  system properties.   All Polyglot-Persistence-related property names  have the "polyglot.repository.config" prefix.  Then, in this example, "mypolyglot" is  the name of an instance.   This way, Polyglot Persistence can support any number of repositories at once.   Here, myPolyglotRepository is the name of  a Spring bean implementing the  de.hybris.platform.persistence.polyglot. ItemStateRepository interface.    When configuring typeCodes, E and G are  SAP Commerce type names, and square  brackets allow us to define conditions based on attributes of those types.   In this example, in the condition "[x=E]", "x" is  an attribute of G that is part of a relation  and E is the target type of that relation.      Such a condition allows the system to narrow  down possible target item types.   In other words, E items are FULLY stored in  Polyglot Persistence, whereas only G items  that are linked back to E items via  the "x" relation attribute are.  At least one type in a configuration  must be FULLY supported.   We are neglecting MANY details here in trying  to convey a general sense of the configuration.    With the unit-of-work polyglot-persistence  feature, you can cache all modifications  performed on a single item and flush them  when the related main operation ends.   This feature is optional and starts out disabled.   To enable it, decorate your ItemStateRepository  Spring bean with  UnitOfWorkAwareItemStateRepository,  and replace the beanName in your  project/local.properties file.   Here is an example configuration.    Here is a glimpse of how the ItemStateRepository API is organized.  We need to provide implementations of  repositories by implementing  the ItemStateRepository interface,  so that the specified types can be supported by Polyglot Persistence.   This is how the relevant interfaces are  related, by dependency.    Once the repositories are configured and their  alternative storage is implemented,  you can use Polyglot Persistence Query Language to search for those items in  alternate storage systems (rather than in the SAP Commerce persistence layer).  This is especially beneficial for document-based  storage where SQL is not supported.   This query language is, essentially, a simplified form of Flexible Search with limited features.   This approach can be used to reduce the load on the database and to provide non-SQL  storage for resource-intensive data (example:  B2C shopping carts).   Through detailed configuration, you can pick  and choose which item types to use with  Polyglot Persistence, whether they are  out-of-the-box item types or newly defined  in an *-items.xml file.   Here is an overview of Polyglot Persistence Query Language syntax.  You can see the keyword GET is used  instead of the SELECT that would appear in Flexible Search.    Also notice the simpler set of  available clauses.    Here are some examples, where we  even use placeholders, in the same  way as Flexible Search.  These examples are based on the  out-of-the-box implementation found  in the ydocumentcart extension.   Being that there is no special console in HAC  for Polyglot Persistence, like we have  for Flexible Search, we must practice using Polyglot Persistence via the API.   These examples can be attempted via Groovy  in HAC's Scripting Languages Console.   Far more information can be found here,  in the documentation portal.   Be sure to have a look.   Thank you for watching.