FileMakerでシステム開発

SE経験者がファイルメーカーを用いた場合、どのような設計、開発を行うのかを検証するブログです。

FileMaker事前検証(10回目)レコードロックと排他制御

2020-12-16 14:30:44 | FileMakerの事前検証(レコードロックと自動採番)
動画『誠実で真面目な美容室管理システム(4回目)』でご紹介していますマスタとの連携を例としてご説明します。

この処理は、新規に来店されたお客様の情報が登録されている伝票データ(売上ヘッダ)からお客様の情報を取得し、
顧客マスタに取込む処理を紹介しています。

1.新規のお客様の情報は、売上ヘッダに以下のように登録されています。
  ・顧客コード :諸口コードが入力されている。
  ・顧客名   :お客様の名前が入力されている。
  ・住所    :お客様の住所が入力されている。
    ... etc

  注)諸口コード:正式な顧客毎に割り振られたコードではなく、顧客マスタに未登録のお客様が来店され
   た時に使用する唯一の仮コード

2.顧客マスタに取込む処理の概要
 ①売上ヘッダから諸口コードが編集されているレコードを特定し画面に一覧表示する。
 ②画面から取込みする明細を指定(1件)する。
 ③指定された明細に編集されているお客様情報(顧客名、住所、TEL・・・)を取得し、顧客マスタ保守画面に新規モード
  として編集する。
 ④顧客マスタ保守にて、編集された項目の値を修正または他の項目の値を入力する。
 ⑤顧客マスタ保守にて、確認ボタンを押下し正式な顧客として登録する。
  同時に売上ヘッダの諸口コードは、顧客マスタに追加した時に採番された顧客コードに更新される。

3.上記2.の検証
 ②の時に、2人の担当者が別々のPCで同時に同じ伝票番号の明細を指定したらどのような結果になるでしょうか?
 何も対策をしていない場合、一人の新規のお客様の情報が、異なる顧客コードで、2件登録されてしまうことになります。

 仮に、②で指定した時にレコードをロックしたとして、⑤が完了するまで間、ロックしたままの状態を
 維持しなければなりません。

 一般的なRDBMSを使用した業務システムでも、上記のようにロックしたままの状態を登録処理が終了する
 までの間、維持させているものを見たことがあります。
 このようなロックの方法は正しいと言えるのでしょうか。

 色んな意見があると思いますが、バッチ形式での更新処理の時にのみ、最初の処理でロックを行い、処理
 終了時にロック解放することが正しいと思います。
 注) バッチ形式での更新処理とは、大規模バッチ処理ではなく例えば、伝票入力プログラムでの登録処理
   の更新部分などを指しています。

 担当者が入力中であってもロックが継続されるような仕組みは普通、採用しません。
 何故なら、
 ・ロックされたレコードは複数の処理で参照と更新が実施されることがある。
 ・複数の処理は、個々に参照と更新のフィールドが異なる。(処理の目的が違うため)

 極端ですが、Aさんが入力途中でそのまま外出してしまった場合、他の処理を実行したいBさんは、Aさんが
 帰ってきて処理を完了するまで、待たなければなりません。
 ➢ 基本、「ロックしたら即開放」が原則です。

 話を戻します。
 以前の記事にもご紹介しましたが、一般のRDBMSではレコードを読む時にロックをかけ、既にロックされて
 いる場合にWait or 制御を戻すことをコーディングすることができます。レコードがロックできれば、その
 レコードの値を読むことができます。更新に必要なテーブルのレコードに対してロックを行い、更新内容を
 編集した後にエラーが無ければ確定(COMMIT)することで、レコードの更新が行われロックが解放されます。

 仮に更新処理の編集途中でエラーと判断すべきことが判明した場合は、取止め(ROLLBACK)することで、
 更新前の状態に戻すことができます。これらの内容をプログラムコードとして記述することができます。

 今回のケースにおいて一般的なRDBMSを用いた場合
  ⑤の更新部分の最初に、売上ヘッダの該当レコードをロックします。ロックが成功すれば、顧客コードを
  チェックします。
  ・顧客コードが諸口コードと異なる場合、既に取込み完了として取止め(ROLLBACK)し、以下のメッ
   セージを表示し応答後、制御を①に戻します。
     “既に他の端末で取込み処理が完了しています。”
  ・顧客コードが諸口コードの場合、以下の処理を行います。
   (1)顧客マスタにレコードを追加する。 insert
   (2)売上ヘッダの諸口コードを自動採番された顧客コードに置換する。 update
   (3)トランザクション処理を確定(COMMIT)する。

4.ファイルメーカーでの検証
  まず、ファイルメーカーのレコードのロック、解放についてみてみます。
   ①レコードをロックする。
    以下の操作を行った時にロックされます。
     ア.フィールド値が変更された瞬間
     (以下のスクリプトを実行した時にもロックされます。試していませんが・・・)
     イ.レコード/検索条件を開く

   ②レコードのロックを解放する。
    ファイルメーカーでは、「レコード内のデータの確定」が該当すると思います。
    以下の操作を行った時に確定されます。
     カ.レコード内のフィールド以外の部分をクリックする
     キ.Enterを押す
     ク.他のモードに切り替える
     ケ.他のレコードを選択する
     コ.他のレイアウトに切り替える
     (以下のスクリプトを実行した時にも確定されます。)
     サ.レコード/検索条件確定
     シ.レコード/検索条件復帰  注)レコード内のデータの復帰
 
  特に、カ.~コ.の5つの操作でレコードが確定し、ロック解放が行われる仕組みは、ファイルメーカーでの
  Nativeな使い方に対する仕組みとして採用されているものと思います。(本ブログは一般的なRDBMSを
  用いた企業の基幹システムの設計および仕様を、ファイルメーカーではどのようになるかを検証することを
  目的としています。その場合、カ.~コ.の操作でレコードが確定することを回避または影響しないように設計
  するようにしています。)

今回のケースにおいて、ファイルメーカーの上記スペックをどのように利用し、排他制御を実現するかを検証
し、美容室管理システムにそれらの仕組みを組み込んでいます。

5.顧客マスタに取込む処理の概要に沿って説明します。
  ①売上ヘッダから諸口コードが編集されているレコードを特定し画面に一覧表示する。

  ②画面から取込みする明細を指定(1件)する。
   ➢ この時、ロックテーブルとして以下の2つテーブルにレコードを追加しています。
   (1)売上ヘッダワーク  (主キー:伝票番号)
      売上入力にて伝票を入力する場合、実際にレコードが保管されている売上ヘッダから、売上ヘッダワークへ
      複写して入力を行っています。
      ・複写した時、既に同じ伝票番号のレコードが存在する場合、エラーとして「他端末にて処理中」の
       メッセージを表示し入力不可としています。
      ・今回の売上取込の処理においても更新時に、諸口コードを正式に採番された顧客コードに更新する
       ため、ここでは主キー以外は空白のレコードを追加し、他の人がそのレコードの伝票修正ができな
       いようにしています。
   (2)顧客取込テーブル  (主キー:伝票番号)
      今回、売上取込で指定した明細の伝票番号についてレコードを追加します。
      ・追加した時、既に同じ伝票番号のレコードが存在する場合、エラーとして「他端末にて処理中」の
       メッセージを表示し入力不可としています。

   上記2つの追加が成功した場合のみ以降の処理を実行します。
   (結果的に、顧客マスタ保守にて登録または取消しまでの間、ロックしたままの状態と同じになります。)

  ③指定された明細に編集されているお客様情報(顧客名、住所、TEL・・・)を取得し、顧客マスタ保守画面に
   新規モードとして編集する。
  ④顧客マスタ保守にて、編集された項目の値を修正または他の項目の値を入力する。

  ⑤顧客マスタ保守にて、確認ボタンを押下し正式な顧客として登録する。
   同時に売上ヘッダの諸口コードは、顧客マスタに追加した時に採番された顧客コードに更新される。
   ➢ 最後に、前述のロックテーブルから、追加したレコードを削除します。
     実際は、取消しボタンをクリックし、OKをクリックした時にも削除は実施します。

画面イメージ
 ②画面から取込みする明細を指定(1件)した時
  既に同じ伝票番号のレコードが存在する場合の状態です。

以上です。

コメント    この記事についてブログを書く
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする
« 誠実で真面目な美容室管理シ... | トップ | カレンダー、その他の機能追... »
最新の画像もっと見る

コメントを投稿

ブログ作成者から承認されるまでコメントは反映されません。

FileMakerの事前検証(レコードロックと自動採番)」カテゴリの最新記事