tomou
1
お世話になります。質問させていただきます。
###・前提条件 ・発生している問題・エラーメッセージ ・実装したい機能
企業によくありがちな伝票入力系の入力画面で複数のテーブルを更新するケースがあると思います。
例えば）
売上入力画面で、「売上テーブル」と「売上明細テーブル」と「在庫テーブル」を登録・更新するようなケースです。
・売上のヘッダデータをINSERT
・売上明細の商品詳細データをINSERT
・対象商品の在庫テーブルの在庫数量をUPDATE（払出としてマイナスする）
です。
こういうケースでは、よくあるシステムではトランザクション処理として不整合にならないように３つのテーブルはすべて登録・更新OKかもしエラーが発生した場合にはすべてNGにするか（元に戻す）
がRDBであるとおもいますが、Bubbleで作成する場合はこのあたりどういう実装にするのが一般的なのでしょうか。
Bubbleで試してみたり、Web記事などいろいろ調べたりもしたのですが、わかりませんでした。
お分かりになるかたアドバイスいただけますと幸いです。
スクリーンショット
*できれば、全体が分かるようにスクリーンショットを載せてもらえれば助かります。
試したこと
*ここに問題に対して試したことを記載してください。
同じようなテーブル設計で、ちょっとBubble用に、売上のカラムに売上明細型をおいたり、売上明細のカラムに商品型をおいたりして、一括で更新処理をworkflowで書けたりするのか試してみましたがダメでした。
補足情報 （調べたURL/参考になりそうな事例）
この操作はBubbleであまり想定されていないケースかもしれません。
DB操作に対して特定の条件時にロールバックする操作がそもそもできないと思います。
実装としては経理データのような形でトランザクションデータを全て記録するテーブルを用意
トランザクションデータとマスタ側の数値比較で処理してOKな場合のみ更新
更新時に他に更新処理がないことを担保するために、処理中であることを示すフラグデータを別テーブルで管理し、処理完了後に消去するや追記するなどで対応する必要もありそうです。
このあたりはBackendWorkflowに処理を作ってしまい、フロントからは呼び出しのみなどにする形になりそう。
参考になれば・・・
「いいね！」 2
tomou
3
yukikunさん
ご回答ありがとうございます。
やはりこのたぐいはなかなか難しいのですね。
よくあるシステムの正規化して伝票入力系みたいなものを処理するのは難しいのですね。
このあたりができれば、業務系のシステムだいぶ簡単に作れるかとおもったのですが。。
フロント(+制御)や照会系はBubbleで作って、更新系のバック側はBackend Workflowを利用したりして、何かしらできるものなのか。。
DBConnect API使ってDBを外側のRDBにして、バッチ系プロシージャ―みたいなのをCALLすればできるのか。
それよりももっと考え方の視点を変えればできるものなのか。考えてると壁にぶつかったので、質問しました。
ありがとうございます！
考えてみたのですが、通常のRDB直接操作と異なりDBのロック機構がBubbleにはないため、ロック機構を擬似的に作れば実現できそうです。
DBの値はリアルタイムに書き換えられてしまうため、Backend Workflowで単一処理であることさえ担保できればできると思います。
同時実行されるBackend Workflowを制限する方法として、フロントからコールされたときにPidが吐き出されるためこの値を基準に同時実行しようとした他のフローを待たせる（実態は繰り返しつつ待たせる）形になりそうです。
ただ、ミリ秒単位で同時に処理が実行される場合などを考慮すると・・・、この方法ではダメかもしれません。
他方で、DBイベントを監視できるため、トランザクションのみを保持するテーブルを作成しそこにOK/NGフラグを持たせ、値が書き込まれたことをキーに他テーブルを確認・更新処理をかけにいくのはありかもと思いました。
この場合、処理を行うタイミングで複数レコードが未処理で残っている場合は、先頭のものから順次処理を行う形で処理の実行順も担保されます（トリガをDBトリガとし、処理の実態はBackend Workflowです）。
「いいね！」 1
トランザクション処理が必要なら、 Unifinity(ユニフィニティー)のような別なツールを選ぶべきではないでしょうか。
厳密にロック処理を実装するなら、少なくともOSの機能を使う必要があると思います。
「いいね！」 1
tomou
6
ありがとうございます。
＞OK/NGフラグを持たせ、
そうですね、一度それでTryしてみます。アドバイスありがとうございます！
tomou
7
コメントありがとうございます。
そうですね、outsystemsとか Wagbyなども検討しているのですが、できればBubbleで視点・切り口をかえて実装できないものかと思いまして。手軽でやすいので。ありがとうございます。
wagby EEなら数年間使用していました。
業務系トランザクション処理も完全に実装できるので、エンジン部分を使用するのはありだと思います。
一方でフロントは貧弱なので、Wagbyをバックエンドに添えてAPIでフロントをBubbleに処理させるのはアリかもしれません。
最新のWagby9でクラウド版もありますが、あちらはフロントがreactなので今風のIFも作れそうですが、触ったことがないためトランザクション処理が大丈夫かが不明です。。
tomou
9
コメントありがとうございます。
そうですか、ご利用されたことあるのですね。直近私も試用版を試そうとおもっていたところですが、
＞フロントは貧弱なので、
はい。まさにこのあたりが気になったので、できればフロントはBubbleみたいな感じで作りたいとおもっていました。
＞reactなので
はい。そうみたいですね。調べてて記事などにのっていました。
こちらも試用版ためしてみようかとおもいますが、こちらはこちらで、どこまで汎用性があるのか、などコメントいただいている通りちょっとわからないところもあるので、もし採用検討するなら、ベンダーさんに確認しようかなとおもいます。
＞Wagbyをバックエンドに添えてAPIでフロントをBubbleに処理させるのはアリかもしれません。
これについては、選択肢の一つとしてかんがえてみます！
ご丁寧にありがとうございます。
「いいね！」 2
