gusuku Customine カスタマインの歩き方 レコード更新編
3. レコード追加、レコード更新に関する「やること」一挙解説

3-8. 別アプリの情報を元に更新できる「レコードをもとに別のレコードを更新する」

前の記事:3-7. 元になるレコードを指定して、Webhook通知も送信できる「レコードを1つずつ書き出す」

次の記事:3-9. 別アプリの情報を元に更新ないし追加できる「レコードをもとに別のレコードを更新または追加する」


複数のレコードをもとにレコードを更新することに関しては、やること「レコードを書き出す」と同じですが、更新先アプリがもとになるレコードのアプリと別のアプリであっても更新が可能な点が違います。


やること「レコードをもとに別のレコードを更新する」は、やること「レコードを書き出す」に比べると処理時間が長くなりやすく、APIリクエスト数も多くなります。同じアプリに対する更新の場合は、やること「レコードを書き出す」を利用することをおすすめします。


一方、違うアプリに対して更新する場合には、やること「レコードを書き出す」]では実現できませんので、この記事を参考にしてやること「レコードをもとに別のレコードを更新する」を利用してください。


この記事では、「活動履歴」アプリのボタンを押すと、一覧でチェックボックスにチェックしているレコードの案件IDに紐づく「案件管理」アプリの案件状況を、ダイアログで選択した案件状況に一括更新するカスタマイズを作ります。実行例は次のようになります。


アプリ

カスタマイズ例を確かめるためには、2つのアプリを作成します。

※今回動かすのに必要最低限となるフィールドのみ記載しています


活動履歴

※フィールド名とフィールドコードは同じものを指定

フィールド名

フィールドタイプ

備考

案件ID

文字列(1行)



案件管理

※フィールド名とフィールドコードは同じものを指定

フィールド名

フィールドタイプ

備考

案件ID

文字列(1行)


案件状況

ドロップダウン

項目と順番は「受注」「失注」「継続」「クローズ」を設定


カスタマイズ

カスタマイズは「活動履歴」アプリに対して行います。

また、アクションは次のように設定してください。


一覧にチェックボックス列を追加する

やること「一覧にチェックボックス列を追加する」、条件「一覧画面を表示した時」を用います。


ボタンをメニュー位置に配置する

やること「ボタンをメニュー位置に配置する」、条件「他のアクションの実行が完了した時」を用います。


ボタンを押した時に案件状況の選択ダイアログを表示

やること「選択肢から選択するダイアログを表示する」、条件「ボタンを押した時」を用います。


また、パラメータの選択肢は


受注

失注

継続

クローズ


を設定します。


OKが押されたらチェックしたレコードを取得

やること「一覧で選択されたレコードを取得する」、条件「確認・入力ダイアログで「OK」を押した時」を用います。


取得したレコードを元に別のレコードを更新

やること「レコードをもとに別のレコードを更新する」、条件「他のアクションの実行が完了した時」を用います。


「やること」のパラメータの、キーとなる更新先のフィールドと、キーの値となる元になるレコードのフィールドはそれぞれ「案件ID」を設定します。

元になるレコードはやること「一覧で選択されたレコードを取得する」を実行したアクション(今回の例でいうと17番アクション)を指定します。


また、マッピングは次の要領で指定してください。


解説

この記事では「活動履歴」アプリの一覧画面で選択したレコードを元に、「案件管理」アプリを更新するカスタマイズを実現しました。


今回の例では「キーとなる更新先のフィールド」には「案件ID」フィールドを指定しています。一覧で選択した複数レコードの「案件ID」が同じレコードに対して、一括で「案件管理」アプリの「案件状況」フィールドの内容を更新します。


「案件状況」の値は、やること「選択肢から選択するダイアログを表示する」を使って、プルダウン形式で選択しています。


やること「レコードを書き出す」の場合は、元になるレコードと違うアプリに対してレコード更新することができませんでしたが、やること「レコードをもとに別のレコードを更新する」を使うと、それが可能になります。


元になるレコードを指定するために、やること「レコードをもとに別のレコードを更新する」のアクションの前にレコードを取得する[やること](例えば、やること「一覧の条件でレコードを全件取得する」など)を使ったアクションを実行しておく必要があります。



コラム:1件ずつ処理することが適しているケース

やること「レコードをもとに別のレコードを更新する」のアクションでは、1件ずつ更新先のレコードを取得したあとにレコード更新を行っており、処理時間とAPIリクエスト数が多くなりやすいです。

一方でメリットもあり、1件ずつ更新先のレコードを取得することで、下図のようにマッピングで更新先のレコードの値を使うことができます。


たとえば、在庫数の管理をしている「備品管理アプリ」と入出庫数を記入する「入出庫記入アプリ」を例に説明します。以下の例だと、すでに「備品管理アプリ」のA4ノートは 25 個の在庫があります。そのため、入庫があった際には入庫数の5を「備品管理アプリ」に登録するのではなく、すでに在庫数登録している 25個に入庫数の5個を足す必要があります。


やること「レコードをもとに別のレコードを更新する」が実行されると、「製品コード」のフィールド値が同じレコードを「備品管理アプリ」から1つ取得します。取得したレコードの値はマッピングで使うことができるため「更新後の在庫数 = 更新前の在庫数 + 入出庫数」のように、計算結果をレコードに反映するような処理が実現できます。


上図のように「マッピング先アプリ」からフィールドを選ぶと「@out.」がつき、更新先アプリのフィールド値を使用できます。また、下図のように「カスタマイズ対象アプリ」からフィールドを選ぶと「@this.」がフィールドコードの前に付き、カスタマイズ対象アプリのフィールド値を使用できます。




おわりに

この記事では、やること「レコードをもとに別のレコードを更新する」を使った、レコードを元にして別アプリを更新するカスタマイズをご紹介しました。


やること「レコードをもとに別のレコードを更新する」を使えば、予め取得しておいたレコードを元に別のアプリのレコードを更新することができます。


ドキュメントサポートページもぜひご活用ください。

また、ご不明点等ございましたら、チャットにてご質問ください!


gusuku Customine カスタマインの歩き方 レコード更新編
3. レコード追加、レコード更新に関する「やること」一挙解説

3-8. 別アプリの情報を元に更新できる「レコードをもとに別のレコードを更新する」

前の記事:3-7. 元になるレコードを指定して、Webhook通知も送信できる「レコードを1つずつ書き出す」

次の記事:3-9. 別アプリの情報を元に更新ないし追加できる「レコードをもとに別のレコードを更新または追加する」