データベースと相互作用する多くの実行可能ファイルで構成される大きなWindowsレガシーアプリケーションがあります。実行可能ファイルには、主に4つの目的があります。
（a）データベース上のファイルの解析とロード
（b）ファイルを変換します（たとえば、ファイルをエンコードします）。これにより、ファイルを多くの部分に分割することもできます。
（c）データベースである種の複雑な更新を実行する
（d）ファイルを作成する
これらの実行可能ファイルは、バッチファイルによって呼び出されます。バッチファイルは、実行内容に基づいて3つのタイプになります。
（1）条件を待ち、外部パスからファイルを取得し、場合によっては（b）で変換し、（c）を実行し、アクティビティの結果に関する通知を送信し、データベースにレコードを書き込みます
（2）条件を待ち、（c）を実行し、ファイルを作成し、（b）で変換してから、1つまたは複数の宛先（ローカルファイル、データベース、ftp）にコピーし、アクティビティの結果に関する通知を送信します、データベースにレコードを書き込みます。
（3）（abcd）実行可能ファイルの他の複雑なシーケンスを調整し、アクティビティの結果に関する通知を送信し、データベースにレコードを書き込みます
バッチファイルは、Windowsマシン上の通常のBATファイルです（おそらく相互に呼び出します）。ファイルはスケジューラーによって起動されます。
問題は次のとおりです。
-各バッチファイルでは、環境（共通ディレクトリなど）に関するほとんどの情報が複製されており、タイプ（1）または（2）のほとんどのファイルは非常によく似ています。
-バッチファイルは、テスト環境用に簡単に構成することも、自動的に簡単にテストすることもできません。
-通知および開始条件の待機のコードが部分的に重複しています（errorAがbを呼び出す場合、エラーbがcを呼び出す場合、エラーdがeを呼び出す場合）。
-gotoの使用
-どのバッチファイルが廃止され、どのバッチファイルが定期的に呼び出されるかを正確に追跡することはできません
-送信または受信されたファイルを理解するには、バッチごとに個別に開く必要があります。
-アプリケーションに設計上の制約を課し、一般的なコードを抽象化することはできません
-水平機能を実装するには（たとえば、デフォルトのログポリシーがあり、各ジョブが呼び出された回数を数えます）、多くのファイルに（保守不可能な？）コードを書き込む必要があります。
プラス面：
バッチファイルは簡単に変更できるため、何らかの理由でバッチが失敗した場合でも、バッチを作成して状況を安全な状態に戻すことは難しくありません。
彼らは戦いでテストされています。彼らは長い間生産されてきました
私はこの解決策を思いついた：
共通の関数と構成（イベントを通知する関数、ファイルを転送する関数、条件を待つ関数）を提供するJavaライブラリーをいくつか作成します。
タスククラスをロードして実行できるJava「スクリプトエンジンフレームワーク」コマンドラインアプリケーションを作成します。（タスククラスは、上記のライブラリで提供されている関数を使用できます。）
スクリプトは、ユーザーが必要に応じて別のjarファイルのクラスで提供できます。
スクリプトは、注釈を使用して自動文書化できます
スクリプトエンジンは、スクリプトにそれ自体とそのパラメータの説明を出力するように要求できます
ファイルの作成とコピーを分離する
スクリプト言語（PHP、Python）ではなく、Javaを使用することにしました。これにより、コンパイルのメリットを享受でき、「致命的なエラー」を引き起こす可能性のある共通のライブラリに何かを書くことを恐れる必要がなくなります。スクリプトの実行を停止します。
これにより、最も標準的なバッチファイル（タイプ1および2）の実行が簡単になると思いますが、タイプ3のバッチを表すのは難しいと思います。また、自動展開と私の心配は、悪いバッチファイルを書くと問題が発生する可能性がある一方で、エンジン自体（コンパイルとテストのために発生する可能性が低い場合でも）または構成にバグのあるコードをデプロイすると、すべてのスクリプトに影響を与える大きな懸念が生じる可能性があることです。
システムは100％信頼できる必要があり、システムタスクを実行するための期限と「時間枠」があることに注意してください。
私の質問は次のとおりです。
バッチファイルは大丈夫だと思いますか？それらはこの文脈で広く使用されていますか？
私は正しい方向に進んでいると思いますか？考えていないことはありますか？<
誰かがより良いアイデアを持っていますか？
私を助けることができるフレームワークを知っていますか？
将来的に柔軟性を高めるためにこのシステムを開発する価値があると思いますか、それともバッチを保持したほうがいいですか？
開発する新しいソリューションは、最初は既存のシステムと統合されるため、たとえば、アプリケーションサーバーで機能するようにすべてを書き直すことはできません。