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

Compare with Current View Page History

« Previous Version 11 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 key words, 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.

In this design guide

Concept

When searching for information, only information that is persisted is taken into account. Data is persisted using Aggregates (More information on this can be found in the Persistency Management guide). When modeling your domain, it often occurs that you want to store information in different aggregates, that 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 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 that a complex structure of aggregates that reference other aggregates or documents is translated to a single index entry. Now OracleText is able to use the index to find the most relevant entries.

Preconditions

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

  • Obtain a license that includes search possibilities.
  • Setup an Oracle database so that OracleText can be used.
  • Define a connection to the Oracle database in the aquima.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
  • Set the correct dialect for the oracle database in the aggregatedao.hibernate.properties
    • Example:
      hibernate.dialect=org.hibernate.dialect.Oracle10gDialect
  • Enable search in the aquima properties
    • aggregate.dao.fulltext=true
  • Define in the aquima.properties that aggregate actions create entries in the oracle connection, so that these can be indexed.
    • aggregate.dao.jdbc.connection=search_dev

Basic Modeling

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 this. When storing and aggregate, the runtime then nows 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 in Studio should look like this:

A reference attribute to a document in Studio should look like this:

When attributes are set in this way, 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.

Searching for your case

Technical Information

 

  • No labels