Wir verwalten ein System mit über einer Million Zeilen COBOL-Code. Hat jemand Vorschläge, wie man auf eine GUI (wahrscheinlich Windows-basiert) migriert, ohne die gesamte Geschäftslogik zu verlieren, die wir in COBOL geschrieben haben? Und ja, einige der Geschäftslogik sind in der aktuellen Benutzeroberfläche verborgen.Migrieren zu einer GUI ohne Verlust der in COBOL geschriebenen Geschäftslogik
Schreiben Sie eine screen scraper ist wahrscheinlich Ihre beste Wette. Einige der großen ERP-Systeme haben dies seit Jahren beim Übergang von serverbasierten zu dreistufigen Anwendungen getan. Eine, mit der ich gearbeitet habe, hatte viele interessante Funktionen wie Dropdown-Listen für regelmäßig verwendete Felder, Datums-Popups und sogar Client-basierte Makrosprachen, die auf der Scraping-Eingabe basieren.
Diese waren nicht großartig, aber funktionierte gut für die Kunden und sorgte dafür, dass die Anwendungen noch zuverlässig funktionierten.
Es gibt viele verschiedene Möglichkeiten, dies zusammen zu setzen, aber wenn Sie darüber nachdenken, könnten Sie wahrscheinlich Java oder .net verwenden, um eine Desktop-basierte Anwendung zu erstellen und mit etwas mehr Aufwand eine webbasierte Implementierung.
Wenn es mir war ich aussehen würde, in so etwas wie:
Es sollte ziemlich einfach sein, Ihre COBOL mit einer Schnittstelle zu wickeln, die die Funktionalität macht (wenn es nicht bereits geschrieben, dass Weg) und dann aus einer .NET-Anwendung heraus aufrufen.
Wir brauchten ungefähr 15 Jahre, um von unserem Mainframe zu kommen, weil wir so etwas nicht gemacht haben.
Microfocus bieten Sie ein Tool namens Enterprise Server, mit dem COBOL mit Web-Services interagieren kann.
Wenn Sie ein COBOL-Programm A und ein anderes COBOL-Programm B und A über den Schnittstellenabschnitt B aufrufen, können Sie mit dem Tool den Schnittstellenabschnitt von B als Webdienst verfügbar machen.
Für Programm A generieren Sie dann einen Client-Proxy und A kann nun B über einen Web-Service anrufen.
Natürlich, weil B jetzt einen Webdienst hat, kann jede andere Art von Programm (Befehlszeile, Windows-Anwendung, Java, ASP usw.) es jetzt auch aufrufen.
Mit diesem Ansatz können Sie "an den Rändern knabbern", um die GUI zu einem modernen, browserbasierten Ansatz mit etwas wie ASP zu bewegen, während Sie immer noch die COBOL Business Engine verwenden.
Und sobald Sie eine anständige Reihe von Webdiensten haben, können diese für jede neue Entwicklung verwendet werden, die eine Möglichkeit bietet, sich längerfristig von COBOL zu entfernen.
Sie könnten eine ESB verwenden, um die Legacy-Back-End-Dienste verfügbar zu machen, und dann Ihre GUI codieren, um die Dienste über den ESB aufzurufen.
Dann können Sie damit beginnen, die Legacy-Services durch Implementierungen auf Ihrer neuen Plattform Ihrer Wahl zu ersetzen.
Die Benutzeroberfläche muss sich nicht der Schnittmenge der Back-End-Service-Implementierung bewusst sein, solange sich die Schnittstelle zum Service nicht ändert - geringfügige Änderungen können vom ESB aus der GUI ausgeblendet werden.
Geschäftslogik, die sich auf der Legacy-Benutzeroberfläche befindet, muss refaktoriert werden, indem die Geschäftslogik extrahiert und als neue Dienste auf der neuen Plattform für die neue GUI über den ESB verfügbar gemacht werden.
Wie für die Wahl der Plattform für die neue GUI, warum nicht in Betracht ziehen, eine Web-basierte Benutzeroberfläche statt einer nativen Windows-Plattform, dann müssen zumindest Updates auf der Benutzeroberfläche nur auf den Webserver angewendet werden Änderungen an jeder einzelnen Workstation durchführen zu müssen.