#タスク のアラート(通知)について

A user requested that we specify the time at which task alert e-mails are to be sent.

I would like to share with you the results of my confirmation regarding this and how we finally handled it.

みなさまこんにちは。
早速ですが、まずは先日の記事と重複しますが告知です。

以下、いずれもノーツコンソーシアム会員に限らず参加可能です。
Dominoの枠に収まらない研究会、情報交換会ですので、ぜひご検討ください。

●2023年6月23日(金) 第二回 大阪研究会
　　詳細は上記リンクよりご確認ください。
　　今回もかなり濃い内容になりそうです。

●2023年7月13日（木) ノーツ新任担当者向けワークショップ（2023年 春開催）
　　ついに東京オンサイト開催!
　　大阪サテライト会場も準備して、皆様のご参加をお待ちしております。

●2023年8月25日(金) ユーザー情報交換会(@京都)
　　第三回大阪研究会、第三回名古屋研究会併催!!
　　終了後は鴨川　川床で懇親会!
　　今一度、対面のよさを見直しましょう!

---

さて今回はユーザーより、ノーツのタスクについて、通知時間を指定してメールを送信したいとの問い合わせが入りましたので、少し調べてみました。

以下がタスクのアラーム通知オプション画面になります。

通知方法をここで細かく説明する必要はないかとは思いますので割愛しますが、この[アラームを鳴らす時]を細かく設定したいということになります。

ここでは、

日にち単位しか設定できません。
〇日後、もしくは〇日前ということになります。

弊社の環境で、そのまま設定した場合、

なぜか 12:01:00 に設定されていました。

ちなみに予定の場合は、

このように「日」だけでなく、「時間」や「分」が設定できました。

そこでいつもながら、サポートへ問い合わせです。
正直なところ、「仕様です」っていう答えのみかなと考えていたのですが、以下のような回答を頂けました。

1. HCL社様環境においてもアラームの通知オプションで特定の日時を選択できないことを確認しております。
2. 「タスク」は日にち単位で作成されるため、開始日と終了日を指定し、アラームの通知設定を期日より前か後の日数のみ指定することができます。
3. 残念ながら、このタスクに特定の日や時間を選択する方法はございません。そのため、ユーザーは特定の日や時間にタスク通知を受け取ることができません。

との事でした。
「ごもっとも」というのが本音です。
ただその後、以下の内容が続けられていました。

お客様のご期待に添うことができず大変申し訳ございませんでした。

タスクのアラームの通知に特定の日や時間を指定するための機能の改善要望が「HCL #dominoforever Product Ideas Portal」サイトに提出されています。
当機能の追加を希望されるお客様は投票（VOTE）をお願いします。

https://domino-ideas.hcltechsw.com/ideas/NTS-I-2372

同じことを考えられている方がいらっしゃるのですね。
もちろん即時VOTEですが、まだ2なんです(汗
もし同じお悩みをお持ちでしたら、ぜひVOTEください!!

インターフェイスは持っているので、実装するのはそれほど難しくなさそうなのですが・・・。

以上を踏まえて、弊社ではタスクとしてではなく、スケジュールとして登録することでユーザーの思う動作を得ることができましたので、解決は解決です。

ちなみに昨日も記事を書きましたが、弊社ではOnTimeを利用しております。
OnTime上ではタスクが表示されないのですが、スケジュールとして登録することで、OnTime上でも確認することができるようになりました。

こちらの凡例として「タスク」というものを設定することで、色分けされますので、これはこれで使いやすい方法と感じております。

お試し頂く価値はあるのではないでしょうか。

ノーツでサーバーの #サービス監視

This time, I applied the logon management app that was created the other day, and tried to finish it as a service monitoring app for the server.

みなさま、こんにちは!!

curl にはまった筆者です。

今回は先日の「ログオン管理」を応用して、サーバーのサービス死活監視を開始致しましたので、その方法を紹介致します。

実は弊社で使用しているとあるサーバーなのですが、かなり負荷が大きいようで、時折サービスが落ちてしまうというものがあるのです。
仮想サーバーですので、リソースが潤沢にあればそちらを割り当ててやればいいのですが、導入から4年半を経過したオンプレのサーバーですので、そうもいかず・・・
ということで、根本解決には至らないのですが、サービスの死活監視を行うというものを作ってみたというのが背景になります。

取り急ぎ監視するサーバーのCドライブにcurlをインストールします。
手順はお手数ですが、先の「ログオン管理」をご確認ください。

次に監視するバッチファイルです。
対象サーバーに以下の記述を行ったバッチファイルを作成します。

その前に対象となるサービスの名前を確認しなければなりません。
対象サーバーのコマンドプロンプトで以下を実行し、名前を確認します。

sc getkeyname **名前**

例えば"DHCP Client"ならば、

sc getkeyname "DHCP Client"

と実行します。
すると以下のような画面が表示され、名前が"Dhcp"であることがわかります。

その名前を利用し、以下内容のバッチファイルを作成します。
申し訳ありません、コマンド内容についてはここでは触れませんので、ご了承ください。

@ECHO OFF  set dt="" FOR /F "USEBACKQ" %%i IN (`sc query ^| findstr /i "名前"`) DO @SET DT=%%i  IF %DT%=="" GOTO error  GOTO end  :error  cd c:\curl\bin  curl -i -H "Content-type: application/json" -X POST -d  "{\"creator\":\"名前\",\"stamp\":\"サーバー名\",\"time\":\"%date% %time%\"}" -u "ノーツユーザー名":ノーツパスワード http://サーバー名/ノーツファイル名.nsf/api/data/documents?form=log  :end

curl部分は、前回作成したバッチファイルをそのまま転用しています。
ノーツアプリケーションもコピーして少し修正して済まそうという魂胆です。
タスクスケジューラーに「名前」のタスクが実行してなければ、error処理が発生し、curl以降が実行されるというものです。

ちなみにノーツアプリケーションのフィールドには、以下内容がセットされることになります。

　creator : サービスの名前
　stamp : サーバーの名前
　time : 日時

あとはタスクスケジューラーに毎日実行するタスクとしてこのバッチファイルを登録しておきます。

続いてノーツアプリケーションです。
先の通り、「ログオン管理」をコピーして使用します。
とは言っても、先のバッチファイル側で制御していますので、コピーするだけで既にerror処理が発生すれば、文書が追加されてきますので、テストしてみてください。

あとはビューやフォームを少しさわるだけで完成しました!!

まずはビューから

すいません、サーバー名とサービス名をぼかしたので、わかりにくいですね(汗

続いてフォームです。

結構、いい感じに仕上がっているかと思います。

それでは文書が新規作成された際に、メールを飛ばすエージェントを追加します。
新規エージェント作成にて、シンプルアクションを使用します。

シンプルアクションでは、「メールメッセージの送信」を選択し、宛先・件名・文面を記述します。
また「メッセージに文書リンクを含む」にチェックしておきます。

最後にトリガーですが、シンプルアクションではイベントでの検知ができない(?)・・・詳しい方、フォローお願いします。
また今回は1日1回9時にバッチファイルを実行するイベントとして設定したため、「一日一回以上」のスケジュールとして、登録しました。

エージェントの実行間隔を23時間とし、有効時間帯を9:30～9:50としましたので、おそらくは、

 9:00 タスク実行・・・サービスが起動していない場合、ノーツデータベースに文書が追加される
 9:30 エージェント実行・・・文書が追加されていた場合、文書リンクのついたメールが送信される⇒次回起動予定は翌8:30ですが、有効時間帯の9:30を待ってエージェントが実行される

というイメージになります。

今回届いたメールは以下のような感じになります。

以上で組み込みは完了となります。

テストは9時前に意図的にタスクを落としてノーツに文書が追加され、メールが発信されるかどうかを2日続けて実施する必要があります。

なお実際の運用では、サービスダウンを検知した際に、該当のサービスを起動する記述をバッチファイルに組み込めば、検知後にサーバーにログインしてサービスを起動するという必要もなくなります。
ただ自動で再起動してしまうと、落ちていたことを知る機会がログを見なければなりませんので、このようなノーツアプリケーションへの連携は効果があると考えます。

また今回は1日1回としましたが、さらに細かく監視したいという場合もあるかと思います。
その場合はタスクスケジューラーに必要間隔で登録し、エージェントの間隔も考慮すれば、ある程度は細かく対応できるようになります。

以上、あまりにも簡単なのですが、まだまだ使い方は増えそうですよね。
また何か思いついたら紹介させて頂きます。