1. Einleitung Pimcore
Last updated
Last updated
Pimcore ist eine Open-Source-Plattform für Product Information Management (PIM) und mehr. Ursprünglich entwickelt als PIM-System, hat es sich zu einer umfassenderen Plattform für das digitale Asset Management (DAM), Customer Experience Management (CMS/UX), und eCommerce weiterentwickelt.
Pimcore ermöglicht es Unternehmen, Produktinformationen zentral zu verwalten, zu pflegen und zu synchronisieren. Dies ist besonders nützlich für Unternehmen mit umfangreichen Produktkatalogen.
Pimcore bietet Funktionen für das Erstellen und Verwalten von Inhalten für Webseiten, einschließlich Templates, Workflow-Management und mehrsprachige Unterstützung.
Es bietet umfangreiche Funktionen für die Verwaltung von digitalen Assets wie Bilder, Videos, Dokumente usw. Diese können zentral organisiert, bearbeitet und für verschiedene Zwecke bereitgestellt werden.
Durch die Integration von Pimcore mit eCommerce-Plattformen können Unternehmen nahtlose Einkaufserlebnisse über verschiedene Kanäle hinweg bieten.
Die MOTOREX-BUCHER GROUP AG setzt Pimcore ein um die folgenden Webseiten und deren Inhalte zu verwalten:
Pimcore unterstützt die Integration mit anderen Systemen und Diensten über eine API, was die nahtlose Verbindung mit bestehenden IT-Infrastrukturen ermöglicht.
Die Architektur umfasst eine bidirektionale Integration zwischen SAP ERP und Pimcore, die über eine REST-API realisiert wird. Dies ermöglicht einen nahtlosen Datenaustausch und die Synchronisation von Informationen zwischen den beiden Systemen.
SAP ERP Modul: Enthält verschiedene Module wie MM (Material Management), SD (Sales and Distribution), PP (Production Planning), und FI/CO (Finance and Controlling).
Pimcore: Besteht aus PIM, DAM, CMS und MDM, die für das Management und die Bereitstellung konsistenter Daten und Inhalte verantwortlich sind.
Datenreplikation Pimcore:
Daten aus SAP (z.B. Produktstammdaten, Bestandsdaten, Preisdaten) werden regelmäßig in Pimcore importiert. Der Datentransfer erfolgt zunächst durch einen Initial Load und wird anschließend über einen Event-Mechanismus mit RFC-Aufrufen und Funktionsbausteinen aktualisiert. Änderungen an den SAP-Datenobjekten werden erkannt, in eine Synchronisationstabelle geschrieben, und Pimcore liest diese Tabelle regelmäßig (alle 5 Minuten) aus. Bei erkannten Änderungen liest Pimcore die aktualisierten Daten aus SAP. Die Architektur ist so gestaltet, dass nur ein Minimum an Schnittstellen zwischen Pimcore und SAP erforderlich ist.
Folgende Business Objekte werden aus dem SAP System zu Pimcore repliziert
Produkte (Dokumentinfosätze im ERP), Objekt: PRODUCT
Artikel (Materialstamm im ERP), Objekt: ARTICLE
Rezepturen (Materialstamm im ERP), Objekt: RECIPE
Auftraggeber, Warenempfänger (Geschäftspartner im CRM), Objekt: BPARTNER
Ansprechpartner (Geschäftspartner im CRM), Objekt: BPARTNER
Händler (Geschäftspartner im CRM), Objekt: BPARTNER
Distributor (Geschäftspartner im CRM), Objekt: BPARTNER
Klassen (Klassifizierung im ERP), Objekt: CLASS
Merkmale (Klassifizierung im ERP), Objekt: CHARACTERISTIC
Datenreplikation zu Pimcore manuell anstossen
Für die initiale Datenübertragung wird im SAP das Programm ZPC_INITIAL_LOAD über die Transaktion ZPC_SYNCH_OBJ ausgeführt. Dabei wählt man anhand des Business Objekttyps passende Selektionskriterien, um die zu synchronisierenden Objekte einzuschränken. Mit der Option "abhängige Objekte selektieren" können auch verknüpfte Objekte, wie z.B. Rezepte eines Produkts, mit synchronisiert werden. Wenn die Verarbeitung erfolgreich ist und neue Synchronisationseinträge erstellt wurden, werden diese nach Abschluss als Liste angezeigt. Pimcore startet danach automatisch den Synchronisationsprozess.
Synch Einträge anzeigen
Durch setzen eines "x" unter "Synch Einträge anzeigen" kann der Synch-Status eines Objekts überprüft werden.
U (Änderung offen)
Status der gleich nach Anstossen des Synch-Eintrags gesetzt wird. Das Objekt wird in die Warteschlange gesetzt. Dieser Status sollte innert kürzester Zeit auf Status P wechseln.
P (Sync-Prozess läuft)
Der Synchronisations-Prozess läuft.
S (Synchronisiert)
Die Daten wurden erfolgreich zu Pimcore repliziert
Bleibt der Synch-Status auf U hängen liegt in der Regel ein Problem bei SAP vor
Bleibt der Status auf P hängen liegt in der Regel ein Problem bei Pimcore vor
-> In beiden Fällen soll das Webshop Team kontaktiert werden.
Datenanreicherung in Pimcore:
In Pimcore werden die importierten Daten weiter angereichert und verwaltet. Pimcore ermöglicht die Anreicherung von Produktinformationen, Verwaltung von digitalen Assets (Bilder, Videos, Dokumente), und die zentrale Steuerung von Marketing- und Vertriebskanälen.
Datenexport aus Pimcore:
Angereicherte und validierte Daten können aus Pimcore zurück in SAP exportiert werden oder in andere Systeme und Kanäle (wie eCommerce-Plattformen, Print-Kataloge, Mobile Apps) übertragen werden.
Der Indexierungsprozess wird verwendet, um Daten in OpenSearch zu aktualisieren und sicherzustellen, dass die neuesten Informationen in Pimcore und somit auch im Frontend verfügbar sind. Dabei werden Daten regelmässig verarbeitet und aktualisiert. Es gibt ein paar Regeln und Zeitpläne, die beachtet werden müssen.
Regelmässige Updates - Funktionsweise:
Zur vollen Stunde wird ein neuer Indexierungsprozess initiiert. Die Entscheidung, ob und welche Indizes aktualisiert werden, hängt von folgenden drei Faktoren ab:
Timeout: Wenn ein Index aktualisiert wird, wird dieser gesperrt („gelocked“). Das Lock bleibt auf den Umgebungen QA und P für zwei Stunden aktiv, auf D/Demo dauert es länger. Nach Abschluss der Indexbearbeitung wird das Lock entfernt, was verhindert, dass der Prozess mehrmals gestartet wird. Der Status des Locks kann im "Report Indexer Status" in der Spalte „Timeout“ eingesehen werden, die den Ablauf des Locks anzeigt und somit den Startzeitpunkt des Prozesses erkennen lässt. Die Dauer des Locks ist im Code festgelegt und kann von Valantic angepasst werden. Im Falle eines katastrophalen Fehlers wird das Lock nicht entfernt; es sollte dann Valantic informiert werden. Ein entsprechender Report sieht wie folgt aus:
Name: Product
Messages: 0
Errors: 0
Timeout: ausgefüllt
Cooldown: entweder ausgefüllt oder nicht (vermutlich nicht)
Dies kann auch geschehen, wenn es keine Objekte für einen Index gibt, z.B. bei Intranet-Indizes. Das Lock läuft in jedem Fall nach der angegebenen Zeit ab.
Cooldown: Nachdem ein Index fertiggestellt wurde, wird das Timeout Lock entfernt und ein Cooldown Lock erstellt, welches auf P+QA eine Stunde und auf D/Demo zwei Stunden dauert. Ein Cooldown Lock hat denselben Effekt wie das Timeout Lock; während des Cooldowns wird kein neuer Durchlauf für diesen spezifischen Index gestartet, jedoch wird der Lock nicht programmatisch entfernt, sondern es wird immer das Ablaufen des Timeouts abgewartet.
Nicht verarbeitete Nachrichten: Wenn Nachrichten in der Queue sind, die noch nicht verarbeitet wurden, wird der Prozess nicht gestartet, und beim nächsten Durchlauf wird ein erneuter Versuch unternommen.
Parallelisierung:
Die Indizes werden durch mehrere Symfony-Messenger-Consumer aktualisiert, die aus einer gemeinsamen Queue Nachrichten abarbeiten. Obwohl vier Consumer gleichzeitig eingesetzt werden können, bedeutet das nicht, dass sie simultan an vier verschiedenen Indizes arbeiten. Stattdessen holen sich die Consumer die nächstverfügbare Nachricht aus der Queue und bearbeiten somit bis zu vier Dokumente gleichzeitig, die aber zum selben Index gehören können.
Diese Konfiguration ermöglicht eine effiziente Verarbeitung von Dokumenten in der Weise, dass mehrere Dokumente parallel bearbeitet werden, während die Indexaktualisierung selbst sequenziell erfolgt. Dadurch wird gewährleistet, dass die Ressourcen optimal genutzt werden, indem die Consumer gleichzeitig Aktionen ausführen können, ohne auf die Fertigstellung von Aufgaben eines anderen Consumers zu warten.
Dauer des Indexierungsprozesses:
Bedeutung der Gesamtdauer des Indexierungsprozesses im Kontext der Queue-Verarbeitung:
Bei dieser Implementierung wird für den vollständigen Aufbau der Indizes eine Queue verwendet, wobei jede Stunde für jedes Dokument eine Nachricht generiert und in die Queue eingefügt wird. Die verfügbaren Consumer verarbeiten diese Nachrichten aus der Queue. Sobald alle Dokumente eines Indexes abgearbeitet wurden, erfolgt ein 'Blue/Green'-Switch, um den aktualisierten Index live zu schalten.
Die Gesamtdauer des Indexierungsprozesses ist zwar weiterhin von Bedeutung, jedoch ist die Priorität auf die kontinuierliche Verarbeitung der einzelnen Nachrichten und die Vollständigkeit jedes Indexes vor dem Umschalten gelegt. Die Dauer des gesamten Prozesses hängt folglich weniger vom Zeitpunkt des Beginns und der Beendigung ab, sondern vielmehr von der kontinuierlichen und effizienten Abarbeitung der Nachrichten in der Queue. Dies führt zu einer gleichmäßigeren Lastverteilung im System und einer stetigen Aktualisierung der Indizes, was die Sichtbarkeit der Gesamtdauer relativiert.
Die Konzentration auf die Verarbeitungsgeschwindigkeit und -qualität jeder einzelnen Nachricht innerhalb der Queue stellt sicher, dass Indizes effizient und zuverlässig aktualisiert werden, ohne dass ein einzelner, zeitlich umfangreicher Indexierungsprozess notwendig ist.
Fehlerbehandlung:
Falls während des Aufbaus des Index ein Fehler in einem Dokument auftritt, wird der gesamte Prozess für diesen Index gesperrt. Der Fehler wird im Report angezeigt und geloggt, und es werden keine weiteren Dokumente generiert oder ein Wechsel durchgeführt. Nach einer Stunde wird ein erneuter Versuch gestartet. Derzeit werden noch keine Benachrichtigungen ausgelöst. Motorex hat momentan keine Möglichkeit, die Ursache des Fehlers zu analysieren, was sich jedoch in Zukunft ändern könnte. Valantic kann den Fehler in der Datenbank (Tabelle: messenger_messages; queue_name: elastica_bridge_failed) analysieren.
Name: Index Name
Messages Remaining: Nachrichten welche noch verarbeitet werden müssen um den aktuellen Prozess abzuschliessen
Errors: Fehler die aufgetreten sind. Dieser Count wird nur von valantic zurückgesetzt.
Timeout: Wenn der Prozess aktiv ist, wird hier angezeigt wie lange es dauert, bis theoretisch ein neuer Prozess gestartet werden kann, ohne dass der aktuelle abgeschlossen ist. (Es müssen dann trotzdem alle Nachrichten abgearbeitet worden sein)
Cooldown: Frühester Zeitpunkt wenn der nächste Prozess startet
Weiterführende Informationen:
Symfony Messenger Developer Documentation: https://symfony.com/doc/current/messenger.html
Symfony Messenger Component: https://symfony.com/doc/current/components/messenger.html
Das Projekt "E-Com" umfasst den Aufbau und die Weiterentwicklung des Webshops bzw. Pimcore. Das Projektteam besteht aus Mitarbeitenden der MOTOREX sowie dem externen Dienstleister Valantic.
Weitere Informationen zum Projekt können bei den Projektverantwortlichen eingeholt werden. Zusätzlich stehen folgende Links den berechtigten Mitarbeitenden zur Verfügung:
Netzwerkordner Projekt E-Com
P:\Projekte\E-Commerce Plattform
Systemdokumentation E-Com
P:\Projekte\E-Commerce Plattform\10_Dokumentationen\00_Systemdokumentationen
REST API Dokumentation E-Com
P:\Projekte\S4HANA\00_S4-HANA (Motorex)\02_Arbeitsdokumente\TP010 E-Shop Integration
