データ形式の変換システム

形式の違うファイルを、変換の待ちから結果まで一つの流れで扱う仕組みです。前の世代では変換の状態と文字コードを処理として持ち、後の世代では同じ変換を画面と API から実行できるようにしています。API の仕様は OpenAPI で残し、画面とは別に、どんな入出力があるかをたどれるようにしています。変換の実行、状態の確認、仕様の参照を一つの成果としてまとめています。

変換を依頼すると、処理待ちから結果までを同じ記録で追えます。前の世代は状態と文字コードの処理を中心にし、後の世代は画面と API からその処理を呼び出します。仕様は OpenAPI で残し、実装を読む前に入出力を確認できるようにしています。成功と失敗も、別の帳票ではなく状態として見ます。

受け取るファイルの形式が揃っておらず、変換のたびに待ち、処理中、成功、失敗を別々の場所で確認していました。一部だけ失敗したときと、全件失敗したとき、変換元が空だったときの見分けも、担当者が結果を開いて判断していました。文字コードと改行の違いも、変換の前後で見比べる必要がありました。状態の名前が揃っていないと、処理が止まっているのか、元のファイルが無いのかが、見る人によって違っていました。

形式が違うファイルを受け取ると、どの文字コードで読むかを毎回判断していました。一部だけ失敗したファイルと、全件失敗、変換元が空のケースが、同じ失敗として扱われていました。処理中なのか止まっているのかも、画面の外のログを見ないと分かりませんでした。改行の違いで、変換後のファイルが別の環境で崩れることもありました。

変換の状態は、処理待ち、処理中、全件正常、一部失敗、全件失敗、変換元が空、システム異常に分けています。文字コードは UTF-8 と SJIS を扱い、改行の違いも変換の前後で持てるようにしています。前の世代ではこの状態と文字コードを処理の中心に置き、後の世代では画面から変換を実行し、API が受け付けます。結果は状態として残り、成功と失敗を同じ一覧の見方で確認できます。API の項目は OpenAPI の画面でたどれ、画面の操作と仕様の記述を別々のメモにしないようにしています。

利用者は変換を開始し、状態が処理待ちから処理中、そして全件正常か、一部失敗、全件失敗、変換元が空、システム異常のどれになったかを見ます。UTF-8 と SJIS、改行の違いは変換の前後で持てます。後の世代ではこの操作を画面から行い、API が受け付けます。仕様の項目は OpenAPI で追い、状態の意味と入出力を同じ説明として参照できます。

前の世代は CakePHP で、変換の状態、変換前後の見出し、文字コードを扱います。次の世代の画面は Next.js、API は Laravel と PHP です。変換の記録は MySQL に置き、キャッシュは Redis です。画面、API、データベース、キャッシュは Docker で起動します。仕様の記述は OpenAPI で、画面の実装とは別の置き場から確認できます。世代が違っても、変換の状態を見て結果を判断する流れは同じ仕組みとして残しています。

CakePHP は前の世代の変換処理で、状態、見出し、文字コードを扱います。Next.js は後の世代の画面で、変換の開始と結果の確認を出します。Laravel と PHP は API として変換の受け付けと記録を行います。MySQL は変換の記録、Redis はキャッシュ、Docker は一連のプロセスの起動です。OpenAPI は実装とは別の仕様として、入出力を固定します。