kintoneAPIによるレコード一括更新処理のエラー発生時の通知方法について

<現在設定している環境>

Aアプリにおいて、顧客コードをルックアップキーにして、Bアプリから顧客情報のルックアップ引用をしています。

Bアプリにおいて、顧客情報の編集が行われた際に、Bアプリの保存ボタン押下をトリガーにして、Aアプリの該当顧客コードのレコードを一括更新(ルックアップ再取得)の処理をしています。

レコード数が多いものでは、同じ顧客コードのAアプリレコード数が1000を超えるため、ルックアップの再取得処理に20分近くかかる場合もあります。

<発生している課題>

Bアプリ編集によるAアプリレコードの一括更新が、途中で止まってしまっている場合があります。具体的には、Aアプリで1700件ある顧客コードの顧客情報をBアプリで修正保存したところ、Aアプリのレコードが500件分しか更新されていませんでした。
(別のタイミングでBアプリの保存を再実行すると、1700件更新されました)

たまたま、JavaScriptによる自動更新処理と、Aアプリ画面上で対象レコードを画面更新する処理とがタイミング的に重なって、排他制御等により処理が止まってしまったのではないか、ということを疑っているのですが、テストで再現することは困難で、明確な原因追究はできていない状況です。

仮に排他制御だとした場合、処理が途中で止まってしまうのは致し方ないのですが、せめて処理が止まってしまったことを認識したいと思っています。
しかし、処理に20分かかるようなものをJavaScriptの機能で画面にエラー通知するのは非現実的ですし、エラー通知の手段について全く思いつかない状況でして、もし何かアイディアや実現方式についてご存じの方がいらっしゃれば、教えていただけると幸いです。

また、そもそものエラーの原因が他にあるのではないか、ということの心当たりがありましたら、そちらに対する指摘をいただけるのでも大変助かります。

よろしくお願いいたします。

 

さかもとさん

コードはこちらを拡張されたものに近いかと思いますが、頻度はどの程度でしょうか。コードとその操作性・運用が問題なく、UIからの更新頻度が高ければ排他は疑われると思います。ここで言う操作性・運用とは、ユーザーが間違って途中で動作を止めてしまうような事象を誘発しうる実装になっていないかというところです。

排他が間違いないとわかったら、必要に応じて夜間バッチやAアプリのレコード表示時に更新するようにして、衝突確率を落とすしかないでしょう。

 

事象の把握としては、原因特定への距離感はあるかもしれませんが、いくつか方法があるかと思います。

  • 監査ログ(左端のiアイコン、CSV出力でリクエスト結果と大まかなエラー種別が見れますので、申告内容と照らし合わせると良いと思います)
  • コンソール(そのケースに居合わせれば、こちらの方法で赤の部分を探るのはそう難しくないと思います)

なお、20分(はかかり過ぎな感じはしますが、)かかるからこそ、また、調査による再現がしにくいからこそ、画面にエラー時のレスポンス(messageやerrorsプロパティ)を伴うアラート表示を設定した方が良いように思います。

 

バックグラウンドな通知として昇華するには、エラー処理の一環として、エラー時に別アプリにエラー内容(リクエスト内容やエラーレスポンス・プロパティ)を登録するのも良い方法だと思います。