Technische Dokumentation
Shopware 6 - Quick Price Change App
App Highlights
- Preise beliebig anpassen
- Prozentuale und absolute Anpassung
- Individuelle Preisstrategie
- Zeitgesteuerte Preisänderung (coming soon)
- Pseudopreise setzen (coming soon)
App Features
- Preise erhöhen und senken
- Preisanpassung für Hersteller
- Preisanpassung auf dynamische Produktgruppen
- Anpassung auf Brutto oder Nettopreise
- Backups der Änderungshistorie
- Runden von Preisen (Einser, Zehntel, Hundertstel)
- Preisendungen bestimmen (Einser, Zehntel, Hundertstel)
Tech-Stack
Der Tech-Stack für die App sieht wie folgt aus:
- Shopware App
- Manifest
- Shopware Admin API
- UI Frontend
- React App
- Typescript
- Fluent UI
- App Service
- Azure Functions
- Azure durable Functions
- C#
- Azure Storage
Wir haben uns für die Kombination aus Azure Functions & React als UI Framework entschieden, da wir bereits viele Kundenprojekte damit realisiert haben und langfristig ein sehr großes Potenzial in der Azure Cloud für die E-Commerce-Szenarien unserer Kunden sehen. Azure Functions bieten eine sehr gute Möglichkeit, skalierbare Serverless Lösungen in relativ kurzer Zeit zu realisieren.
Diga App Framework
Damit wir schnell neue App Services umsetzen können, haben wir uns entschieden Funktionen, die wir für jede App benötigen in eine eigene Bibliothek auszulagern. Dafür haben wir intern das Diga App Framework Projekt gestartet. Die .NET Core 3.1 Class Library beinhaltet alles, was für einen App-Service notwendig ist. Funktionen wie Registration, RegistrationConfirmation, AppDeleteRequest usw.
Das App-Framework besteht aus den folgenden Komponenten:
- Shopware 6 App
- Diga[ShopwareAppTechName]App
- Diga[ShopwareAppTechName]App
- Azure Functions API Service(s) Logic
- Diga[ShopwareAppTechName]Service
- Diga[ShopwareAppTechName]Service
- UI for App Iframes
- Diga[ShopwareAppTechName]ServiceUI
- Diga[ShopwareAppTechName]ServiceUI
- Diga.SwAppFramework
- C# Framework for Shopware Apps
- AppRegistration
- AppInstalled
- AppDeleted
- …
- Diga.Sw6APIClient (C# API Client)
Besonders das Zusammenspiel der drei Komponenten zwischen Shopware App, Service UI und des Services der die eigentliche Logik beinhaltet sind wichtig zu verstehen um schnell mit der App Entwicklung starten zu können. Der Sw6APIClient wird bei uns für viele weitere Projekte genutzt und entwickelt sich stetig weiter, damit bauen wir Anbindungen an WaWi Systeme, automatisieren kundenspezifische Prozesse mit und auf Azure. Für Integrationen von Shopware 6 und der Microsoft 365 Plattform haben wir damit einen wichtigen Grundstein gelegt und bauen diesen nach und nach aus.
Shopware App
Unsere Shopware App ist recht simpel, es war nur wichtig die UI in dem Admin Bereich zu registrieren und die nötigen Rechte anzufordern.
Menue Entry
<admin>
<module name="changePrices"
source="https://[service-endpunkt].azurewebsites.net/app/index.html"
parent="sw-catalogue"
position="50">
<label>App</label>
<label lang="de-DE">App</label>
</module>
</admin>
Registrierung im Admin Bereich, damit die User auf das App UI zugreifen können.
Manifest with Permissions and URLs to the Endpoint
<permissions>
<!-- this is to work with the products -->
<read>product</read>
<update>product</update>
<read>seo_url</read>
<read>tax</read>
<read>category</read>
<read>product_manufacturer</read>
<read>product_stream</read>
<read>property_group</read>
<read>property_group_option</read>
</permissions>
Die Rechte mussten wir ein paar mal anpassen, bis wir alles für unseren Service notwendige abgedeckt haben. Das ist aber während der Entwicklung schnell gemacht.
React UI
Die App haben wir mit React umgesetzt, weil wir ein leichtgewichtiges Framework haben wollten und bereits gute Erfahrung aus anderen Projekte hatten. Für Fluent UI haben wir uns entschieden, um ein bisschen Microsoft 365 Look-and-Feel zu erzeugen, aber auch weil diese einige gute React Komponenten bieten, eine gute Doku und eine riesige Community aus der SharePoint Entwickler Ecke.
- UI Frontend
- React App
- Typescript
- Fluent UI - Microsoft React Component Library
Azure App Service
Das Herzstück der App ist als eine Azure Function App realisiert. Azure Functions ermöglichen uns sehr schnell C# oder auch einen anderen Code in kleinen Funktionen zu organisieren, schnell in die Cloud zu bringen und über unterschiedliche Trigger zu starten. Die Functions können beliebig skalieren, sodass wir eine beinahe beliebige Menge an Anfragen bearbeiten können. In Kombination mit Azure durable Functions haben wir die Möglichkeit sogenannte statefull functions zu realisieren und Cloud Pattern, mit denen wir unseren Anforderungen gut abbilden konnten. z. B. nutzen wir das Async HTTP APIs Pattern, um den Kunden über den Fortschritt seines Updates zu informieren.
- App Service Endpoint
- Azure Functions serverless
- Azure durable Functions
- C#
- Azure Storage
- Azure Functions because
- Easy to start
- HTTP trigger to build APIs
- Simplify complex orchestration with durable functions
- Nice ready to use patterns
- Nice Monitoring
https://azure.microsoft.com/en-us/services/functions/#features
Lessons Learned
-
Shopware ID ist nicht eindeutig, wenn man Shops dupliziert oder eine Staging Umgebungen erstellt wird. Das haben wir zum Glück auf einem Testsystem herausgefunden, danach haben wir die Identität über Shopware ID + Host überprüft.
- Batch Bulk API Performance: wir mussten uns herantasten wie viele Artikel wir in einem Batch gut verarbeiten können, dafür haben wir die Batch Size konfigurierbar gemacht und das dann nach dem deployen justiert.
- Indexieren: Für das Ändern der Preise war auch das Indexieren ein Thema, mit dem wir uns auseinandersetzen mussten. Dafür ist die Shopware Admin API Doku eine gute Quelle.
- Auch dieser Header war für uns nützlich, um bei Fehlern nicht den ganzen Batch an Requests abzubrechen request.AddHeader("fail-on-error", "false");