kintone の停電対策を考える

公開日:

更新日:

注意

本記事は情報提供を目的としており、本記事の内容は無保証、サポートの対象外です。
サポート窓口、問合せ窓口にご質問をいただいても対応いたしかねますのでご了承ください。

皆さんこんにちは、築山です。
突然ですが皆さん「kintone の停電対策」していますか?

「な~に言ってんだ築山、kintone のインフラはしっかり対策してるんだぞ!
と思われた方、甘いです!!!

ノートPC で仕事をしている方はいいかもしれませんが、デスクトップPC で仕事をしている方に言いたい。

「真夏にエアコンなど家電の使いすぎでブレーカー落ちたらどうするんですか?」
「落雷で停電が発生したらどうするんですか?」
「編集中に間違えてブラウザの☓押して閉じちゃったらどうするんですか?」

特に3番目。これはノートPCでもありますね(停電じゃないですけどw

これからの時期、暑さに備える必要があります。作業中の不慮の事故を防ぐために、対策を考えてみましょう!

ご紹介する内容は「ムリヤリ」対策した気になる方法です。オススメできません。

「バックアップ」用の連携サービスでは駄目なのか?

kintone の連携サービスでは弊社に gusuku Deploit を含めていくつか「バックアップ」を目的としたサービスがあります。


しかし、これらのサービスは「定期バックアップ」や「画面上でボタンを押した時にバックアップを取得する」ように作られているため、リアルタイムにデータが保存されるものではありません。弊社の gusuku Deploit も同様です。

gusuku Deploit のバックアップ・リストア画面

そのため、作業中に突然何らかの理由によってブラウザが強制的に閉じられた場合には、「前回の保存以降」のデータはすべて消えてしまいます。

今回考えるのは「作業中に突然何らかの理由によってブラウザが強制的に閉じられた場合」を考えたいので、gusuku Deploit などのバックアップ用のサービスでは要件を満たせません。

対策案:勝手にドンドン保存する

では、どうするのか?という話です。

私の考えてみた方法は「勝手にドンドン保存する」です。具体的には、実際に使用するアプリと全く同じ構成のアプリをもう1つ用意しておいて、「書きかけのデータ」をそのアプリに自動的に転記するカスタマイズを作成します。

kintone の JavaScript カスタマイズにおいては、「change」と呼ばれるイベントが発生したときに何らかの処理を行うことが可能です。これは「ユーザーが画面操作にて、そのフィールドの値を変更したとき」を指しています。この「change」のタイミングで別のアプリに転記すれば、「保存」ボタンを押す前にブラウザが閉じてしまってもデータを復旧させることができます。

※gusuku Customine(以降カスタマイン)においては、「条件:フィールドの値を編集して値が変わった時」が JavaScript の「change」と同等のものとなります。

では、これを踏まえてカスタマインを使って「ユーザーが画面操作にて、そのフィールドを変更した」タイミングでどんどん他のアプリに転記するカスタマイズを作ってみます。

簡易的に作ったアプリ構成はこんな感じです。


「更新用キー」はユーザーが入力するフィールドではなく、転記時のキーとなるフィールドなので自動採番によって値が入るようにしています。プレフィックス(接頭辞)に入っている「2703」はアプリIDです。あまり意味はありません。

そして、カスタマイズはカスタマインを使用して以下のように作ります。


アクション1,2は自動採番のためのカスタマイズ、転記するカスタマイズはアクション3です。


「条件」に記載の通り、「フィールドの値を編集して値が変わった時」を契機として、「レコードを更新する(キーの値を直接指定)」が動いて転記しています。

これであれば、フィールドの値が変わるたびに処理が動くので、不慮の事故によって保存前にブラウザが閉じられてしまっても復旧することができます。

注意点

上記のカスタマイズでは「添付ファイル」や「テーブル」を考慮していません。

この記事では詳しくは触れませんが、テーブルも同様に転記したいのであれば「やること:テーブル行をレコードとして取得する」などを使用するとほぼほぼ解決できます。


ただ、「添付ファイル」については kintone の特性上リアルタイムに保存することは難しいと考えていただくのが良いと思います。

重要なポイント

では、「添付ファイル」が無ければ実用的か?というと、知っておいていただきたい大きなポイントがあります。

それは、このカスタマイズはめちゃくちゃ API リクエスト数を消費する、という点です。

具体的には「フィールドの値を編集して値が変わった時」(kintone の JavaScript イベントの「change」)が発生するたびに「転記先」アプリにレコード更新を行うこととなります。そのため、フィールド数が多いアプリであったり、頻繁に多くの人がレコードの登録・編集をするアプリで使用するとあっという間に API リクエスト数が 10,000(スタンダードコースの上限値)を越えてしまうと思います。

まとめ

、、、ということで、個人的には今回の結論は「やめた方が良い」です。

「保存ボタンを押さなくても自動で保存してほしい」というのはお客さまからたまにご相談いただくのですが、色々課題があってなかなか対策が難しいんですよね。今回挑戦した方法では上手くいかなかったので、また他の方法を思いついたらチャレンジしてみたいと思います。

ショートカットキー(保存:Ctrl+s、編集:e)を駆使して頻繁に保存するなど、工夫して対策いただくのが良いと思います。

投稿者プロフィール

アバター画像
築山 春木
gusuku シリーズのエンドユーザー様への提案・パートナー様への支援をメインに活動しています