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 link 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 using 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 it would be nice if references between aggregates should can be taken into account when searching. For documents that are attached relevant to information in 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 in the database that stores the aggregates. 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 aspectsindex entries has some advantages over searching in each aggregate or document separately:

• 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

  Include Page
  DOC:_PropertiesFileJava DOC:_PropertiesFileJava

  : 
  
  • aggregate.daoblueriq.customerdata-sql-store.fulltext=true

  UI Text Box
  type note
  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

  Include Page
  DOC:_PropertiesFileJava DOC:_PropertiesFileJava

   file
  

  • Example:

    Code Block
    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 documents will be indexed using this connection.
  • aggregate.dao.jdbc.blueriq.customerdata-sql-store.supported-documents-connection=search_dev
• Set the correct dialect for the oracle database in the aggregatedao.hibernateOracle 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.

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 Container type: 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