Read Article

ルックアップコピー元が更新されてもコピー先が更新されない

ルックアップコピー元が更新されてもコピー先が更新されない

こんにちは!
趣味が漢字の武井です!
趣味が漢字の人に会ったことがありません!
(早くもブログでの難読漢字禁止令が発布されました!)

さて、前回ルックアップ改善案を提案しましたが、まだまだルックアップの闇はこの程度ではありません。

シリーズでお伝えする「kintoneルックアップ改善案」。

――届けこの想い。日本橋へ――

その第2回である今回は、
「ルックアップコピー元レコードが更新されているのに、コピー先レコードの情報がそのまま」問題です。

前回記事はこちら→kintoneのルックアップでは自動「クリア」ができない

問題詳説

例えば、「従業員マスタ」というkintoneアプリがあるとします。
また、それをルックアップ参照する「給与」というアプリがあります。

「従業員マスタ」アプリには[ID][氏名]というフィールドがあり、
「給与」アプリには[ID(ルックアップ参照)][氏名(ルックアップコピー参照)][日付][給与]という4フィールドがあります。

今、「従業員マスタ」アプリは以下のようになっています。201607131536

今月、国親さんにお給料が支払われることになりました。
そこで、「給与」アプリにレコードを作成しました。

201607131542

ここまではよかった。

レコード作成後、漢字にこだわる国親さんから「俺の名前を旧字体にしろ」という要請がありました。
従って「従業員マスタ」のレコードを以下のように対応しました。

201607131552

しかし、「給与」アプリを見てみると、
なんと先ほど更新した氏名が新字体のまま!更新されていない!

201607131606

さらに、「従業員マスタ」アプリのIDを以下のように更新します。

201607131617

「給与」アプリのレコードの「ルックアップ取得」ボタンを押してみると……

201607131619

なんてこった。

ついには取得すらできなくなってしまいました。

何が問題なの?

とはいえ、自動でコピー先も更新されるというのは、一長一短あるとは思います。
参照整合性なしが総合的によろしいという立場でこのようになっている可能性もあります。

しかし、今まで携わってきたkintoneシステム開発案件の中で、コピー先が自動更新されないと想定していた顧客は皆無、0パーセントでした。

逆に言うと、私が携わる案件では百発百中で本問題にぶち当たるのです。

また、カスタマイズで、編集画面を開いた時にlookup = true(ルックアップの自動取得)を行っているケースもままあると思います。

その場合、ユーザーは「データがありません。」というエラーをいきなり見せられることとなり、戸惑うこと請け合いです。

その他、問題点をまとめると以下の通りであると考えています。

  • 一般的な想定と異なる挙動であるために、開発時に余計な手間がかかる
  • はなはだしく悪いUX
  • 考え方によってはデータに齟齬が発生しているともいえる
  • システムに齟齬が発生する(上記でいうと、「氏名」をキーにして何かの処理をする場合など)
  • わざわざ参照整合性を低下させているにもかかわらず、結局デプロイ時などはこのルックアップが手かせ足かせになる

どう解決するか?

今まで私が本問題を解決するに当たって取った手法は大きく2つになります。

1. ASTERIAやDataSpiderといったEAIツールを活用する。

開発工数を低減する意味ではお勧めの手法となります。

基本的には、各EAIツールのスケジューラーを利用し、

定期的にルックアップキーを空更新するだけで済みます。

◎メリット  お手軽に本問題に対処できる。

×デメリット EAIツールに慣れていないと結局工数もかかるかも。
        ・ツールは新規導入だと数百万円かかる。
        ・(やり方次第ではあるが)APIを大量にコールしてしまう。
        ・(この問題にかかわらずだが)定期メンテナンスなどでバッチ処理が失敗するリスクが新たに発生してしまう。
        ・ルックアップのキーも変更される可能性があるシステムの場合、相当厳しいと思われる。
        ・更新者/更新日時はバッチ処理実行者/実行時間に変更されてしまう。

2. JavaScriptで頑張る。

現状で最もスタンダードな手法かと思います。

要は、kintoneでゆるゆるの参照整合性をJavaScriptで疑似的に再現するものになります。

概ね以下のような態様になるのではないでしょうか。

上記例でのサンプルコードと併せて例示します。

●ルックアップ参照先(コピー元)アプリのレコード保存時イベントで、ルックアップ参照元(コピー先)アプリの紐づくレコードを更新する。

「従業員マスタ」アプリ:[ID]フィールドコード→「id」・[氏名]フィールドコード→「name」
「給与」アプリ:[ID]フィールドコード→「id」・[氏名]フィールドコード→「name」・アプリID→「1402」

以上のコードで、「従業員マスタ」アプリから編集保存すると……

■従業員マスタ

201607131911

■給与

201607131901

国親さんのID・氏名だけを一括で更新することができました!!!

◎メリット  対処できる範囲が広い。(ルックアップキーも対応できる)

×デメリット システムが複雑な分だけ工数がかかる。
        ・更新対象が多すぎるとオーバーヘッドが大きくなる。
        ・コピー元とコピー先でアクセス権限が異なると無理な場合が出てくる。
        ・コピー先の更新者/更新日時はコピー元の更新者/更新時間に変更されてしまう。

◆まとめ

ルックアップのキーは極力変更されないように予めよく設計しましょう。

(コピーフィールドだけなら何とかしやすい)

キーが名称とかだと、苦労しますよ。

【更新】関連記事はこちら→ルックアップフィールドの値変更時イベントにフックできない

この記事を書いた人

武井 琢治
武井 琢治
サイボウズスタートアップス株式会社の武井と申します。
kintoneカスタマイズを行う上での勘所を敷衍して発信していきたいと考えております。
kintoneは中国語対応しているため、中国語でも発信していきたいと思います。
大家好,我叫QB,请多关照。我喜欢吃肠粉。

趣味は漢字です。
所持する資格は、日本漢字能力検定一級です。
URL :
TRACKBACK URL :

COMMENTS & TRACKBACKS

  • Comments ( 2 )
  • Trackbacks ( 0 )
  1. こちらの記事を元に自社開発を行っています。
    同じ環境でJSEdit for kintoneを使い再現しているのですが動きません。。。
    フィールドに「値の重複を禁止する」をなどはしているつもりですが
    他に設定する箇所がありましたらご教授いただけると幸いです。

    • koyayamさん

      JSEditが悪さをしているかどうかはちょっと私の作ったものではないのでわかりませんが、
      他にそれぞれの環境で変更しなければならない箇所としては、

      ・JS内のアプリID
      ・JS内のフィールドコード

      くらいしかないと思います。

      または、別のJSやプラグインを実装している場合、
      処理が競合して動かなくなっている可能性もございます。

LEAVE A REPLY

*
*
* (公開されません)

Return Top