COBOLで書かれたビジネスロジックを失うことなくGUIに移行

Question

COBOLコードが100万行以上あるシステムを維持しています。 COBOLで作成したビジネスロジックをすべて失うことなく、GUI（おそらくWindowsベース）に移行する方法についての提案がありますか？そして、はい、ビジネスロジックのいくつかは、現在のユーザーインターフェイスの内部に埋め込まれています。

Answer 1

おそらくscreen scraperを書くことが最善の策です。いくつかの主要なERPシステムは、サーバーベースのアプリケーションから3層アプリケーションへの移行中にこれを何年もやってきました。 1つは、定期的に使用されるフィールド、日付ポップアップ、さらにはスクレイピング入力に基づくクライアントベースのマクロ言語のドロップダウンリストなどの面白い機能が満載です。

これらは素晴らしいものではありませんでしたが、クライアントにとってうまく機能し、アプリケーションが依然として信頼できる方法で動作していることを確認しました。

これをまとめる方法はたくさんありますが、もし考えてみれば、おそらくjavaや.netを使ってデスクトップベースのアプリケーションを作成し、少しでもWebベースの実装を行うことができます。

Answer 2

それは私だった場合、私はこのようなものになります。

NetCobol for Windows

それはまだことを書かれていない場合（機能を公開インターフェースを使用してCOBOLをラップするためにかなり簡単なはずNETアプリケーションから呼び出すことができます。

このようなことをしなかったので、私たちのメインフレームから降りるまでには約15年かかりました。

Answer 3

Microfocusは、COBOLがWebサービスと対話できるようにするEnterprise Serverというツールを提供しています。

COBOLプログラムAと別のCOBOLプログラムBとAがインタフェースセクション経由でBを呼び出す場合、このツールでは、BのインタフェースセクションをWebサービスとして公開することができます。

プログラムAの場合、クライアントプロキシを生成し、AはWebサービス経由でBを呼び出すことができます。

もちろん、BにはWebサービスがあるので、他の種類のプログラム（コマンドライン、Windowsアプリケーション、Java、ASPなど）でも呼び出すことができます。

このアプローチを使用すると、COBOLビジネスエンジンを利用しながらASPのようなものを使用して、GUIを現代的なブラウザベースのアプローチに移行することができます。

そして、まったく適切なWebサービスがあれば、長期的にCOBOLから離れる方法を提供する新しい開発にこれらを使用できます。

Answer 4

ESBを使用して、バックエンドのレガシーサービスを公開し、GUIをコーディングしてESB経由でサービスを呼び出すことができます。

次に、選択した新しいプラットフォームでレガシーサービスを導入して、導入することができます。
サービスへのインターフェイスが変更されない限り、GUIはバックエンドサービスの実装の切り分けを意識する必要はありません。わずかな変更がESBによってGUIから隠されることがあります。

ビジネスロジックを抽出し、ESB経由で新しいGUIで消費される新しいサービスとして新しいサービスとして公開することで、従来のユーザーインターフェイスレイヤーに存在するビジネスロジックをリファクタリングする必要があります。

新しいGUIのプラットフォームの選択については、ネイティブのWindowsプラットフォームではなくWebベースのUIを検討してみてください。少なくとも、UIの更新は少なくともWebサーバーに適用する必要があります。個々のワークステーションに変更を展開する必要があります。