ToDo #488
村上 達也 さんが8ヶ月前に追加.
6ヶ月前に更新.
説明
村上が4月6日から7日にかけて不具合調査を行った過程で、食材店舗23件の出力フラグを誤って99にしたままにしていたため、下図のように不要な食材店舗ファイルがFoodITへ連携されておりました。ご迷惑をお掛けして申し訳ございません。
一次対応として、FTPに残っていた当該CSVファイルを削除しました。
根本対応として、今後も行われるであろうテストや検証時の出力フラグの修正漏れを防ぐワークフローを作成し、実装しております。
内容は、食材店舗やメニュー店舗のレコードに出力フラグ99が付与されていても、原材料規格やメニューの当該レコードに99が付与されていない（不完全・不自然な状態の）場合にはSupabaseからの連携を止め、99のフラグをリセットするものです（下図参照）。
テストや開発時に出力フラグのON・OFFを完全に把握して、不要な99をリセットし忘れないよう徹底する、というのが大前提ではあるのですが、完全に把握出来ない場合もありえるため、人による確認のモレを日次ワークフロー（連携前に最終確認）がチェックするようにしてみました。
手動連携のテストには、ご準備頂いたテスト用FTPサイトへファイルをアップするようにしておりますが、今回のように自動連携に関わるものは深夜に動いてみて気付くことがあるため、その時間帯のチェックが必要だと思った次第です。
ご確認のほど宜しくお願い致します。
村上
ファイル
- 期日 を 2024/04/19 にセット
- ステータス を 新規 から 進行中 に変更
- 優先度 を 通常 から 今すぐ に変更
本件、ご報告ありがとうございます。
以下、対応をいたしましたので共有いたします。
▽CH@RKマスタ連携ファイルの取込破棄
▽FOODIT側通知
高裁はメール内容をご確認ください。
「FOODIT 4/7マスタ更新分のマスタファイル連携について ご報告とお詫び」
また、テスト、開発時のSE作業漏れをチェックするロジックを人層との旨、承知いたしました。
本番運用に影響がないのであれば問題ございません。
1点気になったのですが、以下処理で連携フラグを消す処理は本番運用に影響ないでしょうか？
→後日対面にて改めてご説明いただけますと幸いです。
内容は、食材店舗やメニュー店舗のレコードに出力フラグ99が付与されていても、原材料規格やメニューの当該レコードに99が付与されていない（不完全・不自然な状態の）場合にはSupabaseからの連携を止め、99のフラグをリセットする
- 期日 を 2024/04/19 から 2024/04/26 に変更
4/11Mtg
内容は、食材店舗やメニュー店舗のレコードに出力フラグ99が付与されていても、原材料規格やメニューの当該レコードに99が付与されていない（不完全・不自然な状態の）場合にはSupabaseからの連携を止め、99のフラグをリセットするものです（下図参照）。
上記処理でフラグをリセットした際はメール通知とエラー詳細ログをテーブルに格納する処理を追加
メール：エラーの有無をシステム管理者が感知できれば形式不問
テーブルログ：エラー日時、フラグ削除対象レコードが一意に特定できる情報（対象テーブル、メニューコードorアイテムコード、店舗コード、id）
また、緊急対応が必要な不具合対応案件毛は亡くなった認識ですので期限を延長いたします。
村上さん
本件の動作確認を実施しようとしたのですが、本日のナレッジ移管の際見せていただいた村上さん専用ボタンを見つけることができませんでした。。。
基本的な動作についてはMtg時に実演していただいた動作で問題ない認識ですが、以下条件の際のログテーブルの保存のされ方のみ仕様を確認しておきたいです。
・同タイミングでメニュー2つ以上または食材2つ以上の99フラグが削除された場合
【期待する動作】
・コード単位でレコードが分かれて保存される
※実装工数がかかる場合は現在の仕様でも問題ないです。ご相談させてください。
他の形式にエクスポート: Atom
PDF