You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 35 Next »

Introduction

When working with a case management solution, the knowledge worker often wants to search for a case that he/she has worked on in the past, or that in some other way is interesting. When viewing a list of elements, there are multiple ways for searching for the correct information. One such way is to use filters on columns. Another way is to use a search field.

From applications such as Google we are used to be able to type certain keywords, and all relevant pages are shown, with the most relevant page on top. This knowledge article describes how you can search for information in the Blueriq runtime in a similar manner. It provides the preconditions, information on how to model your project, and technical guidelines for tweaking your application.

 

We have decided to temporarily deactivate Search in structured and unstructured information in version 10.1 to increase the speed of development of the persistence API. This feature will return in a future release

In this design guide

Concept

When searching for information, only information that is persisted is taken into account. Data is persisted using Aggregates (for more information on aggregates see the Persistency Management guide). When modeling your domain, you often want to store information in different aggregates and these aggregates relate to each other. See the left side of the diagram below. The topmost aggregate could be information that belongs to a case. The aggregate that is linked to it could be contact information of a person. This is stored separately in another aggregate, as it can be re-used in different cases. When searching for the name of a person, you may not only want to find the person aggregates that match, but also the cases that this person is involved in. So references between aggregates should be taken into account when searching. For documents that are attached to an aggregate, the same principle holds. This leads to a complex structure of aggregates that reference other aggregates or documents. This structure is translated to index entries. OracleText is able to use the index to find the most relevant entries.

The translation of model structures to an index entry allows for several favorable aspects:

  • All relevant information in one entry results in good performance.
  • System set attributes are also stored, enabling search on derived values.
  • Allowing to search on display values of value lists without the need to consult the model.
    • Please notice that the display value is evaluated and stored at the moment of storing an aggregate. If you change the display value later, you have to re-index the database.
Please be aware that the search uses internal values. This means you should take extra care in what values your are using internally.
(e.g. 1 for Male and 2 for Female is not advised)

Preconditions

In order to be able to search for data you need to take care of the following points:

  • Obtain a license that includes search possibilities.
  • Setup an Oracle database so that OracleText can be used.
  • Enable search in application.properties
    • blueriq.customerdata-sql-store.fulltext=true
  • Define a connection to the Oracle database in the application.properties file
    • Example:

      connection.search_dev.sql.type=jdbc
      connection.search_dev.sql.url=jdbc:oracle:thin:@servername:portname:xe
      connection.search_dev.sql.driver=oracle.jdbc.driver.OracleDriver
      connection.search_dev.sql.username=username
      connection.search_dev.sql.password=password
  • Define that documents will be indexed using this connection.
    • blueriq.customerdata-sql-store.supported-documents-connection=search_dev
  • Set the correct dialect for the Oracle database in application-externaldatasources.properties or application-jndidatasources.properties
    • Example: blueriq.hibernate.customerdata-sql-store.dialect=org.hibernate.dialect.Oracle10gDialect

Basic Modeling

References

In order to find information in aggregates that are referenced, it is of utmost importance to indicate which attributes in your domain are used for referring. When storing an aggregate, the runtime then knows that a reference to another aggregate was created when such an attribute is filled with a value. The same holds for documents.

A reference attribute to another aggregate is modeled as follows

A reference attribute to a document is modeled as follows

When attributes are set as reference, it is known at runtime when storing or updating an aggregate which other aggregates or documents hold importance to the stored aggregate. This also means that it is possible to hide a reference from the search by not checking the 'Acts as Reference' checkbox.

Aggregate list

The next step is to model an AQ_Aggregate_List container which displays your search results. In this container you select that type of aggregate that you want to see as a result. So if you are only interested in contact information, you would choose the aggregate that stores the contact information. If you want see aggregates that store case information you select that aggregate. You are still able to search for contact information if the contact information aggregate is referenced correctly (see above).

On the aggregate list you have to fill the Search Query parameter, using an expression. This is typically a string attribute that you placed on the same page with a refresh. The aggregate list could look like this:

Searching for your case

 

Technical Information

This section describes technical information and provides guidelines on how to make changes to the most common scenarios

ScenarioSolution
I want to change the frequency of the indexing.How to configure full-text index synchronization
I want to maintain search performance over timeHow to maintain full-text search performance
I want to have a case-sensitive search.How to enable case-sensitive search
I want that diacritics are treated as regular characters.How to configure diacritics in the full-text index
I want to search efficiently for dates.Dates are indexed in the ISO 8601 format
I do not want certain frequent words to be indexedHow to configure stopwords
What database permissions do I need?

In order to use full-text search in Oracle, the database user needs the following system privileges:

  • EXECUTE ON CTX_DDL
  • CREATE JOB (if synchronization at regular intervals is used)
How can I index aggregates that already exist?How can I (re-)index aggregates as an automatic batch operation?
  • No labels