Wir haben bereits in der Vergangenheit einige Beiträge veröffentlicht, welche unsere Tätigkeiten in der Entwicklung aus technischer Sicht beschreiben. Oft ist für den Endanwender nicht immer klar ersichtlich warum wir Zeit und Ressourcen in bestimmte Themen investieren.

Um dies transparenter für Sie zu machen, möchten wir ein Grundlagen Thema der neuen Shop-Entwicklung einmal etwas detaillierter beleuchten:

Die ereignisgesteuerte Entwicklung in Verbindung mit Aufgaben und Warteschlangen.

Einleitung

Wenn man Prozesse auf einer Webseite oder in einem Online-Shop Abläufe einmal genauer „unter die Lupe nimmt“, wird man feststellen, dass dabei sehr viele einzelne Aufgabe und Prozesse auszuführen sind.

Nehmen wir ein Beispiel aus der Praxis: Ein neuer Endkunde registriert sich im Shop.

Ausgangssituation:

Der Endkunde hat in ihrem Shop das Registrierungs-Formular vollständig ausgefüllt und klickt anschließend auf den Knopf „Jetzt registrieren“.

Anschließend müssen einige Prozesse im Hintergrund ablaufen, von denen der Endkunde nichts mitbekommt/mitbekommen soll:

  • Alle Informationen, welche der Endkunde eingegeben hat (E-Mail-Adresse, Anschrift etc.) sollen dauerhaft gespeichert werden, damit diese später jederzeit wiederverwendet werden können.
  • Der Endkunde soll so schnell wie möglich eine Rückmeldung erhalten, welche ihn darüber informiert a) ob seine Registrierung erfolgreich war, b) ob seine Registrierung erst überprüft werden muss (je nach Systemeinstellung), c) ob seine Registrierung nicht angenommen werden kann (evtl., weil er schon registriert wurde), d) ob es technisch evtl. zu einem Fehler gekommen ist und seine Registrierungsdaten nicht gespeichert werden konnten etc.
  • Evtl. möchten Sie den Endkunden nicht nur am Bildschirm über den Registrierungsprozess informieren, sondern ihm auch eine E-Mail zukommen lassen, welche ihn über den Registrierungsstatus informiert.
  • Evtl. möchten Sie vor dem Start des Registrierungsprozesses erst einmal sicherstellen ob der Endkunde eine E-Mail-Adresse angegeben hat, welche tatsächlich erreichbar ist. Also muss vorab eine Bestätigungsemail an den Endkunden gesendet werden. In dieser Mail ist ein „Bestätigungs-Link“ enthalten den der Endkunde anklicken muss, um mitzuteilen „Ja, ich habe mich unter dieser E-Mail-Adresse registriert“.
  • Der Shop-Betreiber möchte evtl. darüber informiert werden, dass sich soeben ein neuer Endkunde registriert hat.
    Je nach Systemeinstellung muss der Shop-Betreiber die Neu-Registrierung evtl. überprüfen um diese „freizugeben“.
    (Nur freigegeben Endkunden dürfen im Shop bestellen)
  • Ist die Freigabe durch den Shop-Betreiber erfolgt, muss der Endkunde darüber informiert werden, dass sein Registrierungs-Prozess nun abgeschlossen ist und er Produkte im Shop bestellen kann. Eine entsprechende E-Mail-Benachrichtigung soll versendet werden.
  • etc.

Wie sie sehen fällt hier schon einiges an Aufgaben an, auf dessen Weg auch das ein oder andere „schief“ gehen kann:

  • Die Kontaktdaten des Endkunden können genau in diesem Augenblick aus irgendwelchen Gründen nicht gespeichert werden
  • Die E-Mails können nicht versendet werden, weil der Mailserver aus irgendwelchen Gründen nicht erreichbar ist
  • etc.

Was tun, wenn ein solches Problem auftritt?

Wie oft wird Ihr Endkunde den Versuch erneut starten das Formular neu auszufüllen?
Wird er es überhaupt tun oder geht er zum nächsten Shop in dem keine Probleme entstehen?

Wir alle kennen die Antwort! In min. 90% der Fälle wird der Endkunde das nicht tun – er ist „weg“ und Ihnen geht das Geschäft mit diesem Kunden durch die Lappen – völlig unabhängig von den Produkten oder der Preisgestaltung – es ist schon an der ersten „Hürde“ gescheitert.

Als Entwickler machen wir es uns somit zur Aufgabe, diese Hürden zu vermeiden oder zumindest auf die niedrigste, mögliche Schwelle zu reduzieren.

Was bedeutet diese Aussage in Zusammenhang auf das oben beschrieben Beispiel?

Als Entwickler haben wir dafür Sorge zu tragen, dass der Endkunde die Daten nicht noch mal eingeben muss, auch wenn Fehler während des Prozesses auftreten.
Fehlerhafte Prozesse (z.B. speichern, Mail versenden) müssen solange wiederholt werden bis es klappt – bzw. nach dem X-ten Versuch muss „jemanden“ mitgeteilt werden das dies nicht funktioniert.

Als Entwickler müssen wir dafür Sorge tragen, dass es auch möglich sein muss, bei einem gut etablierten Shop, auch 200 und mehr Registrierungen in der Minute verarbeiten zu können ohne, dass dies zu Problemen führt, oder der Shop dadurch zu langsam wird.

Prozesse, die wir einmal programmiert haben, sollten wir so entwickeln, dass Sie wiederverwendbar, konfigurierbar sind:
a) um Ressourcen in der Entwicklung zu sparen
b) noch viel wichtiger: um spätere Erweiterungen/Korrekturen nur an einer Stelle durchführen zu müssen.

In jedem Fall sollte der Endkunde damit nicht „belastet“ werden um ihn nicht zu „verlieren“.

Zusammenfassung der Entwicklungstechnischen Aufgaben

Wir müssen in der Lage sein:

  • Aufgaben abhängig vom eingetretenen Ereignis auszuführen
  • Aufgaben die durch z.B. Fehler nicht erledigt werden konnten nochmal ausführen
  • Weniger wichtige Aufgaben zeitversetzt zu starten, um die Geschwindigkeit des Shops nicht zu beeinflussen
  • Fehlerhafte Prozesse zu protokollieren, zu melden etc.

Ereignisgesteuerte Entwicklung vs. „Lineare Entwicklung“

Moderne Programmiersprachen bieten heute viele Funktionen und Techniken im Bereich der Ereignisgesteuerten Entwicklung.
Das von uns eingesetzte PHP Framework Laravel bringt hierzu von Haus aus noch viele Werkzeuge mit, die für uns die Umsetzung vereinfachen.

„Lineare Entwicklung“ (VShop PRO)

Die Programmiersprache auf der unser aktuelles Shop System „VShop PRO“ historisch bedingt aufbaut, unterstützt solche Funktionen und Techniken nicht.

Aus diesem Grund wurden Prozesse und Funktionen im VShop linear und nicht ereignisgesteuert programmiert.

Bei einer linearen Entwicklung werde Aufgaben einfach der Reihe nach abgearbeitet.

Nachteile:

  • Gibt es Fehler während des Ablaufs, werden nachfolgende Prozesse des Ablaufplans gar nicht mehr ausgeführt
  • Es ist nicht mehr nachvollziehbar welche Prozesse des Ablaufplans nicht ausgeführt werden konnte. Im Besten Fall ist noch der erste aufgetretene Fehler protokolliert. Folgeprozesse nicht da diese während des Ablaufs gar nicht erreicht wurden.
  • Lineare Prozesse beinhalten immer die komplette Logik und sind nicht tatsächlich wiederverwendbar.
    Beispiel:
    „Mail senden an den Shop-Betreiber“ ist eine Aufgabe des linearen Prozesses und auch z.B. in einem Prozess der das Kontaktformular an den Shop-Betreiber sendet.
    In einem Linearen-Prozess programmiert man die Aufgabe „Mail senden an Shop-Betreiber“ zwei Mal in einem anderen Kontext.
  • Zu ermöglichen fehlgeschlagene Prozesse neu auszuführen ist in der linearen Entwicklung nur mit sehr hohem Aufwand zu realisieren. Somit wird es bei Kosten/Nutzen- Analyse häufig in der Entwicklung nicht berücksichtigt.
  • Bei Einführung neuer Ereignisse, müssen entsprechende Prozessketten komplett neu programmiert werden. Der Aufwand ist entsprechend hoch.
  • Lineare Prozesse sind schlecht zu korrigieren und zu erweitern. Wird z.B. ein neues Feld im Registrierungsformular eingeführt (z.B. Platzbelieferung) muss die Änderung in alle Prozessketten eingeführt werden, die sich mit dem Registrierungsprozess befassen.