本文へジャンプ

ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Notes/Domino > 

LDD Today

テンプレートに関するトラブルPart 2


Lotus Software
by David Byrd、Timothy Speed
レベル:すべて
対 象:Notes/Domino 6
原文の掲載:2003年9月3日

LDD Todayの原文(US)

インデックス
テンプレートのベスト・プラクティス
テンプレートのトラブルシューティング
シングル・コピー・テンプレート
シームレス・メール・アップグレード
テンプレートの実際

このシリーズのパート1では、Notesテンプレートのしくみとその利用法を簡単に紹介し、設計変更の制御やACLの設定について取り上げ、記事の中で紹介したツール(Sandboxからダウンロード可能)を使って設計情報を取得する方法を説明しました。完結編となるこの第2部では、テンプレートのベスト・プラクティス、トラブルシューティングのTIPS、およびシングル・コピー・テンプレートやシームレスなメール・アップグレードなどの新機能について説明します。

この記事は、Notes/Dominoのプログラミングについてある程度の経験があることを前提としていますが、初心者にとって有益な情報もたくさん含まれています。また、LDD Todayの記事「Enhancements to Notes/Domino 6.0.1 and 6.0.2」で、最新のテンプレート機能についてお読みになることをお勧めします。


テンプレートのベスト・プラクティス
ここでは、ドメインの構造、命名規則、リビジョンの追跡など、テンプレートのベスト・プラクティスをいくつか紹介します。

ドメイン
ドメインを効果的に使用することは、テンプレートを管理する上で重要な要素の1つとなります。Lotus Notesにおける「ドメイン」とは、同じDomino Directoryを共有する(したがって、同じ構成情報を共有する)サーバーとクライアントのグループです。ドメインには、ユーザー、サーバー、およびグループの定義が含まれます。Domino Directoryは、ドメインの内部および外部のNotesの通信を制御します。

Notesドメインを使用して、アプリケーションの論理的なコレクションを制御することもできます。多くの企業には、職務に沿って構成された複数のドメインがあります(プロダクション・ドメイン、開発ドメイン、テスト・ドメインなど)。この種の構造は、アプリケーションを管理する上で役に立ちます。これにより、設計変更の管理はもちろん、アプリケーションのセキュリティ保護や配置もより簡単になります。

実働アプリケーションで原因不明の問題が発生し、調べてみたところ、開発者がアプリケーションの実働コピーに手を加えたことがすぐに判明した、というようなことがよくあります。よかれと思った開発者が設計要素の1つに変更を加えた結果、アプリケーションが破損したのです。こうした開発者によるちょっとした変更は、瞬く間にドメイン全体に波及して、アプリケーションを停止に追い込みます。この問題は、「隔離した」環境(すなわちテスト・ドメイン)でアプリケーションをテストするという十分な管理が行われていれば、簡単に回避できます。このような理由から、実働テンプレートは、テスト・テンプレートや開発テンプレートから隔離しておくことをお勧めします。このほか、許可されていない変更や予想外の変更が実働アプリケーションに加えられるのを防ぐために、実働ドメインの開発者のACLエントリーを削除する必要もあります。

以下は、新しいアプリケーションのテストおよび配置のための推奨される構造の例です。



この架空の組織では、プロダクション・ドメインがテスト・ドメインや開発ドメインから隔離されています。各ドメインには、それぞれ組織レベルの認証者がいます。プロダクション・ドメインは外部ドメインと通信します。各ドメインには、それぞれ責務が定義されています。プロダクション・ドメインは、ユーザー、顧客、および場合によっては不特定多数の人々に向けて、アプリケーションが配置される場所です。開発ドメインは、開発者によって、新しいアプリケーションの開発や既存のアプリケーションの更新のために使用されます。テスト・ドメインは、新しいアプリケーションや更新されたアプリケーションのテストを目的としています。

テンプレートの命名
ドメインの定義が完了したら、アプリケーションの開発を開始します。まず最初に、簡単な命名規則を作成します。
  • ファイル名
    次のような構造に従ってファイル名を付けることをお勧めします。

    [アプリケーション/テンプレート名の最初の8文字] + [アプリケーション・バージョン番号] + [拡張子(NTF/NSF)]

    たとえば、Accounting Trackingテンプレートの2つ目のバージョンのファイル名は、Accounti002.ntfになります(Accountiはテンプレート名の最初の8文字、002はバージョン)。
  • テンプレート・タイトル
    テンプレートのタイトルには、アプリケーションの名前とバージョン番号を使用します。たとえば上の例の場合、テンプレートの名前はAccounting Tracking 002になります。
  • テンプレートの継承名
    次の構造に従います。

    [部門コード] + [アプリケーション名の最初の8文字]

    上の例の場合、テンプレートの継承名はV123Accountiになります(V123は部門コード)。

テンプレートの追跡
ドメイン構造と命名規則をテンプレートのリビジョンの追跡に利用すると、各テンプレートを適切なドメインに配し、他のドメインから隔離することができます。先ほどの例では、実働テンプレートがAccounti002.ntfなら、開発者が作業するのはAccounti003.ntfになります。この場合、実働テンプレートはプロダクション・ドメインにあり、更新作業中のテンプレートは開発ドメインまたはテスト・ドメインにあります。このプロセスのワークフローは、たとえば次のようになります。

  1. アプリケーションに対する変更が、変更管理システムを通じて要求されます。
  2. 変更が承諾されて、開発者が割り当てられます。
  3. 開発者は、テンプレート管理システムを使って、Accounti002.ntfをアーカイブからチェックアウトします。
  4. 開発者がテンプレートに変更を加え、テンプレートをAccounti003.ntfとして保存します。
  5. 開発者は、テスト・シナリオを作成し、テンプレートをテストのためにTestドメインに配置するように依頼します。その後テスト・チームが、そのテスト・シナリオを使ってアプリケーションの変更内容をテストします。
  6. すべてのテストが成功したら、アプリケーションの最終検収を実施します。検収プロセスについてここで詳しく説明することはできませんが、少なくとも、アプリケーションへの署名(ECLの実装についてはIris Todayの記事を参照)、ファイル名とテンプレートの継承名のチェック、変更管理システムの更新、既存データの更新や変更に関する特別な指示の追加、および実稼働環境でアプリケーションにエラーが発生した場合のための「バックアウト」プランの作成が、検収のチェックリストに含まれている必要があります。
  7. 検収プロセスと変更の管理が完了したら、アプリケーション・テンプレートを実働サーバーに移します。指定した日時(日曜の午前1時などのトラフィックの少ない日時を指定するのが一般的)に、更新したテンプレートで実働アプリケーションが更新されます。
多くの管理者は、サーバー上のNotes.iniの変数ServerTasksからDesignタスクを削除します。この場合、アプリケーションの設計の更新には、指定されたサーバー(アプリケーション「マスター」サーバーなど)が使用されます。このマスター・サーバーには、すべてのアプリケーションと関連テンプレートが含まれています。テンプレートはこのサーバーのみに存在し、(ワークステーションを通じて)要求があった場合にのみ更新されるため、Designタスクが実行されることはありません。この方法の大きなメリットの1つは、テンプレートのACLとアプリケーションのACLの両方から開発者をブロックできるという点です。アプリケーションが実働サーバーに移されたら、開発者のACLアクセス権を削除できます。

以下は、アプリケーションの更新を追跡するための追跡フォームの例です。


アプリケーションの情報:
アプリケーション名:


バージョン番号:


アプリケーションの説明:


テンプレート名(アプリケーションがテンプレートの場合):


アプリケーションが継承するテンプレートの名前:


テンプレート・ファイルの名前:


リリース日:


リリースの種類(新規、バグ・フィックス、強化):


データベースの所有者:


サーバー名:


ディレクトリー名:


開発者名:




アプリケーションの状態:
  • 設計の置き換えですか、それとも更新ですか?
  • 変更管理システムによって承諾されていますか? Y/N
  • 新しいリリースは検収テストに合格しましたか? Y/N
  • アプリケーションがオフラインになっているかどうか、またはユーザーがアプリケーションを使用していないかどうか、あるいはその両方を確認しましたか? Y/N
質問:
  • [設計]プロパティー・ボックスの[更新時に再設計/設計の置換を禁止する]オプションは選択解除されていますか? Y/N
  • 要素(アイコン、ナビゲーター、ヘルプ、およびデータベースの使い方文書)のアプリケーション・バージョン番号は更新されていますか? Y/N
  • 更新または置き換えの後にアプリケーションにコピーする必要がある文書はありますか? Y/N
  • 構成文書やプロファイル文書についての開発者からの指示はありますか? Y/N
  • アプリケーションの更新後に実行する必要があるエージェントはありますか? Y/N
  • テスト用のフォーム、ビュー、およびフィールドはすべて削除されていますか? Y/N
  • ACLやロールに変更を加える必要はありますか(開発者からの指示による)? Y/N
  • アプリケーションの現行リリースはバックアップされていますか? Y/N
  • アプリケーション・アップグレードのバックアウト・プランはありますか? Y/N
  • 新しいリリースについてユーザーに通知してありますか? Y/N
  • テンプレートとアプリケーションのACLから開発者名(またはグループ)が削除されていますか? Y/N
  • 必要な署名IDによるテンプレートへの署名は行われていますか? Y/N


他の開発リソースと同様に、テンプレートの管理も、正しく行わないと面倒な作業になります。テンプレート自体を、他のソース・コードと同等に扱う必要があります。テンプレートに変更管理のためのバージョンを付けるのは簡単です。上で述べたように、テンプレートやファイルの名前にバージョン番号を含めることによって、テンプレートを最も効果的に管理できます。更新の完了後は、無許可アクセスを防止するためにACLに制限を加えるか、場合によっては完全に削除する必要があります。こうした手動による管理方法のほか、サードパーティーのツールを使って(Ives DevelopmentのTeamStudio CIAO!など)テンプレート・リビジョンを追跡することもできます。こうしたツールをサイトで使用することを検討してみるのもよいでしょう。
 
上に戻る
 
テンプレートのトラブルシューティング
テンプレートのトラブルシューティングは、きわめて単純な作業と言えます。起こりうる問題はごく限られている上、修正方法もとても簡単です。以下のそれぞれの状況には、Lotus Notesの担当者が遅かれ早かれ遭遇する一般的な問題が含まれています。

  • サーバーでDesignタスクが実行されると、要素が表示されたり消えたりする。この問題は、Designタスクを夜間にサーバーで実行した場合に発生することがあります。テンプレートのバージョンに注意しないと、予想外の設計変更が行われる可能性があります。また、設計テンプレートもその他のデータベースと同様に複製されるため、既に削除されているはずの設計要素が古いコピーによって復活したりしないように注意する必要があります。
  • 設計要素が正しく更新されない。テンプレートで行った変更が、親データベースに反映されないことがあります。これには次のような原因が考えられます。
    • 設計要素がロックされていて変更できない。
    • テンプレート名の設定から継承されたデータベースのレベルが、ベース・テンプレートと一致していない。
    • テンプレート名の設定から継承された設計要素のレベルが、ベース・テンプレートと一致していない。
    • 複数のデータベース・テンプレートが同じテンプレート名を共有している。
  • テンプレートから作成したデータベースに文書が表示される。開発者がテンプレートに文書を残しておいた可能性があります。文書を意図的にテンプレートに残しておく場合もあります。たとえば、アプリケーションでキーワード・リスト・ビューに事前にキーワードを設定しておく必要がある場合は、そのための文書をテンプレートに追加することができます。
  • テンプレートACLから作成したデータベースのACLが正しく設定されていない。テンプレートの設計者が、新しいデータベースに移すACLエントリーをブラケットで囲んでいなかった可能性があります。
  • テンプレートのODSが20 (R4形式)になっている(その他のデータベースのように41 (R5形式)や43 (Notes/Domino 6形式)になっていない)。
  • ODS20は、テンプレートのデフォルトのODS (On-Disk Structure)です。この形式が使用されている最大の理由は、R5やNotes/Domino 6の新しいODS形式より省スペースであるという点にあります。4GBのサイズ制限があることを除いては機能の違いもなく、このサイズの制限も、通常は、ほとんどのテンプレートで問題になりません。
  • Designタスクの実行後、アプリケーションに重複した設計要素が表示される。この問題は、設計要素をテンプレートにコピー・アンド・ペーストした場合に発生します。Designタスクは、要素の名前と、それに対応する固有ID (UNID)に基づいて設計要素を更新しますが、設計要素をペーストすると、このUNIDが変更されます(設計要素をコピー・アンド・ペーストすることは、一般的な開発手法としては問題ありません。しかし、注意が必要な場合もあります。たとえば、「Document」という名前のフォームがテンプレートにあり、このフォームに設計変更を加える場合に、変更の数が多いため、すべての変更をテンプレート内で一度に行いたくなかったとします。そこで、テストのために、テンプレートのコピーでいくつかの変更を行うことにしました。その後、テンプレートから「Document」フォームを削除し、更新した「Document」フォームをテスト・データベースからテンプレートにコピー・アンド・ペーストしました。この場合、テンプレート内のフォームは、元のテンプレートと名前は同じでもUNIDが異なります)。
テンプレートの更新の問題をデバッグする際には、ローカルでの更新の場合はNotesクライアントのステータス・バーを、夜間の設計更新の場合にはサーバー・ログ(log.nsf)を確認するのが最も有効です。これらには、追加、更新、または削除された各設計要素が、基となるテンプレートと一緒に表示されています。

言うまでもないことですが、そもそも問題が発生しないようにすることこそが最高のトラブルシューティングです。以下の単純な規則に従うことによって、トラブルを防止できます。
  • テンプレートで命名規則を使用します。
  • 実働テンプレートをテスト・テンプレートや開発テンプレートから隔離します。
  • テンプレートやアプリケーションを管理するためのツールの使用を検討します。
  • 変更管理システムを使ってアプリケーション環境を管理します。
  • テンプレートから更新するプロパティーと更新しないプロパティーを区別できるようにしておきます。
  • 設計テンプレートをバックアップします(いつ元のコピーが必要にならないとも限りません)。
  • 変更は既存の設計要素に対して行い、要素をコピーして元の要素を削除するのは避けます。
 
上に戻る
 
シングル・コピー・テンプレート
Lotus Domino 6.0.1には、シングル・コピー・テンプレート(SCT)という新しい機能が実装されています。この機能を使用すると、1つのデータベースの設計要素を複数のデータベースで共有することができます。たとえば、Lotus Dominoの典型的な構成では、各ユーザーのメール・データベースに、メール・データと共にすべての設計要素が含まれています。これらの設計要素によって追加されるスペースは、7〜11MBに及びます(Lotus Dominoのリリースによって異なる)。SCTは、すべてのメール・データベースの設計要素を1つのデータベースにリンクさせることによって、これを変えます。

たとえば、StdR6Mailテンプレートを使ってメール・データベースを作成したとします。以下の図は、何も文書が含まれていないときのこのメール・データベースのサイズを示しています。




SCTによるスペースの節約を最大限に活用するには、まず最初にデータベースを圧縮する必要があります。下の図は、このメール・データベースをSCT対応のメール・データベースに変換した後のサイズを示しています。変換後は、データベース自体のサイズは元の12MBのままであるにもかかわらず、使用されているスペースはそのうちの11.5パーセントだけです。




このデータベースを圧縮すると、そのサイズは約1.3MBまで縮小します。これにより、10.7MBのディスク・スペースを節約できます。

04/28/2003 09:53:43 AM Compacting mail\admin.nsf (Admin)
04/28/2003 09:54:02 AM Compacted mail\admin.nsf, 10752K bytes recovered (87%)

これにドメインのメール・ファイルの数を掛けると、SCTによってどれ程のディスク・スペースが節約されるのかがわかります。

メール・データベース(またはその他のデータベース)でSCTの使用を有効にするには、以下の手順に従って操作します。
  1. 現在のメール・テンプレートのコピーを作成し、そのコピーに新しい名前を付けます(mail6sct.ntfやinotes60sct.ntfなど)。これが「特殊な」テンプレートであることがわかるように、データベースのタイトルも変更しておくとよいでしょう。たとえば、ファイル名とデータベース・タイトルの両方に「SCT」を付けるとわかりやすくなります。
  2. [データベース]プロパティー・ボックスを開き、[シングルコピーテンプレート]オプションを選択して、このテンプレートをシングル・コピー・テンプレートとして有効にします。
  3. ターゲット・データベースの設計を、この新しいテンプレートを使用するように修正します。そのためには、Convertサーバー・タスクを使用するか、[ファイル] - [データベース] - [再設計]を選択します。次のConvertステートメントは、mailサブディレクトリーの下にあるメール・データベースの設計を更新します。

    >load convert mail\*.nsf StdR6Mail mail6sct.ntf
    04/28/2003 10:01:59 AM Mail Conversion Utility starting
    04/28/2003 10:02:29 AM Mail Convert: Started replacing design template 'StdR6Mail' with 'StdR6MailSCT' in 'mail\admin.nsf'
    04/28/2003 10:03:00 AM Mail Convert: Finished replacing design template in 'mail\admin.nsf'
    04/28/2003 10:03:00 AM Mail Conversion Utility shutdown
  4. 4. サーバー・コンソールでDesignタスクを実行します。これにより、メール・データベースから設計要素が削除され、シングル・コピー・テンプレートへのポインターに置き換えられます。

    >load design
    04/28/2003 10:04:05 AM Database Designer started
    04/28/2003 10:04:30 PM Database Designer shutdown
  5. データベースを圧縮して余分な空白文字を削除します。
 
上に戻る
 
シームレス・メール・アップグレード
Notes/Domino 6でアップグレードされたもう1つの重要なテンプレート機能が、シームレスなメール・アップグレードです。この機能を使用すると、デスクトップ・ポリシーを定義することによって、サイト全体にわたるメール・データベース・テンプレートの基準を定義することができます。ユーザーがこの基準を外れてサーバーにアクセスすると、Notes/Domino 6がその問題を自動的に修正します(R5では、そのために多大な労力が必要になります)。ポリシーと設定の作成の詳細については、この記事の範囲を超えているため、ここでは取り上げません。製品マニュアルやヘルプ・データベースを参照してください。

シームレスなメール・アップグレードを行うには、Dominoディレクトリーにデスクトップ設定文書を作成します(または既存のものを修正します)。デスクトップ設定文書で、以下のフィールドをそれぞれの組織に合わせて設定します。



デスクトップ設定文書が完成したら、ポリシーを適用するユーザーを対象とするポリシーを定義します。ユーザーがサーバーにアクセスすると、ユーザーのメール・テンプレートが自動的にアップグレードされます(そのように構成されている場合)。
 
上に戻る
 
テンプレートの実際
以上で、2部構成のNotes/Dominoテンプレートのツアーは終了です。これまでに、テンプレートの基本概念、そのしくみ、および利用法について説明してきました。また、設計情報を取得するためのツールを紹介し、テンプレートのベスト・プラクティスについても取り上げました。これで、「テンプレート技術」の基礎を十分に身に付けることができたはずです。しかし、ここで説明できなかったこともたくさんあります。この後は、サンプルをセットアップして、テンプレートのさまざまな新しい機能やオプションを自分で試してみてください。フィードバックもお待ちしております。



著者について
David Byrdは、米国ジョージア州アトランタ出身の、IBM Software Services for Lotus (ISSL)のコンサルティングITアーキテクトです。C/C++ API開発からアプリケーション、セキュリティー、およびメッセージングのアーキテクチャーに至るまで、ほとんどすべての分野のLotusの製品と技術に通じていますが、エンタープライズレベルのメッセージングとディレクトリーに特に力を入れています。1990年代初めからLotus NotesとDominoに携わっており、Lotus、IBM、Redhat、Microsoft、およびNovellからの多数の認定を取得しています。メール・アドレスは、david_byrd@us.ibm.comです。

Timothy Speedは、IBM Software Services for Lotus (ISSL)のインフラストラクチャー/セキュリティー・アーキテクトです。1992年以降、インターネットおよびメッセージングのセキュリティーに携わってきました。長野オリンピックではDominoインフラストラクチャー・チームに参加し、シドニー・オリンピックでもLotus Notesシステムをサポートしました。彼が取得している認定には、MCSEc、VCA (VeriSign Certified Administrator)、Lotus Domino CLP Principal Administrator、Lotus Domino CLP Principal Developerなどがあります。

また、これまでに4冊の書籍を共同で執筆しています(『The Internet Security Guidebook』(ISBN: 0122374711、2001年2月)、『The Personal Internet Security Guidebook』(ISBN: 0126565619、2001年10月)、『Enterprise Directory and Security Implementation Guide: Designing and Implementing Directories in Your Organization』(ISBN:0121604527)、および『Internet Security: A Jumpstart for Systems Administrators and IT Managers』(ISBN 1555582982))。メール・アドレスは、Tim Speed@us.ibm.comです。
 
上に戻る