方式設計
項目 | 内容 |
---|---|
大方式 |
|
ファイル受信検知方法 | 連携されたことをどうやって検知するか?(ポーリング、S3PUTトリガ、HULFT、etc...) |
連携の方向(IN/OUT) | IN/OUT |
接続許可設定 | IP制限要否(必要な場合のIPアドレス・ポート) 設定が必要な環境の洗い出し(本番、検証、...) 方向(IN/OUT): 受ける側だけでなく出る側でも許可設定が必要な場合があります 申請から許可までに要する時間1 |
格納場所 | ストレージを利用する場合は何を使う? PUT/GET方法は?(SFTP?もしくはAWS Lambdaのように自動的にトリガできる?) |
ファイル名 | どうやって一意とするか? タイムスタンプをファイル名に含めるのか?その場合のフォーマットは? ファイル名は同じとしてディレクトをわけるか? |
時間・頻度 | データの処理に関する実行時間や頻度 |
データ量・ファイルサイズ | 処理対象データの量やファイルサイズ |
前処理 | ファイル処理前に行う必要がある作業 |
後処理 | リネーム規則(タイムスタンプとか) 場所移動するのか削除するのか放置か 記録 完了通知・エラー通知など |
取り込み順序 | 複数のファイルが配置されている場合、どういう順序で取り込むか? 例)ファイル名の昇順で取り込む(ファイル名がファイル種別+タイムスタンプで構成されている場合) |
取込方法 | 洗替、追加、更新など |
連携頻度 | 日次?随時?その他 随時の場合は間隔やトリガも明記。タイムラグによって不整合が発生しないか?の考慮も必要 |
処理ログ | ログの管理方法 |
エラー処理 | リトライ要否・方法 エラー検知・・・最初に全部チェックするか?逐次チェックとするか? エラー時処理・・・全件ロールバックになっているか? ※一部だけ取り込むとリトライ等が複雑になるので原則として全件ロールバック エラー通知・・・どうやって通知2するか?誰に通知するか? 空データの扱い・・・データ0件は異常か?ファイルが連携されてこない場合は異常か? |
リカバリ方法 | 連携エラー発生時のリカバリ方法・手順を明確化する |
ファイル設計
項目 | 内容 |
---|---|
ファイル形式 | CSV、TSV、JSON、XML |
文字コード | SJIS、UTF8 |
ヘッダ有無 | 有/無 |
改行文字 | CR、CRLF、LF |
区切り文字 | (具体的な内容は記載されていない) |
囲み文字 | 囲み文字の有無、エスケープ処理 |
データの並び | 日時やなんらかのID順 |
各項目定義
項目 | 内容 |
---|---|
項番 | ファイルごとに1から始まる一意な連番。 レビューや情報共有時に素早く探すのに有用(というか必須) |
項目名/物理名 | 例.quantity |
項目名/論理名 | 例.数量 |
項目の意味 | 項目が持つ意味 |
必須/任意 | 項目が必須か任意か。〇△など △は他項目の値によって必須となる場合 |
一意性 | 項目が一意であるか。 複数項目で一意の場合もある |
データ型 | 数値、文字(列)、日付、時間、フラグなど |
値の範囲 | 上限、下限、桁数、正規表現(Eメール、電話番号等) |
とりうる値と意味 | 例: 0:無効、1:有効、99:xxx |
値の例 | 項目が持つ具体的な値の例 |
他項目との関係 | 他項目との関連性や依存関係。 例: 項番nの値がXXXの場合、この項目の値を参照してxxxする。 例)項番nの値がXXXの場合は、この項目の値は「XXX」、それ以外の場合は、「xxx」となる |
更新履歴
日付 | 更新内容 |
---|---|
2025/01/02 | 余計な前書きを削除 |
2025/01/02 | ChatGPTにテーブルに書き換えてもらいました。 |