LotusScript のオンサイトサポート

先日、ノーツコンソーシアムの研究会 Domino Lounge で一緒に活動しているユーザ企業の方から LotusScript に関する問い合わせがありました。ちょうど良いタイミングでオフ会があったので、前乗りしてオンサイトサポート活動を行いました。LotusScript におけるハマりポイントがいくつかあったので、許可をもらって記事にさせていただくことにしました。

なお、材料となるのは Domino IQ のサンプルアプリですが、Domino IQ の機能に特化した話ではありません。予めご了承ください。

お問い合わせ内容

ディスカッションテンプレートをもとに Domino IQ のサンプルアプリを作っており、次の２つの処理をまとめて実行させたいとのことでした。

1. 文書内の本文を IQ に要約させて Summary フィールドにセット
2. その要約からさらにカテゴリを生成させ、Categories フィールドにセット

お問い合わせがあった時点でのコードは次の通りでした（記事化に当たり一部調整済み）。

Sub Initialize    Dim ns As New NotesSession    Dim ndb As NotesDatabase    Dim nuiw As New NotesUIWorkspace    Dim nuid As NotesUIDocument    Dim llmreq As NotesLLMRequest    Dim llmres As NotesLLMResponse    Dim sText As String    Set ndb = ns.CurrentDatabase    Set nuid = nuiw.CurrentDocument    '要約の問い合わせ    sText = nuid.FieldGetText("Body")    Set llmreq = ns.CreateLLMRequest()    Set llmres = llmreq.Completion(ndb.Server, "DiscussSummerry", sText)    If (llmres.FinishReason = LLM_FINISH_REASON_STOP) Then       Call nuid.FieldAppendText("Summery",llmres.Content)       Call nuid.Save()       Call nuid.Reload()    End If    'カテゴリの問い合わせ    Dim sText1 As String    sText1 = nuid.FieldGetText("Summery")    Set llmreq = ns.CreateLLMRequest()    Set llmres = llmreq.Completion(ndb.Server, "DiscussCategory", sText)    If (llmres.FinishReason = LLM_FINISH_REASON_STOP) Then       Call nuid.FieldAppendText("Categories",llmres.Content)       Call nuid.Save()    End If End Sub

このスクリプトを実行すると『文書は保存されていません。』とエラーが出るので、何が悪いのか教えてほしいというお問い合わせでした。

コードを見る限り、処理 1 と 2 をそれぞれ作成し、スクリプトをつなげたように見えます。そして、つなげる前のスクリプトは単体では正常に動作したとのご報告がありました。

エージェントの対象と NotesUIDocument

調査にあたり、まず、現象を確認します。

新規で文書を作成し、エージェントを実行すると確かに『文書は保存されていません。』エラーが発生します。

どこでエラーが発生しているのか確認するために、デバッグモードにして実行してみます。すると、デバッガが起動することなくエラーが発生します。この結果より LotusScript のエラーではないと判定できます。

Use したスクリプトライブラリ内の Initialize 内でエラーが発生した場合、LotusScript が原因でもデバッガは起動しません。今回はそのようなパターンではないので LotusScript のエラーではないと判定しています。

このような場合、エージェントのプロパティの確認が必要です。今回のエージェントでは次のようになっていました。さて、問題点がわかりますか？

エラーの原因は［実行時］－［対象］の設定が『すべての選択文書』となっているからです。

LotusScript のエージェントの場合、この対象の設定は NotesDatabase クラスの UnprocessedDocuments プロパティの利用を前提にした機能だと理解しておくとよいでしょう。ビューで選択した文書や新着メールなどを効率よく取得することができます。

そうした仕様からなのか UI の文書が新規文書でまだ保存されていない状態だと『文書は保存されていません。』エラーが発生することになります。UI の文書がバックエンドの nsf 内に存在しないからだと思います。

今回のスクリプトでは、処理対象の文書は NotesUIDocument 経由で取得しているので、対象による文書の特定は不要です。このような場合では、対象を『なし』としておく必要があります。

その結果、問題のエラーが回避でき、デバッガが起動するようになります。これでやっと LotusScript の土俵に乗った状態といえます。

今回は LotusScript のエージェントのエラーではあったのですが、原因はスクリプト外にあったという点がポイントですね。

保存は何度も行わない

お問い合わせのコードを見ていて気が付いた点です。nuid.Save() を 2 カ所で実行している点です。先の『文書は保存されていません。』エラーに対応するため試行錯誤で入れたコードだと思われますが、よい対応とは言えません。

本件に限らずエンドユーザ作成のコードを見ていると、一連の処理で何度も保存しているコードを見ることがあります。正常に動けばそれでいいじゃないか、細かいこと言うなと思うかもしれませんが、私は気になりました。

例えば、将来の改造で作成者や読者の操作する機能を追加したことを考えてください。一度目の保存で文書に対する権限がなくなったとすると、二度目の保存ではエラーが発生することになります。複数回の保存が、将来の改造において足かせになりかねません。後任者（将来の自分を含む）に対するトラップになりうるので、保存は一回にとどめるようにしましょう。

また、保存するなら目立つ場所で行うのも重要です。コードの最後や関数のできるだけ外側がよいと思います。文書の取得や作成と同レベル（同じ関数内）にしておくと気づきやすいですね。

サポート終了後のスクリプト

今回のお問い合わせに対しては、最終的に以下のコードを回答としました。

'これは編集モード前提のエージェントです。 Option Declare Sub Initialize    Dim ns As New NotesSession    Dim ndb As NotesDatabase    Dim nuiw As New NotesUIWorkspace    Dim nuid As NotesUIDocument    Dim llmreq As NotesLLMRequest    Dim llmres As NotesLLMResponse    Dim sBody As String    Dim sSum As String    '変数初期化    Set ndb = ns.CurrentDatabase    Set nuid = nuiw.CurrentDocument    '本文をテキストで取得    sBody = nuid.FieldGetText("Body")    '要約問い合わせ    Set llmreq = ns.CreateLLMRequest()    Set llmres = llmreq.Completion(ndb.Server, "DiscussSummerry", sBody)    If (llmres.FinishReason = LLM_FINISH_REASON_STOP) Then       '要約取得       sSum = llmres.Content       '要約セット       Call nuid.FieldAppendText("Summery", sSum)    End If    'カテゴリ問い合わせ    If sSum <> "" Then       'カテゴリ問い合わせ       Set llmres = llmreq.Completion(ndb.Server, "DiscussCategory", sSum)       If (llmres.FinishReason = LLM_FINISH_REASON_STOP) Then          'カテゴリ取得とセット          Call nuid.FieldAppendText("Categories",llmres.Content)       End If    End If End Sub

修正にあたり意識した点は次の通りです。私が担当した LotusScript 講座の受講経験をお持ちだったので、（復習を兼ねて）少々細かな点についても補足させていただきました。

• 編集モード（入力中の実行）を前提に、保存をなくし、IQ の結果をフィールドにセットするだけにした（保存は UI の操作に任せ、スクリプトに頼りすぎない）
• IQ が作成した要約を文字列変数に保管し、カテゴリ作成に利用（UI と スクリプト間の往復を減らす）
• NotesLLMRequest の初期化は 1 回でよい
• Option Declare を宣言し、暗黙の変数宣言を禁止

NotesDBDirectry の使い方

Domino サーバの管理アプリを作成しているとサーバ内のアプリケーションの一覧を取得したくなることがあります。このようなときに利用するのが NotesDbDirectory クラスです。

先日久しぶりにこのクラスを利用しようとしたとき、思い出せずヘルプのお世話になりました。いい機会なので使い方などをまとめておきたいと思います。

オブジェクトの取得方法

NotesDbDirectory クラスは NotesSession クラスと同様に New でオブジェクトを新規作成することができます。

Dim ndbdir As NotesDbDirectory     Set ndbdir = New NotesDbDirectory( serverName$ )

引数には一覧を取得したいサーバ名を設定します。Null を指定するとサーバではなく、ローカルに接続します。

一覧の取得

接続したサーバの一覧を取得するには GetFirstDatabase というメソッドを使用します。

Set ndb = ndbdir.GetFirstDatabase(DATABASE)

引数には、データベースの種類を指定します。次の定義済みの定数が利用できます。

値	定数	説明
1247	DATABASE	Notes データベース (NSF ファイル）
1248	TEMPLATE	Notes データベースのテンプレート (NTF ファイル)
1245	REPLICA_CANDIDATE	複製不可ではない Notes のデータベースまたはテンプレート
1246	TEMPLATE_CANDIDATE	Notes データベースまたはテンプレート

GetFirstDatabase 実行すると一覧の最初のデータベースが返されます。その次のデータベースは GetNextDatabase メソッドを使用ます。

例えば、次のスクリプトでは、ローカルのすべてのデータベースのファイルパスを順にメッセージボックスで表示します。

Dim ndbdir As NotesDbDirectory     Dim ndb As NotesDatabase          Set ndbdir = New NotesDbDirectory("")    'ローカルに接続     Set ndb = ndbdir.GetFirstDatabase(DATABASE)    '最初のDB     While Not (ndb Is Nothing)         MsgBox ndb.FilePath         Set ndb = ndbdir.GetNextDatabase()    '次のDB     Wend

最後のデータベースの次は Nothing となる点がポイントですね。

一覧はソートされていない

NotesDbDirectory クラスが作成する一覧がどのような順序なのかは不明です。例えば、上記スクリプトをあるサーバに対して実行したところ次のような結果でした。少なくともファイルパス順ではないようです。

homepage.nsf     AgentRunner.nsf     PwdResetSample.nsf     help\decsdoc.nsf     help\lccon.nsf     help\lsxlc.nsf     help\help14_admin.nsf     help\help14_client.nsf     help\jconfr11.nsf     help\help14_designer.nsf     help\help145_admin.nsf     help\help145_client.nsf     help\help145_designer.nsf     panagenda\PMCInstaller.nsf     panagenda\pmc_config.nsf     panagenda\pmc_analyze.nsf     iNotes\Forms9.nsf     ontime\installer.nsf     ontime\ontimegc.nsf             ・・・

作成する処理によってはソートする必要があります。LotusScript でソートするには以下の記事を参考にしてください。

• 2024.08.30 LotusScript で値のソートを作成
• 2024.09.01 複数のフィールド値をセットでソート

DB は Open されていない

NotesDbDirectory クラスを利用した特徴をもう一点。取得した NotesDatabase は「Open されていない」点に注意が必要です。

例えば、上記スクリプトを変更して文書数を取得するように変更します。

MsgBox ndb.AllDocuments.Count

すると、次のようなエラーが発生します。

このエラーを回避するためには NotesDatabase クラスの Open メソッドで DB を開く必要があります。

NotesDbDirectory クラスは、DB をリストアップすることが目的のクラスです。この時点では、ファイルパスや DB 名のように公開されている情報のみにアクセスできます。これが Open されていない状態ということになります。

DB 内の文書（数）にアクセスするためには適切な ACL が必要です。Open することで ACL が評価され、文書にアクセスできるということになります。

アプリケーションを開くダイアログでは、アクセス権のない DB もリストアップされます。DB を選択して開こうとすると ACL が評価されます。このタイミングと Open が同じだと理解すればわかりやすいですね。

ちなみに、LotusScript のヘルプでは、Open が必要な機能は明示されています。

DXL Step-by-Step：#64）システムアクションとアクションの種類の判定

#62 でアクションバーに配置するボタンの DXL について紹介しました。この記事でシステムアクションの記述に関して漏れていたので追記します。

システムアクション

システムアクションは、アクションバーの右クリックメニューで［システムアクションの挿入］を選択することで追加できます。

挿入すると複数のアクションがまとめて挿入されます。アクションの名称やアイコンなどのプロパティ、非表示式などは変更できますが、動作の変更はできません。また、不要なアクションは削除することが可能です。

システムアクションの DXL

このシステムアクションをDXL で確認すると systemcommand 属性が存在し、アクションの動作が値に設定されています。

システムアクションのプロパティでは名称や非表示設定などを変更することができます。修正した設定はノードや属性に追加されます。このあたりの動作は他の DXL と同様ですね。

アクションボタンの種類の判定

今回はシステムアクションを紹介しましたが、それ以外のアクションの DXL は次の通りです。

これらの DXL の構造からアクションの種類を判定することができます。

1	systemcommand 属性が存在	→	システムアクション
2	code ノードが存在し event 属性が 'action'	→	シンプルアクション
3	code ノードが存在し event 属性が 'click'	→	formula や lotusscript などサブノードの名称で言語が決定

なお、code ノードには非表示式（event = 'hidewhen'）など、アクションの動作ではないものも含まれるので注意が必要です。

前回

DXL Step-by-Step

複製と競合

複製環境でアプリを運用していると、競合文書が発生することがあります。同じ文書を別々のレプリカで編集してから複製が走ると、Domino はどちらの変更を正とするか判断できず、片方の結果を “競合文書” として扱います。

今回は複製と競合文書の関係についてまとめます。

複製競合の発生

複製競合は次のようなケースで発生します。

• サーバで文書を更新
• ローカルでも同じ文書を更新
• その後双方のレプリカ間で複製が実行される

この時 Notes/Domino は、どちらの更新を ”親文書” とするか判定し、もう一方の更新を ”競合文書” として保存します。結果として、1 つの文書に対して、複数のバージョンが存在することになります。

このような現象はサーバ/ローカル間だけでなく、サーバ間の複製でも発生します。

競合文書の状態

通常の競合文書と複製競合はどちらも同じ ”競合文書” で、内部的に次のような状態・関係になっています。

競合文書には３つの特殊フィールドが追加されています。

フィールド名	説明
$REF	元の文書（親文書）のユニバーサル ID。
$Conflict	フィールドが存在することで競合文書であること表す。 値としては文字列で Null。
$ConflictItems	競合したフィールドを記録。

$ConflictItems は公式ヘルプには項目単独で解説がありませんが、競合したフィールド名を内部的に保持するフィールドとして実際に存在します（仕様として公開されない内部アイテムのひとつです）。

競合文書とビュー

ディスカッションテンプレートなど一般的な Notes アプリの場合、競合文書が発生すると次のように、インデントされ特別な表示となります（開くと通常通りのフォームで文書が確認できます）。

このような表示を行うビューのプロパティでは「返答文書を階層表示する」がチェックされています。これは $REF フィールドが存在することからわかる通り、返答文書の機能を利用しているからです。

競合文書の発生はアプリ開発者にとって、招かざる客といえます。競合文書の発生を監視できるビューがあると便利です。次のような選択式のビューを作成すると競合文書だけを表示するビューを作成できます。

SELECT @IsAvailable($Conflict)

@IsAvailable は引数のフィールドが存在するかを判定します。フィールド名には引用符が付かない点に注意が必要です。

なお、このビューではプロパティの「返答文書を階層表示する」のチェックを必ず外してください。選択式に合致する文書に親文書が含まれないことから、何も表示されなくなります。

競合の解消方法

上記の通り Notes は競合を表示する機能はあるだけで、競合を解消する作業はユーザの手で行う必要があります。その操作の流れは次の通りです。

1. 親文書と競合文書を確認し、競合内容を調べる（$ConflictItems でフィールドを特定）
2. 競合文書から親文書に反映すべき内容があれば、コピー＆ペースト反映する
3. 競合文書を削除する

競合文書側を残したい場合、競合文書をいったん編集し、保存すると親文書になります。その後、元の親文書を削除する対応が可能です。この操作でもともと親文書にぶら下がっていた子文書は、新しい親文書の下に付け替えられます。

ただ、この方法では新しい親文書のユニバーサル ID が変わりますので、元の親文書に対する文書リンクは機能しなくなるので、注意が必要です。

また、親文書の付け替えにより、子文書の $REF フィールドが更新されます。 これに伴い、子文書が未読になる点にも注意が必要です。

このような背景から競合文書側を残す運用は現実的ではないと思います。

複製の基本操作と動作

今回は複製（レプリカ）の基本的な操作と挙動についてまとめます。

複製の作成

ワークスペースで複製したい DB のアイコンをクリックし、［ファイル］－［複製］－［複製の作成］を選択します。表示された画面で、新しく作成する複製先のサーバとファイルパスを指定します。

複製先のサーバは、サーバだけでなくクライアント（Local）も指定できます。

ファイルパスは複製元と同じにする必要はなく、変更することが可能です。これは、ファイルパスではなくレプリカ ID を使用して複製を実行する仕様だからです。ただし、レプリカ ID は目で見て DB を判別するのが難しいため、特に理由がない限り、同じパス／ファイル名にしておくことをおすすめします。

複製の作成が開始されると「複製と同期」という画面が開き、作業の進捗が表示されます。

レプリケータ

この「複製と同期」の画面のことをレプリケータと呼ぶことがあります。この画面は Notes クライアントとサーバ間の複製操作に特化した画面です。［複製の開始］ボタンをクリックすると、チェックが付いているすべての複製を一度に実行することが可能です。

複製が終了すると「複製結果」欄に詳細が表示されるので、全体の結果を簡単に確認できます。

また、各エントリを右クリックして［選択したアプリケーションの複製］を選択することで、個別に複製を実行することも可能です。

多数のアプリケーションをローカルに複製して持ち歩き、まとめて更新するような運用では、非常に便利な画面です。

手動複製の操作（クライアント）

ワークスペースで複製したい DB のアイコンを右クリックし、［複製］－［複製］から「オプションの複製」を選択すると、どのサーバと複製するのかを指定する画面が表示されます。ここで指定したサーバとの間で複製が実行されます。

複製が終了すると、文書の追加 / 更新 / 削除など実行結果が詳細に表示されます。

個別に複製を実行したい場合や、特定のサーバとの間で手動で複製を行いたいときに使用する操作です。

差分の反映と削除スタブ

複製の動作において、複製元に文書がなく複製先にのみ存在する場合、文書は追加されます。複製先の文書が更新されていた場合は、文書が更新されます。ここまでの動作は想像しやすいでしょう。

では、複製元に存在する文書が、複製先で削除されていた場合を考えてみます。もし文書が完全に削除されていたとすると、「複製元で文書が追加された」と誤って判定されてしまいます。

この問題を回避するため、Notes では文書を削除した場合でも、完全に消すのではなく「削除された文書」として DB 内に情報を残します。これを「削除スタブ」と呼びます。

複製先で削除スタブとなっていた場合、文書は削除されたものと判断され、複製元の文書も削除される、という動作になります。

レプリカスタブ

複製の作成画面には「すぐに複製する」というオプションがあります。このチェックを外して複製を作成すると、ワークスペース上にはアイコンが作成されますが、プロパティを開こうとすると「初期化中です」というメッセージが表示され、開くことができません。

これは、複製の器（NSF ファイル）だけが作成された状態で、文書はもちろん、設計要素もまだ反映されていない状態です。このような状態を「レプリカスタブ」と呼びます。次回、複製が実行されることで、必要な文書や設計要素が反映され、通常のアプリケーションとして使用できるようになります。

特にサーバ間で複製を作成した際などに、この状態に出くわすことがあります。Notes のデータベース（NSF）には、このような「中身のないレプリカ」が存在し得る、ということを覚えておくとよいでしょう。

複製（レプリカ）とは？

Notes/Domino の特徴的な機能として「複製」というものがあります。「レプリカ」とも呼ばれ、Notes の世界ではほぼ同じ意味で使われています。

管理者としてサーバを触っているときはもちろん、Notes クライアントを使っているときも、Designer で開発しているときも、気づけばどこかで必ず登場する機能です。

何年も Notes に触っているのに、実は仕組みはよく分からないまま使っている、という人も多いのではないでしょうか。私自身も、長い間そんな感じでした。

複製の基礎から設定、周辺知識、実運用での注意点まで、「複製」にはいろいろと語れるトピックがあります。思いつくままに、そのあたりを書いていこうと思います。まずは、いちばん基本的なところからはじめます。

複製とコピーの違い

「複製」と「コピー」、言葉の意味だけを見るとほぼ同じに思えますが、Notes の世界ではこの 2 つはまったく異なる動作をします。実際に Notes クライアントでは、どちらもメニューとして用意されています。

実行してみると、「コピー」の場合はワークスペースに新しいアイコンが追加されます。この挙動の通り、別の新しい器（データベース）に、設計と文書を丸ごとコピーして作成されます。この時点でコピー元との関連性はなくなり、以降は完全に別物のデータベースとして扱われます。これが Notes における「コピー」です。

一方、「複製」の場合はアイコンが重なって表示されます。右下のアイコンをクリックすると、複製メニューが表示され、重なっているデータベースの配置（サーバ名やファイル名）を確認できます。

複製メニューの［複製］を選択すると、複製相手のデータベースと文書を送受信する画面が表示されます。このように、「複製」で作成したデータベースは、作成後も双方の内容を同期し続けられる点が最大の特徴です。

複製とレプリカ ID

複製の関係にあるデータベースのプロパティを確認すると、同じレプリカ ID が設定されていることがわかります。

Notes/Domino では、このレプリカ ID を利用してデータベースを識別し、複製関係にあるかどうかを判定しています。そして、レプリカIDが一致する場合にのみ、データベース間での同期（レプリケーション）が行われます。

ちなみに、先ほど「コピー」で作成したデータベースでは、元のデータベースとは異なるレプリカ ID が割り当てられています。

文書 ID（ユニバーサル ID）

データベースのレプリカ ID と同様に、文書にもそれぞれを一意に識別するための ID が存在します。これをユニバーサル ID（UNID、ユニーク ID とも呼ぶ）といいます。文書のプロパティ画面の［文書 ID］タブに表示されている上 2 行がユニバーサル ID です。

ユニバーサル ID はデータベース全体で一意となる ID であり、複製先のデータベースでも同じ ID が維持されます。下図は複製関係にある文書のプロパティを比較したものです。他の ID には差がありますが、ユニバーサル ID は一致していることが確認できます。

複製が必要となった背景

Notes/Domino はインターネット黎明期から存在する製品です。当時のネットワークは通信速度が遅く、コストも高額でした。そのため、拠点ごとにサーバを配置し、LAN 内からアクセスさせることで、速度とコストの両立を図っていました。

拠点間の情報共有については、通信コストの安い時間帯を利用して後から複製（同期）を行う、という運用が一般的でした。

当時、複製は Notes の特徴的で先進的な機能でしたが、その後 Oracle など他のデータベース製品でも同様の仕組みが実装されていったと記憶しています。

現在ではネットワークが高速かつ安価になったため、純粋に通信コスト削減を目的として複製を利用するケースは少なくなりました。しかし、Notes/Domino において複製は今なお基本機能のひとつであり、Domino クラスタをはじめ、多くの機能の前提として使われています。そのため、動作原理は今でも知っておくべき重要な知識といえるでしょう。

Domino 体力測定：#4）ビュー操作 ④ - ビューの列数と値の取得

背景と目的

前回は実運用に近い検証を目的に、ビューから取得する文書のサイズ（フィールド数）とビュー操作を行うメソッドの特定を測定しました。今回は、ビューに定義されている列数とレスポンスの関係について調査します。

測定環境

測定に使用する PC はこれまでと同じ PCを使用します。また、DB は前回作成したダミーフィールドを 200 個追加したものを使って測定します。

今回のテストでは、ビューに配置するダミーフィールドの数を変化させテストします。利用するビューは次の 5 種類です。

View 名	テスト文書の状態
000	ダミー列なし。
050	ダミー列を 50 個追加（Text_00 ～ Text_31）
100	ダミー列を 100 個追加（Text_00 ～ Text_63）
150	ダミー列を 150 個追加（Text_00 ～ Text_95）
200	ダミー列を 200 個追加（Text_00 ～ Text_C7）

手順

測定手順はこれまでと全く同じとします。ビューに対して 20 回の検索を行い、取得したコレクションからエントリと値を取得する操作を 50 回行います。測定回数は 10 回です。

この測定を View 050 ～ 200 まで順に行います（View 000 については前回の結果を流用）。

なお、テスト項目と測定の項目は「#1）ビュー操作 ① - 測定方法」をご確認ください。

結果

測定結果は次の通りでした。

このままではわかりにくいので、測定時間の推移をテスト項目ごとにグラフ化します。

結果が水平となっているのは、D2、D3、E4、E5 です。それ以外のテスト項目については、列数に比例して処理時間が増えているように見えます。

前回に倣って、値の取得（D1 ～ D3、E1 ～ E3 ）に絞ってグラフ化ました。全体の処理時間（折れ線グラフ）も、列数にほぼ比例して処理時間が増えています。また、列数の増加に比例して、GetAllEntriesByKey の方が遅くなっていることが確認できます。

考察

今回の測定結果より推察できるビュー操作の特徴を整理します。

◇ 検索時間の違いはコレクション作成時間？

まず、ビューを検索し検索結果のコレクションを確認する D1 と E1 を比較します。処理時間の比率を確認するとダミー列なしで 1.7 倍、200 個で 1.6 倍の差があり、グラフ化すると次の通りでした。

D1 と E1 の測定では、検索キーの指定、検索結果が同じなので、ビュー検索時間は一定と仮定できると思います。グラフはほぼ水平であることから、コレクション作成時間は、ビューの列数に比例しており、列数が増えるほど GetAllEntriesByKey には不利に働くといえます。

◇ NotesViewEntry クラスのオーバヘッド

E2 の NotesViewEntry 取得の結果を見るとダミー列数に比例して、処理時間が増えています。D2 の NotesDocument の取得はダミー列数に依存せず一定な上、ほぼ 0 なので、エントリ取得という点においても、GetAllEntriesByKey が不利といえます。

◇ 列数の調整で逆転はない

前回のテストで、NotesDocument から値を取得すると文書サイズに比例して遅くなる結果が出ました。今回のテストはその特性が顕著に表れるダミーフィールド 200 個のテストデータで行いました。

ところが、上記 2 点のとおり、検索処理自体に加え、検索結果からエントリを取得する処理でも、列数に比例してコストが発生することがわかりました。

NotesViewEntry??? クラスを使用したオーバヘッドを赤の斜線、NotesDocument 使用時のオーバヘッドを青の斜線で表すと次のようになります。

最も有利なダミー列なしでも赤の部分があまりに大きく、列を増やすにつれてその差が開きます。この結果より、今回のテストケースにおいては、ビューの列数の調整で GetAllEntriesByKey が早くなることはないことがわかります。

◇ ビュー索引を活用

アルゴリズムの評価ではオーダ（Order）とい指標があります。これは、入力データ数に対して処理時間の変化するかを示すものです。

ソートを例にするとデータ数を n とすると、最悪で n²（n の 2 乗）、一般的には n log n の処理時間が必要なります。データがソート済みだった場合に限定すると n となるパターンがあります。オーダ n は、データ件数と処理時間が比例の関係になることを示します。一方、n log n や n² は、データ件数の増加に従い急激に処理時間が増加します。

今回のテストでは、ビューの列数に依存する D1、E1、E2 はほぼ比例の関係になっています。この結果から、今回テストしたメソッドには、実行時にソート処理を行うような要素は含まれていないと推察できます。

よって、今回テストした処理では、すでにソート済みの索引データを順になぞっているだけであり、比例的な特性（オーダ n）になっていると考えられます

ビューの検索処理が、ビュー索引を活用した構造になっていることの一つの証左と言えますね。

まとめ

前回の検証では、

• 文書から値を取得する処理は、フィールド数に比例して遅くなる
• ビューからの値取得では、文書内のフィールド数に依存せず一定

という結果が出ました。

今回の検証では、ビューに必要な列を用意すれば GetAllEntriesByKey の方が早くなる可能性を調査したのですが、結果は、

• ビューの列数とレスポンスは比例の関係
• NotesViewEntry??? の処理コストがあまりも高い

ことがわかり、優位に立つことはない結果となりました。

ただ、前回、今回の検証では、検索結果（コレクションのサイズ）を 1000 としていました。実運用では、少々大きすぎるかもしれません。コレクションを小さくした場合や GetEntryByKey ではどうなるかの検証が必要かもしれませんね。

前回

Domino 体力測定

Int と CInt （LotusScript）

LotusScript で実数を整数に変換する関数として Int と CInt 関数の 2 種類があります。PC が一般的になり始めたころに BASIC 言語を使用していた私には Int の方がなじみがあります。その経験から CInt も同じだろうと無頓着に使用してきましたが、微妙に差があったのでまとめておきます。

丸め方の違い

デザイナーヘルプによると次のように説明されています。

Int	引数に指定した数値に等しいか、それよりも小さい整数値のうち、指定した数値に最も近い値を返します。
CInt	値を Integer データ型に変換して返します。 最も近い整数に丸め、Integer 型の値として返します。

ニュアンスから関数の立ち位置が見えてきますね。Int は整数値に変換することを主題にしてています。CInt は型変換が主題で、その副次的機能として丸め処理が発生しているようです。

そして、小数値の処理である丸め方の表現に違いがあることがわかります。

丸め方の動作検証

それでは実際に処理の違いを確認しましょう。簡単なエージェントを作成し、Int と CInt の差を確認します。

Option Declare Sub Initialize    xTest 1.5 End Sub Function xTest(vdVal As Double)    MsgBox "Int(" & CStr(vdVal) & ") = " & CStr(Int(vdVal))    MsgBox "CInt(" & CStr(vdVal) & ") = " & CStr(CInt(vdVal)) End Function

引数を変えながら動作検証した結果は次の通りでした。

	1.1	1.5	1.9	2.1	2.5	2.9
Int	1	1	1	2	2	2
CInt	1	2	2	2	2	3

Int は切り捨て処理であることが確認できます。しかし、CInt では 0.5 の処理が単純な四捨五入とは違います。この部分の動作を詳しく確認します。

	1.49	1.50	1.51	2.49	2.50	2.51
Int	1	1	1	2	2	2
CInt	1	2	2	2	2	3

プログラミングや統計の世界では、5 ちょうどの扱いを「常に切り上げない」といった仕様が使われることがあり、統計的に偏りが出にくいことを目的としています。

CInt はこの仕様を採用しており、ヘルプでは ”四捨五入” と表現せず、”最も近い整数に丸める” という表現になっているということですね。

負の数の対応

続いては、負の数の処理に関して確認します。

CInt の動作はわかりやすく、単に符号が付いただけの動作になります。

ところが、Int の場合は、絶対値が変化しています。これは、指定した値よりも ”小さい” 最も近い整数となるためです。

	-1.49	-1.50	-1.51	-2.49	-2.50	-2.51
Int	-2	-2	-2	-3	-3	-3
CInt	-1	-2	-2	-2	-2	-3

負の数はビジネスでは使用頻度が低いかもしれません。ただ、頻度が低いと間違い（確認漏れ）が発生しやすいので注意しましょう。

イレギュラーの対応

最後に、これら関数に対してイレギュラーな値を与えた場合の動作について整理します。

テストデータ	値	Int	CInt
Integer の範囲を超える数値	77777.7	77777	エラー
数値に変換できる文字列	"2.50"	2	2
数値に変換できない文字列	"14.5 FP1"	エラー	エラー
日付/時刻	Now	2026/1/18	エラー
Empty な Variant 型変数		0	0
配列		エラー	エラー

まず、この結果より Int 関数は名称から Integer 型と思いがちですが、Integer 型を超えた値の処理が可能です。そのおかげで日付/時刻データから時刻部分（小数値）を削除する演算としても使用可能です。

式言語の @TextToNumber で文字列を数値に変換する場合、変換できる範囲で実行する機能があります。例えば "14.5 FP1" は、14.5 に変換してくれるのですが、LotusScript では単純にエラーとなります。

Variant 型変数を引数にする場合には、Empty（変数の宣言だけして値を代入し忘れた状態）は 0 となり、配列やオブジェクトが入っている場合にはエラーとなります。

このような、イレギュラー処理が発生すること自体あまり良いコーディングとは言えないと思います。必要な場合はコメントに記すなど、後から見てわかるようにしておきましょう。

@Sort は高性能！

@Sort を使えば、リスト値をソートすることができます。 先日、この関数のヘルプを見ていると、さまざまな機能が入っていることに気付いたので紹介します。

@Sort の構文

Domino デザイナーヘルプで @Sort を調べると構文は次のようになっています。

@Sort( list ; [ order ]; customSortExpression )

今回紹介するのは 2 つ目の引数 order です。

ここにキーワードを指定するとソート動作を詳細にコントロールできるようになります。キーワードは 2 つずつが対になっています。

キーワード（〇：デフォルト）		機能
[ASCENDING]	〇	昇順 / 降順を指定
[DESCENDING]
[ACCENTSENSITIVE]	〇	濁点、半濁点の区別
[ACCENTINSENSITIVE]
[CASESENSITIVE]	〇	大文字、小文字の区別
[CASEINSENSITIVE]
[PITCHSENSITIVE]	〇	全角、半角の区別
[PITCHINSENSITIVE]

デフォルトは ”昇順” かつ ”区別する” になっていて、区別させたくない場合に [???INSENSITIVE] を指定することになります。

キーワードの指定は :（コロン）で複数指定することができるので、さまざまなパターンのソートが実現できるということですね。

動作検証

大文字/小文字、全角/半角については結果が想像できるので、濁点/半濁点を検証します。

まず、キーワード未指定と [ACCENTINSENSITIVE] を指定した場合を比較すると次のようになります。[ACCENTINSENSITIVE] では濁点/半濁点だけでなく、小書きも無視してソートしてくれるようです。

ただ、これだけではひらがなとカタカナには効果がありません。区別なくソートするためには [CASEINSENSITIVE] も指定します。

残念ながら、カタカナの全角/半角については、正しく判定されません。モノは試しと [PITCHINSENSITIVE] も指定してみましたが効果がありませんでした。半角カタカナでは濁点/半濁点が 2 文字になるためだと思われます。

まとめ

今回は @Sort のソート順を指定するオプションについて紹介しました。Notes/Domino は海外の製品ですが、日本語の扱いにここまで対応しているんですね。『ソートといえば文字コード順』と思い込んでいたので、正直驚きました。どのような仕組みで実現しているのか ”中の人” に聞いてみたくなりました。

なお、@Sort のキーワードには [CUSTOMSORT] というものがあります。こちらについては、まだ不明瞭な点もあるため触れませんでした。解説できるぐらい理解できたら、改めてまとめたいと思います。

Domino 体力測定：#3）ビュー操作 ③ - フィールド数による影響

背景と目的

前回はビュー操作を行う 2 つのメソッドの基本的な特性の測定結果を紹介しました。そのテストでは、テストデータの文書は小さく軽量、検索用のビューもシンプルでした。より実運用に近い検証となるよう、追加でテストしたいと思います。

今回はフィールド数を変化させ、レスポンスにどのような影響があるのか測定します。

測定環境

まず、測定に使用する PC は前回と同じものを使用します。SSD 搭載の今どきの環境の想定です。

フィールド数とレスポンスの関係を調べることから、今回のテスト DB は、一定のダミーフィールドの個数を変化させた5 種類を用意します。ダミーフィールドには、読み込み用と同じ 100 Byte のテストを設定します。

DB 名	テスト文書の状態	文書サイズ
000	前回と同じ。	188 Byte
050	000 の文書にダミーフィールドを 50 個追加（Text_00 ～ Text_31）	5288 Byte
100	000 の文書にダミーフィールドを 100 個追加（Text_00 ～ Text_63）	10388Byte
150	000 の文書にダミーフィールドを 150 個追加（Text_00 ～ Text_95）	15488Byte
200	000 の文書にダミーフィールドを 200 個追加（Text_00 ～ Text_C7）	20588Byte

参考までですが、ダミーフィールド作成する部分のコードは次の通りです。

'取得用の値       s = Right("0000000000" & s, 10)       s = s & s & s & s & s & s & s & s & s & s       Call nd.Replaceitemvalue("Text", s)       'ダミーフィールド作成（viWait は作成する個数）       For i = 0 To viWait - 1          Call nd.Replaceitemvalue("Text_" & Right("00" & Hex(i), 2), s)       Next

250 個作成しようとするとエラーとなりました。9.0.1 FP8 以降で対応した LargeSummary を有効化する必要があるので、今回は 200 個までで検証としています。

手順

測定手順は前回と全く同じです。ビューに対して 20 回の検索を行い、取得したコレクションからエントリと値を取得する操作を 50 回行います。測定回数も同じ 10 回とします。

この測定を DB 050 ～ 200 まで順に行います（DB 000 については前回の結果を流用）。

結果

測定結果は次の通りでした。

横軸を文書サイズに設定し、各測定項目と DB 毎の結果をグラフ化すると次の通りです。

D3、E5 のグラフは右肩上がりの直線となっており、フィールド数に比例しているといえます。それ以外のグラフは水平で、フィールド数の影響は受けないことがわかります。

考察

今回の測定結果より導くことができるビュー操作の特徴を整理します。

◇ ビュー検索はフィールド数に依存しない

ビューの検索を行う D1、E1 ともフィールド数増減の影響を受けず、ほぼ一定の処理時間となっています。また、コレクションからエントリを取得する処理（D2、E2）も同様です。さらに、NotesViewEntry から NotesDocument を取得する処理（E4）も一定です。

これらの結果より、コレクション、コレクション内のエントリ操作、NotesDocument オブジェクトの取得までは、文書単位で処理をしており、文書内のフィールド数には依存しないことがわかります。

ここまでの処理においては、1 文書は 1 文書で、その内部の状態は関係ないということですね。

◇ 値取得はフィールド数に依存

NotesDocument から値を取得する処理（D3、E5）では、フィールド数に比例して、処理時間が増加します。

今回の検証データは、読み込む Text フィールド作成後、ダミーフィールドを追加しました。内部的に作成順で記録されていると仮定すると、Text フィールドは文書のほぼ先頭に存在します。それでも、フィールド数に比例した結果になるということは、フィールドにアクセスしたタイミングで、すべてのフィールドの一覧を作成していると考えられます。

アプリの仕様変更を行うと無用となるフィールドが発生することがあります。実害がないので、ついつい残しがちなのですが、パフォーマンスという観点でいうと削除しておいた方がよさそうですね。

なお、今回の検証では、ダミーフィールドのサイズを固定したため、フィールド数 ≒ 文書サイズとなっています。今回の特性の要因が、文書サイズである可能性が残ります。

◇ 逆転の可能性

文書から値を取得することだけに限定すると、D1 ～ D3、E1 ～ E3 までで実現できます。この部分に絞って、結果を整理すると次のようになります。

GetAllDocumentsByKey（青）のグラフは右肩上がりで、GetAllEntriesByKey（オレンジ）は水平です。ダミーフィールドなしでは、ほぼダブルスコアですが、200 個ではずいぶん差が小さくなっています。さらにフィールドを増やしたテストを行えば逆転することがあるかもしれません。

なお、今回の検証では、ダミーフィールドのサイズを 100 バイトにしています。そのため 200 個以上フィールドを増やせませんでした（Summary フィールドの上限）。セットする値を小さくし、フィールド数を増やした場合や Domino 9.0.1 FP8 以降で対応した LargeSummary 環境での特性も気になりますね...

まとめ

今回の検証では、GetAllEntriesByKey で検索し ColumnValues で値を取得する限りにおいては、フィールド数に依存せず同じレスポンスになることがわかりました。逆に NotesDocument オブジェクトを介して値を取得するとフィールド数に比例した処理時間が必要とります。ただ、ここまでの検証では GetAllEntriesByKey の方が早くなるパターンは見つかっておらず、GetAllDocumentsByKey が優勢の状態に変わりはありません。

なお、今回の検証で不明瞭な点は、次の通りです。機会があれば検証したいと思います。

• もっと大量のフィールドが存在する場合、処理時間が逆転することはあるか？
• フィールドサイズの大小で変化はあるか？
• LargeSummary 環境において特性に変化はあるか？

前回

Domino 体力測定