以下の各セクションに記載されているガイダンスを使用して、API 呼び出しのトラブルシューティングを行います。
API 呼び出しが動作しない
以下に示すとおり、Audit History を使用して API の問題をトラブルシューティングします。
- エディタでアプリを開きます。
- [Manage] > [Monitor] に移動し、[Audit History] を開きます。
- [Launch log analyzer] をクリックします。
Audit History のログが表示されます。 Actionの値がREST API invokeである監査レコードを探します。
注: Audit History に監査レコードが表示されるまで、最長で 5 分かかる場合があります。AppSheet は監査レコードをグループ化し、グループ化された監査レコードを定期的に書き込むことで、オーバーヘッドを削減しています。このため、監査レコードが Audit History に表示されるまでに遅延が生じる場合があります。監査レコードが表示されるまで、間隔をおいて [Get audit history records] をクリックしてください。- [Details] アイコンをクリックすると、API 呼び出しの結果が表示されます。
- API 呼び出しが失敗している場合は、その理由が [Details] に示されます。
- 監査レコードの最後に
"Result": "Success"と表示されている場合、API 呼び出しは成功しています。
エラー: キーを含む行が見つからない
Row having key '<キー値>' not found エラーは、指定したキーを含むレコードを更新または削除しようとしたときに、対象のレコードが見つからなかったことを意味します。レコードを除外するセキュリティ フィルタがテーブルに設定されている場合に、このようなエラーが発生する可能性があります。
REST API リクエストは、REST API の UserId プロパティで指定したユーザー ID で実行されます。UserId を指定していない場合、REST API リクエストはアプリオーナーのユーザー ID で実行されます。AppSheet API を呼び出すをご覧ください。
エラー: 値を型に変換できない
Value '<値>' in field '<フィールド名>' cannot be converted to type '<型>' エラーは、フィールド内のデータ値が無効であるか、想定外の形式であることを意味しています。
Date、Time、DateTime、Decimal、Percent、Price のデータ値を検証するときは、Locale プロパティが使用されます。たとえば、Locale が en-US の場合、日付値は MM/DD/YYYY 形式で入力する必要があります。Locale が en-GB の場合、日付値は DD/MM/YYYY 形式で入力する必要があります。Locale を指定していない場合は、Locale en-US が設定されるため、データ値を MM/DD/YYYY 形式で入力する必要があります。
エラー: AppSheet の Webhook アクションの深度制限に達した
AppSheet Webhook action depth reached エラーは、自動化 Webhook が REST API の呼び出しを繰り返し試みていて、再帰呼び出しの深度制限である 5 回に達したことを意味しています。
このエラーは通常、以下のような状況で発生します。
- アプリケーションに Webhook をトリガーする自動化 bot が組み込まれているとします。この Webhook はテーブル内のレコードを追加、更新、削除する REST API を呼び出します。
- 呼び出された REST API は、適切なレコードを追加、更新、削除します。次に、操作対象のレコードに関連付けのあるすべてのイベントをトリガーします。そうしたイベントには、REST API を呼び出す Webhook をトリガーするイベントが含まれる場合があります。それによって、意図したものであるかどうかにかかわらず、呼び出しの再帰が起きる可能性があります。
- Webhook のアクションが REST API の呼び出しで、REST API のアクションが Webhook のトリガーであるとき、REST API の呼び出しと Webhook のトリガーは無限に繰り返され、意図しない再帰が発生します。これは無限再帰の形態です。無限再帰が発生しないようにするための方策として、AppSheet は無限再帰を検出、防止するためのカウンタを保持しています。呼び出し深度制限の 5 回に達すると、
AppSheet Webhook action depth reachedというエラーが表示され、それ以上の再帰が阻止されます。
EnumList フィールド レポートの追加または更新で「Valid_If 条件が失敗した」
EnumList フィールドを含むレコードを追加または更新する場合、その追加 / 更新が次のエラーにより失敗する場合があります。
「Error: Row having key '<キー値>' in table '<テーブル名>' containing value '<EnumList フィールド値>' failed Valid_If condition」
このエラーは、EnumList フィールドが有効な値のリストを含む Valid_If 式を指定している場合に発生します。EnumList フィールドに 2 つ以上の値を含むレコードを保存しようとすると、Valid_If 条件が失敗します。これはサーバーの式システムに長期間存在する欠点に由来するものです。
たとえば、EnumList フィールドに次のような Valid_If 式が指定されているとします。
LIST("A", "B", "C", "D")
システムはこの Valid_If 式を以下の同等な Valid_If 式に自動的に変換します。[_THIS] は現在のフィールド（この場合は EnumList フィールド）の値を指すことに注意してください。
IN([_THIS], LIST("A", "B", "C", "D")
サーバーの式システムは、IN() 式を評価する際に、EnumList フィールドが値の LIST() を含む可能性があることを検出できません。そのため、EnumList フィールドの値を LIST() の各値と比較する 1 つの値として誤って扱ってしまいます。たとえば、EnumList フィールドが "A , C" を含む場合、"A , C" を LIST() 値 "A"、"B"、"C"、"D" と順に比較します。EnumList 値 "A , C" はこれらの値のいずれとも一致しないため、Valid_If 条件は失敗します。
注: Google では、サーバー式システムにおけるこの欠点を修正する方法を調査しています。この作業は思いのほか困難です。というのも、意図している / いないにかかわらずこの動作に依存するお客様の満足を損なわずに、問題を解決する必要があるからです。現時点では EnumList フィールドの Valid_If 式を削除する以外に、この問題を回避するいかなる方法も確認していません。