Blog: Latest Entries (15):


Shopware: Artikel-Events

Oft will man irgendwelche Aufgaben erledigen, nach dem ein Artikel gespeichert wurde. Z.B. kann es sein, dass man diesen Artikel prüfen und zu irgendwas hinzufügen möchte oder auch einfach mit dem Artikel verknüpfte andere Artikel mit updaten muss.

Es gibt ein entsprechendes Event, um auf das Speichern eines Artikel im Backend zu reagieren. Dabei wird ein allgemeines Controller-Event verwendet, wie es für jeden Controller erzeugt wird und gegen die dort aufgerufene Action geprüft.




public static function getSubscribedEvents(){
return [
'Enlight_Controller_Action_PostDispatch_Backend_Article' => 'articleRefresh',
];
}

public function articleRefresh(\Enlight_Event_EventArgs $args){
/** @var $subject \Enlight_Controller_Action */
$subject = $args->getSubject();
$request = $subject->Request();
if ($request->getActionName() === 'save') {
$params = $request->getParams();
//TODO do something
}
}



Nun fehlt noch, dass wir auch Änderungen mit bekommen, wenn ein Artikel über die REST-API geändert wird.

Der Controller ist "Articles" und das Module ist "Api". Also ist unser Event "Enlight_Controller_Action_PostDispatch_Api_Articles". Die Action ändern sich natürlich auch, weil wir bei der REST-API Actions wie PUT und POST haben.



public static function getSubscribedEvents(){
return [
'Enlight_Controller_Action_PostDispatch_Backend_Article' => 'articleRefresh',
'Enlight_Controller_Action_PostDispatch_Api_Articles' => 'articleRefresh',
];
}

public function articleRefresh(\Enlight_Event_EventArgs $args){
/** @var $subject \Enlight_Controller_Action */
$subject = $args->getSubject();
$request = $subject->Request();
if (in_array($request->getActionName(), ['save', 'put', 'post'])) {
$params = $request->getParams();
//TODO do something
}
}



Damit sollte man jede Änderung an einem Artikel mitbekommen.

Das gleiche Prinzip sollte entsprechend auch für alle anderen Controller funktionieren.

Invitation-Code bei mobile-time-tracking.com

Manchmal kann es sein, dass man die Email-Adressen von allen die man einer Gruppe hinzu fügen will nicht kennt. Gerade wenn sich diese mit privaten Email-Adressen anmelden.

Nun hat man für jede Gruppe in https://www.mobile-time-tracking.com einen Einladungs-Code den man verschicken oder in Chat-Gruppen teilen kann. Wenn ein Benutzer diesen Code eingibt, wird er automatisch zur Gruppe hinzugefügt.

bbcode-image


bbcode-image

Neuer MP4toGIF-Filter

Nach langer Zeit.. also einigen Monaten gibt es mal wieder einen neuen Bild-Filter für MP4toGIF. Er spiegelt die linke Seite des Bildes an der Mittellinie und ersetzt damit die Rechte Seite des Bildes.



Ist an sich ein sehr alter und schon oft verwendeter Effekt des etwas von 80er Jahre Musikvideos hat. Aber er ist eben auch schön trashig und retro und machte Spaß ihn zu bauen.

Video-Material von Under Siege aka Alarmstufe Rot.. der beste Steven Seagal Film !!!!

General error: 1436 Thread stack overrun

Wenn man in Shopware den Cache geleert hat und beim Anlegen der Keywords im Frontend danach eine Exception auftritt, die in etwas so "General error: 1436 Thread stack overrun" lautet, muss man die MySQL-DB anpassen.

Dafür muss man in der my.conf den Wert für den thread_stack erhöhen.


thread_stack = 768K


hat dann am Ende bei mir gereicht.

Einfacher Hintergrund Job mit WildFly

Manchmal möchte man einfach einen kleinen Thread laufen lassen, der eine kleine Aufgabe erledigt wie z.B. ein Verzeichnis überwachen oder auf SMS-Eingänge horcht. Normal würde man so einen einfach über die CLI starten und laufen lassen. Im WildFly ist es kaum anders nur dass man die CLI-Argumente aus einer Config-Datei lesen muss.


package de.hannespries.test.wildfly;

import javax.annotation.PostConstruct;
import javax.ejb.Singleton;
import javax.ejb.Startup;


@Startup
@Singleton
public class SimpleThreadTest {

@PostConstruct
public void startThread(){
//TODO read config
TestThread thread = new TestThread();
thread.start();
}
}


Wenn man Zeitgesteuert arbeiten möchte ist ein Scheduler des WildFly anstelle eines eigenen Threads aber die bessere Wahl.


Events mit mobile-time-tracking.com

Wie man mobile-time-tracking.com auf für Events nutzen kann.

Events behandeln wir hier bei wie einen normalen Kunden. Ich werde die Übersetzung noch mal neu machen und dann wird es alles auch auf Deutsch geben und dann werde ich Events direkt mit einbringen.

Zuerst legen wir uns eine Gruppe für unsere Events an. Gruppen haben die Aufgabe ähnliche Kunden und Events zusammen und auch die Zuordnung zu den Benutzern abzubilden. Gruppen sind dafür da wenn man für verschiedene Firmen Kunden als Freelancer bedient oder für Teams und Abteilungen in einer Firma, die alle einzeln ihre Kunden und Zeiten abrechnen.

Wir legen also hier eine Gruppe „Events“ an, damit wir unseren Mitarbeitern und Aushilfen bei den Events die Möglichkeit geben Zeiten auf die Events buchen zu können.

bbcode-image


Danach kommt jetzt unser Event No1. Das legen wir direkt an. Wir brauchen dafür nur einen Namen. Kontaktinformationen werden nicht benötigt, helfen aber den Mitarbeiten um zum Kunden oder zur Event-Location zu finden oder sich dort zu melden, falls etwas etwas zu klären ist. Die OpenStreetMap-Integration ist jetzt nicht wirklich toll, aber doch eine Hilfe, um den Weg zu finden, falls man sich dort nicht auskennen sollte. Aber es ersetzt keine "echte" Navi-App.

bbcode-image


Ich überlege gerade ob Appointments praktisch wären.. also man Termine für einen Mitarbeiter eintragen kann, so damit der Mitarbeiter weiß, wann er wo sein soll. Also etwas wie „Event No1, Appointment 17:00“. Dann weiß der Mitarbeiter, dass er um 17:00 an der Event-Location von Event No 1 sein soll.

Falls jemand das System benutzt und so etwas gerne hätte.. einfach bei mir melden und ich bauen es ein :-)

Nachdem wir unser Event No1 anlegt haben, können wir Zeiten darauf buchen. Aber wir wollen ja, dass unsere Mitarbeiter ihre Zeiten darauf buchen.

bbcode-image


Also gehen wir "edit“ bei der Gruppe und tragen weiter unten den Benutzernamen/ die Emailadresse unseres Mitarbeiter ein. Er muss dafür bei mobile-time-tracking.com registriert sein.

bbcode-image

bbcode-image


Danach sieht er die Gruppe auch auf seiner Startseite und kann seine Zeiten auf die Events in der Gruppe buchen.
Wenn er also bei der Event-Location ankommt, wählt er das Event aus und drückt auf "Start“. Nachdem er dort fertig ist drückt er auf "Stop“ und geht glücklich und erschöpft nach Hause.

Der Besitzer der Gruppe darf alle Zeiten sehen. Normale Mitarbeiter (also !Besitzer) sehen nur ihre eigenen Buchungen.

Immer Refactoring, nie einfach nur hinzubauen

Stellt euch mal ihr kauft ein Haus und alles sieht gut aus. Gute Wände, viele Steckdosen, alles sieht ganz modern aus. Aber dann nehmt ihr die Verkleidung von der Wand und ihr merkt, dass der Vorbesitzer einfach nur schöne neue Sachen ran-/vorgebaut hat und die Grundstruktur alt und schlecht ist. Anstatt beim letzten Umbau neue Kabel zu ziehen und Steckdosen zu setzen, würde einfach eine Verkleidung vor den alten Kram gesetzt und darauf dann die neuen Steckdosen verbaut.

Dass kennt man vom Entwickeln sehr gut. Wenn man einen Service in PHP 7.1 schreibt mit nullable Arguments und void return-Type und dann das Laden der Daten über mysqli geschieht und die DB-Logik nicht mal gekapselt wurde.

Also wenn man was neues baut, immer auch an den alten Code denken, der damit zusammen hängt und gerne diesen auch dann modernisieren/renovieren.
Sonst ärgert man sich später um so mehr, wenn man alles zeitlich falsch einschätzt, weil alles zu erst nachdem schönen modernen Code aussah.

bbcode-image

WildFly und IntelliJ IDEA, erstes Deployment

Falls es beim ersten Deployment zu einer Fehlermeldung vom JBoss/WildFly kommt, das eine Resource nicht gefunden werden könnte. Sollte man "STRG" + "SHIFT" + "ALT" + "S" drücken und dort unter Artifacts das vorhandene Artifact auf einen "Archive"-Typ ändern.

bbcode-image


Diese Artifacts sind ganz praktisch, da man sie gut in einander verschachteln kann. Man nutzt ein Artifakt zum Bauen der Haupt-JAR und nutzt dieses Artifakt dann wieder im dem Artifakt, das man zum Bauen
der EAR nutzt.

bbcode-image


Maven Elemente kann man einfach mit rein packen in die EAR und die entsprechenden JARs werden in der fertigen EAR abgelegt. Teilweise sehr viel einfacher als eine Standalone Anwendung über Maven zu bauen, wo auch alle Libs als JAR in eine große JAR zusammen kompiliert werden.

Ich mag EAR-Files....

und ich hatte auch etwas den Kampf mit dem JBoss/WildFly vermisst.. so etwas hat man mit PHP einfach nicht.

Resteasy toHeaderString Nullpointer Exception

Meine Lösung für dieses Problem https://issues.jboss.org/browse/RESTEASY-1579.

bbcode-image


Ich hatte einfach keine Lust eine neue Modul-Version in meinen lokalen 10er zu basteln. Also auch wenn man seit JBoss 7 an sich Pause hatte und erst jetzt wieder mit WildFly 10 angefangen hat... es sind immer noch genau die selbe Art von Problemen die einen Ärgern.

Ich mag WildFly trotzdem :-)

Bremen 2017 - Switch Time-System in Action

Am 24.6. war es wieder so weit und das Bremer Oldtimer-Rennen stand wieder für mich vor der Tür. Wie im Jahr davor sollte meine Aufgabe sein, die Zeitmessungen (jeden Falls einen Teil davon) durch zu führen und am Ende die Gewinner benennen zu können. Klingt erst einmal ganz einfach aber für diese Sache, die an sich voll automatisch laufen sollte, ist immer viel mehr zu tun als man so denken würde.

Dafür muss man das Grund-Setup kennen und verstehen. Bei dem Rennen nehmen 170 Autos teil. Jedes dieser Autos wird mit einem aktiven RFID-Tag ausgestattet der den Tag über die Kennung des Autos aussendet. Die Veranstaltung besteht genau genommen aus 3 Rennen. Da es natürlich unfair wäre, bei Autos von 1920 bis 1970 auf Minimalzeit pro Strecke zu fahren, wird immer auf eine Richtzeit gefahren. Der Fahrer, der am dichtesten an der Zeit dran ist gewinnt. Also kann der zweit etwas langsamer als die Zeit sein und der 3. etwas schneller. Es nur um die absolute Differenz.

Am Anfang und am Ende jeder Strecke steht dabei ein RFID-Reader, der alle Autos erfasst, die vorbei fahren.

RFID sendet aber bei einem aktiven Tag mehr als die Sekunde sein Signal und die Reader decken mit ihren Antennen einen größeren Bereich ab. Es funktioniert also grundlegend anders z.B. eine Lichtschranke. Man bekommt also eine Menge an Messwerten, die vom Auto gesendet werden, während es vorbei fährt. Daraus wird nach dem relativ einfachen Prinzip von Zuerst-Gesehen und Zuletzt-Gesehen der Mittelwert berechnet.

Dabei kann an sich schon genug schief laufen. Gerade wenn man kleine und kurze Strecken hat. Wenn das Auto schon soweit beim Start an den Reader heran fährt und schon Messwerte erfasst werden, aber das Auto noch nicht losfährt. Dann wird die Zeit in der das Auto steht, mit Pech mit in die Zeitberechnung mit hinein gerechnet.
Aber auch die Chips und Sender der Tags sind nicht immer zuverlässig. Auch wenn sie 100 mal die Sekunde senden sollen, kann man nicht immer sicher sein, dass es keine Einbrüche in dieser Frequenz gibt. Autos aus Metall können außerdem sehr gut Abschirmen und so die Sendeleistung stark beeinflussen. Bautechnische Probleme wie schlechte oder defekte Schalter zum Ein- und Ausschalten kommen noch dazu.
Diesmal hatten wir im Vorwege das Problem, dass allein durch die Bewegungen der Tags in der Kiste sich einige einschalteten und anfingen zu senden und so Tags empfangen wurden, die gar nicht zum Rennen gehörten.

Durch einen guten Aufbau und ein wenig mehr Programm-Logik kann man fast alle Probleme unter Kontrolle bringen. Aus der Menge der Messpunkte werden konkrete Werte errechnet. Mehrfachmessungen eines Autos werden entfernt und fehlende Messungen werden herausgesucht. Das benötigt etwas mehr Rechenleistung, weswegen die Messstationen mit etwas Leistungsfähigeren Notebooks ausgestatteten sein müssen.

Damit kommen wir erst einmal wieder zurück an den Anfang. Die Vorbereitung und was diesmal alles zu tun war.

Vorbereitung:

Nachdem im letzten Jahr mehr oder weniger spontan Notebooks mit dem Mess-Client ausgestattet wurden und es zu vielen Problemen kam:

- Fehlende Runtime-Umgebungen
- andere Server-Anwendungen die Ports blockierten
- Notebooks auf denen schon so viel installiert war, dass sie langsam waren
- Akkus die nicht mehr lange durch hielten und deswegen immer Strom nötig war (den es nicht immer gibt)

Ich fing also schon 2 Monate vorher an, das Problem in Angriff zu nehmen. Ich entschied mich die Hardware diesmal komplett selbst zu stellen und somit etwas mehr Sicherheit zu haben. Das Alienware sollte diesmal nicht benutzt werden, da es schwer ist und man es nicht mal schnell zur Seite nehmen kann, wenn es regnet. Außerdem ist es einfach nicht dafür gedacht, über den Akku zu laufen.. jedenfalls nicht langer als 15min.
Da ich für Notfälle aber eine Entwicklungsumgebung haben wollte, damit ein Fehler nicht ein Rennen versauen kann oder die Auswertung unmöglich macht, entschied ich mich mein Surface mit zunehmen. Es ist relativ Wetter-beständig und der Akku hält sehr lange. Die Rechenleistung ist nicht wirklich groß, aber ausreichend.

Damit waren meine eigenen Notebook Vorräte aber erschöpft und extra welche Kaufen würde sich nicht lohnen. Also kam ich auf die Idee meine Kontakte als Mitarbeiter bei Notebooks Wie Neu zu nutzen. Ich konnte mir 2 Lenovo Thinkpad T410 leihen. Mit i5, 4GB RAM waren die mehr als schnell genug und Thinkpads sind auch stabil genug, so das ich mir wegen Regen nicht zu viel Sorgen machen musste. LAN und USB Anschlüsse waren auch vorhanden. Der Akku hielt mehr als genug und am Ende waren die Akkus nicht mal halbleer, obwohl die Thinkpads ca. 2h damit beschäftigt werden durchgehend Daten abzurufen und in eine MySQL-Datebank zu schreiben.

Nur eine Sache störte mich etwas.. das war Windows 7. Egal was viele im Internet so schreiben.. bei der Bedienung ist Windows 10 sehr viel schneller und intuitiver als Windows 7. Aber da alles wie Java 1.8 und MySQL laufen, ist es nicht so schlimm, weil die Client-Software sowie so rein über die CLI bedient wird. Eine GUI Version existiert, ist aber noch auf eine Verbindung zum Server angewiesen, was da nicht gegeben war. Ein portabler UMTS-WLN-Router wäre eine gute Lösung gewesen, aber die Idee kam mir zu spät und ich wollte ja gerne den Server bei Problemen schnell ändern und fixen können. Was mit einer lokalen Instanz, die man direkt in der IDE hat, natürlich sehr viel schneller und einfacher geht als mit einem System das auf einem Server im Internet läuft.

Vielleicht bin ich nächstes Jahr mal mutiger. Es hätte auch noch andere Vorteile für die Veranstalter.. aber dazu später mehr.

Die Liste der Teilnehmer konnte ich am Abend vorher importieren und dabei noch 2 kleine Fixes einbauen. Deswegen wollte ich die Liste gerne schon vorher haben.
170 Autos. 170 importierte Rennteilnehmer am Ende. Alles perfekt.

Ich hatte also 4 Notebooks (das Alienware war als Fallback dann doch dabei), Reader, Netzwerk-Kabel und einen Switch. Was man aber immer dabei haben sollte, ist auch Essen und Trinken. Wasser und Energiedrink. Eines für den Durst und das andere für Energie. IBUs für Notfälle und natürlich das Smartphone für Navigation und Informationsbeschaffung. Beim Essen kann man sich ruhig abends vorher was kochen, denn gutes Essen macht es einen sehr viel einfacher, wenn man morgen um 4:15 aufstehen muss und dann noch kein Frühstück hatte.

bbcode-image


Immerhin war das Wetter gut und nicht so verregnet wie im letzten Jahr... jeden Falls am Anfang

Der Tag:

Um 4:45 war ich in Stockeldorf bei "die Halle" wo die Switch GmbH ihren Sitz hat. Die Mitarbeiter wuselten durch die Gegend und packen alles in den VW Bus was man so brauchte. Dann wurde ein Karton mit Tags hochgehalten und gefragt, ob die auch mit sollen. "Nein, das sind die, die nicht funktionierten und ausgewechselt wurden".
Klingt erst einmal nicht so schlimm, aber wenn man bei 170 Teilnehmern 30 Tags für jeweils drei Rennen austauschen muss.. also 90 Einträge per Hand bearbeiten, dann klingt es nicht mehr gut. Am Ende wurden also diese Ausgetauschten alle geöffnet und Batterien getauscht. Am Ende waren es pro Rennen nur jeweils ca. 6 Tags, die per Hand übergetragen werden mussten.

bbcode-image


Hier fiel mir auch auf, dass die Tags dieses Jahr gefühlt sehr viel Fehleranfälliger waren. Beim Testen wurden noch 4 ausgetauscht, weil sie nicht vom Reader erkannt wurden. Die Schalter schalteten in den Karton bei jeder kleinen Bewegung wie sie wollten.

bbcode-image


Und dann kam der Regen. Viel Regen. Alles wurde unter die offene Heckklappe des VW-Bus gestellt und das Surface wechselte erst einmal in eine Plastiktüte.
Es war zum Glück nicht wirklich kalt. Nur sehr sehr nass. Wer glaubt das Regen und die Nässe nur immer von oben kommt, irrt sich. Tropfen fallen auf Tische und spritzen dann in alle Richtungen. Am Ende ist doch alles nass.
Aber es gab auch positives zu berichten. Weniger Tags streuten in den Messbereich und die Erkennung war dieses mal sehr viel besser. Das andere Team meldete sich schon kurze Zeit später und meldete, dass alles laufen würde. Ich bin immer sehr unruhig wenn ich bei so etwas nicht in der Nähe sein kann, um möglicherweise auftretende Fehler zu beheben. Ich kenne das System zu 100% und einfach unerfahrene Benutzer damit los zu schicken.. dazu gehört sehr viel Vertrauen in die eigene Software dazu.
Am Ende war alles super. Alles hatte beim ersten Rennen funktioniert und das Thinkpad konnte zeigen was es konnte. Beim Surface braucht ich so 15min mit Client in der IDE um die Daten zu übertragen. Dabei liest der Client und schreibt der Server auch in die selbe Datenbank, was auch nochmal bremst. Das Thinkpad brauchte gerade mal 4-5 Minuten. Schnelle CPU, schnelles Lesen von der Festlatte. Das Schreiben in die DB auf dem Surface war dann auch sehr entspannt, weil nebenbei nicht so viel gelesen oder gerechnet werden musste. Also Server und Entwickler-Rechner hat sich das Surface mehr als bewährt. Das selbe gilt auch für die Thinkpads als Messstationen-Clients.

bbcode-image


Das 2. Rennen war dann die kritische Phase, die dann aber auf Grund der stabilen Bauweise der Reader und viel Nachrechnen und eliminieren von Fehlmessungen, am Ende doch gut ging. Wir hatten kaum Zeit zum Aufbauen, ein Reader lief an einem Diesel-Generator und 50m Lan-Kabel. Die ersten Autos wurden manuell gemessen mit der eingebauten App vom Time-System, während wir nebenbei den zweiten Reader aufbauten, der dann am Alienware lief. Sturm, Regen und noch mehr Regen. Wir saßen im Bus und nur die Kabel zu den Readern im Regen gingen nach draußen. Ich wüsste zwischendurch nicht ob der Reader am Start noch lebte und Daten sendete. 1,5h später war der Regen vorbei und man ordnete sich und guckte mal wieder auf die Terminal-Ausgaben auf dem Surface. Alles lief super. Es fuhr gerade das letzte Auto vor und der Reader meldete den Tag also ob vorher nicht gewesen wäre. Sein Netzteil hing so im Regen und ein Teil des Kabel lag vorher schon blank. Aber kein Aussetzer bei der Datenerfassung. Ich war wirklich stolz auf den kleinen tapferen Reader.
Das Netzwerk-Kabel wurde auch nebenbei als Streckenbegrenzung verwendet. Von der Planung her eine Katastrophe, aber mit den Fallback-Lösungen konnte man alles retten.

Danach ging es zur Test-Strecke von Mercedes und das 2. Thinkpad übernahm das Rennen dort. 1. Rennen war in 20min fertig. Ich hab bevor Korrektur-Funktionen über die Daten liefen immer lieber noch einmal die Daten gesichert. Berechnen lief schnell.
Das 2. Rennen brauchte mehr Zeit. über eine Stunde, da ich viel bei den Korrektur-Funktionen nacharbeiten musste, die Fehlmessungen eliminierten und ich lieber 3 mal die Liste der gefahrenen Autos durch ging, um sicher zu sein, dass wirklich kein Auto übersehen oder nicht gemessen wurde.

bbcode-image


Das 3. Rennen ging dann wieder sehr schnell und es gab keine Überraschungen.

bbcode-image


Bestes Frauen-Team musste dann per Hand berechnet werden. Waren aber nur sehr wenige Teams, deswegen ging es. Der Gesamtsieger war aufwendiger, weil man über die gesamten drei rennen Rechnen musste, zum Glück sind es doch immer die selben Fehler die vorne liegen. Damit war es ausreichend die 9 Sieger der 3 Rennen zu nehmen und für diese die Werte der 3 Rennen auszuwerten. Kontrolle bei den 4. und 5. Plätzen zeigten gleich, dass von dort keine Konkurrenz mehr kam.
Auch fiel dabei auf, dass man kein großes Kopf-an-Kopf-Rennen hier hatte. Die ersten Plätze waren immer sehr eindeutig, eher am Ende des ersten Drittels konzentrierten sich die Zeiten auf eine geringe Zeitspanne.

Das Fazit:

Das Event lief sehr viel besser als das letzte Jahr und die Zeiten für die Auswertungen war sehr viel geringer. Die automatischen Analysen und Korrekturen von Fehlmessungen hat viel gebraucht und sehr viel besser und zuverlässiger funktioniert, als es per Hand war.
Trotzdem hätte ich gerne eine andere Lösung für das nächste mal. Die Tag an sich sind eine Fehlerquelle für sich und diese würde ich gerne eliminieren. Eine Lösung wäre eine Kamera gestützte Erfassungsmethode mit QR-Codes. Wie Lichtschranken, gibt es da aber Probleme bei parallel fahrenden Autos. Deswegen müsste man ein Gestell haben, um die Kameras von oben auf die Start- und Ziellinie gucken zu lassen. Dann muss man die Autos erkennen, da man so wirklich von vorderen Punkt des Autos messen kann und nicht nur die Position des RFID-Tags (was viele Teilnehmern nicht klar war, sich aber natürlich auf die Messungen auswirkt).
So ein System ist sicher zu bauen, aber braucht seine Zeit. Am Ende hätte man aber sicher gute Ergebnisse mit Beweisfoto.

Auch sollte alles so aufbaubar sein, dass die Technik die Autos nie verlassen muss. Mehr Schutz vor Regen und man kann schneller aufbauen, wenn nur noch Kabel verlegt werden müssen.

Ein großer Traum wäre es, es wirklich als Cloud-Anwendung laufen zu lassen, so dass die Clients direkt vor Ort über einen WLAN-UMTS-Router ihre Daten direkt an den Server schicken können. Vielleicht sogar kurz nach dem sie gemessen wurden. Damit hätte man auch die Möglichkeit eine Echtzeit Anzeige zu realisieren.

Nochmal im NBWN-Blog

Creditfair Vereinsprogramm

Das Creditfair Vereinsprogramm ist released worden. Es basiert auf einem Shopware 5.3 Shop, das mit verschiedenen eigenen und dafür geschriebenen Plugins erweitert wurde.

bbcode-image


Auf der Seite kann ein Sportverein sich registrieren und für jede Angebotsanfrage eines Mitglieds, die zu einem Vertrag führt, wird dem Verein eine entsprechende Menge an Punkten gut geschrieben, die der Verein dann in Prämien eintauschen kann.

Es gibt also zwei verschiedene Kunden-Arten. Die normalen Mitglieder der Vereine, die sich Informationen über die Leistungen von Creditfair auf der Seite einholen können und dann über ein Anfrage-Formular ein Angebot anfordern können.
Dann gibt es noch die Vereine, die die eigentliche Shop-Funktionen nutzen und ihr Bonuspunkte-Konto dort pflegen können.
Vereine können sich nicht direkt registrieren sondern werden von einem Administrator dort angelegt und freigeschaltet. Es ist hier also eher eine B2B Lösung in einem sehr kontrollierten Rahmen.

Um diese Funktionen abbilden zu können, kommen 3 Plugins zum Einsatz:

1. Das Bonuspunkte-Plugin
Hier erhält jeder Verein ein Budget von Bonuspunkten, die ihm auch im Account angezeigt werden. Das Eintragen der Punkte geschieht im Backend. Dawird nicht nur ein einzelner Punkte-Wert gepflegt, sondern es gibt einzelne Einzahlungen. Das sit wichtig, weil die Punkte eine Sperrzeit haben können. Wenn nun ein Vereinsmitglied einen Vertrag abschließt erhält der Verein direkt seine Punkte. Das Vereinsmitglied hat aber natürlich noch eine Zeitspanne in dem es vom Vertrag zurück treten kann. Erst wenn diese Zeit abgelaufen ist, können die Punkte auch verwendet werden.
Im Checkout wird eine Bestellung verhindert, wenn sie das Budget übersteigt und die ausgegebenen Punkte werden nach der erfolgreichen Bestellung verrechnet und abgezogen.
Punkte verfallen nach einem gewissen Zeitraum auch wieder, wenn man möchte.

bbcode-image


Dieses Plugin wurde allein für diese Seite geschrieben und deckt eine sehr spezielle Anforderung ab, die mit den vorhandenen Lösungen so nicht erreicht werden konnte.

2. Kunden/Vereins-Liste
Da man gerne damit werben wollte, welche Vereine schon an dem Programm teilnehmen, sollte eine Liste der Vereine mit Logo, Beschreibung und Suche ermöglicht werden. Hier kann jeder Kunde/Verein sein Profil selbst verwalten. Unter jedem Eintrag kann es einen Promotion-Link geben, der auf eine andere Seite verlinkt und den Vereinsnamen mitgibt (z.B. zum automatischen befüllen eines Formulars.. was momentan noch eher schlecht als recht funktioniert).

bbcode-image


Dieses Plugin dient also rein zur Eigenwerbung und der Präsentation der Kunden. Das sich die Kunden selbst noch mal präsentieren können, ist dabei eher nettes Beiwerk.

bbcode-image


3. Registrierungsanfrage mit eigenen Formular
Vereine sollen sich über ein Formular melden, damit ein Admin sie anlegen können. Dabei soll das normale Formular für die Registrierung durch ein eigenes ersetzt werden.

bbcode-image


bbcode-image


Hier kommt mein eigenes Plugin zum Einsatz, das unter anderen die Funktion bietet ein beliebiges Formular dort anzeigen zu können. Es sind keine speziellen Formulare, so dass diese ganz normal wie immer im Backend angelegt und bearbeitet werden können.

bbcode-image


Neben den Plugins waren die Einkaufswelten der zweite große Punkt bei der Realisierung. Man klickt diese nicht in paar Minuten zusammen. Auch sollte man davon ausgehen, dass man HTML + CSS schreiben muss. TinyMCE ist nett, kommt aber auch sehr schnell an seine Grenzen. Ein Duo aus Designer und Entwickler/Programmierer ist hier nötig, wenn nicht direkt beides in einer Person hat. Man kämpft viel mit dem Layout. Bilder suchen und finden kann auch ein größerer Unterfangen werden.
Mit 5.3 kann man Einkaufswelten exportieren. Damit gibt es Staging und man kann sich selbst Sicherheitskopien ziehen und Änderungen versionieren. Ohne ist es echt nervig, da man nicht einfach Undos für größere Bereiche hat.

bbcode-image


Und für Mobile-Ansichten muss man nochmal Hand anlegen. Das Grid ist gut, aber funktioniert eben auch anders als das von z.B. Bootstrap das sich besser anpasst. Auch die Skalierung der Bilder muss beachtet werden. Sie verhalten sie wie "cover" bei "background-size" in CSS. Also sind Bilder gut, die viel freie Fläche am Rand hab, die abgeschnitten werden kann und das Bild Trotzdem noch gut aussieht. Fotos funktionieren hier sehr viel besser als
Info-Grafiken.

Das Projekt wurde "nebenbei Abends" innerhalb von 3 Monaten Umgesetzt, was wohl 2 Wochen normaler Arbeitszeit entsprechen würden und war mein erstes echtes Shopware-Projekt. Es gab viel zu lernen aber auch viele positive Erkenntnisse wie einfach es ist mit Shopware zu arbeiten und zu entwickeln.

Oracle und Java EE

Wie man überall lesen kann will Oracle nun auch JEE gerne abgeben. Aber sie sichern zu weiterhin an Java festzuhalten.

In den meistens News klingt es so als wäre das ein Widerspruch in sich. Ich kann Oracle aber vollkommen verstehen. Der Java-Core ist so oder so OpenSource und JEE ist optional und kann durch andere Lösungen wie Spring ersetzt werden. Wie Standards wie JMS, EJB3 und so sind wirklich toll und funktionieren super. Sie werden auch viel genutzt, also kann man die auch nicht wirklich sterben lassen, gerade wenn man selbst damit viele Anwendungen gebaut hat.
Oracle auch wirklich viel mit Java gemacht und auch sehr gute Anwendungen damit entwickelt. Nur warum sollte man dafür im Besitz eine Standards sein? Als das alles noch bei Sun lag lief auch alles super und (jetzt folgt der wichtige Punkt) man musste sich nicht mit dem ganzen Drumherum rumärgern.
Als PHP Entwickler hat man ja auch nicht gleich Lust sich den PHP-Standard noch mit auf zu halsen.

Bei der Eclipse Foundation wäre JEE gut aufgehoben und Oracle kann weiterhin mit Java entwickeln und sich sogar einbringen ohne gleich für alles verantwortlich gemacht zu werden.

Ich bin jeden Fall gespannt wie es weiter geht und sehe da mehr Zuspruch in die Zukunft Javas von Oracles Seite als mögliches Abwenden von JEE oder gar Java an sich.

PS: Ich sehe es ähnlich wie dieser Artikel auf Heise-Developer

Shopware Kunden Registrierungsanfrage

Manchmal will man nicht, dass sich Kunden direkt registrieren können. Sie sollen dann ein Formular ausfüllen und werden dann vom Administrator des Shops anlegt.
Dafür muss natürlich deaktiviert sein, dass Gäste bestellen können, damit man es nicht einfach umgehen kann.

Ich werde mein Plugin dafür wohl versuchen in den Community-Store von Shopware zu bekommen, da es wirklich mal ein Plugin mit allgemeinen Nutzen ist und nicht nur für einen Kunden einen ganz bestimmten Fall abdeckt.

bbcode-image

Shopware... Standards und Plugins

Ich habe mich jetzt die letzten 2-3 Monate doch relativ ausführlich mit Shopware beschäftigt. Das erste Projekt das live ging war das Creditfair Fair-Vereinsprogramm. Dafür mussten 2 Plugins geschrieben und einige Theme-Anpassungen vorgenommen werden.

Die Plugin-API mit den Events ist wirklich einfach zu erlernen. Einzig die Suche nach dem passenden Event kann immer etwas länger dauern, wobei am Ende weniger die Frage ist, ob es das richtige Event ist, sondern ob es das beste Event ist. Events für jeden Fall gibt es mehr als genug, wobei die Unterschiede wirklich oft in Feinheiten zu suchen sind.

Nebenbei habe ich als Test ein kleines Plugin geschrieben, das das Kunden-Objekt (wenn denn ein Kunde eingeloggt) ist auch beim Versenden von Forms im Template verfügbar macht. Forms verwenden eine eigene kleine und sehr einfache Template Engine. Für die Erweiterung um den Kunden kommt aber dann Smarty3 zum Einsatz. Damit kann man bei Anfragen über Forms, die nur angemeldeten Kunden zur Verfügung stehen, die Kundendaten direkt zur Email hinzufügen, ohne dass der Kunde es selber tun muss.

Hier kann man es Downloaden

Insgesamt macht es viel Spass mit Shopware zu entwickeln.. nur.. nur eine Sache gibt.. die bereitet mir noch Kopfzerbrechen.

STAGING


Mit der 5.3 kann man wenigstens Einkaufwelten exportieren und wieder importieren. Das ist schon mal wirklich eine große Hilfe, da so Designer auf dem lokalen System arbeiten und testen können und man erst dann nach der Freigabe die Einkaufwelten auf das produktive System verschieben kann.

bbcode-image


bbcode-image


Themes kann auch relativ einfach kopieren. Plugins aus dem Community-Store sollte man so oder so nicht durch ein Staging laufen lassen, sondern auf dem produktiven Server neu installieren und konfigurieren.

Content-Seiten sind der Punkt, wo ich noch am Überlegen bin wie man damit umgehen soll. Hier fehlt eine vergleichbare Import/Export Funktion wie bei den Einkaufwelten.


Ein anderes Thema betrifft Shopware aber auch fast alle anderen Shop-Systeme. Das Problem beginnt damit Produkte, Hersteller, etc in das Shop-System zu bekommen. Denn wenn man keinen winzigen Shop mit 10-50 Artikeln hat, wird man sicher die Produkte aus einem Waren-Wirtschafts-System beziehen wollen. Die REST-API von Shopware ist toll und man kommt schnell zu Ergebnissen. Der CSV-Import ist auch nicht schlecht. Aber das Problem ist, dass man dann immer eine Lösung für Shopware baut. Bei anderen Shops eben für das jeweilige System.
Es gibt wohl kaum Shop-Systeme (oder ich konnte sie nicht finden), die Standard-Formate als Core-Feature lesen oder schreiben können.

Bei der Arbeit dürfte ich nun mit CSV, XML und IDocs aus SAP kämpfen. IDocs sind für den Datenaustausch wirklich nicht toll. Jedenfalls nicht, wenn man die SAP-Welt verlässt. In dem Artikel Warum Sie beim Datenaustausch im E-Commerce auf Standardformate setzen sollten von Daniel Peters trifft es sehr gut gut. Ich stimme da zu 100% zu und er trifft wirklich den Punkt, den ich schon seit Jahren nicht verstehe. Wenn ich ein neues System entwickle, dass mit anderen Systemen kommunizieren und Daten austauschen muss. Warum baue ich mir dann immer wieder ein eigenes Format und nehme mir nicht von Anfang an ein Standard-Format. Damit habe ich auch schon mal eine Art Blaupause, wie man mit dieser Art von Daten umgehen kann und sollte mal ein System ausgewechselt werden, muss ich hoffentlich nicht wieder ein neues proprietäres Format in eine Schnittstelle für mein System umwandeln.

Ich hatte mir ein kleines Plugin geschrieben, dass Bestellungen direkt nach dem Speichern als JSON auf dem Server abgelegt hat. Es war zuerst zur Kontrolle und zum Debuggen auf dem Live-Server da. Es hat nicht lange gedauert und ich hatte auch einen XML-Export und 2 Stunden später auch einen rudimentären [url=]OpenTrans[/url] 1.0 export. Auch wenn der Standard sicher noch nicht zu 100% korrekt umgesetzt ist, habe ich doch schon mal ein Export-Format für Bestellungen, das alles enthält was man braucht, strukturiert ist und auch einfach wieder gelesen werden kann.
Ich werde auf jeden Fall an dem Plugin noch mal weiter rumbauen und vielleicht nochmal OpenTrans 2.1 implementieren.

Ich glaube auch das man einfacher eine OpenTrans zu IDoc Lösung findet, ohne selbst was machen zu müssen, als eine Shopware-internes-Format zu IDoc.

Auch der Import der Produkte... warum kann ich nicht einfach OCI oder BMEcat verwenden, um meinen Shop mit Daten zu befüllen. WWS und andere ERP-Systeme können ja diese Format ausgeben. Die Formate, gerade OCI, sind ja auch sehr verbreitet. Warum kann der Shop diese also nicht nativ lesen und benötigt Zusatzsoftware oder Plugins?

Auf der Roadmap von Shopware-Enterprise steht bei B2B jetzt OCI in der "Unsere Visionen für die Zukunft". Richtiges Punchout muss ja nicht mal sein.
Aber die OCI-XML Daten importieren zu können wäre schon einfach toll und würde an vielen Stellen sehr viel Arbeit und Geld sparen.

bbcode-image


Das wohl gerade an einem Import für Kunden aus Drittsystemen gearbeitet wird kommt wohl für mich auch zu spät, aber ist schon mal eine tolle Sache.


bbcode-image


Momentan überlege ich einen kleines Plugin zu schreiben, dass BMEcat versteht. Nichts all umfassendes mit User-Data-Extensions und so. Ein einfaches kleines, dass nur dafür sorgt, dass Systeme die BMEcat ausgeben können, grundlegend den Shop mit Produkten befüllen können. Wenn ich dann mal wieder Daten aus einem System in Shopware importieren soll, würde ich einfach die Daten auf BMEcat umbiegen können (mit einer Middleware oder XSLT oder so) und müsste an Shopware nichts mehr ändern. Shopware hätte dann eine stabile Schnittstelle, die nicht nur für mich sondern allgemein genutzt werden kann und sogar ein sehr gut dokumentiertes Format nutzt.

Sich der Welt mit Standard-Formaten als Core-Feature zu öffnen, würde vielen Shop sehr gut tun. ... aber wohl auch einen Markt der sich nur auf das verschieben von Daten zwischen Systemen spezialisiert hat, empfindlich treffen können. Für den normalen Entwickler und seinen Shop wäre es aber wirklich ein großer Vorteil.

Older posts: