Analytics

Systemische Sammlung, Analyse, Aufbereitung und Darstellung Ihrer Daten für optimale operative und strategische Entscheidungen.

Advanced Analytics
Mit Hilfe von Advanced Analytics Lösungen gelingt es, entscheidende Verbesserungen in...
Mehr lesen
Predictive Analytics & Maintenance
Predictive Analytics ermöglicht es, mit Hilfe unternehmenseigener Daten zukünftige Trends...
Mehr lesen
Selfservice BI, Adhoc Analysen
Die Anwender der einzelnen Fachabteilungen können jederzeit eigenständig und unabhängig...
Mehr lesen
Machine Learning
Ein System lernt aufgrund eines aus Algorithmen aufgebauten Modells aus bereits erfolgten...
Mehr lesen
Digitalisierung, IoT & Industrie 4.0
Daten werden in sämtlichen Unternehmensprozessen generiert, gesammelt und analysiert....
Mehr lesen
Data Science
Data Science bietet Ihnen die Chance - nicht auf den ersten Blick ersichtliches Wissen -...
Mehr lesen

Development

Umfassende Situationsanalyse, fundierte Beratung, professionelle Umsetzung individueller Softwarelösungen sowie kompetente Unterstützung.

Development
Wir entwickeln für Sie individuelle Lösungen mit projektspezifischen Funktionen.
Mehr lesen
Business Process Management
​​​​​​​Wir führen durch das Business Process Management eine kontinuierliche Verbesserung...
Mehr lesen
SharePoint Entwicklung
Unsere SharePoint EntwicklerInnen, entwickeln und erstellen Konzepte und Lösungen für die...
Mehr lesen
Internet of Things
Das Internet der Dinge (Internet of Things; IOT) beschreibt die zunehmende Vernetzung...
Mehr lesen
Zur Übersicht
Zur Startseite
Schliessen

Aktuelles

Neuigkeiten rund um cubido.
Zur Übersicht

Modernisierung von Legacy-Applikationen - das versteckte Gold im Unternehmen fördern (Teil 2)

Hier lesen Sie den zweiten Teil zum Thema Modernisierung von Legacy-Applikationen. Teil 1 finden Sie hier

Fallbeispiel: Migration einer OracleForms- Anwendung in ein zeitgemäßes Windows-Umfeld

Man glaubt es kaum, aber es gibt noch eine Menge an OracleForms- Applikationen im betrieblichen Umfeld, die einerseits noch fleißig genutzt werden, andererseits aber langsam das Ende ihrer Lebensdauer erreichen. Ich weiß, ich lehne mich hier weit aus dem Fenster, da seitens Oracle ja volle Unterstützung für Forms zugesichert wird, die Praxis im betrieblichen Alltag sieht meiner Erfahrung nach jedoch anders aus.

Dies hat unterschiedliche Gründe:

  • Unterstützung der 64Bit- Plattform und aktueller Betriebssystem- Varianten

Nicht alle Komponenten (vor allem die Charting-Komponente ist hier recht heikel) kamen gut mit dem Umstieg von 32- auf 64-Bit zurecht. Es gibt deswegen nicht selten einen Rechner im Unternehmen, der vom allgemeinen Plattform- Wechsel ausgenommen wurde, um die Applikation weiterhin betreiben zu können. Der System- Betreuer rollt zwar wild mit den Augen, es nützt aber nichts. :-)

  • Unterstützung der Entwicklungswerkzeuge

Für den Benutzer einer aktuellen Visual Studio oder Eclipse- Version mag dies anachronistisch klingen, aber es hat sich in der Praxis als gar nicht so einfach herausgestellt, auf einer aktuellen Windows- Version das Debuggen von OracleForms- Applikationen zu ermöglichen. Es sind allerlei Kunstgriffe nötig und speziell dieses KnowHow ist nicht in allen Unternehmen vorhanden. Deswegen wird wiederum zumindest ein Rechner nicht aktualisiert, um hier ein Debugging zu erlauben. Zusätzlich ist man in aktuellen Entwicklungsumgebungen einen Bedienkomfort gewohnt, den z.B. der Oracle Designer nur bedingt bieten kann.

  • Knowhow der Entwickler

Es gibt (man mag es kaum glauben) nach wie vor eine Menge an Entwicklern mit OracleForms- Knowhow, die zumeist aber so intensiv im Tagesgeschäft eingebunden sind, dass keine oder wenig Zeit bleibt, sich mit anderen Entwicklungsumgebungen und Programmier- Paradigmen auseinanderzusetzen.

Hier kommt auch der sogenannte "Ferali"- Effekt zum Tragen. Eine Anwendung in neuer Technologie wird meist im risikofreien Raum anhand eines zurechtgestutzten Szenarios von einem oder mehreren Ferial- Praktikanten umgesetzt. Am Ende des Praktikums gibt es dann eine Übergabe und ehe man sich versieht, landet diese Applikation in der Schublade, um angesehen zu werden, "wenn einmal mehr Zeit ist". Leider kommt diese Phase spät oder gar nie und das aufgebaute Knowhow ist verloren.

  • Kaufmännische Entscheidungen

Auch dieses Thema spielt mitunter eine große Rolle, vor allem wenn hohe Lizenzgebühren für eine proprietäre Entwicklungsumgebung bezahlt wurden (im 4-GL- Bereich ist dies gang und gäbe). Im Sinne eines vorgeblichen Investitionsschutzes wird versucht, diese Kosten über einen möglichst langen Zeitraum zu rechtfertigen und dementsprechend zaghaft erfolgt die Erlaubnis, andere Entwicklungsumgebungen zu evaluieren.

Wie kann man eine solche Migration in Angriff nehmen?

Holen Sie sich mindestens zwei Stakeholder an Board: die Benutzer der Applikation und jemanden, der Ihr Projekt finanziert und Ihnen auch entsprechenden zeitlichen Spielraum gibt.

Sichern Sie technologische Entscheidungen mit Prototypen experimentell ab, vor allem Performance-Themen. Beachten Sie dabei, dass OracleForms z.B. eine Art eingebautes Paging besitzt, d.h. beim Laden einer Tabelle werden z.B. nur 50 Datensätze geladen und man "blättert" weiter. Wenn Ihre Umsetzungstechnologie einen ähnlichen Mechanismus erlaubt, ist das gut, andernfalls müssen Sie sich ggf. mit Filter-Feldern oder den "TOP 1000" Zeilen helfen, um keine unangenehmen Überraschungen zu erleben.

Versuchen Sie, Migration und Erweiterung so gut wie möglich zu trennen. Es ist aus mehreren Gründen verlockend, im Zuge einer Migration auch gleich jene Dinge, "die schon immer suboptimal funktioniert haben" mit zu lösen. Dies sichert einerseits das Wohlwollen der Benutzer und erlaubt zudem eine bessere kaufmännische Rechtfertigung.

Die Erfahrung hat allerdings gezeigt, dass es ratsamer ist, die Dinge möglichst 1:1 zu übernehmen und abnicken zu lassen. Wenn die User dann das Gefühl haben, dass sie mit der neuen Applikation exakt das Gleiche erreichen wie mit der bestehenden Applikation, ist immer noch Zeit für Verbesserungen. Im Rahmen dieser Migrationsphase haben Sie nämlich das nötige Fachwissen soweit aufgebaut und fühlen sich sicher genug, um vernünftige und seriöse Aufwandsschätzungen in Bezug auf neue Features abgeben zu können.

Wichtig: Planen Sie für den Parallelbetrieb im Schnitt 50% mehr Zeit ein, als Ihnen Ihr Bauchgefühl sagt.

Achten Sie auf Ihr Wording. Es ist ein Zeichen von Respekt (sowohl den Usern als auch dem/der/den Entwickler/in/n gegenüber) wenn Sie von der "bestehenden" Applikation sprechen und nicht von der "alten" (niemand gehört gern zum „alten Eisen“). Respekt ist generell empfehlenswert, auch wenn es z.B. um Code Reviews der bestehenden Applikation geht. Versuchen Sie, nicht die Nase zu rümpfen, wenn Ihnen ein Lösungsansatz antiquiert erscheint.

Software ist oft ein Produkt ihrer Zeit und auch das Ergebnis beschränkter Ressourcen. Eine Applikation als "Pfusch" schlechtzureden, ohne die Bedingungen zu kennen, unter denen sie entwickelt wurde, ist nicht nur schlechtes Benehmen, sondern pure Arroganz. Versuchen Sie sich stattdessen in Demut gegenüber dem, was geschaffen wurde. Damit haben Sie auch einen leichteren Einstieg in die Projektarbeit.

Fünf Eigenheiten von OracleForms- Applikationen, auf die Sie bei Ihrer Modernisierung Rücksicht nehmen sollten:

  • Filtern mit F7 + F8
  • Durch den Druck auf F7 versetzt man Tabellen in eine Art „Filtermodus“, d.h. alles, was jetzt in die erste (und nur diese) Tabellenzeile eingegeben wird, dient beim Druck auf F8 als Filter für die Daten, im Grunde also eine Art WHERE- Bedingung, wenn man sich das Ganze als SQL- Statement vorstellt. Als Ersatz dafür bedarf es entweder eigener User-Controls oder der Einführung von Filterfeldern (bzw. Spaltenfiltern) und Erfahrungswerten, nach welchen Feldern tatsächlich bzw. am häufigsten gefiltert wird.

  • DBMS_PIPE und DBMS_ALERT
  • Mit diesen beiden Konstrukten können Sie auf Datenbank- Ebene ein asynchrones Messaging nutzen, was auf der einen Seite sehr nützlich ist, um auf Datenbank- Events zu reagieren und andererseits auch dazu genutzt werden kann, Nachrichten garantiert zugestellt zu bekommen (vereinfacht gesprochen). Wie dem auch sei, damit diese Mechanismen funktionieren, muss eine Applikation entweder eine offene Datenbank- Verbindung halten (was in Zeiten von Hochskalierbarkeit tendenziell problematisch ist) bzw. entsprechende Datenbank- Treiber verwenden, die dieses Verhalten in den Applikations- Layer projizieren. Eine dritte Variante wäre die Verwendung eines eigenen Messaging- Systems.

  • Paging
  • Das eingebaute Paging erlaubt es, auch die Inhalte sehr großer Tabellen schnell anzuzeigen, indem quasi nur eine „Kostprobe“, z.B. die ersten 50 Datensätze (sortiert nach dem angegebenen Kriterium) gelesen und am Client angezeigt werden. Wenn die verwendete Datenzugriffstechnologie nicht dazu in der Lage ist, ein solches Paging zu ermöglichen, sind andere Maßnahmen erforderlich (z.B. nur TOP 1000 anzeigen oder Filtern der Einträge), um nicht womöglich Millionen von Datensätzen aus der Datenbank zu lesen und dem Client zu Anzeige zu senden, was aus Sicht der Performance alles andere als wünschenswert ist.

  • Stored Procedures und Trigger
  • Die Logikbausteine in OracleForms werden in so genannten Trigger- Prozeduren gekapselt, welche sehr große Ähnlichkeit mit Datenbank- Triggern haben, aber eben nicht dasselbe sind. Beachten Sie, dass Trigger- Prozeduren auf dem Anwendungs- Layer ausführt werden, während Datenbank- bzw. Tabellen- Trigger direkt in der Datenbank ausgeführt werden, d.h. diese kommen erst später zum Zug und können Ihre Applikationslogik ordentlich durcheinander bringen.

    Umgekehrt ist es auch möglich, im OracleForms- Code gespeicherte Prozeduren aufzurufen, die nur dort existieren, d.h. achten Sie bei der Migration nicht nur auf Procedures, die Ihr Abfragetool findet, sondern durchforsten Sie auch den OracleForms- Code nach dem Schlüsselwort „procedure“.

  • Transaktionen
  • Wenn Ihre Datenzugriffstechnologie Transaktionen unterstützt und Sie diese auch nutzen, seien Sie sich der Tatsache gewahr, dass es auf der Datenbank- Ebene (z.B. in Stored Procedures oder Triggern, die ggf. noch andere Procedures aufrufen) ebenfalls Transaktionen gibt. Ein modernes, verteiltes Transaktionsmodell nimmt darauf insofern Rücksicht, als dass Applikations- Transaktionen an Datenbank- Transaktionen teilnehmen (sofern dies eingestellt wird).

    Interessant wird es aber beispielsweise beim „CommandTimeout“, das in dem Fall über die gesamte Transaktions- Dauer gerechnet wird. Läuft dieses Timeout ab, so wird die gesamte Transaktion zurückgerollt, d.h. aus Applikationssicht scheint die Ausführung eines INSERT- Statements mehr oder minder sofort fertig zu sein, durch die Teilnahme an einer verteilten Transaktion können aber Drittkomponenten (unbewusst) ein Timeout provozieren und Ihr Statement wird zurückgerollt.

     

     

     

     

    Blog | Trends und Innovationen
    24. Juli 2018 von David Mariacher
    Werbeagentur Moremedia, Linz