元号変更はあなたのノーツシステムに影響するのか?

天皇陛下の退位が閣議決定で 2019 年 4 月 30 日と正式に決まりました。生前退位ということで、新しい元号は退位される前に(恐らく来年中)に発表されるものと思われます。今回元号が切り替わるタイミングが事前にわかり、それに関連してだと思いますが、あるお客様から Teamstudio のツールで日付フィールドの特定の設定を簡単に洗い出せないかという趣旨のお問い合わせをいただきました。

「日付」に関する問題といえば、「2000年問題」を真っ先に思い受けべますが、それ以降、ほぼすべてのITシステムでは西暦でシステムが運用されているものだと勝手に思っていました。しかしながら、公共性の高いお客様の一部には和暦を使用したシステム運用をされているところもあるようです。お問い合わせをいただくまで正直私自身もノーツにこんな設定があるなんて思ってもいませんでしたのでこのブログであらためて皆様にもご紹介したいと思います。

話が少し外れましたが、これから起こりうる元号の変更に関するノーツ・ドミノ上の問題は非常に限定的なものです。なぜならノーツのシステム内部では日付は西暦で管理されており、表示上の問題だけで、2000 年問題のように年が 2 桁しか持っていないという致命的なシステム上の問題とは違います。ほとんどのノーツ利用企業にはあまり関係がないと話題かもしれませんが、社内で関係者と一度協議、確認してみてはどうでしょうか?万に一つでも和暦で表示をしている可能性(エンドユーザーが作成したアプリケーションがどうなっているのかわからないとか)がある場合には念のために一度調査されてはどうでしょうか。

ノーツの日付フィールドおよびビューの列のプロパティの設定

まず下のスクリーンショットをご覧ください。

フィールドの種類を「日付/時刻」型にし、「表示」セクションのユーザープリファレンスを「カスタム」し、年のオプションを「yy」や「yyyy」以外の設定し和暦表示させることができます。

和暦表示させるためのパラメーターは以下のものがあります。

  • ge
  • gee
  • gge
  • ggee
  • ggge
  • gggee

表示されるものはこのような形です。

入力は西暦でも表示時には自動的に和暦に現れます。試しに入力も和暦でできるみたいです。もちろん入力した元号と年の整合性の初歩的(完璧ではありません)なチェックもされます。

ではこのような日付フィールドやビューの日付表示列を探すにはどうするか?

ノーツバージョン間のアップグレード非互換チェックで多くのお客様に支持されている Analyzer の監査機能を使用します。設計のプロパティに合わせ、その条件に合致する設計をレポートする機能です。

Analyzer の監査機能を使用する

Analyzer フィルタデータベースの作成

Analyzer と一緒にインストールされているフィルターデータベース用のテンプレートから新規のデータベースを作成します。
データベースを作成するとすでにいくつかのフィルターが用意されていますが、今回は一旦すべてのフィルターを削除しておくことにします。

では、和暦表示するフィールドとビューの列を調査するフィルターを作成していきましょう。今回作成するフィルターは以下のようにフィールド用、ビューの列用それぞれ6個の合計12個です。

フィルター文書の作成と条件の指定

「新規フィルタの作成」ボタンを押し、フィルタ文書を開きます。フィルターの名前、重大度、クラスはみなさんの任意で文言や内容をまず入力または指定をしてください。
ここから大事なところですが、まず「適用設計要素」に「フィールド」を指定します。
「査定対象」は「プロパティ」となり、プロパティのダイアログボックスから「年の形式オプション」を指定します。プロパティの数が非常に多いので探すのが大変ですが、指定したプロパティが正しいかどうかは「現在の式」で表示される条件式に出てくるフィールド名で確認してください。ここでは、年の形式オプションは ffltYear になります。余談ですが、フィールドの年の形式オプションもビュー列の年の形式オプションも Analyzerの分析結果では ffltYear というフィールドに設定内容が出力されます。
査定対象のプロパティを指定できたので、次に「オペレーション」で条件を作成していきます。
ここでは次の値を含むものとして、キーワードを指定します。
しかし、ダイアログで表示されるキーワードは yyyy と yy だけでそのままでは gge などのプロパティが指定できません。
でも安心してください。一旦ここで yyyy を仮に指定しておきます。
そして「条件の追加」ボタンを必ず押してください。


「条件の追加」ボタンを押すと、下の方に「検証式」と「検証テキスト」に何か追加されたのを確認してください。

検証式には

@IsMember("yyyy"; ffltYear)

が追加されたと思います。

因みに Analyzer 監査機能で一番核となる部分が「適用設計要素」とこの「検証式」のふたつです。
この「検証式」にはノーツ式やTMSxxxxで始まるTeamstudio独自の関数を使用することができます。

「検証式」にある "yyyy" を "gge" にマニュアルで変更すれば完成です。
「検証テキスト」は機能的には何も役割を果たしません。人が見て確認したりする単なるメモ書き程度のものをお考えください。ブランクでも構いません。

修正したらこのフィルター文書を保存して閉じます。

このようにして 6種類の年の形式オプションをフィールド用とビュー列用でそれぞれ作成します。
今回はオプションごとにフィルターをひとつずつ作成しましたが、「検証式」で

@IsMember("ge"; ffltYear) | @IsMember("gee"; ffltYear) | @IsMember("gge"; ffltYear) ......

のようにパイプ記号の「または」という条件付けでフィールド用にひとつ、列用にひとつを作成しても大丈夫です。

Analyzer の監査機能を有効

フィルターが作成完了したら、Analyzer を起動して「監査」タブで「監査を有効にする」にチェックし、今回作成したフィルターデータベースの指定、クラスの指定、レポート出力先のデータベースの指定を行い「OK」ボタンを押しスキャンを開始します。

監査結果の確認

レポートデータベースは分析結果データベースとは違い自動的に表示されませんのでマニュアルで開いて確認してください。

元号への変換をするスクリプトや式など

ここまでは、ノーツの標準の機能で和暦表示するものを追跡してきましたが、オリジナルのスクリプトや式で元号を表示しているロジックがあるかもしれません。
単純にこれは式やスクリプトに対して「平成」や「昭和」といった手がかりになる言葉を探すことで対処できます。
Analyzer のフィルターを作成するとすれば「適用設計要素」には「すべて」を、「プロパティ」には「すべてのコード(式 / スクリプト / JavaScript)」と指定し条件を作成できます。

あるいは Configurator を使って、設計の全文検索をサラッと行ってみても良いのではないかと思います。

まとめ

今回の事象に関しては、Analyzer を中心としたツールがあれば簡単に洗い出しできることがお分かりいただけたと思います。。また、レポートデータベースのエージェント設計には Analyzer をバッチモードで複数のデータベースをスキャンするためのサンプルスクリプトなども用意されており、皆さんでカスタマイズしてサーバー上のデータベース全てをチェックすることも簡単です。カスタマイズする時間もない方は、弊社へご相談ください。複数データベースを一括で処理できる仕組みもサービス・プロダクトもご提供可能です。今回の事象に関わらず、Analyzer の監査機能を使用すれば面倒な調査作業なども簡単にできます。是非ご活用ください。