In den letzten Wochen hat sich doch einiges beim meinem XML-Export Plugin getan. Langsam aber zielstrebig geht es in die Bereiche Dropshipping und Bestellung-Konsolidierung. Dadurch wird es zu einem wichtigen B2B-Baustein.
Mit der Version 0.4.1 ist nun viel mehr in dem Bereich möglich (Veröffentlichung folgt in den nächsten Tagen)
Als erstes Beispiel wie man das Plugin nicht nur dafür verwenden kann für das eigene ERP Bestellungen zu exportieren, habe ich hier erotikgrosshandel.de . Deren Schnittstellen-Doku ist ziemlich gut und sie haben ein sehr minimalistisches Format, so dass man relativ schnell zum Ziel kommt. Die Voraussetzung waren:
- Ein eigenes passendes XSLT-Template (nach deren Doku)
- Der ApiClient muss FORM-Data per Post senden können (nicht nur wie bisher JSON)
- CronJob und CLI-Command müssen den Push an eine API auslösen
- Das Model muss die Lieferanten spezifischen Bestellnummern der Artikel enthalten (Puchase-Preise kamen gleich mit dazu...)
Das ganze war dann eigentlich nur viel Kleinkram und der POST als FORM-Data. War also an sich relativ schnell umgesetzt und lies sich gut testen.
Eingestellt muss sein:
- Format: eigene XSLT-Transformation
- Den Pfad zur eigenen XSLT angeben (absoluter Pfad vom /-Root aus!)
- Export-Pfad ist nicht nötig, aber sollte man doch setzen, falls man als Kontrolle die XML-Daten doch selbst noch mal vorhalten möchte (auch hier der absolute Pfad)
- nie automatisch exportieren (nur per CLI, CronJob oder API), man sollte den CronJob verwenden
- CronJob soll nur Bestellungen mit dem Status 0 und 12 (offen und vollständig bezahlt) verarbeiten: "0,!1,!2,!3,!4,!5,!6,!7,!8,!9,!10,!11,12,!13,!14"
- nach dem Export auf Status 1 (in Bearbeitung) setzen
- Host und URL setzen für erotikgrosshandel.de
- Content-Feldname auf "data" ändern
- Post-Format auf "FORM" setzen, damit in "data" die XML-Daten zu finden sind
Damit sendet er per CLI oder CronJob alle 0+12 Bestellungen im Lieferanten eigenen XML-Format an deren Schnittstelle und setzt danach die Bestellung auf 1+12, damit sie beim nächsten Durchlauf kein weiteres mal übertragen wird.
Den CronJob auf 10min stellen und dann sollten alle 10 Minuten alle "offenen" Bestellungen an den Server übertragen.
Über XSLT-Dateien kann man in anderen Fällen natürlich dann auch andere Formate wie GS1 oder OCI implementieren. Um die Daten zu den anderen Systemen übertragen zu können stehen der API-Client, Emails, Abruf über die Shopware-API oder der Export als Datei (und dann Übertragung per FTP oder SCP) zur Verfügung.
In den nächsten Wochen steht bei mir auf dem Plan, Bestellungen konsolidieren zu können, so dass bei einem CronJob-Lauf alle 2h nicht alle Bestellungen einzeln übertragen werden müssen, sondern auch zusammen gefasst werden können, wenn die Bestellungen für den selben Empfänger vorgesehen sind.
B2B ist anders. B2C ist einfach. Bei B2C macht man Werbung, zeigt Preise und versucht einen möglichst offenen (Paypal-Express) und einfachen Checkout den Kunden zu präsentieren. Bei B2B kommt der Kunde teilweise nicht einfach in den Shop. Da ist der Shop eine Dienstleistung, die den Kunden bereit gestellt wird. Also wird man teilweise erst Kunde und kommt dann in den Shop. Preise sind oft auch so eine Verhandlungssache und nicht jedem Kunden werden sofort Preise präsentiert, weil diese ihn verschrecken könnten, da man mit Abnahmen in kleinen Mengen kalkuliert und Staffelpreise zu ungenau wären, weil hier keine Abnahmen pro Jahr oder so dargestellt werden können. Bloß weil ich 1000 Stück bestelle heißt es nicht, dass ich als B2B-Kunde nicht schon genau weiß, dass ich noch weitere 11000 im restlichen Jahr bestellen werde (aber ich will natürlich Lagerplatz sparen oder nicht Dinge aufwendig gekühlt lagern).
Mein erster Versuch etwas für den B2B-Bereich in Shopware zu entwickeln war mein Plugin zum Verhindern von Kundenregistrierungen. Das klingt nach weniger als es kann, weil es doch sehr fein granulär regelt was bei der Registrierung möglich sein soll:
- Keine Registrierung und nur ein Text mit Infos
- Keine Registrierung aber ein Formular für Anfragen
- Blockieren von bestimmten Email-Adressen
- nur bestimmte Email-Adressen erlauben (Mitarbeiter-Shops und so)
- Nur Firmen als Kunden
- Keine Firmen als Kunden
Damit lässt sich schon mal sehr klar definieren, wer und wie in meinen B2B-Shop darf. Muss ich den Account selbst anlegen für meinen Kunden (dann kann ich direkt festlegen was er sehen darf und was nicht) oder darf es selbst muss aber meine Einstellungen abwarten und darf erst dann kaufen? Das alles kann ich damit steuern.
Ich würde gerne stärker in die Richtung gehen und habe anfangen mir eine recht eigene aber doch nicht so einzigartige, wie Firmen oft glauben, Fantasy-Firma aus zu denken und damit einmal exemplarisch einen Weg zu einem fertigen B2B-Shop zu skizzieren. Die Firma vertreibt noch nicht über einen Shop, hat aber eine entsprechende IT mit ERP und WWS. Die Firma produziert selbst, oft auch nach Bedarf, bietet aber auch einige kleine OEM-Produkte zusätzlich zu ihren Produkten an. Diese OEM-Produkte sind meist kleines Zubehör und Verbrauchsmaterialien.
Als Shopware Edition kommt die CE zum Einsatz, weil die an sich ja alles kann und wenn mehr Support gewünscht ist, kann man ja immer noch nachrüsten. Die B2B-Suite lasse ich aus und gucke, ob man nicht die nötigsten Dinge auch einfacher und günstiger selber schreiben kann und wo hier die Grenzen sind (Workflows mit Freigaben und Hierarchien, wäre hier ein Punkt, wo man echt überlegen sollte, ob man da selbst was schreibt).
Die wichtigsten Punkte sind:
1) Produkt-Daten in den Shop bekommen
2) Bestellungen exportieren
3) Lagerbestände abgleichen
4) Kunden Registrierung
5) Preise und Rechnungen
6) Abrufbestellungen
7) Sets aus Produkten (in Hinsicht auf OEM-Zubehör, das ausgehen könnten)
Also fangen wir mal an die Punkte zu analysieren und einfache + schnelle Lösungen zu finden. Denn eine Time-To-Market sollte auch hier nicht länger als 4-6 Monate benötigen. Was das kostet... darüber kann man vielleicht ganz am Ende noch mal nachdenken. Aber so viel würde ich schon mal sagen: Das Team sollte aus einem Shopware-Entwickler, einen Entwickler aus dem ERP-/WWS-Bereich, jemanden für das Theme + allgemeines Design (Umsetzung kann ja über den Shopware-Entwickler laufen) und jemanden der Kunden-/Preis-/Produktdaten betreut.
1) Produkt-Daten in den Shop bekommen Das ERP sollte an sich schon eine Schnittstelle mitbringen um Produkte zu exportieren, wenn nicht kann man die in 2-3 Tagen realisieren. Ob SAP oder was eigenes, es funktioniert alles ganz einfach und linear. Wird ein Produkt angelegt oder geändert und ist von den Daten her vollständig wird es als Datei oder per JMS ausgegeben (per Änderung-Flag oder direkt Live ist dabei sogar egal).
Wenn noch keine Schnittstelle existiert, wäre es gut, wenn diese direkt auf das Event reagiert und den Content per Push an den nächsten Service weiterreicht oder auch auch direkt im richtigen JON-Format an Shopware sendet.
Am einfachsten lässt sich so etwas über eine Template-Engine realisieren, wie sie für fast jede Umgebung existiert.
Ansonsten kann man sich eine eigene kleine Middlware bauen, die Daten per File-Watcher oder MDB empfang, die Daten auf Objekte mappt, die vom Interface her den Models von Shopware gleichen und dann per JSON-Serialisierung ausgeben und direkt an die Shopware-API sendet.
Nur eine Sache würde ich wirklich an der Shopware-API über ein Plugin ändern: Es sollte egal sein, ob man POST oder PUT verwendet, wenn eine Produktnummer dabei steht und useNumberAsId=true gesetzt ist, sollte die API selbst heraus bekommen.
Also das Plugin nimmt die Nummer und lädt die Id dazu nach. Existiert eine wird diese im Model, das gerade rein kommt, ergänzt und die Anfrage an die PUT-Action weitergeleitet. Existiert keine Id wird zur POST-Action weitergeleitet. Das ist dann genau so wie ein Merge bei einem ORM (Doctrine, JPA). Ich hab so ein Plugin schon mal geschrieben und es ist echt praktisch und beschleunigt die Datenübermittlung sehr, weil nicht erst durch ein GET bestimmt werden muss, ob die Software die Daten
als POST oder PUT senden muss.
Sollte als Schnittstelle OCI oder BMEcat zur Verfügung stehen, sollte man diese nutzen. Einen eigenen API-Controller für diese Formate zu schreiben, geht relativ schnell und unkompliziert. Teilweise kann soet was sogar besser sein, als die vorhandene Shopware-API. Wenn man Standard-Formate nutzen kann, sollte man es tun, dann wäre selbst ein Wechsel es ERP (z.B. von was eigenen auf SAP) mit übersichtlich viel Arbeit möglich und was am Shop ändern zu müssen.
2) Bestellungen exportieren
Genau so wichtig wie der Import und Abgleich der Artikeldaten ist der Rückweg, nämlich der Export von Bestellungen. Eine einfache API-Schnittstelle mit Filter auf den Bestell-Status zu schreiben geht schnell und einfach. Somit kann ein anderes System sich alle Bestellungen mit einem oder mehreren Status/Status aus dem Shop einfach abholen. Die simpelste Variante ist es per Scheduler-EJB oder Cron-Job laufen zu lassen.
Wenn man mehr in Richtung Echtzeit gehen möchte, kann man eine neue Bestellung natürlich auch vom Shop aus mit einem Push-Client an eine REST-API einer Middleware oder eines ERP senden.
Die primitivste Variante ist natürlich, die Bestellung als Datei abzulegen und per FileWatcher dann dort abholen zu lassen.
Wichtig bei dem Vorgang ist der Faktor Zeit. Denn ja schneller alles geht, desto weniger Gefahr besteht, das Bestellungen aus dem Shop und dem ERP einen Konflikt um Lagerbestände auslösen könnten.
Es fing alles mit einem kleinen Plugin zum dumpen von Bestellungen an, dass ich zum Debugen auf dem produktiven Server entworfen habe. Es entwickelte sich weiter zu einem vollwertigen order-Export Plugin und kann nun:
- Export als Shopware-XML, openTRANS 1.0, openTRANS 2.1
- per XSLT kann man auch jedes weiter XML-format erzeugen (OCI sollte so auch gehen.. sollte.. habe leider kein System zum Testen)
- Export als Datei direkt nach der Bestellung
- Export über CLI-Command und Cron-Job (in das Dateisystem)
- Automatisches Status-Update nach dem Export
- Export oder einen REST-API Controller (mit manuellen Status-Update)
- Automatischer Push an eine REST-API (RESTEasy im Wildfly wurde getestet)
Mit den ganzen verschiedenen Wegen und Formaten, ist eine Integration in vielen Fällen möglich. Man benötigt weiterhin einen Entwickler, da mit die Gegenseite korrekt eingebunden werden kann, aber wenn man die Kommunikation erst einmal laufen hat, läuft alles sehr stabil und zuverlässig (eine Version läuft seit Nov. 2017 und hat bis jetzt nie Probleme verursacht).
Bestellungen sind zum Glück immer sehr einfach strukturiert und sind seit Jahrzehnten auch fast unverändert geblieben.
Was das Plugin nicht zur Verfügung stellt sind allgemeine Updates beider Status und die Übermittlung von Trackingcodes. Hier ist aber die REST-API die Lösung des Problems. Da die Nummer der Bestellung beim Export mit übermittelt wurde, kann man anhand dieser die Bestellung über die REST-API laden und modifizieren.
Wenn man das fertige Plugin verwendet, ist der Aufwand eher gering und man kann sich eher um die Update-Aktionen, die vom ERP aus getriggert werden kümmern.
Momentan entwickelt es sich auch zu einem Dropshipping-fähigen Plugin, mit dem man Bestellungen, für sich oder für seinen Kunden, direkt an externe Lieferanten und Großhändler weiterreichen kann.
3) Lagerbestände abgleichen Lagerbestände abzugleichen ist mit das komplexeste Thema bei der ganzen Anglegenheit. Während bei den Artikeln sich nur ein System in eine Richtung synchronisieren muss, geht es hier in beide Richtungen. Denn Bestellungen können sowohl über den Shop als auch das ERP ausgelöst werden und manchmal fällt im Lager auch einfach was runter.
Das schlimmste was passieren kann ist, dass man mehr verkauft als man hat. Im einfachsten Fall muss der Kunde länger warten bis man selbst nachbestellt oder nach produziert hat. Im schlimmsten Fall muss man dem Kunden sagen, dass er die bestellte Ware nicht bekommen kann.
Das eigentliche Problem bei den Lagerbeständen ist, dass alles asynchron und nebenläufig ist. Während im ERP eine Order gespeichert wird, wird auch der aktuelle Lagerbestand bestimmt und 2 Bestellungen aus dem Shop liegen in der Import-Queue (alles mit dem selben Artikel). Wenn der Shop jetzt einfach den da bestimmten Lagerbestand anzeigen würde, wäre bis zum nächsten Abgleich der Lagerbestand wieder um 2 höher, weil der schon durch die Bestellungen abgezogene Bestand bei der Neuberechnung nicht verbucht war, der Shop diese 2 Bestellungen aber ab sich schon kennt.
Hier muss mit Differenz-Buchungen und Timestamp gearbeitet werden. Eine sehr gute Lösung ist das führen einer Lagerbewegung-Chain, die durch Absolute-Lagerbestände in Blöcke auf geteilt wird. Man rechnet immer ab dem neusten Absolute-Eintrag aufwerts.
Beispiel:
-1 order 136 2018-01-01 12:15:00 (exportiert)
-1 order 135 2018-01-01 12:14:59 (exportiert)
-1 order 134 2018-01-01 12:02:00 (exportiert und importiert im ERP)
+8 absolute 2018-01-01 12:00:00
Bestand: 5 im Shop
Es ist gerade 12:15:10 und der Lagerbestand im ERP bestimmt und in den Shop importiert, die beiden Orders brauchen noch 15s bis deren Import beginnt (weil der Austausch über Dateien und Cronjobs läuft). Die letzte Bestandsänderung für den Artikel verzeichnet das ERP für 12:03:10, weil dort die Order von 12:02:00 im ERP verarbeitet wurde.
-1 order 136 2018-01-01 12:15:00 (exportiert)
-1 order 135 2018-01-01 12:14:59 (exportiert)
7 absolute 2018-01-01 12:03:10
-1 order 134 2018-01-01 12:02:00 (exportiert und importiert im ERP)
8 absolute 2018-01-01 12:00:00
Bestand: 5 im Shop
Das ist super! Der Bestand aus Shop-Sicht ist gleich geblieben, weil er in beiden Fällen alle Daten kannte. Es wird nie zuviel verkauft werden, obwohl das ERP noch gerade glaubt 7 auf Lager zu haben, weil es die beiden neusten Bestellungen noch nicht kennt.
Am Ende kann man so schnell wie möglich sein und es wird immer diesen kleinen Bereich geben, wo eie BEstellung gerade unterwegs ist, während der Bestand im ERP berechnet wird.
Wo man diese Differenzverrechnung macht ist nicht ganz so wichtig. Ob in einer Middleware oder im Shop direkt, macht kaum einen Unerschied. Es muss immer der verkaufte Bestand aus den Orders als Differenz verbucht werden und Bestandsmeldungen vom ERP entgegen genommen und gespeichert werden.
Das schöne an dem Prinzip ist auch, dass es sich super erweitern lässt, um zukünftige Bestande über Liefer-Avis und ähnliches. Darüber lassen sich dann wieder Lieferzeiten sehr viel genauer bestimmen, wenn man schon weiß, wann wieder etwas auf Lager sein wird und dann auch wie viel. Wenn ich 10 Stück bestelle und im Avis nur 5 Stück angekündigt sind,muss ich ein Lieferdatum nach der kommenden Lieferung verwenden. Normal bei Shopware hätte man nur die typische Lieferzeit des Suppliers, weiß aber nie ob dann wirklich was da ist und wenn doch wie viel Stück.
Die Implementierung so einer Tabelle und den passenden Queries ist relativ einfach. Events für Orders, um die Verkäufe zu vermerken, sind leicht gefunden. Ein API-Controller, um die Bestandmeldungen vom ERP/der Middleware zu empfangen ist auch nicht viel Arbeit.
Ich habe mal so ein Plugin angefangen und einen schon wirklich sehr vollständigen Prototypen hatt ich nach 3 Abenden.. also wohl so 4-5 Stunden. 1-2 Tage voll daran arbeiten und man bekommt so etwas ohne Probleme hin. Die Zeit zum Testen natürlich nicht mit gerechnet.
Eine QNAP TurboStation 120 hat neben der fehlenden Virtualisierung und dem fehlenden Domain Controller nur ein Problem: Es passt nur eine Festplatte rein.
Aber im Gegensatz zu vielen anderen NAS-Systemen hat die TS120 sowohl USB 3.0 als auch einen eSATA-Anschluss. Ich wollte also mal wissen wie kostengünstig ich mein NAS mit einer doch nicht ganz so großen 600GB-Festplatte um Speicher erweitern kann.
Ich habe dann die Festplatte im laufenden Betrieb angeschlossen und mich in der WebUI angemeldet. Die Festplatte wurde sofort erkannt.
Ich konnte sie direkt als Freigabe-Ordner für andere Benutzer konfigurieren.
Und auch unter Windows war die Festplatte sofort zu finden.
Alles sehr einfach und funktioniert super. Man könnte also auch einfach ein 4x eSATA-Gehäuse mit 4x 2GB da ran hängen. Wobei mir die Idee das NAS und den Speicher zu trennen an sich auch ganz gut gefällt.
Eines meiner Plugins hat jetzt eine Bronze-Zertifizierung. Das ist toll, dass besagt, das das Plugin öfters runter geladen und schon bewertet wurde. Wenn man das geschafft hat man die Zertifizierung aktivieren. Es soll viele Vorteile bringen und helfen das Plugin besser zu verkaufen.
Ich bin gespannt!
In der Zwischenzeit wird mehr Zeit in ein andere Projekt und das XML-Export Plugin investiert bzw. so viel Zeit wie der Garten einen gerade übrig lässt.
Die neue Version vom automatischen XML Order-Export, nutzt für openTrans2.1 XSLT und keinen PHP-Code mehr. Der Vorteil davon ist, dass so für jeden Anpassungen an der Ausgabe sehr viel einfacher werden. Man kopiert sich die vorhandene XSLT-Datei und kann die Kopie so anpassen wie man will. Im Plugin kann man die Datei dann angeben und diese anstelle der originalen XSLT-Datei verwenden.
Wenn man z.B. ein Attribute-Field zusätzlich als offiziellen openTRANS2.1 XML-Tag einbinden:
Am 30.6. war wieder Oldtimer Really in Bremen. Diesmal hatte ich frühzeitig zwei Thinkpad T500 organisiert, falls es Probleme bei der Bereitstellung anderer Notebooks geben sollte. Die Software hatte ich seit dem letzten Jahr nicht mehr groß angefasst. Nur die aktuelle Version der Client-JAR zu finden brauchte etwas. Aber nachdem ich die ganz unverhofft im Projekt-Verzeichnis fand, lief dann alles ohne wieder ohne Probleme.
Wieder 5:00 los und.. KEIN REGEN!!!!!! Auch eine weitere Besonderheit kam hinzu. Das 2. Zeitfahren wurde mit einem anderen System gemessen und später sollten die Ergebnisse beider Systeme für das Gesamtergebnis kombiniert werden. Ein kleines PHP-Script lass alle Renn-Ergebnisse als CSV ein und wertete diese aus. Alle Fahrer die nicht alle 3. Zeitfahrten absolviert hatten.
Nach dem Tag hab ich mir vorgenommen, die Integration mit anderen Systemen zu verbessern. Auch die Clients könnten dann ihre Auswertungen nicht nur per REST-API übermitteln, sondern auch eine CSV generieren, die dann ausgelesen werden kann. Der Import wäre dann so flexibel, dass er auch CSV-Dateien anderer Systeme importieren könnte.
Ein anstrengender Tag, aber die Messungen liefen wirklich gut und es gab kaum Fehlmessungen, durch Fahrtzeuge die zu dicht am Messbereich parkten.
Wer also bei Rennen oder ähnlichen jemanden braucht, der die Zeitmessungen und Auswertungen übernimmt, kann sich vertrauensvoll an die Switch GmbH wenden... auch was Temperaturüberwachung angeht.
Aufbauen
Surface als Messstation, der Client läuft noch in Eclipse
Ich war mal wieder auf Kassenzone unterwegs und hab mir mal die Kommentare zu dem eskalierten Thema "Wie #verzichtbar sind Apotheken in Deutschland?" durch gelesen. Es kommt immer wieder der Begriff der Digitalisierung auf, der ja schon halb zu einem politischen Kampfbegriff geworden ist und Hoffnung und Angst der Menschen gleichermaßen umfasst.
Am Ende glaube ich persönlich nicht daran. Ich glaube nicht daran, dass jemand plötzlich die Eingebung hatte: "Machen wir doch ab jetzt alles digital... der Rest der Welt passt sich schon an". Was sind die beschworenen Folgen der Digitalisierung?
- Arbeitskräfte werden ersetzt
- Lokale Geschäfte schließen, weil der Handel ins Internet abwandert
- Lineares TV wird ersetzt
usw.
Irgendwo stand da (jedenfalls so ähnlich): Durch die Digitalisierung müsse der Mensch jetzt lernen, dass er seine Medikamente im Internet bestellen müsse und nicht mehr in der Apotheke um die Ecke bekommt. Das würde Menschen eben ein Umdenken abverlangen und auch Ängste hervorrufen.
Und genau hier sehe ich den Fehler! Nicht der Mensch/Kunde muss sich daran gewöhnen oder umdenken.. das Umdenken hat schon längst stattgefunden. Ladengeschäfte schließen nicht, weil die Digitalisierung den Menschen beigebracht hat im Internet zu kaufen, sondern die Digitalisierung setze ein, weil die Kunden immer mehr im Internet kauften und der Handel eine Strategie brauchte, um da hinterher zu kommen. Die Digitalisierung ist nicht der Anfang, die Digitalisierung der Versuch, dass der Kunde einen nicht total abhängt.
Pro7 bietet "The Orvell" nicht als Streaming-Angebot an, weil die Zuschauer lernen sollen es zu nutzen, sondern weil die Zuschauer es schon verlangen, dass ein Sender seine Inhalte so anbietet.
Es gibt mehr als genug Jobs, die ein Computersystem nicht erledigen kann. Da braucht man die Arbeitskräfte und nicht in Jobs, die so stupide (Computer sind trotz allem was man heute AI nennt noch immer strunz dumm) sind das selbst ein Computer sie erledigen kann. Ich brauche keinen Mitarbeiter der 100.000 Datensätze analysiert und verarbeitet, wenn der selbe Mitarbeiter, mit den Ergebnissen eine tolle PPT bauen kann und anderen die Interpretation der Daten näher bringen kann. Das eine ist wichtig und bringt einen weiter. Das andere ist nur eine nervige Arbeit, die die Grundlage des anderen ist.
Beim Handel überlebt alles, was bei zeitkritischen Dingen hilft. Wenn mit der Hammer oder die Bohrmaschine kaputt geht bei größeren Arbeiten, brauche ich schnell Ersatz. 15 Pakete Laminat kaufe ich nicht spontan und kann die im Internet bestellen. Wenn man die großen Dinge von den kleinen Dingen trennt und seine Vorort-Angebote richtig wählt, passt es auch.
Am Ende wurde durch diese "Digitalisierung" nichts verändert, es ist die gerade laufende Veränderung durch die Menschen/Kunden und keiner kann sie lenken. Sie geschieht einfach.
Am 16.5.2018 fiel in Lübeck der Strom aus. Das war nicht so toll, aber es passiert eben mal. Nach einigen Stunden war auch alles wieder da. Nur als der Strom wieder kam, grillte es wohl das Kabel-Modem der Fritzbox.
Nach viel hin und her mit der Vodafone-Hotline stand fest, dass die Fritzbox getauscht werden müsste. Der komische Vodafone Router lief wurde aber natürlich nicht ohne Grund gegen eine Fritzbox getauscht.
Der Service von Amazon bot auch direkt an die Fritzbox um zu tauschen.
Positiv war, dass es zuerst gar nicht aufgefallen war, dass die Fritzbox sich nicht mehr mit dem Kabelnetz verbinden konnte, weil der UMTS-Fallback super funktioniert. Aber auch nur bis das Guthaben da leer war und das ging relativ schnell.
Als erstes habe ich dann eine Kopie der Config gezogen. Ich wollte behalten:
- Telefoneinstellungen (2 Fritzphone) und Telefonbuch
- VPN und Benutzereinstellungen
- MyFritz Einrichtung
- IP-Zuweisungen zu den verschiedenen Netzwerkgeräten (NAS, Drucker, IP-Kameras, etc)
- WLan SSID und Schlüssel mit zu nehmen wäre auch nett, aber nicht ganz so wichtig
Da merkt man erst wie viele Daten und wie viel Arbeit in so einem Router steckt. Man kann natürlich alles neu einrichten, aber es kostet doch einige Stunden und die wollte ich mir gerne ersparen.
Also Config auf dem PC gespeichert. Dazu musste ich mit einem der Telefon einen Code bestätigen, so dass klar war, dass es ein lokales Backup der Daten war. Effektiv muss man sagen.
Dann 2 Tage mit dem Vodafone-Router überleben und dann war die neue Fritzbox da.
Wer jetzt glaubt, jetzt kommt ein ausführlicher Text, wie man wieder alles einrichtet und so, liegt leider Falsch. Anschließen, einloggen, Backup wieder einspielen.
Die Telefone hatten sich über DECT noch nicht wieder verbunden, aber mit der DECT-Taste etwa rumspielen, hat die Sicherheitscode-Abfrage auch irgendwie bestätigt.
Danach war wieder da:
- Internet
- Netzwerkgeräte
- VPN
- MyFritz
- Telefonbuch und Telefoneinstellungen
- WLan mit den alten Einstellungen (Repeater hat sich auch sofort wieder verbunden)
Nur die Hintergrundbilder der Telefone musste ich kurz nach mal hochladen.
Genau aus diesen Grund mag ich Fritzboxen. Sie können ganz viel, sind günstig, einfach zu bedienen und es funktioniert einfach alles ohne viel Rumgespiele.
Für die perfekte Fritzbox (gerade die ich bei kleinen Firmen installieren würde) fehlen nur ein paar eher exotische Dinge. Die perfekte Fritzbox hätte bei mir noch:
- 10GBE Switch (4 Ports reichen.. selbst ein 10GBE-Port zusätzlich zu den 1GBE-Ports wäre ausreichend)
- Load-Balancing (über externe DSL- oder Kabelmodem, verbunden über Ethernet)
- ein eingebauter Domain-Controller für Windows-Netzwerke (Profile auf USB-HDD oder externen NAS speicherbar)
- Einfache Traffic-Analyse (Homepages und Anwendungen nach Traffic aufgeschlüsselt. Wie viel geht über IP-Telefonie und wie viel über die Cloud-Groupware?)
- UND ein Ein-/Ausschalter :-)
Dann wäre echt alles Perfekt und auch 300 EUR wären dafür noch OK.
Ach ja ein Repeater mit PoE-Port wäre auch ganz nett.
Auch wenn ich eigentlich gar keine Zeit dafür habe, habe ich doch noch mal ein paar Kleinigkeiten an dem Plugin gemacht.
Nun kann man auch nicht-nummerische Werte als Slider darstellen. Die Reihenfolge entspricht dann der der Werte im Backend.
Die checkLicence()-Methode prüft, ob ein Plugin eine gültige Lizenz hat oder nicht. Dafür wird wiederum das Licence-Manager Plugin verwendet. Shopware selbst rät eher davon ab dieses zu verwenden. Sie meinen, dass ein Kunde schon keine Raubkopie verwenden möchte und ungern von Updates abgeschnitten wird.
Bei einigen Plugins sind die Updates nun wirklich minimal umgesetzt. Mal ein paar kleine Schönheitsfixes.
Warum gehe ich lieber das Risiko ein, dass man eine Test-Version länger als gedacht verwendet als zu viel Sicherheit einzubauen?
- Weil ich selbst weiß, dass Test-Zeiträume oft zu gering sind.
- Weil ich die Sicherheitsmaßnahmen von Shopware für ausreichend halten
- Weil meine Plugins im Namespace abzuändern. von der Arbeitszeit oft teurer wäre als es zu kaufen
- Weil ich nicht nur Fixes in Updates habe, sondern Updates bei mir oft auch Features nachliefern oder verbessern (erste Versionen waren oft nicht ansatzweise so umfangreich wie die momentanen Versionen)
Es ist wie mit dem Wasserzeichen auf mp4togif.com. Es nervt und man kann es relativ einfach und ohne viel Einschränkungen entfernen. Meine Plugins sind relativ günstig. Bekommen oft neue Features und ich versuche möglichst guten Support zu leisten.
Sollte sich nichts mehr verkaufen, würde ich auch nicht mehr weiter entwickeln.
Da das Preis/Leistung Verhältnis bei meinen Plugins, glaube ich, stimmt, bin ich auch relativ sicher, dass die Shopbetreiber bereit sind das Geld zu zahlen und weiterhin von der Weiterentwicklung partizipieren zu können. Besonders auch weil ich für jeden Verbesserungsvorschlag dankbar bin und diese auch gerne für Kunden umsetze.
PS: bald veröffentliche ich mal wieder eine aoop-Version, da dort in den letzten Tagen nach langer Zeit wieder mal was passiert ist und ein neues Projekt damit ansteht.. und nicht mit WordPress.. weil das zu unflexibel ist für den Zweck :-)