Legacy Code robust machen – Teil 1

Wie in vielen Unternehmen existiert auch bei uns noch jede Menge Legacy Code, der an manchen Stellen nicht weiter stört, in anderen Bereichen aber die Geschäftsprozesse erheblich verlangsamt oder gar lahmlegt. Bei uns sind das v.a. die Druckdienste unseres ERP Systems. Vor etlichen Jahren wurden diese in VB6 geschrieben und es fehlt an so manchem essentiellen Feature, wie z.B. einer adäquaten Fehlerbehandlung oder einem Logging-System. Das fällt besonders ins Gewicht, da der Dienst sehr instabil läuft.

Deswegen haben wir uns jetzt intern entschieden genau diesen Störfaktor auszuräumen. Das Problem ist nur, dass zu viel Code und zu viele Abhängigkeiten darin verstrickt sind. Deshalb gehen wir mit einer anderen Methodik heran: Wir beheben das Symptom, aber nicht die Ursache. Konkret bedeutet das die Implementierung eines auf .NET basierenden Windows Dienstes, welcher den alten Legacy Code steuert. Dazu haben wir die reine Anwendungslogik aus dem alten Dienst herausgelöst und sauber in einer EXE-Datei verpackt, welche sich per Kommandozeile aufrufen lässt.

Der neue .NET Dienst ist nun dafür zuständig die Druckjobs zu verwalten, diese an den alten VB6 Prozess zu übergeben und die Verarbeitung zu überwachen. Das folgende EPK Diagramm gibt den groben Ablauf wieder (von oben nach unten lesen…). Es ist nicht ganz vollständig, enthält aber alle wichtigen Informationen.

 

Druckdienst Prozesskette

 

Wie man sieht, setzen wir auf Parallelisierung. Durch das Starten des Service werden mehrere Threads erzeugt, die das Verarbeiten der Jobs übernehmen. Im weiteren Verlauf des EPKs zeige ich den Prozess allerdings nur anhand eines Threads.

Wird ein Thread gestartet, so versucht er sich zunächst einen Druckjob aus der Datenbank zu holen. Wenn er keinen findet, dann legt sich der Thread für eine beliebig definierte Zeit X (die Information kommt aus der Konfiguration) schlafen und beginnt danach erneut.

Wenn er dann einen Job zum Abarbeiten findet, startet er den VB6 Prozess, indem er die ID des gefunden Druckauftrags an diesen übergibt, woraufhin dieser zu arbeiten anfängt. Nun können 3 Ereignisse eintreten:

  • Der Job wird erfolgreich verarbeitet: In diesem Fall muss der .NET Service nur noch den Job in der Datenbank als erledigt kennzeichnen. Danach kann er von vorne beginnen
  • Der Prozess antwortet nicht, d.h. das Programm „hängt“
  • Der Job wurde vom Prozess nicht erfolgreich verarbeitet: In diesem Fall wurde der Prozess korrekt beendet, allerdings war der Job fehlerhaft

Die beiden letzten Ereignisse drücken zwar unterschiedliche Ergebnisse aus, führen jedoch zum selben Resultat: Der Druckjob wurde nicht erfolgreich verarbeitet. In diesem Fall wird geprüft, wie oft schon versucht wurde diesen Job zu drucken. Ist eine definierte Anzahl x (die Information kommt aus der Konfiguration) an Wiederholungen erreicht, so wird der Job als fehlerhaft in der Datenbank markiert, sodass er nicht erneut von einem Thread abgeholt werden kann. Ist das nicht der Fall, so wird der Druck durch den VB6 Prozess ein weiteres Mal angestoßen.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: