AppSheet 定期実行時に更新前後の情報をメールで送信

バッチ処理時に、変更前後の情報をメールで送りたい

オートメーションを定期実行し、データを一括更新する場合、
変更前後のデータをメールで通知したくなったりします。

AppSheet自体は、データの変更前後の状態を直接保持する機能を提供していないため、工夫が必要となります。

例えば、

• 方法1: 変更前のデータを別の列に保存する
• 方法2: Google Apps Scriptとの連携を利用する
• 方法3: オートメーションのステップ内で変数を使用
• 方法4: 一時保存用のログテーブルを使用する

更新前後で確認が必要なデータが１つだけなら、方法1でも良いのですが、列が多くなると厳しくなります。（列が２倍になってしまい、良くわからないテーブルになってしまいます。）

方法2は、それは何でも出来てしまうので、最終手段です。

方法3は、

• BeforeName: [_THISROW_BEFORE].[Name]
• AfterName: [_THISROW_AFTER].[Name]

のように、更新前後の情報を用いるやり方です。

一見、これで解決となりそうなものですが、実は制限があり、トリガーで「データ変更」が選ばれている場合に利用可能です。それ以外のトリガーでは利用できないことがあります。

つまり、今回のような定期実行でのオートメーションでは利用ができません。

残念。

ということで、方法4での実現が必要となります。

一時保存用のログテーブルを使用して、更新前後の情報をメールで送信

今回の業務に登場するテーブルです。

上記のように、最新の「顧客情報」を保持する「Customer」テーブルを、顧客の「変更情報」が格納されている「CustomerUpdate」で更新する処理となります。

先ほど述べたように、バッチ処理で変更前の顧客情報を残しておくために「CustomerUpdateLog」に、変更前の情報を退避します。

• Customer:最新の顧客情報
• CustomerUpdate:顧客の変更情報
• CustomerUpdateLog:顧客の変更情報を適用する前に、変更前の情報を退避

上記により、最終的に送信するメール本文です。

本当は、他にも多くの項目があるのですが、１例として「渡航日(Departure date)」を載せています。

Before updateの「<<[Customer Before Update]>>」がポイントになります。

We will notify you that the information you registered has been updated.

--------------------------------------------------
 - User ID : <<[Email address]>>
--------------------------------------------------
Before update

 - Departure date         :  <<[Customer Before Update].[Departure date]>>

--------------------------------------------------
After update

 - Departure date         :  <<[Departure date]>>

データの退避処理

顧客の変更情報は、CustomerUpdateテーブルに格納されていますので、一連の処理は「CustomerUpdate」の未処理データ(※)をループしながら実行されます。

※「imported」列に「OK/NG」がなければ、未処理データです。

そのため、CustomerUpdateテーブルのレコードを元に、Customerの退避処理を呼び出していきます。

以下の「Customer data backup」ステップで、「Customer」テーブルのデータを「CustomerUpdateLog」テーブルへ退避します。

退避処理は「Run action on rows」で、テーブルのアクションを呼び出します。処理中のデータ「List([_THISROW])」に対して、「Call Customer Backup Action」を実行します。

「Call Customer Backup Action」は、Customerテーブルに対して主キーである顧客メールアドレスが一致するデータに対して、「BackupBeforeUpdate」を呼び出します。

「BackupBeforeUpdate」は、Customerテーブルの現在のデータ（まだ更新されていない顧客情報）を、CustomerUpdateLogテーブルへ追加します。

これで顧客情報の退避ができました。

顧客情報の更新

ここでCustomerUpdateテーブルに以下の仮想データ「Customer Before Update」カラムを作成しておきます。

これにより、CustomerUpdateLogテーブルに退避されている、更新前の顧客情報を紐づけることができます。

INDEX(
  ORDERBY(
    FILTER(
      "CustomerUpdateLog",
      ([Customer ID]=[_THISROW].[Email Address])
    ),
    [_RowNumber],
    TRUE
  ),
  1
)

Customerテーブルの退避が完了したら、CustomerUpdateテーブルの変更情報を、Customerテーブルへ反映します。

更新処理は「Run action on rows」で、テーブルのアクションを呼び出します。処理中のデータ「List([_THISROW])」に対して、「Call Customer Action」を実行します。

「Call Customer Action」は、Customerテーブルに対して主キーである顧客メールアドレスが一致するデータに対して、「UpdateFromUser」を呼び出します。

「UpdateFromUser」アクションでは、CustomerUpdateの変更情報で、Customerテーブルを更新します。

ここでも、退避の時と同じようにCustomerテーブルとCustomerUpdateテーブルを紐づけるために、仮想カラム「Next update data」を作成します。

INDEX(
  Orderby(
    Filter("CustomerUpdate",
      and(
        [Email Address]=[_THISROW].[Customer ID]
        ,isblank([imported])
      )
    ),
    [datetime],True
  )
,1)

これにより、顧客情報を更新すべき変更情報を、CustomerUpdateテーブルから見つけることができます。

変更前後の情報を載せたメール送信

最後にメール送信処理です。

以下のメールテンプレートを用いることで変更前後の顧客情報をメールで送信することができます。

We will notify you that the information you registered has been updated.

--------------------------------------------------
 - User ID : <<[Email address]>>
--------------------------------------------------
Before update

 - Departure date         :  <<[Customer Before Update].[Departure date]>>

--------------------------------------------------
After update

 - Departure date         :  <<[Departure date]>>

まとめ

いかがだったでしょうか？

更新情報をバッチ処理する際に、更新前後の情報をメールなりで送信する必要がある場合に、参考になればと思います。