Configuration

Since version 11.3, Wedia relies on ElasticSearch for full text and structured search. All SQL or SQL + Full text queries go through ElasticSearch. The RDBMS is only used to retrieve instances identified by the ElasticSearch search.

Full-text syntax

A "full text" search does not require any special syntax elements. Just list the words you want to search for a result, e.g.: green boat

Prior to version 11.6, the previous search looked for all documents containing both "boat" AND "green".

From version 11.6 onwards, this same search finds all documents containing boat OR green. On the other hand, it is possible to refine this search to obtain the previous result by prefixing the two obligatory words with a '+':
+boat +green

Some words can also be excluded. Using the previous example, we can specify that we do not want green sailboats by prefixing veil of a '-':
+boat +green -sail

The previous search can return boats on a green background. If you want to make sure to find green boat, you can specify the exact phrase:
+"green boat" -sailing

Finally, if you are looking for a boat whose reference is vaguely known, it is possible to do a search starting with suffixing the reference by '*':
+boat +REF25*

To summarize:

• Prefix with '+' to force the presence of a term.

• Prefix '-' to exclude the presence of a term.

• Surround with '"' to search for an exact phrase.

• It is possible to force or exclude a sentence: +"green boat" -"red boat"

From 11.7 onwards, you can also prefix a term with '~' to specify whether a term is wanted but not mandatory. This modifier comes with a new global parameter (/ebNAdministration) of the full text search that allows you to globally specify whether searches without modifier (e. g. white boat) are rewritten to "+boat + white" (search "all terms") or "~boat ~white" (search "at least one term"). By default, the "~Boat ~White" shape is selected to respect the ascending compatibility.

There is also a shortcut to search directly for an instance whose id is known by typing: #id.

zSyslucene object

The use of ElasticSearch entails some changes to be taken into account when developing new applications or migrating existing ones.

First of all, the zSyslucene object is no longer supported. Its use does not generate errors but will not give any correct results. This choice was made to avoid leakage of the internal structure of the ElasticSearch index and thus facilitate the evolutions on the latter. Result: any use of zSyslucene will have to be migrated on a normal SQL + Full text object by object search. This research is very successful and there is no longer any reason to do otherwise. The next version of Wedia should provide a "global" search API on all indexed objects to facilitate development.

bypassing ElasticSearch and using rDBMS directly

Then, it is important to keep in mind that all SQL or SQL + Full text queries go through ElasticSearch. The DBMS is only used to retrieve instances identified by the ElasticSearch search. An effort has been made to make this operation as "real time" as possible. This means that normally: any addition or modification of instance is made directly available to the search. However, in order to avoid any problems caused by a possible mismatch between modifications and searches during modification batches on objects, a new API has been created to completely bypass the search layer ElasticSearch and to use DBMS efficiently. This class is wsnoheto.engine.BatchObjectsIterable.

Faceted searchs

The use of ElasticSearch makes it easy to perform faceted searches allowing you to return the results count for different values of the searched object: by wage type, brand, workflow status, etc. This research has been done until now thanks to an intensive use of wsnoheto.engine.Loader. There is now a specialized class for this purpose: wsnoheto.engine.FacetsBuilder. This class uses natively ElasticSearch to get these results which is more powerful and much easier to use. This class also automatically works as a fallback on the Loader if Elastic is not configured or available. It is therefore highly recommended to go through this class to implement faceted research on front office.

Limit the fields used in the full text search to specific languages.

The content of this article is only valid from version 11.6 onwards.

Before version 11.6 and by default from it, a full text search uses all the indexed fields of an object. The search for a French term is therefore done on all internationalized fields in English, Italian, etc. This is usually no problem if there are not too many collisions between words in several languages.

From version 11.6 onwards, it is now possible to specify the languages in which you want to search. The list of indexed fields used in the search are then filtered as follows:

• Fields not internationalized are systematically kept.

• Internationalized fields (without extension) are kept if the default indexing language configured in /admin/ebnAdministration.ebn is contained in the list of desired languages.

• The internationalization of fields are kept if their language is contained in the list of desired languages.

To use this new functionality in the BackOffice delivered as standard, you just have to fill in the list of "java. util. local" required in the request attribute "fulltext_locales". This attribute is initialized with an empty list in /bov3/init/initbaseWhere/initBaseWhere.jsp which is equivalent to querying all available indexed fields. A plugin delivered as standard "WXM_BO_FulltextOptions" makes it easy to limit the fields used to those compatible with the contribution languages of the logged-in user. To get another behaviour, the easiest way is to create a new plugin by modifying it.