Ensemble Virtual Documents
Defining Search Tables
[Home] [Back] [Next]
InterSystems: The power behind what matters   

This chapter describes generally how to define search tables for virtual documents. It includes the following topics:

Be sure to perform these tasks in the same namespace that contains your production. When you create search tables, do not use reserved package names; see Reserved Package Names in Developing Ensemble Productions.
Ensemble does not retroactively index messages that were received before you added the search table class.
Defining a Search Table Class
To define a search table class, use the following general procedure:
When you compile this class, Ensemble generates code that dynamically fetches the local metadata for each search table property and then caches the metadata if the process is running as an Ensemble host. If the property metadata is not present, as in the case where a mapped search table class does not have local metadata for a new property, the class still indexes all other properties and returns an error to indicate the metadata was not present. Similarly, when the message bodies are deleted, Ensemble removes the corresponding entries from the search table; no work is required on your part.
To use the search table class, specify it as a configuration option (called Search Table Class) for the applicable business host. When that business host processes messages, it uses the configured search table class to index those messages.
XData Details for a Search Table Class
When you create a search table class, your goal is to provide one search table entry for each virtual property that you want to search and filter in the Message Browser, Rules Editor, and other parts of the Management Portal. To do this, you include an XData block like the following stub within your search table class:
XData SearchSpec [ XMLNamespace="" ]
   <Item DocType="doctype1" PropName="name1" PropType="type1" StoreNulls="boolean" 
   <Item DocType="doctype2" PropName="name2" PropType="type2" StoreNulls="boolean">path2</Item>
<  <Item DocType="doctype3" PropName="name3" PropType="type3" StoreNulls="boolean">path3</Item>
When Ensemble indexes virtual documents (thus adding to the search tables), it replaces any vertical bar (|) with a plus sign (+). Take this into consideration when you use the search table to search for content. For example, to search for a message that contains my|string, use my+string as the search criterion.
Example Search Table Class
The following example shows a search table class. The SearchSpec XData block contains the <Item> elements that define the search table.
Class Demo.HL7.MsgRouter.SearchTable Extends EnsLib.HL7.SearchTable

XData SearchSpec [ XMLNamespace="" ]
   <!-- Items that do not depend on DocType, indexing any HL7 message -->
   <Item DocType="" PropName="SendingFacilApp" >{1:4}_"|"_{1:3}</Item>
   <Item DocType="" PropName="RecvingFacilApp" >{1:6}_"|"_{1:5}</Item>
   <Item DocType="" PropName="MSHDateTime" PropType="DateTime:HL7" >{1:7}</Item>

   <!-- Get fields from named segments found in any HL7 message -->
   <Item DocType="" PropName="PatientName" >[PID:5]</Item>
   <Item DocType="" PropName="InsuranceCo" >[IN1:4]</Item>

   <!-- Get patient name from any HL7 message declared type ADT_A05 -->
   <Item DocType=":ADT_A05" PropName="PatientName" >{3:5}</Item>

   <!-- Get specific field from specific segment when the        -->
   <!-- HL7 message is assigned a specific DocType. Only in this -->
   <!-- case can you use names for segments, instead of numbers. -->
   <Item DocType="Demo.HL7.MsgRouter.Schema:ORM_O01 " PropName="ServiceId" >
   <Item DocType="2.3.1:ORU_R01 " PropName="ServiceId" >
The XMLNamespace declaration (as shown in the preceding example) enables Studio to provide word completion as you type.
Defining Custom Search Table Classes
In some cases, the basic search table mechanism described in this chapter might not enable you to index messages as needed. In such cases, you can define and use custom search table classes.
The class can define two kinds of properties. Within this topic, these properties are called: standard properties (which are stored in the search table) and virtual properties (which are not stored in the search table but instead are retrieved at runtime). Either kind of property is either indexed or not. If you index a property, more disk space is consumed but queries for that property run more quickly. The Management Portal displays the indexed properties as a group above the non-indexed ones, so that users can select them appropriately.
To define a custom search table class, define a class as follows:
For OnProcessCondition() and additional options, see the class reference for Ens.CustomSearchTable.
For an example, see Demo.CustomSearchTable.Sample.
Management of Search Tables
The class Ens.DocClassMap manages all the search tables (including custom search tables). It writes to and reads from a global (^Ens.DocClassMap). This global indicates, for each message class, which search tables contain data for it. Note that you should never edit this global directly.
The Ensemble classes use this class to remove search table entries when message bodies are deleted.
It should not normally be necessary to use this class directly. However, if the data in ^Ens.DocClassMap is lost or damaged, use the RebuildMap() method of this class to recreate the global. For details, see the class reference for Ens.DocClassMap.
Customizing Queries Used by the Management Portal
When users search for messages in the Message Viewer and the Message Bank Message Viewer pages in the Management Portal, Ensemble generates and then uses queries. In advanced cases, you can customize how Ensemble generates these queries. To do so, use the following general procedure:

Send us comments on this page
Copyright © 1997-2019 InterSystems Corporation, Cambridge, MA