以前「REST APIを使ってルックアップフィールドの一括更新を行う」で、「ルックアップに関連付けるアプリのルックアップ（コピー）元のキーフィールドの設定が「重複禁止」設定になっている必要がある」というのをご紹介しましたが、ルックアップフィールドに関連するレコード更新について最近また気付きがありましたので、今回続編としてケーススタディ的にお届けしたいと思います！
結論
勿体振らずに結論（と言うより考察）を先に書かせて頂きますと、どうやら次のようになりました。
- – ルックアップ元のアプリのキーフィールドには重複禁止の設定が必要（再掲）
- – ルックアップ元のアプリでルックアップの対象のフィールドが変更された後にしか、ルックアップ先のアプリのコピー対象フィールドは更新されない。ルックアップでコピーされるフィールドへのREST APIによる強制的な更新は不可能ということ（元データが変更されてないのにルックアップ先が更新できるのはおかしいということでしょう）
- – ルックアップ元のフィールドのキーフィールドのみを指定すれば良い（上の前提があれば納得できます）
- – キーフィールド以外の対象フィールドに意図的もしくは誤った値をセットしてAPIリクエストしてもルックアップ元のフィールドの値が反映されて更新される（これもこれまでの前提を見れば納得できます）
手順的に少しまとめ直すと、
- – ルックアップ元のアプリのキーフィールドに重複禁止の設定を行う
- – ルックアップ先にコピーされるフィールドの値を変更する前にルックアップ元のデータを更新する
- – ルックアップのキーフィールドを指定して更新APIをリクエストすることで、ルックアップ先にコピーされるフィールドを更新する
となります。と言っても、文字では変わりにくいので、やはりケーススタディしましょう！
カスタマイズはしたいけれど自分だけではできないという方は、カスタマイズ開発を1週間20万円という定額料金で提供していますので、弊社までお気軽にお問い合わせください。
準備
今回、kintoneアプリストアの「営業支援(SFA)パック」を例にご説明します。
このパックでは、「案件情報」アプリの中で、「顧客情報」アプリから2つのフィールドをコピーしてくるようルックアップが設定されていますので、確認しておきます。
「案件情報」アプリの編集画面も見ておきましょう。
また、説明のためにテンプレートから少し設定を変更しておきます。
- – 「顧客情報（コピー元）」アプリの「会社名」フィールドの設定で「値の重複を禁止する」にチェックを入れます
- – 「案件情報（コピー先）」アプリでルックアップに関連する「顧客名」、「部署名」、「ご担当者名」のフィールドのフィールドコードをそれぞれフィールド名に合わせて変更します
ケーススタディ
ルックアップ元のフィールドの値は変更せずに、APIでルックアップ先アプリの値の更新を試みる
別の言い方をすれば、ルックアップでコピーされるフィールド（ここでは、「ご担当者名」）を、ルックアップ元のフィールドとは異なる値に強制的に更新しようという試みです。
リクエスト自体は、ステータスコード200で、revisionもカウントアップして正常終了しますが、
「案件情報」アプリの「ご担当者」の値は変わらず、変更履歴が刻まれることもなく、華麗にスルーされた感じになります(^^;
ちなみに、「ご担当者」のフィールドだけ指定しても同様です。
また、ルックアップに関係ないフィールドを一緒に更新しても、ルックアップに関連するフィールドがリクエスト通りに強引に更新されるといったことはなく、ルックアップ関連以外で更新しようとしたフィールドのみ更新されます。
ルックアップ元のフィールドの値を変更してAPIリクエストしてみる（お試し）
まず、ルックアップ元である「顧客情報」アプリのフィールドのうち「部署名」、「担当者名」両方変更してみます。
そして、キーフィールドと、試しに「ご担当者」フィールドを指定して更新リクエストしてみます。ここで「ご担当者」フィールドには「顧客情報」アプリで変更した値とは異なる値を指定（姓名間にスペース有）しています。
リクエストは、revisionが3が返り正常終了です。「案件情報」アプリを見てみると、
まず、「ご担当者名」フィールドは、リクエストで指定した値ではなく「顧客情報」アプリでの変更を反映しています。また、「部署名」については、リクエストで指定しませんでしたが、やはり「顧客情報」アプリでの変更を反映しています。右の変更履歴もrevision3で、「顧客情報」アプリでの変更を反映していることを刻んでいます。
ここで気付きます！
- – ルックアップ元のフィールドが変更されて初めて、ルックアップする側のアプリの更新も可能になる
- – また、その更新内容はルックアップ元の変更内容を反映するもので、強制的な変更リクエストは受け付けられないということ
- – そして、そうなると更新のために指定するフィールドはルックアップのキーフィールドさえ押さえておけば良いということになると！
以上のように推察できますが、最終確認です。
ルックアップ元のフィールドの値を変更してAPIリクエストしてみる（確認）
再度、ルックアップ元である「顧客情報」アプリのフィールドのうち「部署名」、「担当者名」両方変更してみます。
そして、キーフィールドを指定して更新リクエストをかけます。
リクエストは、revisionが4が返り正常終了です。もう分かり切っている感が否めませんが「案件情報」アプリを確認すると、
やはり、「顧客情報」アプリの変更内容をもって更新されたことがわかります。
結論（再掲）
結論を再掲します。
- – ルックアップ元のアプリのキーフィールドに重複禁止の設定を行う
- – ルックアップ先にコピーされるフィールドの値を変更する前にルックアップ元のデータを更新する
- – ルックアップのキーフィールドを指定して更新APIをリクエストすることで、ルックアップ先にコピーされるフィールドを更新する
やってみると当たり前といえば当たり前の結論ですが、いざゼロからやろうとすると逡巡しそうなものです。ルックアップ関連のレコード更新時の参考にしていただければ幸いです！
おまけ
ルックアップ更新するには、kintone JavaScript APIを用いてルックアップ元のアプリでレコードが編集されたタイミング（保存イベント）でルックアップ先の対象レコードを更新すればいけると発想しそうなのですが、 実はこの方法には現時点では弱点があります。ルックアップ先のレコードが編集中の時には排他がかかっているので、その最中に更新をかけようとするとエラーが返ってきます。これは確率的な話になりますが、ルックアップ先のアプリのレコードを編集する頻度が少なければ顕在化しませんが、頻度が高めの時に顕在化してきます。更新を安全に処理するためには、ルックアップ先のレコードに留意した処理が必要ですので、参考にして頂ければと思います。
