HOME
流通工房について
各フェーズ定義
トピックについて
Link
■サイトマップ
■書籍・プロフィール
■サイト内検索
-------------------------
|
 |
 |
|
| ＜実装OnePoint！＞ |
＜早瀬＞
ほとんどの機能の基本設計は終了したね。あとは、インフラチームと連携して画面からの
バッチ起動機能の設計をしておいて。開発の優先度としては少し落としてもかまわないから。
＜吉田君＞
画面からバッチ処理を起動するんですか？
今回はバッチ本数が多いことと、処理の先行、後行関係が複雑なのでJOBスケジューラを
入れているので、そちらから起動するようにしてもらえればよいと思いますが。
結構今後の詳細設計から開発までのスケジュール、工数も詰まっているので機能はできる
限り抑えたいですよね
＜早瀬＞
JOBスケジューラを起動できるコンソール画面は当然情報システム部のみへの公開だよね。
今まで、汎用機などでもバッチ処理の実行は情報システムしかできないケースが多かった
ので、必要な時は情報システム部に連絡をしたり、顧客によっては申請書に記載して依頼を
したりといった業務運用となっていることが多い。
ではどういったものが日中に実行するバッチ処理かというと、流通業において主なものは
・月締めにおける営業管理表などの管理帳票
・棚卸し時の関連帳票
などが該当する。
これらは、1ヶ月の全店のデータを対象に粗利を算出したりといった計算や棚卸し対象の
店舗、商品についての計算処理で長時間処理に時間がかかるためため、バッチ処理で実行
することになる。
もうひとつ重要なのは、これらはいったん情報が集まった時点で「仮締め」処理を実行し、
出力された帳票をチェックして、場合によってはデータを調査、修正し再度処理を実行、
最終的に結果がOKであれば「本締め」として確定するといったオペレーションとなることだ。
つまり、「確定」までに何度か実行する必要がある。そして、そのデータチェックをし判断
する部署は情報システム部ではなく、現業部門になる。
よって、実行する処理対象の機能は少ないが、現業部門においてバッチ処理を画面から実行
できるようにしておくことは重要なんだ。
いわゆる「オンラインバッチ」と呼ばれるものだね。
ついバッチ処理というと夜間処理と考えてしまい、JOBスケジューラーや簡易な場合は
UNIXやLiunxであればcronなどを使ってコマンド起動するものだけで考えがちだが、業務を
考えた場合に日中（オンライン時間帯）に実行するバッチ処理は必要不可欠だ。
【ポイント】
トピックとしてはフェーズとしては基本設計フェーズ、視点としてはシステム運用の観点
からの内容となります。
流通業においては上記のような営業管理表、棚卸しなどにおいては一旦「仮締め」で帳票を
出力、チェックをしてOKであれば「本締め」とする業務オペレーションとなります。
よって、そういった業務をより柔軟に実行できるようにすることを考慮する必要があります。
そのほか、新店の際に一連のマスタを作成する処理も店舗運営部などの現業部門で行うケース
情報システム部で実行するが、簡易な作業ができないレベルの社員での実行する場合は同じ
ように画面からの起動とすることもあります。
もちろん、あくまでも情報システム部などに連絡をもらい、そちらで一元管理をする
といった方針の企業もあるので、この部分については顧客担当者に確認をしてみてください。
なお、規模がそれほど大きくなければ、バッチ処理自体もいくつかのバッチ処理を起動する
親スクリプトを用意しておき、コマンド実行するといった実装方式かと思います。
この場合は単純にそのスクリプトの起動コマンドを画面から実行するようにすればOKです。
また、規模が大きい場合はJOBスケジューラー（日立のJP1や富士通のSystem
Walkerなど）
でバッチ処理を制御する実装となるかと思いますが、これらのJOBスケジューラーも
コンソール画面からだけではなく、外部からコマンドで実行が可能です。
もちろん、スクリプトを用意しそれを実行してもよいのですが、JOBスケジューラを導入して
いるのであれば、バッチ処理の処理状況や処理結果などはJOBスケジューラ上で監視、確認が
できるようにしておいたほうが良いでしょう。
それからバッチ処理を起動する画面は
・実行するバッチ処理名
・処理開始時間
・処理終了時間
・ステータス（実行中、異常終了、正常終了）
・実行者
などの情報が必要項目になります。
なお、JOBスケジューラを起動するケースでも、上記の情報についてはバッチ処理の中で
管理テーブルなどに書き込むようにし、バッチ起動画面ではその管理テーブルから情報を
取得するようにしておくと良いでしょう。
機能としては非常にシンプルで簡易なものです。工数もそれほどかからないものですが
業務運用上は非常に有用な機能になります。
また、留意点としては当然バッチ処理においてはメモリ、CPUといったリソースを使うこと
になるため、あまりに重い処理を実行したり、軽いものでも多数実行するとオンライン画面
のレスポンスに大きく影響することがあります。
逆にオンライン画面の使用率の高い時間帯に処理をすると通常は30分くらいで終わるオンライン
バッチ処理が１時間も２時間もかかったりすることがあります。
よって、オンラインバッチの実行においては、処理によるリソースへの負荷やオンライン
処理のピーク時（例えば発注処理が集中する曜日や時間帯、本部からの指示を確認し、作業
を行う午前中など）の確認と実行時間帯の制御（システム的な制御やその時間帯は実行しない
ように顧客側で徹底するなどのシステム運用による制御）を検討する必要があります
|
Copyright (C) ビーコネクト. All rights reserved.
サイト内のテキスト、画像データの無断転載を禁じます |
|