kintoneで別アプリのテーブルを更新したいときは、どのレコードの、どの明細行を変更するかを分けて決めます。アプリ間更新・登録プラグインでは、レコードのキーで対象を探し、テーブルの行キーで一致する明細を更新できます。元にない行は削除しません。
この記事では、既存レコードの明細を「一致する行は更新し、新しい行は追加する」設定を扱います。通常項目だけを反映する商談フェーズの連携例とは分けて、行キー・再実行・削除の扱いを確認します。項目名と値は説明用の例で、導入効果を測定した事例ではありません。
標準機能とプラグインの役割を確認する
別アプリの情報を表示したいだけなら、関連レコード一覧などの標準機能を先に検討します。別アプリから明細を入力画面へ取り込む目的なら、テーブルルックアッププラグインが候補です。ただし、取り込み先の既存明細を置き換える動きと、保存した値を別アプリの既存行へ反映する動きは異なります。
今回は、入力した明細を別アプリへ書き込み、そのアプリ側の既存行や手入力列も残す設計です。アプリ間更新・登録プラグインを、値を送る元アプリに追加します。連携先アプリに同じプラグインを追加する必要はありません。
レコードのキーと、テーブルの行キーを分ける
レコードのキーは「案件コード」、行キーは「明細キー」とする例で考えます。両アプリの案件コードが一致したら、そのレコード内で同じ明細キーの行を探します。
| 照合する単位 | 項目の例 | 決めること |
|---|---|---|
| レコード | テーブル外の案件コード | 連携先のどの案件へ反映するか |
| テーブルの行 | テーブル内の明細キー | 案件のどの明細行を更新するか |
商品コードと明細キーは、必ずしも同じではありません。同じ商品が2行に分かれる業務では、商品コードだけでは行を区別できません。並べ替えても変わらず、同じテーブル内で重複しない明細キーを用意します。表示上の行番号をキーにして、並べ替えのたびに振り直す設計も避けます。
元の行キーは空欄・重複不可です。連携先の重複キーも処理を中止する原因になります。連携先の空欄キー行は残りますが、一致する行としては使いません。
別アプリのテーブルを更新する3つの処理
| 行の処理 | 一致する行 | 一致しない元の行 | 再実行時の注意 |
|---|---|---|---|
| 行キーで更新・なければ追加 | 対応付けた列を更新 | 末尾に追加 | 同じ行キーを保つことが前提 |
| 行キーで更新のみ | 対応付けた列を更新 | 追加しない | 新規レコードには既存行がないため、行をコピーしない |
| 元テーブルの全行を追加 | 一致判定をしない | 実行のたびに末尾へ追加 | 同じ内容を再実行すると、同じ行が増える |
履歴として毎回追加する用途と、同じ明細を最新の数量へ直す用途では選ぶ処理が違います。「どれを選んでも同じ結果になる」と考えず、再実行したときに期待する動きから選びましょう。
行キーで更新・なければ追加する設定手順
- 元アプリと連携先アプリに、テーブル外の案件コードと、テーブル内の明細キー・数量を用意します。連携先に手入力の備考を残す場合は、その列も用意します。
- 元アプリのプラグイン設定で連携先アプリを選びます。既存案件だけへ反映する例では、レコードの処理を［更新する］にします。
- 元キーと連携先キーに、それぞれ案件コードを指定します。レコード単位で一致する対象が1件になるように管理してください。一致するレコードがない場合、［更新する］では新規登録せず、処理なしとなります。
- テーブルの対応付けを追加し、元・連携先のテーブルを選びます。行の処理を［行キーで更新・なければ追加］にし、両テーブルの明細キーを行キーへ指定します。
- コピーする列に数量を対応付けます。連携先の備考を残す例では、備考をコピー対象に含めません。実際のフィールドコードと型が対応しているかも確認します。
- 初めは詳細画面の実行ボタンで検証できるようにし、設定を保存してアプリを更新します。保存後の自動実行を有効にする場合は、どの保存操作で実行されるかを別に確認します。
レコードの処理と、テーブル行の処理は別の設定です。［更新する］で連携先レコードの新規作成を止めても、行の処理を［更新・なければ追加］にすれば、既存レコードのテーブルへ新しい行を追加できます。
完成結果を、少ない明細で見比べる
連携先には「D-001：数量1、備考は確認済み」と「D-099：数量5」の2行があるとします。元には「D-001：数量3」と「D-002：数量2」を用意します。
| 連携先の明細キー | 実行後に期待する結果 |
|---|---|
| D-001 | 既存行の数量が3へ変わる。コピー対象外の備考は残る。 |
| D-099 | 元にない既存行も削除されず、数量5のまま残る。 |
| D-002 | 新しい行として末尾へ追加され、数量2になる。 |
これは仕様に基づく確認例です。実際のアプリで実測した結果ではありません。連携先に必須項目がある場合は、新しい行を追加するときにも、対応付けや初期値で条件を満たす必要があります。
削除・行キー変更・空欄は別に確認する
- 元の行を削除しても、連携先の行は削除されません。削除を伝える必要があるなら、削除対象をどう管理するかを別に決めます。
- 行キーを変えても、以前のキーの行は残ります。新しいキーで一致する行がなければ追加されるため、同じ業務の明細が2行に分かれることがあります。
- 対応付けた列は空欄もコピーします。数量や文字列を空欄で送る場合の結果と、連携先の必須条件を確認してください。
- 対応付けていない列は、既存行では変更しません。コピー先の備考などを保持したい場合は、対応付けの範囲を絞ります。
REST APIでテーブルを更新する際の行IDの扱いは、公式のテーブル更新の解説でも確認できます。このプラグインは既存行のIDを保持し、対象列と新規行をまとめて更新する設計です。
再実行と失敗時は、連携先を確認してから進める
元レコードの保存と、連携先の更新は別処理です。連携が失敗しても元レコードは保存済みで、複数設定の成功済み処理は取り消されません。書き込みは自動再試行しないため、結果メッセージと連携先の実データを確認します。
特に全行追加では、通信切断後に結果が分からないまま再実行すると、同じ行が増える可能性があります。更新・追加の方式でも、別の利用者の更新や行キーの変更があれば、単純に同じ結果になるとは限りません。
利用者の閲覧・編集権限、対象列の型、キーの空欄・重複を確認し、まず少数のテスト用レコードで実行してください。CSV取込・外部API・一覧のインライン編集は実行のきっかけになりません。モバイルで使う場合も、設定を有効にしたうえで実際の端末で確認します。
自社の明細に合う反映方法を選ぶ
別アプリのテーブルを更新する前に、レコードのキー、行キー、コピーする列、削除しない行、再実行の担当者を決めましょう。無料利用時は、有償プランの案内バナーが表示されます。現在の仕様・利用条件・配布ZIPは詳細ページをご確認ください。
行キーの設計や、既存明細を残す範囲に迷う場合は、元・連携先の項目と期待する完成結果を整理してご相談ください。