In der Softwarearchitektur werden häufig verschiedene Schichten für die Implementierung verwendet, um Funktionalitäten wiederverwendbar zu machen.
Dabei darf eine Schicht nur Klassen und Funktionalitäten aufrufen, die in derselben oder den direkt darunter liegenden Schichten vorhanden sind.
Dadurch wird sichergestellt, dass zentrale Funktionalitäten wiederverwendbar sind und nicht für einzelne Ausgabekanäle spezialisiert werden.
SAP Commerce verwendet verschiedene Schichten, um verschiedene Arten von Daten zu verarbeiten.
Dabei durchläuft eine Anfrage oder ein Funktionsaufruf meistens mehrere Schichten.
Der Layer wird als Service Layer bezeichnet, da hier Services implementiert werden sollen, um Informationen abzurufen, zu ändern, zu erstellen und zu entfernen. Er bildet die unterste Ebene ab, auf der implementiert werden soll.
In den jeweiligen Services wird mit den direkten ItemModels gearbeitet. Zudem orchestriert dieser Layer andere Services, Strategien und DAOs, um ein Austauschbares Verhalten zu ermöglichen. Dabei wird jedoch weiterhin hauptsächlich mit ItemModels gearbeitet.
Unter dem Service Layer existiert (als Legacy) der JALO Layer (Persistence Layer), welcher bereits deprecated ist und nach und nach von der SAP entfernt und durch den Service Layer ersetzt wird.
Der Facade Layer liegt über dem Service Layer und orchestriert Services, Converter und Populatoren.
Eine Facade kann dabei ein oder Mehrere Services aufrufen. Die von den Service zurückgegebenen Daten können dann via Converter und Populatoren aufbereitet und abstrahiert werde, sodass diese in anderen Ebenen weiterverarbeitet werden können.
Die Abstraktion der Daten erfolgt mit Hilfe von "Data" Klassen (POJOs), um Informationen vorzubereiten und sie von den ItemModels und dem Persistence Layer zu trennen. Beispielsweise könnten unterschiedliche Informationen an einem Produkt zu einer anderen Darstellung der Daten führen.
Der OCC Layer bildet derzeit die Schnittstelle zwischen Frontend Kommunikation und Backend Logik.
Im OCC Layer sind die Rest (OCC) Schnittstellen definiert, welche die Anfragen aus dem Frontend entgegennehmen und verarbeiten.
Zum Verarbeiten gehört unter anderem:
Im OCC Layer werden hauptsächlich Controller Klassen erstellt, um die Rest Schnittstellen zu definieren und bereitzustellen.
in den jeweiligen Controllern sollte zunächst geprüft werden, ob ankommende Informationen korrekt sind und verarbeitet werden können.
Die Daten kommen dabei in From von einfachen Datentypen wie String, Integer, etc. an oder POJOs, welche im OCC Layer mit dem Suffix WsDTO versehen sind.
WsDTOs sind dabei spezielle POJOs, welche darauf ausgelegt sind, nur die Informationen entgegenzunehmen und an das Frontend zurück zu geben, welche benötigt werden. Dadurch wird Datenlast reduziert und Informationen, welche nicht zurückgegeben werden sollen herausgefiltert. Zudem bietet diese Struktur die Möglichkeit Endpunkte zu erstellen, welche spezialisiert auf Ihre Aufgabe sind.
Der Webservice Layer verwandelt die WsDTOs zu Data Objekten und übergibt diese einer Facade.
Die Facade führt daraufhin die Business Logik aus und gibt ggf. ein Data Objekt zurück.
Das Data Objekt wird anschließend in ein WsDTO Objekt verwandelt und zurück an das Frontend gegeben.
Sollte ein Controller etwas mehr Logik beim Aufruf der Facade und umwandeln der Objekte von Data -> WsDTO benötigen, können Helfer Klassen erstellt werden.
Ein Beispiel hier ist im ProductsController zu finden für die /products/search Schnittstelle.
Es sollte möglichst versucht werden die einzelnen Schichten der Implementierungen einzuhalten und nur aufrufe auf die direkt darunter liegende Ebene zu erlauben.
Dadurch ist es möglich Services und Facaden wiederzuverwenden.
Beispielsweise können CronJobs Services wiederverwenden, um bestimmte Funktionalitäten aufzurufen ohne diese erneut Implementieren zu müssen.
Weiterhin kann Beispielsweise der Facade Layer dafür genutzt werden um Ausleitungen in andere Kanäle, wie zum Beispiel eigene REST-Schnittstellen für interne Zwecke, zu erstellen, dabei aber auf dieselbe Logik und den selben Datenbestand einheitlich zurückzugreifen.
Eine saubere Trennung der einzelnen Schichten sorgt zudem dafür, dass Unit- und Integrationstests einfacher erstellt werden können und Funktionalitäten einheitlich und gemeinsam implementiert werden können.
