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 a single index entry. Oracle Text 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 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.

The next step to do is to model an AQ_AggregateList 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