Beiträge

EHI Reifegrad Analyse 2016 – www.sporthaus.de zählt zu den Top-Shops für Sportartikel

Intersport Krumholz sorgt auch bei kurzentschlossenen Fußballfans für gute Stimmung zur EM 2016!

Köln/Nürnberg/Mülheim-Kärlich, 16.06.2016 – Der von der shoptimax GmbH umgesetzte Onlineshop www.sporthaus.de spielt laut aktuellem EHI Onlineshop-Maturity-Index 2016 deutlich in der obersten Shopping-Highlight-Liga. Das seit 2014 bestehende Online-Verkaufsportal des Sportfachgeschäftes INTERSPORT Krumholz landet mit über 109 von möglichen 150 Punkten auf Platz vier der insgesamt 35 bewerteten Online-Sportartikelshops. Auch wer die Verbundenheit zu seiner Lieblingsfußballmannschaft pünktlich zur EM 2016 zeigen wollte oder noch kurzentschlossen zeigen will, war und ist laut EHI beim Onlineshop von INTERSPORT Krumholz genau richtig.

Infografik-OMI-TOP-10-Sportartikelanbieter-2016-web

Die Top 10 der Sportartikelanbieter in Deutschland – Ranking nach Onlineshop-Maturity-Index (OMI) 2016 (Grafik: EHI)

Bedürfnisse der Kunden stehen bei www.sporthaus.de im Mittelpunkt – nicht nur zur Fußball EM 2016

„Wir sehen unseren Onlineshop als eine zeitgemäße Ergänzung zu unseren Krumholz-Sporthäusern in Neuwied, Mayen, Mülheim-Kärlich und Bad Neuenahr-Ahrweiler“, so Paul Krumholz, Geschäftsführer der Sporthaus Krumholz Mülheim-Kärlich GmbH. Unter www.sporthaus.de wird ein Teilsortiment der stationären Filialen auf einem weiteren Kanal abgebildet, der dem Unternehmen die zusätzliche regionale Vernetzung mit seinen Kunden, aber auch die überregionale Umsetzung der INTERSPORT-verbundübergreifenden Multichannel-Strategie erlaubt. „Preis, Leistung und Service passen bei uns on- wie offline zusammen. Zudem bauen wir das Sortiment des Onlineshops kontinuierlich aus. Schon jetzt werden alle Prospekt- und Preisaktionen abgebildet und wir tun alles dafür, den Shop noch weiter voranzubringen“, so Krumholz weiter.

Infografik-OMI-Sportartikelanbieter-2016-em-web

Sportartikel-Onlineshops: Service- und Bestellmöglichkeiten zur EM 2016 (Grafik: EHI)

Was für INTERSPORT Krumholz als Selbstverständlichkeit gilt, ist aber besonders zur aktuellen Fußball EM gefragt: „Kurzentschlossene Fans waren und sind bei uns zur EM 2016 genau richtig. Wir erfüllen nicht nur den Fairplay-Faktor und bieten neben den Artikeln der Deutschen Elf auch Fanartikel anderer Nationen an. Zudem ist es möglich, unsere Services Click & Collect, Click & Reserve sowie die Anzeige der Verfügbarkeit in unseren Filialen zu nutzen“, so Paul Krumholz.

Umsetzung durch shoptimax

Für die Umsetzung des Onlineshops zeigt sich der E-Commerce-Lösungsanbieter shoptimax aus Nürnberg verantwortlich. „Die nun seit fast drei Jahren andauernde Zusammenarbeit mit shoptimax war und ist jederzeit unkompliziert und lösungsorientiert“, so Paul Krumholz.
Die Plattform „Oxid“ und die E-Commerce-Software „Plentymarkets“ stellen die Infrastruktur von www.sporthaus.de dar und wurden mit mehreren Schnittstellen an das stationäre Warenwirtschaftssystem „Intersys“ der INTERSPORT angebunden. Die homogene Verknüpfung zwischen beiden Systemen ermöglicht den Echtzeitzugriff auf die Lagerbestände der Filialen. Das Controlling von Planung, Einkauf und Disposition erfolgt damit für Online- und Offline-Handel aus einem Kanal. Größter Wert wurde bei der Umsetzung außerdem auf Kundenfreundlichkeit, Datensicherheit und Usability gelegt. So ist der Onlineshop beispielsweise durch Responsive Design auch auf mobilen Endgeräten jederzeit optimal bedienbar. Für beste Suchergebnisse wurde die eigens von shoptimax entwickelte intelligente Shop-Suche „shoptifind“ integriert. Das Zusammenspiel all dieser Punkte hat zu der insgesamt sehr guten Bewertung im Onlineshop-Maturity-Index 2016 geführt.

Positive Bewertung im OMI – positiver Blick in die Zukunft

Für Paul Krumholz bedeutet die positive Bewertung in der aktuellen EHI-Studie, mit seiner Gesamtstrategie alles richtig gemacht zu haben: „Mit unserer über 60-jährigen Tradition im Dienste des Sports, sind wir seit Jahren das führende stationäre Sportfachgeschäft im Norden von Rheinland-Pfalz. Die im EHI Onlineshop-Maturity-Index 2016 erreichte Punktezahl zeigt nun endlich, dass wir auch Online alles zu bieten haben, was das Sportlerherz begehrt.“ Auf dem Erfolg ausruhen wird sich das Unternehmen aber nicht: „Der Käufer und das Shoppingerlebnis stehen bei uns jederzeit im Mittelpunkt – und gemeinsam mit unserem E-Commerce Experten shoptimax tun wir alles dafür, dass dies in Zukunft nicht nur so bleibt, sondern wir in allen vom EHI geforderten Kriterien kontinuierlich besser werden“, so Krumholz abschließend.

Onlineshop-Maturity-Index (OMI) und Reifegradstufen

Maßgeblich für die Bemessung des Onlineshop-Maturity-Index (OMI) bzw. Reifegrades eines Onlineshops sind unter anderem Kriterien wie Benutzerfreundlichkeit, Performance oder Produktpräsentation bzw. –suche. Aber auch die Themen Datenschutz und Datensicherheit sowie die Einfachheit bei Bezahlung, Lieferung und Rückgabe spielen eine erhebliche Rolle bei der Bewertung. Insgesamt werden die Shops individuell auf die Ausführung und das Vorhandensein von 91 Kriterien in 8 Kategorien geprüft, die in einem nach heutigen Standards ideal umgesetzten Onlineshop möglich wären.
Die maximal erreichbare Punktzahl bei der Analyse liegt bei 150 Punkten. Je nach erzielter Punktezahl des analysierten Onlineshops erfolgt die Einordnung in eine von fünf Reifegradstufen, wobei die Reifegradstufe 5 mit über 100 erzielten Punkten der bestmöglichen Bewertungsstufe „Shopping-Highlight“ entspricht:
Im Rahmen der EHI-Studie „Onlineshop-Maturity-Index 2016 – Reifegrad-Analyse Onlineshops“ (Datenerfassung: Mai 2016) bietet das EHI individuelle Sonderauswertungen für die analysierten Onlineshops an. Diese sind über die Seite des EHI bestellbar.

Link zum INTERSPORT Krumholz Online-Shop

OXID EE MySQL Master/Slave Setup

oxid-news

Hintergrund

Der OXID eShop unterstützt in der Enterprise Edition (EE) MySQL Master/Slave Datenbank-Setups, was für sog. „Read-/Write-Splitting“ genutzt werden kann. Dadurch ist es möglich, Datenbank-Abfragen auf mehrere Datenbank-Server zu verteilen, um damit im Idealfall an Datenbank-Performance zu gewinnen und Shops gerade zu Lastzeiten schneller zu machen.
Read-/Write-Splitting kann ebenso helfen, das Shop-Frontend performant zu halten, wenn z.B. gerade Massen-Updates über ERP- oder PIM-Schnittstellen im Shop-Backend laufen, welche mit vielen Insert-Statements nicht selten Datenbank-Locks auslösen, die sich dann auch auf das Frontend auswirken können. Im schlimmsten Fall ist der Shop zeitweise nicht mehr aufrufbar, weil gleichzeitig zu den laufenden Insert- und Update-Statements aus einer gelockten Datenbank-Tabelle gelesen werden soll.

Master/Slave Setup in OXID

Im OXID eShop ist die Konfiguration der Master-/Slave-Verteilung sehr einfach, hier genügt es, in der allgemeinen Shop-Konfigurationsdatei „config.inc.php“ die einzelnen Server einzutragen.

Hierzu gibt es zwei Variablen, die gesetzt werden müssen:

$this->aSlaveHosts = array('localhost', '192.168.0.10:3306', '192.168.0.11:3307');
$this->iMasterSlaveBalance = 0;

Im Array „aSlaveHosts“ können beliebig viele IP-Adressen (mit optionalem Port) eingetragen werden. Auch der Master wird hier als erster Wert hinterlegt.
Der zweite Parameter, „iMasterSlaveBalance“ legt fest, wie die Verteilung der Abfragen zwischen Master und Slave ist.
Ein Wert von „0“ bedeutet hier, dass alle Abfragen auf den Slaves stattfinden und auf den Master nur schreibend zugegriffen wird.

Für Shops mit regelmässig laufenden Artikeldaten-Updates über Schnittstellen zu Warenwirtschaftssystemen usw. sollte diese Einstellung verwendet werden, damit sichergestellt ist, dass auch bei Massen-Updates die Lesezugriffe aus dem Shop-Frontend nicht in Mitleidenschaft gezogen werden.

Das Setup der Datenbankserver an sich geht über den Umfang dieses Artikels hinaus, hierzu finden sich z.B. sehr gute Infos unter https://www.thomas-krenn.com/de/wiki/MySQL_Replikation

Tipps und Tricks für das MySQL Master/Slave Setup

Der OXID EE Shop selbst ist bereits sehr gut für die Master-/Slave-Aufteilung optimiert, sobald Slaves konfiguriert sind, hält sich der Shop strikt an die definierte Aufteilung und führt z.B. Lesezugriffe immer auf den Slaves aus.

Für eigene Erweiterungen des Shops sollte man sich hier am OXID Standard orientieren, hier ist es v.a. wichtig, für Lese- oder Schreibzugriffe die richtigen Methoden des OXID Datenbank-Adapters zu verwenden.

Prinzipiell gilt: für Lesezugriffe sollte man immer die „select()“-Methode der „oxDb“-Klasse nutzen, da nur diese wirklich standardmässig dezidiert auf die Slaves zugreift.

$oRs = oxDb::getDb()->select("SELECT * FROM oxarticles WHERE oxartnum = '12345'"); // liest vom Slave

Man kann allerdings als dritten Parameter „false“ übergeben, um dennoch vom Master zu lesen – Standard ist jedoch „true“ und damit „Slave:

public function select($sSql, $aParams = false, $blType = true)

Auch die Methoden „getOne()“, „getArray()“, „getAssoc()“, „getRow()“ und „getAll()“ selektieren standardmässig von den Slaves, können aber ebenfalls per Parameter auf den Master „umgebogen“ werden bei Bedarf.

Nutzt man hingegen die Methoden „execute()“ oder „query()“, geht das SQL-Statement ausnahmslos an den Master-Server!

$oRs = oxDb::getDb()->query("SELECT * FROM oxarticles WHERE oxartnum = '12345'"); // liest vom Master

Problematisch sind bei Master-/Slave-Setups oft SQL-Fehler, welche zu Fehlermeldungen auf Datenbank-Ebene führen. MySQL ist hier meist recht rigoros und beendet die Synchronisation zwischen Master und Slaves. Diese muss dann vom System-Administrator wieder manuell aktiviert werden.

Man sollte das System also erst auf Herz und Nieren testen und die Synchronisation im Testbetrieb beobachten, um zu entscheiden, ob es hier kritische Stellen im Shop gibt und regelmässige SQL-Fehler auftauchen.

Handelt es sich um temporäre, „unwichtigere“ Daten (z.B. Session-Einträge, Captcha-Codes o.ä.), kann man ggf. in Erwägung ziehen, die betroffenen Tabellen aus der Synchronisation herauszunehmen bzw. MySQL-Fehler für diese Tabellen bei der Synchronisation zu ignorieren, siehe z.B. https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_slave-skip-errors
Ausserdem kann helfen, die Slaves explizit als „read_only“ zu konfigurieren, damit es keine „versehentlichen“ Schreibversuche auf die Slaves gibt.

MySQL Master/Slave in OXID – Fazit

Mit der Option für Master-/Slave-Setups bietet OXID gerade für große Shops mit regelmässigen, umfangreichen Datenänderungen über Drittsysteme einen erheblichen Performance-Hebel.
Weiss man um die technischen Hintergründe des OXID-Datenbankadapters und kennt die möglichen Fehlerquellen auf Seiten der MySQL-Datenbank-Synchronisation, spricht nichts dagegen, dieses Feature im produktiven Einsatz zu nutzen.
Hat man dann noch einen technisch versierten Hoster an seiner Seite, kann eigentlich nichts mehr schiefgehen :)

Hoffentlich hat dieser Artikel dazu beigetragen, die technischen Hintergründe in Bezug auf OXID EE und das Mysql Master-/Slave-Setup zu erhellen!

 

Sprachdateien in OXID Modulen

Dass sich mit dem Release des OXID eShop 4.7/5.0 auch ein Großteil der Verzeichnisstruktur geändert hat, dürfte mittlerweile ja bekannt sein. ;-)

Anfangs war es gar nicht möglich eigene Sprachdateien unterhalb von /modules/ zu nutzen. Dies wurde vor längerer Zeit schon geändert, sodass man diese unter

/modules/mymodule/out/admin/de/mymodule_lang.php

ablegen konnte. Dies war identisch zur Oxid-Standard-Struktur (out/admin/de). In OXID 4.7/5.0 liegen die template-spezifischen Sprachdateien nun in folgenden Verzeichnissen:

frontend: /application/views/azure/de/
backend: /application/views/admin/de/

Also kann man ja “eigentlich” auch davon ausgehen, dass auch bei den Modulen die gleiche Struktur verwendet wird. Leider ist dem nicht so. :-( Hier wird sogar unterschieden zwischen Frontend und Backend:

frontend: /modules/mymodule/translations/de/mymodule_lang.php
backend: /modules/mymodule/views/admin/de/mymodule_lang.php

Nur so werden die Sprachdateien auch richtig geladen. Übersichtlich ist das ganze aber nicht und verursacht nur Chaos. Für den Fallback ist übrigens noch der alte Code im Modul (z. B. out/admin/de) enthalten.

Im OXID Forum wurde dieses Thema schon ansatzweise behandelt. Wir haben auch einen Eintrag im OXID Bugtracker gemacht, jedoch sträubt man sich hier noch etwas dagegen ;-) …


Update für OXID >= 4.9.0

In der Version bis 4.8.x geht für das Backend nur

“mymodule/views/admin/de”

In der Version 4.9. geht

“mymodule/application/views/admin/de” oder
“mymodule/views/admin/de”

ABER:
wenn es das Verzeichnis

“mymodule/application/*”

gibt weil dort die Admin-Templates liegen, dann müssen dort auch die Lang-Dateien liegen!
Das gilt sowohl für das Backend als auch für das Frontend.

FAZIT:
es geht also NICHT mehr

“mymodule/application/views/admin/tpl”

in Kombination mit

“mymodule/views/admin/de/”.

Und wenn ein “modules/…/mymodule/application”-Order vorhanden ist, müssen die Frontend-Templates unter

“mymodule/application/translations/de”

 

usw. liegen (und nicht mehr direkt unter “modules/…./mymodule/translations/…”)!

Blog Einträge

Zierfisch oder Wal – lokale Software-Entwicklung mit Docker

Pünktlich zum 4. Geburtstag von Docker möchte ich ein kleines Fazit ziehen, ob und wie sich Docker-Container für die lokale Entwicklung im Agentur-Alltag mit sehr heterogenen Entwicklungs-Systemen (Windows Home / Pro, von 7 bis 10, Mac OS, Linux) der einzelnen Mitarbeiter bewähren können, welche Vorteile, aber auch Schwachstellen und Probleme es ggf. bei der täglichen Arbeit gibt und ob es sich lohnt, auf den blauen Wal zu setzen.

Die Anfänge

Vor knapp zwei Jahren fing ich an, mich erstmals mit Docker auseinanderzusetzen. Damals wie heute ging es dabei zentral darum, mit möglichst wenig Aufwand eine einheitliche, einfach aufzusetzende lokale Entwicklungsumgebung für verschiedene Software-Projekte zu haben, die idealerweise systemunabhängig zur Verfügung stehen sollte.

Lösungen mit MAMP, XAMP, LAMP usw. waren kaum beherrschbar, die Versionen der einzelnen Komponenten (Webserver, Datenbank, PHP-Umgebung, etc.) auf den Systemen der Mitarbeiter wucherten vor sich hin, unterschiedlichste Projekte stellten auch unterschiedlichste Anforderungen (ZendGuard Loader, ioncube Loader, Opcode-Caches, diverse PHP-Versionen, NodeJS, etc. etc.). Oder es wurde gar gemeinsam gleichzeitig auf nur einem Test-System entwickelt, die Mitarbeiter überschrieben sich „fröhlich“ gegenseitig ihre Änderungen. Gab es irgendwo einen Fehler im Code mussten alle warten, bis der Schuldige das Problem behoben hatte und das System wieder lief… kurzum: totale Anarchie :)

Für jedes Projekt aber eigene VMs zu „basteln“ war ebenso zeitaufwändig wie hardware-hungrig… was also tun? Docker schien eine gute Lösung zu sein, mit Docker Toolbox war es auch für Windows und Mac OS verfügbar, es gab vorgefertigte Docker-Images für Apache, PHP, Mysql auf Docker Hub usw.

Allerdings war Docker Compose noch im Entstehen, grafische Tools zur Container-Administration waren Mangelware, einzelne Container wurden also auf der Kommandozeile über „docker run …“ gestartet. Für „richtige“ Entwickler natürlich ok, für Template- und Frontend-Kollegen eher „so naja“ … ;)
Der Einstieg war also eher holprig, erste Container waren der einfacheren Administration halber „all-in-one“, also entgegen der Docker-Prinzipien liefen Apache, mehrere PHP-Versionen über „phpbrew“, Mysql, NodeJs usw. in einem gemeinsamen Container und waren damit eigentlich schon fast ein „VM-Ersatz“.

Weiterlesen

Continuous Delivery Teil 2 – Ansible Tipps

Im ersten Teil dieser Blogserie haben wir den allgemeinen Entwicklungsworkflow bei shoptimax beleuchtet – in diesem Teil soll es um konkrete Tipps zum Deployment mit Ansible gehen.

Gitlab CI und Ansible kombinieren

Wie bereits beschrieben nutzen wir für automatisiertes Deployment unserer Projekte aus GIT heraus Gitlab CI. Je nach GIT- Branch (bei uns sind das normalerweise „develop“, „stage“ und „master“) löst Gitlab CI unterschiedliche Aktionen aus, welche in „.gitlab-ci.yml“-Dateien in den jeweiligen Projekten definiert sind.
In der Regel werden Änderungen in den „develop“-Branches direkt per Gitlab Runner auf interne Testserver deployed. Optional können hier (und/oder bei einem Git-Push in weitere Branches) Code-Style Prüfungen oder z.B. Codeception-Tests durchgeführt werden, die dann in einem Gitlab-internen Docker-Container automatisch gestartet werden.

Änderungen an „stage“- oder „master“-Branches hingegen werden in der Regel auf externe Server ausgespielt, sei es ein geteilter Staging-Server von shoptimax oder direkt ein Kunden-System. Hier kommt dann unser Ansible-Repository mit unterschiedlichen sog. „Playbooks“ ins Spiel.

Dazu wird im ersten Deployment-Step (welcher im Docker-Container abläuft) unser internes Ansible-GIT-Repository gecloned. Dieses wird am Ende des Durchlaufs in einem sog. Gitlab CI-Artefakt gespeichert, welches in weiteren Deployment-Steps dann ebenfalls zur Verfügung steht. Damit können nacheinander die unterschiedlichen Playbooks in den verschiedenen „Stages“ des Deployments aufgerufen werden. In einer „scripts“-Sektion der .gitlab-ci.yml wird also z.B. folgendes definiert:

- git clone --depth 1 --branch master git@repo:repo_group/ansible_deployment.git ansible

Für das zu erstellende Artefakt wird weiterhin festgelegt, welche Verzeichnisse darin gespeichert werden sollen und wie lange es auf dem Gitlab-Server vorgehalten wird, z.B.

artifacts:
    paths:
    - build
    - ansible
    - deploy_scripts
    expire_in: 5 days

Diese Artefakte können vor Ablauf dieser Zeitspanne übrigens auch über die Gitlab-Oberfläche per Browser heruntergeladen werden.

In der .gitlab-ci.yml wird also definiert, wo das Ansible-Verzeichnis liegen soll und an welchen Stellen im Prozess Ansible Playbooks aufgerufen werden:

variables:
  SHOP_BUILD_DIR: "/builds/oxid/$CI_PROJECT_NAME"
deploy_stage:
  stage: deploy
  environment: deploy_stage
  tags:
    - docker
  script:
- cd $SHOP_BUILD_DIR/ansible/
- ansible-playbook -s ./deploy.yml --extra-vars "target=customer1 custom_source_folder=/../temp shop_docroot=${SHOP_DOCROOT_STAGE} shop_deploy_dir=${SHOP_DEPLOY_DIR_STAGE} ..." -vv

Timestamp-Datei für unabhängige Playbooks

Um eine gemeinsame Referenz für die unterschiedlichen Playbooks zu haben, die ja meist in verschiedenen Build-„Stages“ ablaufen (z.B. lädt das erste Playbook ein *.tar.gz hoch und packt es auf dem Server in Verzeichnis X aus, das zweite Playbook legt dann Symlinks auf dieses Verzeichnis an usw.), wird ein gemeinsamer Timestamp verwendet (z.B. auch für die Verzeichnis-Namen der Deployments). Ein solcher Timestamp wird bereits beim Clone des Ansible-Repositories erzeugt und in einer txt-Datei gespeichert:

- date +%Y-%m-%d_%H-%M-%S > ansible/timestamp.txt

In den Playbooks wird jeweils geprüft, ob es diese Datei gibt, falls ja wird der Timestamp ausgelesen und über diesen Timestamp dann das zugehörige Verzeichnis gesucht / weiter verarbeitet.
Gitlab CI cloned das Ansible Repository in einen projektspezifischen Docker-Container und speichert die Dateien im Build-Artefakt, inkl. der Timestamp-Datei.
Dadurch bleibt der Timestamp während des gesamten Deployment-Prozesses über die verschiedenen, zeitlich nacheinander ablaufenden „Stages“ quasi als „Referenz“ vorhanden und jedes Playbook operiert so auf demselben Verzeichnis.

Projektspezifische Kommandos und Symlinks in JSON-Dateien

Mit Ansible ist es sehr einfach, JSON-Dateien einzulesen und abzuarbeiten. Wir verwenden z.B. JSON-Dateien, um während eines Deployments individuelle Symlinks je nach Kundenprojekt anzulegen oder um auf dem Zielserver projektspezifische Kommandos (Shell oder auch PHP) beim Deployment auszuführen.
Z.B. kann hier ein Shell-Script aufgerufen werden, das eine Datenbank-Sicherung durchführt oder ein PHP-Script, welches das „tmp“-Verzeichnis des Shops leert, Datenbank-Views neu erzeugt oder bestimmte Module automatisch de-/aktiviert usw.
Damit müssen wir keine Fallunterscheidungen oder zusätzliche Variablen und Tasks in Ansible selbst definieren, sondern können in das Kundenprojekt einfach entsprechende JSON-Dateien in das GIT-Repository einchecken. Diese können sogar z.B. pro Git-Branch oder Zielsystem unterschiedlich sein, da die Pfade bzw. Dateinamen der JSON-Dateien im jeweiligen Deployment-Step in der „.gitlab-ci.yml“-Datei als Kommandozeilen-Parameter an das Ansible Playbook übergeben werden können.

- ansible-playbook -s ./deploy.yml --extra-vars "target=customer1 shop_docroot=${SHOP_DOCROOT_STAGE} shop_deploy_dir=${SHOP_DEPLOY_DIR_STAGE} cust_htaccess_file=.htaccess_prelive cust_config_file=config.inc.prelive.php custom_commands_path=/../src/configs/commands.json custom_symlinks_path=/../src/configs/symlinks.json" -vv

So kann es z.B. eine „commands_live.json“ und eine „command_stage.json“ im Projekt geben, in welchen jeweils unterschiedliche Shell- oder PHP-Kommandos definiert sind.

Um z.B. eine JSON-Datei mit einem Array von Kommandos einzulesen, verwenden wir im Ansible-Playbook folgendes:

commands_path: "{{ custom_commands_path | default('/files/cmds.json') }}"
commands_json: "{{ lookup('file','{{ inventory_dir }}{{ commands_path }}') | from_json }}"

Die Variable „custom_commands_path“ (Pfad zur JSON-Datei) kann per Kommandozeilen-Parameter projekt-spezifisch übergeben werden, der aufgerufene Jinja2-Filter „from_json“ liest das JSON aus der Datei in eine Ansible-Variable ein.

Das erhaltene JSON kann dann in einer Schleife („with_items“, s.u.) abgearbeitet werden, die erkannten Kommandos werden dann ausgeführt. Hier ein Beispiel für eine solche JSON-Datei:

{
  "commands":[
    {"path":"/application/views/flow/", "ctype":"shell", "cmd":"ls -altr", "stage":"prerelease", "host":"master01" },
    {"path":"", "ctype":"php", "cmd":"oxid cache:clear" }
 ]
}

Zudem kann man definieren, ob man ein Kommando „prerelease“, also vor dem eigentlichen „Aktivieren“ des Deployments (z.B. ein Backup erstellen) oder aber erst hinterher (z.B. den Cache löschen) ausführen möchte. Die Variable „host“ schränkt die Aktion optional z.B. bei einem Multi-App-Server System auf einen bestimmten Host ein.

Hier ein Ansible-Task, welcher „post-release“ Shell-Kommandos ausführt:

- name: Additional Release Shell commands
  shell: "{{ item.cmd }}"
  args:
    chdir: "{{ release_dir }}/{{ release_subfolder }}{{ item.path }}"
  with_items: "{{ commands_json.commands }}"
  register: command_result
  when:
    - item.ctype != 'php'
    - ((item.stage is defined) and (item.stage != 'prerelease')) or (item.stage is not defined)
    - ((item.host is defined) and (item.host == ansible_nodename or item.host == '')) or (item.host is not defined)

Patchen von .htaccess-Dateien

Beim Release eines Live-Shops will man in manchen Fällen den Shop kurzzeitig für Kunden „sperren“, damit die Agentur und/oder der Shopbetreiber den Shop testen, Testbestellungen ausführen usw. können. Dazu verwendet man in der Regel einen Eintrag in der „.htaccess“-Datei im Shop-Verzeichnis, welche den Zugriff auf die Website / den Shop z.B. nur für bestimmte IPs erlaubt und andere Benutzer auf einen sog. Baustellen-/Offline-Seite weiterleitet oder einen Passwort-Schutz ergänzt.

Unsere Ansible-Playbooks können optional in einem ersten Deployment-Schritt den Inhalt einer frei definierbaren Datei in die .htaccess-Datei des Shops einfügen, welche z.B. eine bestimmte IP-Freigabe enthält. Dann kann, nach Freigabe bzw. Aktivierung des neuen Deployments über das Gitlab CI Backend die Agentur bzw. der Shopbetreiber den Shop testen, um im Erfolgsfall schliesslich ebenfalls über einen Button im Gitlab-CI Backend das letzte Playbook zu starten („publish“). Dadurch wird der zusätzliche Eintrag wieder aus der .htaccess-Datei entfernt. Im Gitlab CI Backend sieht das z.B. so aus:

Die vier Haken im Bild sind die Build-„Stages“, die in der „.gitlab-ci.yml“-Datei definiert sind.
In Stage 1 wird der Shop in einem internen Docker-Container „zusammengebaut“ und ein Artefakt inkl. Ansible-Playbooks erstellt, ab Stage 2 wird Ansible aufgerufen („deploy“ – „release“ – „publish“).
In Stage 2 wird das neue Release via Ansible auf den Server hochgeladen und ein Eintrag in die .htaccess-Datei eingefügt.
In Stage 3 wird der Shop-Symlink auf das neue Deployment-Verzeichnis gesetzt und in Stage 4 wird dann schliesslich der .htaccess-Eintrag wieder entfernt und der Shop ist damit wieder frei zugänglich.

Das Einfügen in die .htaccess-Datei sieht im Playbook wie folgt aus:

- name: Add custom content to .htaccess file
  blockinfile:
    dest: "{{ release_dir }}/{{ release_subfolder }}.htaccess"
    #insertbefore: BOF
    insertbefore: "#ANSIBLE_PLACEHOLDER#"
    block: |
          {{ htaccess_include }}
    marker: "# {mark} ANSIBLE BLOCK"
  when:
    - shop_htaccess_final.stat.exists == True
    - (custom_htaccess_include_rel_path is defined) and (htaccess_include != '')

Die Variable „htaccess_include“ enthält den Inhalt der zu inkludierenden Datei, sofern vorhanden. Der Pfad zur Include-Datei kann wieder auf der Kommandozeile übergeben werden:

- ansible-playbook -s ./deploy.yml --extra-vars "... custom_htaccess_include_rel_path=/../src/configs/htaccess.inc"

Entfernt wird der zusätzliche Inhalt am Ende wieder mit folgender Task-Definition:

- name: Remove included content from .htaccess file
  blockinfile:
    dest: "{{ release_dir }}/{{ release_subfolder }}.htaccess"
    marker: "# {mark} ANSIBLE BLOCK"
    content: ""
  when:
    - shop_htaccess_patched.stat.exists == True

Wir verwenden einen Marker („#ANSIBLE_PLACEHOLDER#„) in den .htaccess-Dateien, vor welchem die Datei dann inkludiert wird. Details dazu finden sich in der Doku zum Ansible „blockinfile“-Modul.

Das war es auch schon wieder mit unserem kleinen Ansible-Exkurs, in der nächsten und letzten Folge dieser Deployment-Serie schauen wir dann Gitlab CI genauer unter die Haube!

Update PHPMailer für ältere OXID Versionen

Hintergrund

Zum Ende des vorangegangenen Jahres wurde eine Sicherheitslücke der PHPMailer-Bibliothek bekannt gegeben. Da diese auch im OXID eShop eingesetzt wird, wurde in einem ausführlichen Beitrag seitens OXID auch eine kurze Anleitung zum Update des PHPMailers auf Version 5.2.21 veröffentlicht.
Es wird darauf hingewiesen, dass durch das OXID eShop framework die Basisinstallation trotz dieser Sicherheitslücke absolut sicher ist. Einzig durch externe Frontend-Module, welche die PHPMailer- Bibliothek direkt ansprechen, besteht ein eventuelles Sicherheitsrisiko. Um diese Möglichkeit komplett auszuschließen, wird mitgeteilt, dass die Klassen class.phpmailer.php und class.smtp.php durch die aktuellste Version ausgetauscht werden sollen.
(Quelle: https://oxidforge.org/en/phpmailer-5-2-21-remote-code-execution-oxid-eshop-is-safe.html)

Update für ältere OXID eShop Versionen (< 4.9.8)

Bei älteren Installationen bis zur Version 4.9.7 reicht der Austausch der beiden Klassen jedoch nicht aus. Für den Fall, dass der Mailversand über SMTP erfolgt, sind zusätzliche Anpassungen am Code notwendig. Bis zur Version 4.9.8 wurde in den OXID Core-Klassen oxEmail sowie auch oxDb jeweils nur die PHPMailer-Klasse eingebunden.

oxemail.php:

require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.phpmailer.php“;

oxdb.php:

include_once getShopBasePath() . ‚core/phpmailer/class.phpmailer.php‘;

Bei älteren Versionen des PHPMailers ist dies auch ausreichend, da die Klasse SMTP bei Aufruf der Funktion SmtpSend() in der PHPMailer-Klasse inkludiert wird:
require_once $this->PluginDir . ‚class.smtp.php‘;
In der aktuellsten PHPMailer-Bibliothek werden jedoch die einzelnen Klassen (darunter auch SMTP) nicht mehr innerhalb von class.phpmailer.php‘, sondern über eine eigene autoloader-Klasse initialisiert (Quelle: https://github.com/PHPMailer/PHPMailer/wiki/Tutorial).
Um die Funktionalität von PHPMailer bei älteren OXID eShops komplett zu gewährleisten, ist daher eine weitere Anpassung notwendig. Zusätzlich zur beschriebenen Aktualisierung, muss in den beiden OXID Core-Klassen noch class.smtp.php eingebunden werden. Der folgende Code zeigt, wie die aktualisierte Klasse SMTP in OXID, Version 4.9.7, verwendet werden kann. Für weit ältere Installationen ist es nötig, sich an der schon bestehenden Einbindung der PHPMailer-Klasse zu orientieren und diese für class.smtp.php zu adaptieren.

Klasse oxEmail (v4.9.7):

require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.phpmailer.php“;
require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.smtp.php“;

Klasse oxDb (v4.9.7):

include_once getShopBasePath() . ‚core/phpmailer/class.phpmailer.php‘;
include_once getShopBasePath() . ‚core/phpmailer/class.smtp.php‘;

 

Continuous Delivery mit Docker, Gitlab CI und Ansible

Im letzten Jahr haben wir bei shoptimax den Entwicklungs- und Deployment-Workflow stark optimiert, um Projekte möglichst effektiv umsetzen, automatisiert testen und Fehler vermeiden zu können, die z.B. bei manuellen Uploads oder Änderungen direkt auf dem Server auftreten können. Mit einem passenden Continuous Delivery Workflow kann man erreichen, dass Änderungen zeitnah und zuverlässig ausgespielt werden können und dass auf einem Server immer ein genau definierter Zustand herrscht. Nicht zuletzt werden dadurch auch die Entwickler entlastet, da sie sich nicht mehr um das Hochladen von Änderungen, Abgleichen unterschiedlicher Datei-Versionen usw. kümmern müssen und sie durch automatisierte Tests und Validierungen frühzeitig Feedback bekommen, sollte es Probleme im Zusammenspiel der Software geben.

Alle neuen Projekte werden seit einigen Monaten bereits mit automatisiertem Deployment und nach dem Grundsatz „Continuous Delivery“ umgesetzt, ältere bzw. größere laufende Projekte stellen wir nach und nach um.

Entwicklungs-Workflow

Grundsätzlich gilt: jeder Entwickler sollte primär in seiner lokalen Umgebung entwickeln können, wozu Docker eingesetzt wird. Der Entwickler arbeitet, testet und debugged lokal auf seinem eigenen Rechner, „committed“ und „pusht“ seine Arbeit anschliessend in unsere GIT-Versionsverwaltung, für welche wir einen internen Gitlab-Server nutzen. Im Docker-Container der Entwickler sind zudem Tools wie Blackfire.io oder XHProf sowie Xdebug verfübar.

Sobald mit GIT in den sogenannten „develop“-Branch gepusht wird, übernimmt unser Gitlab-Server das automatische Deployment auf ein internes Test-System, auf welchem dann Projektleiter oder andere Beteiligte (Grafiker usw.) den aktuellen Stand begutachten können.

Pusht ein Entwickler in den sog. „stage“-Branch, wird der Stand, nach optionalem Durchlaufen von Tests usw., auf einen externen Entwicklungsserver gespielt, z.B. auf einen Kunden-Staging-Server.

Ein Release-Manager kann schliesslich noch in den sog. „master“-Branch pushen, dieser wird dann automatisch auf den Live-Server ausgerollt, allerdings wird hier ein Feature von Gitlab CI genutzt, welches es ermöglicht, neue Deployments über die Gitlab-Oberfläche manuell per Button zu „aktivieren“ – dazu reicht ein simples

when:
– manual

in der Datei „.gitlab-ci.yml“.

So kann der genaue Zeitpunkt bestimmt werden, wann der neue Stand online geht und es können vorher z.B. noch Kontrollen durchgeführt werden. Der vorherige Stand wird auf dem Server belassen, so ist ein blitzschnelles „Rollback“ über die Gitlab-Oberfläche oder die Shell möglich, sollte es doch einmal Probleme mit der neuen Version geben.

Build und Testing

In allen drei Fällen (develop, stage und master Branch) können optional vorab in einem automatisch von Gitlab gestarteten Docker-Container z.B. Akzeptanz-Tests usw. mit Codeception durchgeführt oder Coding-Standards mittels PHP Codesniffer und ähnlicher Tools geprüft werden etc.
Ausserdem können mit einem auf „ioly“ bzw. „OXID Modulconnector“ basierenden Installer im Shop benötigte Module aus anderen GIT-Repositories oder auch von Drittanbietern automatisch installiert und aktiviert werden.
Schlägt einer der automatisierten Tests fehl, wird das Deployment gestoppt. Sind die Tests erfolgreich, wird der komplette, getestete Shop im Docker-Container als *.tar.gz gepackt.

Ausrollen mit Ansible

Im nächsten Step wird innerhalb des Docker-Containers unser Ansible-Deployment Repository aus GIT geclont.

Ansible ist eine Server-Orchestrierungs/Konfigurations-Software, womit man von einem mit Ansible ausgestatteten Rechner beliebig viele „entfernte“ Rechner/Server administrieren kann. Dazu ist auf den Remote-Rechnern keinerlei Client- oder Server-Komponente nötig, es muss lediglich ein Public Key hinterlegt werden. Die Ansible Befehle definiert man in sog. „Playbooks“, die einfach im YAML-Format geschrieben werden können.

Unser Ansible-Playbook kann nun den kompletten Shop auf beliebige Server hochladen/verteilen und diverse zusätzliche Tasks ausführen, z.B. Symlinks anlegen (die in einer JSON-Datei definiert werden können) sowie Shell- oder PHP-Befehle ausführen (ebenfalls in JSON beliebig definierbar, z.B. Tmp-Verzeichnis leeren, Datenbank-Views neu erzeugen, Module aktivieren usw.).
Abschliessend kann von Ansible automatisch oder auch manuell per Button der Symlink auf das Haupt-Shopverzeichnis geändert und so der neue Stand live geschaltet werden. Wie schon erwähnt ist auch ein schnelles Rollback kein Problem, da der vorherige Stand (sowie einige ältere Stände) noch auf dem Server vorgehalten werden.

In weiteren Blog-Beiträgen werden wir sowohl Gitlabl CI näher vorstellen als auch einige Ansible-Features näher beleuchten. Teil 2 zum Thema „Ansible“ jetzt hier lesen!

OXID Hackathon Nürnberg 2016

OXID-Hackaton

Um was geht es beim OXID Hackathon?

Den Ruf nach einem OXID Hackathon gab es schon lange – endlich wurde dazu auch ein Termin und eine passende Location im Coworking Space Nürnberg gefunden. Ziel dieses Hackathons ist es, innerhalb der beiden angesetzten Tage gemeinsam nützliche, coole und kreative Erweiterungen rund um OXID (gern auch die OXIDforge.org) herzustellen.

Wie ist der Ablauf?

Am Freitagmorgen werden die Sessionvorschläge gemeinsam angesehen und entscheiden, an welchen Themen gearbeitet werden soll. Offizielles Ende ist Samstagnachmittag/-abend. Die Teilnehmer können jedoch so lange im Coworking Space bleiben, wie sie möchten – das Gleiche gilt für Freitagabend. Wer von außerhalb anreist, wird womöglich schon am 09.11.16 in Nürnberg sein – deshalb gibt es ein Treffen zu einer kleinen Abendveranstaltung am Donnerstag. Von OXIDs Seite ist für das Catering über die Veranstaltungstage gesorgt.

Wie kann man teilnehmen?

Die Registrierung erfolgt über den Openspacer. Bitte schon jetzt Themenvorschläge einreichen, es erfolgt eine Abstimmung auf der offiziellen Seite bzw. final vor Ort, woran gearbeitet wird.

Wo kann man übernachten?

Nur 300m vom Coworking Space entfernt ist das *** Garden-Hotel. Weitere verfügbare Hotels sind hier zusammengefasst.

Veranstaltungsdetails

11.11.2016 bis 12.11.2016
ab 09:00 Uhr

Coworking Nürnberg
Josephsplatz 8
90403 Nürnberg

http://coworking-nuernberg.de

Veranstalter

OXID Community
http://oxidforge.org

EXKLUSIV bei OXID: B2B-Shopsystem-Studie im Wert von 700 Euro kostenlos!

Vor einiger Zeit haben wir in unserem Blog darüber berichtet, dass das Shopsystem unseres Partners OXID eSales zu einem der besten B2B Shopsysteme gekürt wurde. Nun kann die zugehörige Studie im Wert von 700 Euro kostenlos heruntergeladen werden.

OXID iBusinessStudie
In der Studie von iBusiness werden die besten und bekanntesten B2B-Shopsysteme bis und ab 100.000 Euro Investitionsaufwand unter die Lupe genommen, die sich für die Umsetzung verschiedener B2B-Anforderungen am besten eignen. Das ausgewogenste Verhältnis zwischen Aufwand und Leistung zeigte in der Budgetklasse bis 100.000 Euro dabei das Shopsystem OXID eSales.

Die Studie enthält wertvolles Wissen und fundierte Grundlagen, wodurch Interessierte wichtige Entscheidungen in Bezug auf die Auswahl des für ihre Anforderungen am besten geeigneten Shopsystems treffen können. Es wird gezeigt:

– worauf bei der Auswahl von B2B-Shopsystemen zu achten ist
– welches Shopsystem in welchem Segment die beste Leistung bietet
– wie die Systeme im Vergleich zu bewerten sind
– welche Dienstleister bei der Implementierung unterstützen können

Jetzt zugreifen und die Studie im Wert von 700 Euro hier KOSTENLOS herunterladen!

OXID launcht eShop 5.3: Neue Einkaufswelten wecken Shopping-Emotionen

OXID eSales hat seine Shopsoftware OXID eShop einer umfangreichen Kur unterzogen. Mit dem Launch der Release 5.3 hat das ausgereifte und hundertfach eingesetzte System nun das lang erwartete Responsive Theme „Flow“ sowie ein vollintegriertes echtes E-Commerce Content Management System „Visual CMS“ im Standard mit an Bord. „In einer zunehmend Amazon-dominierten Welt, ist es für Onlinehändler wichtig, sich mit einem einzigartigen Online-Offering klar abzuheben. Relevanter Content und emotionale Einkaufswelten auf allen Kanälen sorgen für neue Umsätze und bessere Kundenbindung“, sagt Roland Fesenmayr, Vorstand der OXID eSales AG.

oxid-news

Mit „Flow“ verkaufen auf allen Kanälen

Mit dem neuen full-responsive Design-Theme „Flow“ bereitet OXID eSales bereits out-of-the-box auch auf Smartphones und Tablets ein unverwechselbares Einkaufserlebnis. Neben der weitrechenden plattformübergreifende Darstellbarkeit des Webshops sorgen Social Media Integrationen dafür, dass alle gängigen Kanäle von facebook, twitter und Google+ über youtube bis hin zu WordPress bespielt und Kunden überall kommunikativ erreicht werden können. Über API eingebundene Schnittstellen wie Google Shopping und Google Analytics geben wertvolles Feedback zu Erfolgsmessung und Kampagnencontrolling. Das „Flow“-Theme ist mit den Shop-Versionen 4.10 (Community Edition/Professional Edition) und 5.3 (Enterprise Edition) verfügbar.

“Visual CMS” – ein echtes E-Commerce CMS

„Ein Webshop kann heute nicht mehr ein statischer Produktkatalog sein. Der Händler steht im B2C- wie auch im B2B-Geschäft unter dem Druck, seinen Kunden kontinuierlich aktualisierten, relevanten Content anzubieten. Dazu wollen wir dem Shopmanager die nötigen Mittel an die Hand geben“, erklärt Fesenmayr.
Eine Besonderheit des ab sofort im Lieferumfang enthaltenen „Visual CMS“ ist der direkte Zugriff auf Artikeldaten und ihre Einbindung in frei gestaltbare Inhalte. Diese neue Backend-Funktionalität kommt mit einer grafisch zu bedienenden Oberfläche, sodass die Händler selbst direkt im Shop Landing Pages und Kampagnen gestalten können. Auf diese Weise werden Shopdaten, Markeninhalte und verkaufsfördernde Inhalte perfekt miteinander verknüpft – es gibt keinen Systembruch mehr.

Dank der serienmäßig vorhandenen Basic Widgets ist mit nur wenigen Mausklicks eine neue zielgruppenspezifische Landingpage erstellt. Wem das nicht reicht und auch für speziellere Anforderungen entwickeln E-Commerce Agenturen auf Basis von „Visual CMS“ individualisierte Widgets. „Egal ob „basic“ oder „custom“, die Bedienung der Widgets ist ohne technische Kenntnisse möglich – wie geschaffen also für den Einzelhändler jeder Größe, der online erfolgreich sein möchte“, resümiert Roland Fesenmayr von OXID die jüngste Ausbaustufe des Shopsystems.

Die OXID eSales AG gehört zu den führenden Anbietern von E-Commerce-Lösungen und Dienstleistungen. Auf Basis der OXID-Plattform lassen sich skalierbare, modulare und hochwertige Webshops in allen Branchen, für B2B ebenso wie für B2C, aufsetzen und effizient betreiben. Im B2C-Geschäft vertrauen Unternehmen wie Porsche Design, Melitta, Trigema, Lascana, oder Intersport auf OXID. Die umfassende Lösung für B2B-Shopbetreiber nutzen unter anderem 3M, Murrelektronik oder Unilever Food Solutions. Die modulare Standardsoftware wird dabei von über 150 Solution Partnern nach Wunsch implementiert, eine stetig wachsende Open Source-Gemeinde sorgt stets für neue und marktgerechte Impulse, mit der die Software voll dem Bedarf entspricht. Webshop, Mobile und Point of Sale (POS) decken dabei das volle Multichannel-Spektrum ab.

Und jährlich grüßt die Oxid Academy

Wie bereits im vergangenen Jahr machten sich auch im diesjährigen Juni wieder einige Entwickler der shoptimax GmbH auf zum Workshop-Seminar „OXID eShop Zertifizierung Technik Modul 1 – Modul 3“.

Freuen sich über ihre erfolgreiche OXID-Zertifizierung: (v.l.n.r.) Artem Eremitschew, Vaclav Hoblik und Xiuqi Zhu

Freuen sich über ihre erfolgreiche OXID-Zertifizierung: (v.l.n.r.) Artem Eremitschew, Vaclav Hoblik und Xiuqi Zhu

Vaclav Hoblik, Artem Eremitschew und Xiuqi Zhu lernten an drei aufeinanderfolgenden Tagen in Berlin geballtes OXID-Wissen – angefangen von der sicheren Anwendung des OXID eShop inklusive Basiswissen über individuelle Anpassungsmöglichkeiten, tiefgehende Kenntnisse über die Architektur des OXID eShop, die zur Entwicklung eigener, einfacher Module befähigen bis hin zu Besonderheiten der Enterprise Edition und sich daraus ergebenden Möglichkeiten.

„Mir war es wichtig, dass nicht nur ich als Teamleiter des Bereichs Softwareentwicklung meine Kenntnisse in Bezug auf OXID eSales vertiefe und mir neue Inspiration hole, sondern dass auch Xiuqi und Artem als meine Teammitglieder von dieser wirklich ausführlichen Schulung profitieren. Natürlich arbeiten sie bereits tagtäglich mit dem Shopsystem, aber der Workshop biete eine optimale Möglichkeit, sich auch mit anderen Entwicklern einmal austauschen zu können und den eigenen Horizont zu erweitern“, so die Bilanz von Vaclav Hoblik. Nun dürfen sich die drei Entwickler von shoptimax offiziell „OXID eShop Certified Engineer (PE) & OXID eShop Certified Engineer (EE)“ nennen. Damit reihen sie sich in eine stolze Anzahl von in den vergangenen Jahren bereits über 25 durch OXID zertifizierte shoptimax-Mitarbeiter ein.

Ein unschlagbares Team – OXID eSales und shoptimax

Bereits seit 2004 ist shoptimax OXID Premium Solution Partner – seit 2013 OXID Enterprise Level Partner. Unsere Entwickler nehmen regelmäßig an Seminaren und Schulungen der OXID eSales AG teil, um immer auf dem neuesten Stand zu bleiben und die bestmöglichen Lösungen aus dem Shopsystem für unsere Kunden erarbeiten zu können.

Einer der Hauptschwerpunkte unserer Arbeit liegt auf der Entwicklung von OXID Modulen für die unterschiedlichsten Anwendungsmöglichkeiten und der Implementierung des Shopsystems in die ERP- und PIM-Backendsysteme unserer Kunden. Eine besonders beliebte Schnittstelle ist beispielsweise OXID2plentymarkets, die offiziell autorisierte Schnittstelle zwischen OXID und der E-Commerce-Warenwirtschaft plentymarkets.

EHI Reifegrad Analyse 2016 – www.sporthaus.de zählt zu den Top-Shops für Sportartikel

Intersport Krumholz sorgt auch bei kurzentschlossenen Fußballfans für gute Stimmung zur EM 2016!

Der von der shoptimax GmbH umgesetzte Onlineshop www.sporthaus.de spielt laut aktuellem EHI Onlineshop-Maturity-Index 2016 deutlich in der obersten Shopping-Highlight-Liga. Das seit 2014 bestehende Online-Verkaufsportal des Sportfachgeschäftes INTERSPORT Krumholz landet mit über 109 von möglichen 150 Punkten auf Platz vier der insgesamt 35 bewerteten Online-Sportartikelshops. Auch wer die Verbundenheit zu seiner Lieblingsfußballmannschaft pünktlich zur EM 2016 zeigen wollte oder noch kurzentschlossen zeigen will, war und ist laut EHI beim Onlineshop von INTERSPORT Krumholz genau richtig.

Infografik-OMI-TOP-10-Sportartikelanbieter-2016-web

Die Top 10 der Sportartikelanbieter in Deutschland – Ranking nach Onlineshop-Maturity-Index (OMI) 2016 (Grafik: EHI)

Bedürfnisse der Kunden stehen bei www.sporthaus.de im Mittelpunkt – nicht nur zur Fußball EM 2016

„Wir sehen unseren Onlineshop als eine zeitgemäße Ergänzung zu unseren Krumholz-Sporthäusern in Neuwied, Mayen, Mülheim-Kärlich und Bad Neuenahr-Ahrweiler“, so Paul Krumholz, Geschäftsführer der Sporthaus Krumholz Mülheim-Kärlich GmbH. Unter www.sporthaus.de wird ein Teilsortiment der stationären Filialen auf einem weiteren Kanal abgebildet, der dem Unternehmen die zusätzliche regionale Vernetzung mit seinen Kunden, aber auch die überregionale Umsetzung der INTERSPORT-verbundübergreifenden Multichannel-Strategie erlaubt. „Preis, Leistung und Service passen bei uns on- wie offline zusammen. Zudem bauen wir das Sortiment des Onlineshops kontinuierlich aus. Schon jetzt werden alle Prospekt- und Preisaktionen abgebildet und wir tun alles dafür, den Shop noch weiter voranzubringen“, so Krumholz weiter.

Infografik-OMI-Sportartikelanbieter-2016-em-web

Sportartikel-Onlineshops: Service- und Bestellmöglichkeiten zur EM 2016 (Grafik: EHI)

Was für INTERSPORT Krumholz als Selbstverständlichkeit gilt, ist aber besonders zur aktuellen Fußball EM gefragt: „Kurzentschlossene Fans waren und sind bei uns zur EM 2016 genau richtig. Wir erfüllen nicht nur den Fairplay-Faktor und bieten neben den Artikeln der Deutschen Elf auch Fanartikel anderer Nationen an. Zudem ist es möglich, unsere Services Click & Collect, Click & Reserve sowie die Anzeige der Verfügbarkeit in unseren Filialen zu nutzen“, so Paul Krumholz.

Umsetzung durch shoptimax

Für die Umsetzung des Onlineshops zeigt sich der E-Commerce-Lösungsanbieter shoptimax aus Nürnberg verantwortlich. „Die nun seit fast drei Jahren andauernde Zusammenarbeit mit shoptimax war und ist jederzeit unkompliziert und lösungsorientiert“, so Paul Krumholz.
Die Plattform „Oxid“ und die E-Commerce-Software „Plentymarkets“ stellen die Infrastruktur von www.sporthaus.de dar und wurden mit mehreren Schnittstellen an das stationäre Warenwirtschaftssystem „Intersys“ der INTERSPORT angebunden. Die homogene Verknüpfung zwischen beiden Systemen ermöglicht den Echtzeitzugriff auf die Lagerbestände der Filialen. Das Controlling von Planung, Einkauf und Disposition erfolgt damit für Online- und Offline-Handel aus einem Kanal. Größter Wert wurde bei der Umsetzung außerdem auf Kundenfreundlichkeit, Datensicherheit und Usability gelegt. So ist der Onlineshop beispielsweise durch Responsive Design auch auf mobilen Endgeräten jederzeit optimal bedienbar. Für beste Suchergebnisse wurde die eigens von shoptimax entwickelte intelligente Shop-Suche „shoptifind“ integriert. Das Zusammenspiel all dieser Punkte hat zu der insgesamt sehr guten Bewertung im Onlineshop-Maturity-Index 2016 geführt.

Positive Bewertung im OMI – positiver Blick in die Zukunft

Für Paul Krumholz bedeutet die positive Bewertung in der aktuellen EHI-Studie, mit seiner Gesamtstrategie alles richtig gemacht zu haben: „Mit unserer über 60-jährigen Tradition im Dienste des Sports, sind wir seit Jahren das führende stationäre Sportfachgeschäft im Norden von Rheinland-Pfalz. Die im EHI Onlineshop-Maturity-Index 2016 erreichte Punktezahl zeigt nun endlich, dass wir auch Online alles zu bieten haben, was das Sportlerherz begehrt.“ Auf dem Erfolg ausruhen wird sich das Unternehmen aber nicht: „Der Käufer und das Shoppingerlebnis stehen bei uns jederzeit im Mittelpunkt – und gemeinsam mit unserem E-Commerce Experten shoptimax tun wir alles dafür, dass dies in Zukunft nicht nur so bleibt, sondern wir in allen vom EHI geforderten Kriterien kontinuierlich besser werden“, so Krumholz abschließend.

Onlineshop-Maturity-Index (OMI) und Reifegradstufen

Maßgeblich für die Bemessung des Onlineshop-Maturity-Index (OMI) bzw. Reifegrades eines Onlineshops sind unter anderem Kriterien wie Benutzerfreundlichkeit, Performance oder Produktpräsentation bzw. –suche. Aber auch die Themen Datenschutz und Datensicherheit sowie die Einfachheit bei Bezahlung, Lieferung und Rückgabe spielen eine erhebliche Rolle bei der Bewertung. Insgesamt werden die Shops individuell auf die Ausführung und das Vorhandensein von 91 Kriterien in 8 Kategorien geprüft, die in einem nach heutigen Standards ideal umgesetzten Onlineshop möglich wären.
Die maximal erreichbare Punktzahl bei der Analyse liegt bei 150 Punkten. Je nach erzielter Punktezahl des analysierten Onlineshops erfolgt die Einordnung in eine von fünf Reifegradstufen, wobei die Reifegradstufe 5 mit über 100 erzielten Punkten der bestmöglichen Bewertungsstufe „Shopping-Highlight“ entspricht:
Im Rahmen der EHI-Studie „Onlineshop-Maturity-Index 2016 – Reifegrad-Analyse Onlineshops“ (Datenerfassung: Mai 2016) bietet das EHI individuelle Sonderauswertungen für die analysierten Onlineshops an. Diese sind über die Seite des EHI bestellbar.

Link zum INTERSPORT Krumholz Online-Shop