検索テーブルの定義

この章では、仮想ドキュメントの検索テーブルを定義する方法について簡単に説明します。以下のトピックについて説明します。

これらのタスクはプロダクションが存在しているネームスペースで実行する必要があります。検索テーブルを作成するときに、予約パッケージ名を使用しないでください。"Ensemble プロダクションの開発" の “予約パッケージ名” を参照してください。

Note:

Ensemble では、検索テーブル・クラスを追加する前に受信したメッセージに対し、遡ってインデックスを割り当てることはありません。

検索テーブル・クラスの定義

検索テーブル・クラスを定義するには、以下の一般的な手順を使用します。

プロダクションが含まれているネームスペース内でクラスを作成します。ここでも、予約パッケージ名は使用しないでください。"Ensemble プロダクションの開発" の “予約パッケージ名” を参照してください。

次のような仮想ドキュメントのタイプに使用されるデフォルト検索テーブル・クラスのサブクラス (または必要に応じてコピー) を作成します。

ドキュメント・タイプ	デフォルト検索テーブル・クラス	メモ
HL7	EnsLib.HL7.SearchTableOpens in a new tab	共通して必要な一連のプロパティにインデックスを付けます。"Ensemble HL7 バージョン 2 開発ガイド" の “デフォルトでインデックスが付けられるプロパティ” を参照してください。
X12	EnsLib.EDI.X12.SearchTableOpens in a new tab	X12 ドキュメント ID に対応する Identifier プロパティにインデックスを付けます。
ASTM	EnsLib.EDI.ASTM.SearchTableOpens in a new tab	ASTM ドキュメント ID に対応する Identifier プロパティにインデックスを付けます。
EDIFACT	EnsLib.EDI.EDIFACT.SearchTableOpens in a new tab	EDIFACT ドキュメント ID に対応する Identifier プロパティにインデックスを付けます。
XML	EnsLib.EDI.XML.SearchTableOpens in a new tab	XML ドキュメントのルート要素の名前にインデックスを付けます。

必要に応じて、このサブクラスに仮想プロパティを定義する XData ブロックを含めます。以降の項で詳細を説明します。
この XData ブロックには、選択されたスーパークラスによってインデックスが付けられた仮想プロパティに関する詳細を含める必要がありません。例えば、検索テーブル・クラスの一部では、Identifier という名前のプロパティにインデックスが付けられます。これらのクラスのいずれかをサブクラス化する場合は、XData ブロックに Identifier を含める必要がありません。選択的でないプロパティを指定することで、検索の効率を向上させることができます。プロパティが選択的でないのは、多くのメッセージがそのプロパティに対して同じ値を持つ場合です。Ensemble でメッセージを検索する場合、選択的でないプロパティの値をテストする前に検出されるメッセージの数を選択的プロパティによって制限すると、検索の効率を向上させることができます。プロパティが選択的でないことを指定するには、XData ブロックで Unselective="true" を指定します。
検索テーブル・クラスが複数のネームスペースにマッピングされている場合は、その検索テーブル・クラスをそれぞれのネームスペースでコンパイルして、各ネームスペースに対するローカルのメタデータが最新状態になるようにします。

Important:

検索テーブルのメタデータは、Ensemble ネームスペースごとのデフォルト・グローバル・データベースに配置されます。そのため、検索テーブル・クラスを変更しても、クラスがマッピングされているすべてのネームスペース内のメタデータは更新されません。そのため、これらのネームスペースごとに検索テーブル・クラスを再コンパイルする必要があります。

このクラスをコンパイルすると、検索テーブル・プロパティ別にローカル・メタデータが動的に取得され、そのプロセスが Ensemble ホストとして実行されている場合は、そのメタデータがキャッシュに格納されます。プロパティのメタデータが存在しない場合 (例えばマッピングされた検索テーブル・クラスに新しいプロパティのローカル・メタデータが保持されていない場合など)、このクラスは他のすべてのプロパティをインデックス化してから、メタデータが存在しなかったことを示すエラーを返します。同じように、メッセージ本文が削除されると、対応するエントリが検索テーブルから削除されます。ユーザ側での操作は必要ありません。

検索テーブル・クラスを使用する場合は、該当するビジネス・ホストの構成オプション ([テーブルクラス検索]) として指定します。そのビジネス・ホストがメッセージを処理する際に、構成済みの検索クラスを使用してこれらのメッセージをインデックス化します。

検索テーブル・クラスに関する XData 詳細

検索テーブル・クラスを作成する目的は、メッセージ・ブラウザ、ルール・エディタ、および管理ポータルのその他の部分で検索とフィルタの対象とする仮想プロパティごとに 1 つずつの検索テーブル・エントリを提供することです。これを実現するために、以下のスタブと同様の XData ブロックを検索テーブル・クラスに追加します。

XData SearchSpec [ XMLNamespace="http://www.intersystems.com/EnsSearchTable" ]
{
<Items>
   <Item DocType="doctype1" PropName="name1" PropType="type1" StoreNulls="boolean" 
     Unselective="true">path1</Item>
   <Item DocType="doctype2" PropName="name2" PropType="type2" StoreNulls="boolean">path2</Item>
<  <Item DocType="doctype3" PropName="name3" PropType="type3" StoreNulls="boolean">path3</Item>
</Items>
}

説明：

path1、path2、path3 などは仮想プロパティ・パスです。
これらのそれぞれが文字列式になっています。文字列式には、以下の要素を任意に組み合わせたものを含めることができます。
- 二重引用符で囲まれたリテラル文字。
- {} または [] で囲まれた仮想プロパティ構文。これは、X12 ドキュメントの特定のフィールドの値に解決します。角かっこは中かっことは異なり、segment:field の組み合わせを囲みます。この場合、含まれるドキュメント構造を識別する必要がありません。中かっこの構文で解決する場合は、ドキュメント構造を把握している必要があります。
- 連結に使用するアンダースコア (_) などの ObjectScript 文字列演算子。
- $PIECE または $EXTRACT などの関数。
doctype1、doctype2、doctype3 などは DocType 識別子です。これらのそれぞれが次のようにコロンで区切られたスキーマ・カテゴリ名とドキュメント構造名になっています。
```
category:structure
```
category がない場合は、任意のスキーマが一致します。structure がない場合は、任意の構造が一致します。"" の値 (空白の文字列) は、任意のカテゴリ・スキーマおよび任意のドキュメント構造と一致します。
この <Item> の部分で、特定のプロパティ・パスにインデックスを付ける DocType が指定されます (複数可)。
name1、name2、name3 などは選択された仮想プロパティ名です。
これは、管理ポータルに表示される名前です。リスト内で他の項目と一緒に表示されたときに区別しやすい文字列を選択します。
複数の <Item> 要素に同じ名前を割り当てた場合は、その名前を検索で選択すれば、同じ名前を持つすべてのエントリが検索されるという便利な相加効果があります。
type1、type2、type3 などはオプションのタイプ識別子です。以下のリテラル値のいずれかを指定します。
- String:CaseSensitive
- String:CaseInsensitive
- Integer
- Numeric
- Boolean
- DateTime:ODBC
- DateTime:HL7 (HL7、ASTM、または EDIFACT メッセージを転送する仮想ドキュメント専用にサポートされています)
String:CaseSensitive がデフォルトです。
boolean は、ドキュメント内で空のフィールドが見つかった場合の処理を制御するオプション・フラグです。このフラグが真の場合は、空の文字列に有効なポインタが返されます。このフラグが偽の場合は、[見つかりません] ステータスと NULL ポインタが返されます。
1 (真を意味する) と 0 (偽を意味する) のどちらかを指定します。デフォルトは 0 です。
Unselective="true" は、プロパティの値が少数のメッセージを通常選択しないことを示します。Ensemble では、この情報を使用して検索の効率を向上させます。デフォルト値は Unselective="false" です。

Important:

Ensemble は、仮想ドキュメントをインデックス付け (つまり、検索テーブルに追加) すると、縦棒 (|) をプラス記号 (+) に置き換えます。検索テーブルを使用して内容を検索する際には、このことを考慮してください。例えば、my|string という文字列を含むメッセージを検索するには、検索条件として my+string を使用します。

検索テーブル・クラスの例

以下の例は、検索テーブル・クラスを示しています。SearchSpec という XData ブロックには、検索テーブルを定義する <Item> 要素が含まれています。

Class Demo.HL7.MsgRouter.SearchTable Extends EnsLib.HL7.SearchTable
{

XData SearchSpec [ XMLNamespace="http://www.intersystems.com/EnsSearchTable" ]
{
<Items>
   <!-- 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" >
     {ORCgrp().OBRuniongrp.OBRunion.OBR:UniversalServiceID.text}
   </Item>
   <Item DocType="2.3.1:ORU_R01 " PropName="ServiceId" >
     {PIDgrpgrp().ORCgrp(1).OBR:UniversalServiceID.text}
   </Item>
</Items>
}
}

XML ネームスペース宣言 (前出の例に示すとおり) により、スタジオでは入力した語を完全に表示することができます。

カスタム検索テーブル・クラスの定義

この章に説明する検索テーブルの基本メカニズムでは、必要に応じたメッセージのインデックス化が実行できない場合もあります。そのような場合は、カスタム検索テーブル・クラスを定義して使用することができます。

このクラスでは、2 種類のプロパティを定義できます。このトピックでは、これらのプロパティを標準プロパティ (検索テーブルに格納されているもの) および仮想プロパティ (検索テーブルには格納されていない代わりに、実行時に取得されるもの) と呼んでいます。どちらの種類のプロパティでも、インデックス化する場合とインデックス化しない場合があります。プロパティをインデックス化すると、ディスク容量がより多く消費されますが、そのプロパティに対するクエリ実行が高速化されます。管理ポータルではインデックス化したプロパティをインデックス化していないプロパティの上にグループで表示するため、ユーザは適切に選択できます。

カスタム検索テーブル・クラスを定義するには、クラスを以下のように定義します。

Ens.CustomSearchTableOpens in a new tab を拡張します。
このクラスによって 1 つの標準クラス・プロパティ、DocId が定義されます。これはインデックス化されています。
必要に応じて追加のクラス・プロパティを定義し、そのクラス・プロパティのインデックスを追加します。以下に例を示します。
```
Property Type As %String(COLLATION = "EXACT");

Index Type On Type [ Type = bitmap ];
```
コレクション・プロパティは、現在はクエリ生成メカニズムによって直接サポートされていません。コレクション・プロパティに対しては、以下に説明する GetVirtualPropertyList() メソッド・メカニズムを使用します。
オプションとして、必要に応じて GetPropertyList() メソッドを実装します。
```
classmethod GetPropertyList(Output pIndexedProperties As %List, Output pProperties As %List) as %Status
```
説明：
- pIndexProperties は、インデックス化が必要な標準プロパティの $LISTBUILD リストです。
- pProperties は、定義する標準プロパティの $LISTBUILD リストです。
この手順の目的は、標準プロパティとして使用するクラス・プロパティを指定し (このリストの前に示した定義を参照してください)、その中でインデックス化が必要なものを指定することです。
デフォルトでは、このメソッドが生成され、Ensemble では検索テーブル・クラスのすべてのクラス・プロパティが標準プロパティとして使用され、すべてがインデックス化されます。ただし、private、internal、transient、および multidimensional の各プロパティを除きます。
仮想プロパティの場合は、代わりに (または追加として) GetVirtualPropertyList() を実装します。
オプションとして、必要に応じて GetVirtualPropertyList() メソッドを実装します。
```
classmethod GetVirtualPropertyList(Output GetVirtualPropertyList As %List, 
                                   Output pVirtualProperties  As %List) 
                                   as %Status
```
説明：
- GetVirtualPropertyList は、インデックス化が必要な仮想プロパティの $LISTBUILD リストです。
- pVirtualProperties は、定義する仮想プロパティの $LISTBUILD リストです。
この手順の目的は、仮想プロパティとして使用するクラス・プロパティを指定し、その中でインデックス化が必要なものを指定することです。
標準プロパティの場合は、代わりに (または追加として) GetPropertyList() を実装します。
GetVirtualPropertyList() を実装した場合は、GetVirtualProperty() メソッドも実装します。このメソッドは、ドキュメント ID と仮想プロパティ名が指定されている場合、以下のように仮想プロパティの値を返す必要があります。
```
classmethod GetVirtualProperty(pDocID As %String, 
                               pPropName As %String, 
                               Output pPropValue As %String,
                               ByRef pUserArgs) as %Status
```
説明：
- pDocID は、カスタム検索テーブル内のドキュメントの ID です。
- pPropName は、仮想プロパティの名前です。
- pPropValue は、そのプロパティの値です。
- pUserArgs は任意の引数を指定します。
OnIndexDoc() メソッドを実装します。
```
ClassMethod OnIndexDoc(pDocObj As %Persistent, pSearchTable As Ens.CustomSearchTable) As %Status
```
このメソッドによって、検索テーブル内でプロパティから指定した行を、指定されたメッセージに入力する方法が指定されます。

OnProcessCondition() および追加オプションは、Ens.CustomSearchTableOpens in a new tab のクラス・リファレンスを参照してください。

例については、Demo.CustomSearchTable.SampleOpens in a new tab を参照してください。

検索テーブルの管理

クラス Ens.DocClassMapOpens in a new tab は、(カスタム検索テーブルを含め) すべての検索テーブルを管理します。これは、グローバル (^Ens.DocClassMap) への書き込みと読み込みを行います。このグローバルは、データを含める検索テーブルをメッセージ・クラス別に指定します。このグローバルは、直接編集しないでください。

Ensemble クラスは、メッセージ本文が削除されたときに、このクラスを使用して検索テーブルのエントリを削除します。

通常は、このクラスを直接使用する必要はありません。ただし、^Ens.DocClassMap 内のデータが失われたり壊れた場合は、このクラスの RebuildMap() メソッドを使用してグローバルを再作成します。詳細は、Ens.DocClassMapOpens in a new tab のクラス・リファレンスを参照してください。

管理ポータルで使用するクエリのカスタマイズ

ユーザが管理ポータルの [メッセージ・ビューワ] ページと [メッセージ・バンクのメッセージ・ビューワ] ページでメッセージを検索すると、クエリが生成されて使用されます。高度な手法として、Ensemble によるクエリ生成方法をカスタマイズできます。そのためには、以下の一般的な手順を実行します。

EnsPortal.MsgFilter.AbstractAssistantOpens in a new tab のサブクラスを定義します。詳細は、そのクラスのクラス・リファレンスを参照してください。
クラスの名前を、メッセージ・ビューワでは ^EnsPortal.Settings("MessageViewer","AssistantClass") に、メッセージ・バンク・ビューワでは ^EnsPortal.Settings("MsgBankViewer","AssistantClass") に設定します。