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.

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
  Unable to render {include} The included page could not be found.
  : 
  
  • blueriq.customerdata-sql-store.fulltext=true

  If you already have an aggregate dao datasource defined that connects to the Oracle database, you can skip the next steps.

• Define a connection to the Oracle database in the
  Unable to render {include} The included page could not be found.
   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 aggregate actions create entries in the oracle connection, so that these can be indexed.
  • aggregate.dao.jdbc.connection=search_dev
  Set the correct dialect for the oracle database in the aggregatedao.hibernate.properties
  • Example: hibernate.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.

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