HOME
流通工房について
各フェーズ定義
トピックについて
Link
■サイトマップ
■書籍・プロフィール
■サイト内検索
-------------------------
|
 |
 |
|
| ＜実装OnePoint！＞ |
＜吉田君＞
夜間バッチ処理のジョブスケジュールを作成しようと思うのですが、何かポイントはある
のですか？
＜早瀬＞
大きく以下の2つのポイントを考慮したうえで作成することが重要だ
１．データ処理の整合性を保つ形での処理順序
２．処理負荷、パフォーマンスを考慮した処理順序
このうち２．の処理負荷については、サービスイン直前の総合テストにおいてバッチ処理
を本番同様に実行し、その中で最終的にパフォーマンスチューニングによる処理負荷、
処理速度の改善と、同時実行するJOB数の制御による改善といった調整を行うことになる
【ポイント】
上記の2つのポイントについて詳細に記載します
●データ処理の整合性を保つ形での処理順序
主要なポイントは下記となります
１．バッチ処理の起動タイミングは店舗からの売上データ
店舗の閉店が20：00〜21：00とすると、その後、店舗で「レジ閉め」作業を行い
売上と現金が合致した段階で本部へデータを送信することになります。
大体レジ閉め作業には2時間程度を要するので、店舗の閉店時間によりますが
基幹システムでの売上データの集信は23：00〜25：00ころとなるケースが多い。
なお、最近増えてきた24時間営業の場合でも、1日の閉めをやはり20：00などと
決めておき、店舗で前日の締め後からその時点までの売上をやはり、23：00など
に送信するといった流れになります
２．処理の前半で業務データ処理
売上、仕入、在庫、発注といった流通業の中心となる業務に関わるデータ処理
を行い、1日の業務で発生した商品の動きや伝票処理をデータに反映させます
３．後半に翌日へ向けた処理を実施
ここからさらに2つの処理系等に分かれます。
処理は全ての業務処理が終了してから（実績値が確定してから）の実施となります
(1) PLU関連
商品マスタで履歴管理を行っている場合は当日有効となる商品データを
商品マスタに反映させます。また、当日開始の企画や特売のデータとあわせて
その日の店舗での売価を店舗のストコンへ送信（PLU配信）します
なお、企業ごとの仕組みにより、このPLU送信は前日の夕方までに実施を
するケースもあります。
また、このトピックとは少しずれますが、業務運営上、競合店との対抗の
ために日中に緊急で売価変更を実施することもあります。
この場合は、店舗のストコンで売変を行うストコン売変と、本部から
送信する緊急PLU送信の2つに分かれます
店舗のストコンで売変をした場合は、基幹系システムのマスタ上は
検知できないため、基本的には基幹系システムからの緊急PLU送信とし
ストコン売変については、本部へ連絡をして対応をしてもらう余裕が
なく緊急で売変が必要な本当に特殊なケースのみとすることが多い
(2) 売上速報、営業管理表
前日の店舗ごとの売上状況を把握する売上速報と予実対比や利益率などを
把握するための営業管理表を作成し、店舗と本部に配信します。
●処理負荷、パフォーマンスを考慮した処理順序
売上、仕入、在庫、発注といった業務は流通業における基幹業務であり、当然処理する
データ量は膨大なものとなります。
この中で仕入と在庫については仕入により在庫への入荷が発生するため仕入→在庫といった
処理順となりますが、売上（※注１）、発注は同時に実行をしても構いません。
※注１
最近は店舗在庫についてはほぼリアルで在庫引き落としをし店舗ごとの在庫は
リアルに変動させていますが、仮に店舗の売上による在庫引き落としをこの
バッチ処理で行うのであれば、売上処理も在庫処理の前に実施する必要があります
しかし、大量のデータ処理を実行することによるサーバーへの負荷、あるいはデータ上の
整合性は問題がないが、処理の中で読書きするマスタデータやトランザクションデータが
同一な場合のI/O負荷などから、同時実行をせず処理を分散することになります。
その結果、想定時間内に処理が終了しないといったことがあるため注意が必要です。
＜例（上記の図を例として説明します）＞
■前提
夜間バッチ処理として 0：00〜6：00 までの6時間の割り当てが可能
また、試算上前半の業務データ処理で3時間の割り当てが可能
■試算
売上処理は1時間、仕入処理は2時間、在庫は1時間、発注は2時間、企画・特売で1時間
の想定であり、データの整合性上の観点から、シリアルに実行が必要なのは
・仕入→在庫
のみであり以下から3時間内に終了すると試算
（１）売上（1時間）、仕入（2時間）、発注（2時間）、企画特売（1時間）
※同時実行するため2時間で終了する予定
（２）在庫（1時間）
■実処理
売上、仕入、発注、企画・特売を同時実行したことで、サーバーの処理負荷が高く
想定の2倍強の処理時間がかかってしまい、3時間をオーバー
（１）売上（2時間）、仕入（3時間半）、発注（4時間）、企画特売（1時間半）
※同時実行による処理負荷が高く各処理とも試算よりも処理が延びてしまった
（２）在庫（1時間）
そこで、データ整合性上は問題がないが売上と企画・企画特売を後続処理へ組み替える
ことで試算どおりの処理時間となった
（１）仕入（2時間）、発注（2時間）
※同時実行による処理負荷のため仕入処理で3時間半、発注処理で4時間
かかってしまった
（２）売上（1時間）、企画特売（1時間）、在庫（1時間）
※後続処理は売上、企画・特売処理を追加してもサーバー負荷としては
許容範囲内であったため、試算どおりの時間で終了
|
Copyright (C) ビーコネクト. All rights reserved.
サイト内のテキスト、画像データの無断転載を禁じます |
|
