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 クラスタをはじめ、多くの機能の前提として使われています。そのため、動作原理は今でも知っておくべき重要な知識といえるでしょう。