The HSQ syntax directly reflects the search expression API explained in Entity Search - so the same expressions are possible as if you build complex search queries the programmatic way using the corresponding API. It's main design goal was to provide an easy to understand and easy to use query syntax which can also be used by end users of the Product Manager.

Syntax

HSQ Query: [<CONDITION>]+
HSQ Condition: <TERM> [AND|OR <CONDITION>]* | [NOT]? (<CONDITION>)
HSQ Term: [NOT]? <FIELD QUALIFICATION | CHARACTERISTIC> <OPERATOR> <VALUE LITERAL> | [NOT]? <FIELD QUALIFICATION | CHARACTERISTIC> IN (<VALUE LITERAL> [,<VALUE LITERAL>]*)

Conditions/terms can be connected with AND / OR, whereas the AND has higher priority and thus is evaluated first. Evaluation priority can be influenced by building complex conditions by means of parenthesis (possibe around conditions as well as around terms). NOT is used for negating terms as well as complex conditions (where parenthesis are needed, of course).

See again example from code block above:

Article.EAN in ("123456789", "987654321", "abcdefghij") AND not (Article.Identifier = "abc" OR Article.Identifier equals "xyz")
 
characteristic(9342) = "44"
characteristic(9347) = "22"&catalog=1011

Field Qualification

The HSQ expression is built with a fully qualified field. Please see the REST Field Qualification documentation on the used syntax here. Note, only a single field is allowed in the context of the search query.

Characteristic

Please see the REST Characteristic documentation chapter on the used syntax here. Note, only a single characteristic is allowed in the context of the search query.

Operators

Operators are interpreted case insensitive, thus "equals" and "EQUALS" and "eQuAlS" are, equal

Operator	Allowed Datatypes	Description
equals	String	Value must be exactly the same as the corresponding field content
equalsIC	String	Value must be the same as the corresponding field content, upper and lower case differences will be ignored
contains	String	Field content must contain the given string in the same case
containsIC	String	Field content must contain the given string, but the case of the content is ignored
startsWith	String	Field content must start with the given string in the same case
startsWithIC	String	Field content must start with the given string but the case of the content is ignored
wildcard	String	Value can consist wildcards like '%' ( one or more characters ) and '_' (single character)
wildcardIC	String	Value can consist wildcards but the case of the content is ignored
=	all	Value must be the same as the corresponding field content
~	String	Value can consist wildcards like '%' ( one or more characters ) and '_' (single character)
!~	String	Value can consist wildcards like '%' ( one or more characters ) and '_' (single character)
!= / <>	all	Field content must be unequal to the provided value
>	String, Number, Datetime	The field content must be greater then the given value according to the "natural order" of the value
>=	String, Number, Datetime	The field content must be greater or equal as the given value according to the "natural order" of the value
<	String, Number, Datetime	The field content must be less then the given value according to the "natural order" of the value
<=	String, Number, Datetime	The field content must be less or equal to the given value
in	all	Field content must be equal to one of the provided values in parenthesis
is empty	all	Field content must be null or empty string

While using wildcard/ ~ operators make sure to escape any wildcard character using '\\'. For eg. "\\%" or "\\_"

Value Literal

The textual representation of the value is described in the REST Datatypes. Multiple values (comma separated in parenthesis) can only be used for the "in" operator.

In general, the value literal's type must be compatible to the fields's data type where the field qualification points to. Implicit conversion is currently only performed when field destination type is of DECIMAL and provided value literal is of INTEGER - in all other cases the types have to be the same.

Dynamic Value

A value literal can also be a dynamic literal.

A dynamic value is a placeholder which will be resolved while parsing the field qualification
Syntax: ${Identifier}

Additional named values can be contributed to the PIM server using the extension point: com.heiler.ppm.value.core.namedValues

Currently available named values:

${CurrentDate} = the current date (without time)
${CurrentTime} = the current time (without date)
${CurrentTimestamp} = the current date and time