JTL-Wawi – Der Update-Wahnsinn die Zweite

logo_jtl-wawiEigentlich wollte ich heute darüber schreiben, wie toll WordPress ist und wie glücklich ich mit der Umstellung von Joomla nach WordPress bin. Wie so oft im Leben kommt es erstens anders und zweitens als Mann denkt. Darum an alle meine weiblichen Leser gut aufgepasst. Hier könnt ihr lesen, wie sich Homo Sapiens verrennt (Für die Männer unter meinen Lesern „Der intelligente Mensch“). Aber bevor ich die gute Stimmung nach der Selbstbeweihräucherungsparty in der verbotenen Stadt einen massiven Dämpfer verpasse, gehen wir dem Dilemma auf den Grund.

Auf dem Stammtisch in Hürth diesen Jahres hatte ich Gelegenheit mich mit Thomas Lisson zu unterhalten. Thema war auch die bisherige Update-Praxis von JTL. Ich habe da schon angemahnt, dass die Praxis, mit jedem Update auch die Datenbank anzufassen, auch massive Nachteile mit sich bringt.

Stored Procedures – Fluch und Segen

Der Artikel soll nicht dazu dienen Programmiertechniken Laien zu erklären. Um aber meinen Ausführungen folgen zu können, versuche ich hier mal ganz einfach zu erklären, um was es geht.

JTL-Wawi ist eine Datenbankanwendung basierend auf dem Microsoft SQL Server. SQL steht hier für Standard Query Language (Standard Abfrage Sprache). Mit dieser Sprache werden Daten in die Datenbank geschrieben, geändert, gelöscht oder abgefragt. Das Ergebnis dieser Aktionen sehen sie dann zum Beispiel in der Listenansicht Aufträge. Nun gibt es zwei Möglichkeiten diese Abfragen auszuführen. Erste Möglichkeit sind Dynamische Abfragen. Die zweite Möglichkeit sind sogenannte Stored Procedures. Vorteil für den Anwender ist das der SQL der die Ergebnisse der Abfragen quasi in seinem Speicher vorhält. Damit gibt es weniger Netzwerkverkehr und der Arbeitsplatz-PC des Anwenders wird entlastet, weil er weniger Arbeiten muss. Nachtteil ist, das dieses Konstrukt mehr Serverleistung erfordert und viel schwieriger zu warten ist. Wenn es einen Programmierfehler in den Stored Procedures gibt, müssen alle Clients gleichzeitig berichtigt werden und ein großes Update ist fällig.

Segen – Performance-Gewinn – Fluch – man muss sauberer programmieren.

Ich gehe an dieser Stelle bewusst nicht auf die Versionsnummer von JTL-Wawi ein. Weil mit der aktuellen JTL-Wawi weder ein Release noch ein Patch Management überhaupt möglich sind. Und seit heute weigere ich mich sogar zu behaupten, JTL hätte mit seiner Warenwirtschaft den BETA-Status verlassen. So wie die Wawi sich gerade präsentiert, ist sie nicht für den produktiven Betrieb uneingeschränkt einsetzbar.

Begründung:

Mit jedem Update wird durch die Installation der Clientsoftware auch der SQL-Server mit angefasst. Marc schreibt dazu in der Facebook Gruppe für die Wawi:

Das bei jedem Update ein “Datenbank Update” durchläuft ist einfach dem Punkt geschuldet, dass sehr viel Logik in der Datenbank ist. Welche halt bei jedem Update einfach einmal neu geschrieben wird. Falls dort Fehler gefixt wurden. Die Struktur ändert sich jedoch nicht.

Im Klartext heißt das für mich, mit jedem Update werden die Stored Procedures der Wawi neu in den Datenbankserver geschrieben, ob sich hier nun etwas geändert hat oder nicht. Ich will, wie gesagt, hier nicht auf die Versionsnummern eingehen, die sind für das folgende völlig unerheblich. Weil folgende Aussage hat mich dann aber massiv auf die Palme gebracht:

Die wawi sagt halt selber Sie will immer mit der Aktuellen Version mit welcher die DB läuft laufen. Wenn diese Sicherheits Abfrage deaktiviert würde, würde die Wawi 1.0.4.0 wie auch 1.0.4.1, 1.0.4.2 ohne ein mucken mit der DB laufen. Klar es wäre geiler, wenn dies grundsätzlich klappen würde, Jtl Vielleicht eine SoftVersion noch einbringen würde, und es so möglich macht, dass auch ein Client der Version 1.0.4.0 mit der 1.0.4.2 DB zu Connecten, aber wenn es dann zu Fehler kommt, will das defintiv keiner Fixen, Fehler weil Bugs eigentlich behoben wurden. Jedoch jemand meint, ich arbeite noch mit der alten Version geht ja…. Grundsätzlich wäre sogar je nach Versionsprung (einfacher oder Komplexer) ein Rollback ohne Rücksicherung der DB Möglich. Aber ich glaube dafür wirt man sicher keinen von JTL oder von einem SP die das Know How haben so einfach überreden können.

Sicher wäre ein Rollback ohne Rücksicherung der Datenbank möglich. Aber keiner derer, die angeblich über das ultimative Wissen verfügt, will dies ermöglichen!

Sorry, hier hört gerade meine Form des Humors auf. Was bei anderen Softwareherstellern gang und gäbe ist, soll bei JTL nicht möglich sein! Wenn Clients mit Unterschiedlichen Release-Ständen zu Fehlern im System führen, ist die Software einfach nicht richtig getestet worden oder was tierisch Faul im System!

Einfaches Szenario:

Kunde spielt Update der Wawi auf allen Arbeitsplatzrechnern ein und muss nach drei Tagen feststellen, dass in der neuen Version sich ein Fehler eingeschlichen hat, der ein Rollback auf die vorherige Version notwendig macht. Egal wie ich die das mit den Versionsnummern hier nenne oder nicht, wird bei der JTL-Wawi auch ein Rollback der Datenbank fällig. Die Folgen für den Kunden können hier verheerend sein. Nicht nur das die Aufträge die in dieser Zeit aufgelaufen sind wieder auf irgendeine Art und Weise eingepflegt werden müssen, und zwar mit den richtigen Nummern. Wenn es ganz schlecht läuft macht der Kunde anschließend eine außerplanmäßige Inventur, um seine Bestände wieder auf Vordermann zu bringen.

Wenn ich an dieser Stelle mich bei einigen sehr unbeliebt mache, dann ist das sogar so gewollt. Hier bin ich gerne Homo Erectus (Der aufrechte Mensch). Sorry Thomas, deine Präsentation der Versionsnummern auf der JTL-Connect 2015 war ein netter Griff in die Trickkiste. Damit beeindruckt man die Kunden. Die Realität sieht so aus, das bis jetzt jede neue Version der Wawi nicht abwärtskompatibel ist. Damit findet auch keine Unterscheidung der Versionen in der Praxis statt – jedes Update ist weiterhin ein Major-Release (Ein großes Update) – egal was sich wirklich geändert hat.

Klar ist es leichter nach Außen zu zeigen, was alles toll ist. Ich finde es auch gut, das man seine Leistungen zeigt und stolz darauf ist. Aber nicht nur ich habe oftmals das Gefühl, als wenn gerade das wichtigste Produkt aus dem Hause JTL oft mit der heißen Nadel gestrickt ist. Und hier geht es nicht um eine Kleinigkeit. Hier geht es um die Datensicherheit der Anwender von JTL-Wawi. Natürlich kann das Verbbon-Spiel gut gehen. Aber es ist auch schon in der Praxis daneben gelaufen. Was für manche vielleicht nice to have (schön zu haben) ist, ist für mich hier required (erforderlich oder vorgeschrieben). Dabei gibt es aus meiner Sicht nur drei Arten von Software-Releases:

  1. Bugfixes die Fehler in der Clientsoftware beseitigen und keine Auswirkungen auf die Datenbank haben
  2. Service Packs, die alle Fehler bis zum Stichtag in der Clientsoftware beseitigen (quasi die gesammelten Bugfixes) und eventuell schwerwiegende Fehler in der Datenbank beseitigt (sollte aber im Changelog explizit ausgewiesen sein)
  3. Software Release, das Fehler in der Datenbank beseitigt, Änderungen an der Datenbank durchführt und neue Features dem Client hinzufügt.

Wenn also im Abstand von 4 Tagen jedes mal ein Software Release herausgegeben wird, was gleichzeitig mit dem Risiko des Datenverlust durch ein Rollback behaftet ist, dann empfinde ich diese Vorgehensweise als sehr fahrlässig. Hier stelle ich mir tatsächlich die Frage, ob das Entwicklerteam ihre Software im Griff hat, oder ob bei jedem Fehler, der Forum gemeldet wird, erst mal panisch nach den Ursachen geforscht wird. Die nächste Grundsatzfrage, die ich mir hier stelle ist, wie wird die Software vor dem Release getestet. Bei dieser dichten Folge an Updates sehe ich kein zufriedenstellendes Qualitätsmanagement.

Zu guter Letzt ein Blick aufs Changelog: Als Netzwerkadministrator kann ich relativ wenig bis gar nichts mit Ticketnummern und den gemeldeten Fehlern im Programm anfangen. In ein ordentliches Changelog gehören für mich nicht nur, welche Fehler aus Sicht eines Anwenders gemeldet (kann man sogar weglassen) und hoffentlich auch beseitigt wurden, sondern was sich am System geändert hat. Heißt ja auch Changelog. Jede Änderung an einem Computersystem ist ein Change (Änderung), die einen Change-Request (Änderungsanfrage) nach sich zieht. Und jeder Change muss vom Change-Manager getestet werden, ob auch alles wirklich funktioniert und dann abgenommen werden. Erst wenn die Freigabe vom Change-Manager erteilt wurde, kann die Software im Netzwerk verteilt werden. Wenn ich also im Changelog lese, das mit Ticketnummer 14858 folgender Fehler gemeldet wurde –

In Verbindung mit dem Packtisch wurden an Amazon teilweise keine Tracking-IDs gemeldet

dann frage ich mich an dieser Stelle, was hat sich jetzt wo geändert und welche Auswirkungen hat dies auf mein System, wenn ich dieses Update 1.0.4.2 jetzt einspiele. Da könnte auch stehen, in China ist ein Sack Reis umgefallen – hat den gleichen inhaltlichen Wert. Vielleicht besser so, das keiner die geistigen Ergüsse im Changelog der Wawi ließt, sondern nach dem Motto verfährt: „Geil Update – gleich mal herunterladen und installieren!“

Das ich hier JTL für seine Update-Praxis kritisiere, hat gute Gründe, wie mein Beitrag hoffentlich deutlich gemacht hat. Es geht nicht darum etwas schlecht zu machen, sondern den Finger auf die offene Wunde zu legen und zu zeigen, wo etwas deutlich besser gemacht werden muss. Die eigene Arbeit zu verteidigen ist legitim. Wenn man aber versucht Dinge einfach nur schön zu reden, fühle ich mich dann doch etwas verarscht.

4 Gedanken zu „JTL-Wawi – Der Update-Wahnsinn die Zweite“

  1. Ja, da ist noch ordentlich Luft nach oben, was das Quality-Management, das Release-Management und letztlich dadurch auch die Haltung zum Kunden angeht.

    Ich teste die 1.0.x nur auf einem isolierten System, halte aber trotzdem seit dem “Release” der 1.0.0.0 jeden Tag die Luft an und versuche mir einzureden, wenigstens arbeiten die auf Hochtouren an den vielen Kloppern. Aber das Ganze will scheinbar auch kein Ende nehmen und ich würde inzwischen sogar sagen, dass die Wawi auf dem Besten Wege ist, in 1-2 Monaten das Beta-Stadium zu verlassen… Die Leute, die – aus welchen Gründen auch immer, schon jetzt produktiv mit der 1.0.x arbeiten, tun mir wirklich leid.

    Kleines Beispiel: Ich habe vor ein paar Tagen gemeldet, dass in der 1.0.4.2 trotz Lagerbestand nicht alle Seriennummern eines Auftrags gewählt werden können. Der Support war schnell, freundlich, zielorientiert und hatte das Problem in 5-10 Minuten per TeamViewer isoliert, wirklich kompetent! Die Fix-Meldung kam Gestern und Heute kam die 1.0.4.3, in der man nun überhaupt gar keine Seriennummern mehr auswählen kann, hmm. Jemand anderes vom Support rief rasch zurück, hatte trotz Ticket offenbar KEINE Infos vom letzten Durchgang (?), hat aber rasch diagnostiziert, dass es da ein “großes Problem gäbe” und hat dies etwas später nach Rücksprache mit dem ersten Supporter/Developer bei einem Rückruf bestätigt und der Entwickler sei schon “schwer dran”. Soll heißen, auch bei JTL ließen sich keine Seriennummern mehr picken. Fragt man sich doch glatt, wie da release-getestet wurde, aber die Frage stelle ich mir bei vielen der ernsteren Threads im Forum? Also habe ich sofort zurückgeschrieben, dass dann aber die 1.0.4.3 sofort zurückgezogen werden müsste, damit die Produktivnutzer nicht auf die Schnauze fallen. Bis jetzt (8 Stunden später) aber Fehlanzeige und kein Hinweis im Forum dazu. Was will mir das sagen?

    Ich denke, dieses Beispiel illustriert das Problem ausreichend und in allen Facetten. JTL muß hier dringend erwachsen werden und solche Katastrophen wie dieser 1.0er Release dürfen sich einfach nie wiederholen! Die Usergemeinde mag zahlenmäßig vor allem aus kleinen Fischen bestehen, aber praktisch alle verdienen Ihr Geld mit kostenpflichtigen JTL Produkten und die Wawi ist dabei das Rad, das im Zweifel alle anderen Räder stillstehen läßt. Das muß JTL deutlich ernster nehmen! Und das auf der JTL Connect mehrfach gehörte Argument, vieles ließe sich nur live und produktiv testen ist keins, sorry, dann müssen die Prozesse überarbeitet werden.

    1. Hallo Ingmar,

      danke für deinen sau-guten Beitrag. Neben den technischen Problemen, die zugegeben bei so einem Projekt nie zu 100% ausbleiben, ist die Kommunikation nach Außen zu den Servicepartnern und den Kunden im Moment nicht gerade befriedigend. Die 1.0 hätte in dieser Form so nie veröffentlicht werden dürfen, da sie nicht ausreichend getestet war und ist. Viele Funktionen in der Wawi lassen sich mittels einer Musterfirma und den gegebenen Prozessen auch in einer Testumgebung testen. Die Ausnahme für mich ist die Schnittstelle zu Amazon, da Amazon meines Wissens keine Sandbox anbietet (Hier muss tatsächlich im Live-Betrieb entwickelt und getestet werden).

      Ich im Sommer diesen Jahres beim Vorstellungsgespräch in Hürth bei JTL für die Position eines technischen Redakteurs. Obwohl sie mich angesprochen haben, ich habe mich nicht dafür beworben, haben Sie einen Rückzieher gemacht. Ich weiß gerade nicht, für wen diese Entscheidung besser war.

      Gruß Michael

      1. Das wirklich Schlimme an dieser Situation ist aber, dass gerade solche in großer Eile und unter großem Druck (aka Panik) erstellten Fixes später typischerweise “Bestandsschutz” haben, weil es meistens eigentlich schlimme Hacks sind, die eben gerade so und vielleicht nicht anders funktionieren und wo später jeder Angst vor den Konsequenzen hat, wenn man die anfässt. Ich weiß aus viel leidvoller und teils leider auch aus eigener Erfahrung, wovon ich hier rede.

        Die Behinderungen, die daraus erwachsen, sind aber überhaupt nicht zu abzuschätzen und ich habe selbst an großen Releases von Software mit deutlich größeren Userzahlen mitgearbeitet, bei denen wir zu früh raus sind und sich die Software (intern) ehrlich gesagt NIE WIEDER davon erholt hat. Diese Gefahr ist real, auch für die 1.0er Wawi!

        Klarstellung: Ich hege VIEL Sympathie für JTL und ich arbeite gerne produktiv und jeden Tag intensiv mit der Wawi und dass, obwohl mein Geschäft total atypisch ist, nur ÖR- und Forschungs-Kunden, nur mit Angeboten, Fax-Bestellungen, Shop nein Danke, etc. Ich habe aber so ziemlich alle anderen Systeme, die für normales Geld erreichbar sind, durch und kann sagen, dass die Wawi mit dem (wenigen) was Sie kann, damit wie sie es tut und dem super-aktiven Forum einzigartig auf dem Markt ist und ich jedem, auf den sie passt, auch in (naher) Zukunft (wieder) zuraten würde, es damit zu versuchen.

        Deshalb will ich JTL als Firma hier auch nicht in den Senkel stellen, sondern eher sagen “Ok, und jetzt werdet erwachsen und lasst diesen voreiligen Mist, damit wir durch und mit Euch wachsen können und nicht trotz und gegen Euch wachsen müssen.”

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.