はじめに
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が適したケース・適さないケースを次の記事で紹介しています。
こちらも合わせて確認してください。