はじめに
kintone で在庫管理システムや予約申請システムを構築する場合は、複数人での同時操作の考慮が必要です。
また、複数アプリを用いたデータ管理が必要な場合はデータの不整合を防ぐ必要があります。
これらの考慮ができないと、在庫数以上の注文を受け付けてしまったり、予約が重複してしまうなどの問題が発生します。
このような問題へ対応するために、複数アプリのレコード操作を一括処理する「 bulkRequest」が用意されています。
本記事では、bulkRequest を利用してデータの整合性をとる方法を紹介します。
起こりうる問題
どういったことが起こるのか、在庫管理を例に紹介します。
「在庫」アプリと「入出庫」アプリがあるとします。
「在庫」アプリには、商品ごとに現在の在庫数が管理されており、「入出庫」アプリには、入庫処理、出庫処理の情報が登録されます。
在庫数増減時の競合
たとえば、A という商品が 10 個あったとします。
A に対して、次のように操作すると、A の在庫数は 7 個です。
- 山田さんが 5 個入庫する。
- 鈴木さんが 8 個出庫する。
ところが、次のように山田さんと鈴木さんが同時に操作したケースを考えてみます。
- 山田さんが在庫数を確認する。 → 10 個
- 鈴木さんが在庫数を確認する。 → 10 個
- 山田さんが在庫数を 5 増やす。 → 15 個
- 鈴木さんが在庫数を 8 減らす。 → 2 個
山田さんが 5 個増やしているにもかかわらず、最終的な在庫数が 2 個になってしまいます。
ロールバックできない
入出庫では次の 2 つの操作が必要になります。
- 「入出庫」アプリに登録する。
- 「在庫」アプリの在庫数を更新する。
このとき、いずれかのリクエストがエラーになってしまった場合は入出庫アプリと在庫アプリとの整合性がとれなくなります。
問題への対応
これらの問題へ対応するために、 bulkRequest を利用します。
在庫数の取得
下準備として在庫アプリから在庫数を取得します。
|
|
このとき、$revision というプロパティも取得できます。
|
|
$revision の値はレコードが更新されるたびにインクリメントされます。
レコード更新のリクエストに revision を指定することで、レコードが他のユーザーによって更新されていた場合はリクエストをエラーにできます。
入出庫アプリへの登録と在庫アプリの更新を同時実行
次に bulkRequest を使って入出庫アプリへの登録と在庫アプリの更新を同時に実行します。
|
|
bulkRequest ではいずれかの処理が失敗した場合、すべてのリクエストがロールバックされます。
|
|
このとき、在庫アプリの更新リクエストに revision を指定していることに注目してください。
revision には在庫数を取得したときの $revision と同じ値を設定します。
在庫アプリのレコードが他のユーザーによって更新されていた場合は、在庫アプリの更新がエラーになり、入出庫アプリへの登録もロールバックされます。
おわりに
本記事では bulkRequest と revision を利用してデータの整合性をとる方法を紹介しました。
この方法を利用すれば在庫管理システムや予約申請システムを構築できます。
しかしながら、同じレコードの更新頻度が高い場合、リクエストはエラーになる可能性が高まるため、kintone で構築するかどうかは慎重に検討することをおすすめします。
在庫管理を例に kintone で構築するメリットや kintone が適したケース・適さないケースを次の記事で紹介しています。
こちらも合わせて確認してください。