Glossar

aus CommerceWiki, dem Wiki zum S2I-Commerce-Framework und der S2I-Software-Standardisierung

Abgeschlossener Formularprozess: (englisch: complete form process); Ein Formularprozess gilt als abgeschlossen, wenn die complete-Methode der Process-Klasse fehlerfrei beendet werden konnte, es also zu keiner Exception und keiner ActionMessage vom Typ Error gekommen ist.; Der Navigator entscheidet, wie sich die Navigation verhält, wenn der Prozess abgeschlossen ist. Er kann beispielsweise verhindern, dass complete ein zweites Mal durchgeführt wird und jede Navigation auf die Abschlussseite zwingen (ChainedNavigator), oder aber er lässt weiteres Arbeiten ungehindert zu (FacultativeNavigator).; Mehr zu diesem Thema findet ihr in Abschnitt 6.1 (Formularprozesse).
Abstrakte Entitätsklasse: (englisch: abstract entity class); Eine der beiden von dem Entitätsgenerator erzeugten Klasse für einen Entitätstypen.; Der Entitätsgenerator erzeugt neben dem Hibernate-Mapping für jeden Entitätstyp eine abstrake und eine konkrete Klasse, wobei die konkrete Klasse von der abstrakten erbt. Grund hierfür ist, dass in der abstrakten Klasse sämtlicher generierter Code beheimatet ist, während die konkrete Klasse im Projekt mit weiteren Helpern und Geschäftslogik befüllt werden soll. Der Generator überschreibt beim nächsten Generieren lediglich die abstrakte Klassen, welche auch nicht modifiziert werden dürfen, die konkreten Klassen werden nur angelegt, wenn sie noch nicht existieren, und anschließend nicht mehr vom Generator angefasst. Er kann also beliebig oft aufgerufen werden.; In der Anwendung sollte stets nur der konkrete Typ verwendet werden, um auf die Methoden beider Klassen zugreifen zu können.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Administrationsoberfläche: (englisch: administration UI); Das Administrationsoberfläche ermöglicht Redakteuren (wie Produkt-Administratoren), Produkte zu pflegen, Preise zu vergeben und Bundles zu definieren. Desweiteren kann man Bestellungen und Benutzer einsehen und bearbeiten. Die größte Stärke des Frontends ist die Fähigkeit, die Produktadministration allein durch die bereits definierte Typisierung der Produkte und Kategorien aufzubauen. Dadurch erhält man projektspezifische Eingabemasken, die sich einheitlich und leicht von dem Redakteur bedienen lassen, ohne dass hier eine Implementierung stattfinden muss.; Eine vergleichbare Methodik ist bereits bei dem Talkline-Backoffice eingesetzt worden.; Die Oberfläche kann projektspezifisch erweitert werden, wobei für die meisten Erweiterungen im Bereich der Produktverwaltung lediglich eine Konfiguration notwendig ist.; Mehr zu diesem Thema findet ihr in Kapitel 8 (Administration).
Administrator: Der Administrator (szzadm) ist eine Rolle im Rahmen der Distribution über das One-Click-Deployment. Er ist für die Wartung der Host-Hardware, sowie für die Installation und Pflege der Software unabhängig von der gehosteten Anwendung verantwortlich (z.B. Installation des Betriebssystems und des Tomcats, Anlegen von Benutzern, etc.).; Bei von SinnerSchrader betriebenen Anwendungen wird diese Rolle von dem SinnerSchrader Betrieb wahrgenommen.; Mehr zum Thema One-Click-Deployment findet ihr in Abschnitt 10.5.3 (One-Click-Deployment).
Adressadapter: (englisch: address adapter); Der Adressadapter ist eine Abstraktion zur einheitlichen Durchführung von Überprüfung der Validität von Kunden- und Adressdaten (Bonitätsprüfung). Zur Zeit ist er für den Dienst eScore (InfoScore) implementiert.; Mehr zu Adressadaptern findet ihr Abschnitt 5.3.3 (Adress- und Bonitätsprüfung).
Adresse: (englisch: address); Eine Adressobjekt kapselt alle Angaben wie Straße, Hausnummer, Postleitzahl, Ort, Land, etc. zu einer physikalischen Postadresse wie z.B. der Lieferadresse oder Rechnungsadresse, aber auch den Vor- und Nachnamen, den Firmennamen, die Anrede etc. Letztes hat den Grund, dass auch diese Angaben zwischen Lieferung und Rechnungsstellung abweichen können.; Mehr zum Thema Adressen findet ihr in Abschnitt 5.2.1 (Benutzer).
Ant: Mit Hilfe von Apache Ant lassen sich der Build- und Deployment-Prozess, sowie gewisse Development-Prozesse steuern. Entsprechende Projekt- und Build-Strukturen sind bereits in Konventionsdokumenten und in der Projektvorlage gefestigt und bieten damit einen Standardablauf. Auch der Projekt-Wizard basiert auf Apache Ant.; Die Homepage von Ant: http://ant.apache.org/
Ant-Properties: Ant-Properties sind Konfigurationsdateien, mit der an der Anwendung Einstellungen vorgenommen werden können, die von einem Entwicklungsrechner oder einer Deployment-Umgebung abhängen. Diese Dateien werden beim Build zurate gezogen und liegen unter src/main/resources/conf/ant.; Die Konfiguration beim Build hat den Vorteil, dass rechner- und umgebungsabhängige Einstellungen eingecheckt, versioniert und gebrancht werden können. Dies minimiert die Migrationsarbeiten und damit das Risiko eines Fehlschlags des Deployments.; Mehr zum Thema Versionsplanung findet ihr in Abschnitt 10.5.2 (Versionsplanung).
AOP: Aspektorientierte Programmierung (AOP) schafft eine Trennung orthogonaler Konzepte, welche mit rein objektorientierten Mitteln sich zuvor nicht trennen ließen. Vor allem für Transaktionssteuerung und Datenbankverbindungen bieten sich AOP-Interceptors an. AOP wird im Commerce-Framework durch das SpringFramework realisiert, welches sich gut mit Hibernate integriert.; Informationen zu Problemen bei der Verwendung von AOP mit dem SpringFramework findet ihr in Abschnitt 13.3.2 (AOP-Probleme).
Applikations-Host: Der Applikations-Host ist ein Host, also eine physische Maschine, auf der ein Applikations-Server (z.B. Tomcat) betrieben wird. In einer Umgebung können mehrere Applikations-Hosts existieren.; In diesem Dokument wird der Begriff Host für eine physische Maschine, der Begriff Server jedoch für die auf einem Host betriebene Software (z.B. Apache HTTPD oder Tomcat) verwendet. Diese Begriffe sind nicht zu verwechseln mit den Apache-Virtual-Hosts, welche durch den Apache HTTPD betriebene Anwendungen beschreiben.; Weitere Informationen zum allgemeinen Setup von Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Applikations-Server: Ein Applikations-Server ist ein Java-Programm, in dem eine Web-Anwendung betrieben wird, z.B. Tomcat, BEA WebLogic, IBM WebSphere, Oracle Appliation Server, Resin, uvm.; Applikations-Server werden auf Applikations-Hosts betrieben.; In diesem Dokument wird der Begriff Host für eine physische Maschine, der Begriff Server jedoch für die auf einem Host betriebene Software (z.B. Apache HTTPD oder Tomcat) verwendet. Diese Begriffe sind nicht zu verwechseln mit den Apache-Virtual-Hosts, welche durch den Apache HTTPD betriebene Anwendungen beschreiben.; Weitere Informationen zum allgemeinen Setup von Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Assoziationsattribut: (englisch: association attribute); Eine Relation, bei der ein oder mehrere andere Produkte referenziert werden. Referenzierte Produkte werden im Gegensatz zur Komposition nicht gelöscht, wenn das referenzierende Produkt gelöscht wird.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Asymmetrische Verschlüsselung: (englisch: asymmetric encryption bzw. public key encryption); Asymmetrische oder Public-Key-Verschlüsselung ist eine Art von bidirektionaler Verschlüsselung, bei der die Schlüssel zum Ver- und Entschlüsseln unterschiedlich sind, so dass zum Schlüsseltausch zu keinem Zeitpunkt ein geheimer Kanal zwischen Sender und Empfänger existieren muss.; RSA ist ein asymmetrisches Verfahren.; Das Gegenteil der asymmetrischen Verschlüsselung ist die symmetrische Verschlüsselung. Mehr zum Thema Verschlüsselung findet ihr in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Attribut: (englisch: attribute); Ein Attribut ist die konkrete Ausprägung eines Attributtypen und ist einem Entitätstyp zugeordnet. Attribute definieren den Namen, unter dem in der typisierten Entität ein für den Attributtypen gültiger Wert gespeichert werden soll.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Attributeditor: (englisch: attribute editor); Der Editor eines Attributtypen definiert das Look and Feel für ein Attribut in der Administrationsoberfläche. Dies beinhaltet eine JSP-Komponente, welche in der Oberfläche an der entsprechenden Stelle eingeblendet wird. Aus Architekturgründen ist die Administration inkl. aller Editoren eine getrennt Lösung in einer Schicht oberhalb des Commerce-Frameworks.; Mehr zu diesem Thema findet ihr in Kapitel 8 (Administration).
Attributgenerator: (englisch: attribute generator); Der Generator eines Attributtypen sorgt dafür, dass ein entsprechendes Java- und Hibernate-Konfigurationssnipplet erzeugt wird, welches für die Persistenz und Validierung der Attribut-Daten sorgt.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Attributgruppe: (englisch: attribute group); Eine Attributgruppe fasst mehrere Attribute in einem Entitätstypen zusammen, um sie beispielsweise in der Administrationsoberfläche in Reitern gruppiert leichter editieren zu können.; Attribute müssen nicht gruppiert werden, und es ist desweiteren möglich, einige Attribute eines Typen zu gruppieren, andere jedoch ungruppiert zu lassen. Die Administrationsoberfläche stellt die ungruppierten Attribute als weiteren Reiter dar.; Mehr zum Thema Attributgruppen findet ihr in Abschnitt 5.1.3 (Attribute im Überblick).
Attributtyp: (englisch: attribute type); Attributtypen definieren die Persistierung eines Wertes, seinen möglichen Werteraum und ggf. GUI-Elemente in der Administrationsoberfläche. Attributtypen werden programmiert, d. h. der Typ wird als Java-Klasse konkretisiert und in einer XML-Datei definiert. Beispiele für Attributtypen sind Text, Ganzzahl, Assoziation und Datei.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Auswahlattribut: (englisch: choice attribute); Der Redakteur wählt aus einer Liste vorgegebener Werte einen aus. Hiermit kann z. B. die Größe eines Kleidungsstücks selektiert werden (S, M, L, XL). Zusätzlich kann die Auswahl auch uneingestellt sein, sofern das Feld kein Pflichtattribut ist.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Authentifizierung: (englisch: authentication); Authentifikation ist der Vorgang, die Identität (Benutzerkennung) eines Benutzers anhand eines nur ihm bekannten Merkmals, meist einem Passwort, zu überprüfen. Login und Passwort werden im Commerce-Framework in den Credentials zusammengefasst.; Weitere Informationen zu Benutzern findet ihr in Abschnitt 5.2.1 (Benutzer), mehr zur Authentifizierung in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Authorize: Authorize ist in der Kommunikation mit einem Zahlungs-Provider wie Bibit oder eScore der Vorgang, bei dem ein Geldbetrag für einen späteren Capture reserviert wird. Die Bank garantiert, dass dieser Betrag gecapturet werden kann, er ist beim Kunden blockiert, er wird aber ohne Capture nach einer gewissen Frist wieder freigegeben und in diesem Fall nicht abgebucht.; Mehr Informationen über Zahlungsadapter findet ihr in Abschnitt 5.3.4 (Zahlungsadapter).
Auto-Wiring: Auto-Wiring ist eine Funktion des SpringFrameworks, bei der Properties von Spring-Beans automatisch mit anderen Spring-Beans befüllt werden (Injection), wenn diese denselben Name haben wie die Property.
Autorisierung: (englisch: authorization); Autorisierung ist die Überprüfung, ob eine Operation von einem bestimmten Benutzer durchgeführt werden darf.; Weitere Informationen zu Benutzern findet ihr in Abschnitt 5.2.1 (Benutzer), mehr zur Authentifizierung in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Axis: Eine Java-Implementierung des SOAP-Protokolls, mit der es leicht möglich ist, Web-Services in Web-Anwendungen zu integrieren oder aufzurufen (Server und Client).; Die Homepage von Axis: http://ws.apache.org/axis/
Beispiel-Shop: Der Beispiel-Shop ist eine einfache Implementierung eines Shops auf Basis des Commerce-Frameworks, um möglichst viele Funktionen zu illustrieren. Er ist in der Projektvorlage und dem Projekt-Wizard integriert, so dass er durch eine Checkbox bei der Anlage eines neuen Projekts mit angelegt werden kann.; Mehr zum Beispiel-Shop findet ihr in Abschnitt 3.3 (Der PDA-Shop).
Benannte Entität: (englisch: named entity); Eine versionierte Entität, die bereits einen fachlichen, gut darstellbaren Namen (name-Property), sowie einen technischen Namen (code-Property) enthält.; Mehr zum Thema Entitäten findet ihr in Abschnitt 4.1 (Entitäten).
Benutzer: (englisch: user); Benutzer fassen alle mit dem System interagierenden Personen zusammen, die einen Namen, ein Login und ein Passwort besitzen. Kunden und Redakteure spezialisieren den Benutzer und fügen ihm weitere Eigenschaften hinzu.; Mehr zu diesem Thema findet ihr in Abschnitt 5.2.1 (Benutzer).
Benutzerattribut: (englisch: user attribute); Ein Relationsattributtyp, welcher einen oder mehrere Benutzer (Kunden und/oder Redakteure) referenziert.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Benutzerkategorie: (englisch: custom category); Eine Kategorie in der Produktverwaltung, die von einem Redakteur angelegt wird und zu der ein Kategorietyp gehört. Gegensatz: Systemkategorie.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.2 (Produkte und Kategorien).
Benutzerkennung: (englisch: user login); Eine meist von dem Benutzer vergebene, eindeutige Kennung, die ihn identifiziert. Kennung und Passwort nennt man zusammen Credentials. Hiermit kann ein Benutzer authentifiziert werden.; Weitere Informationen zu Benutzern findet ihr in Abschnitt 5.2.1 (Benutzer), mehr zur Authentifizierung in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Benutzerverwaltung: (englisch: user management); Die Benutzerverwaltung verwaltet sowohl Endkunden (Customers), als auch Redakteure und Administratoren (Editors). Sie bietet desweiterenn Funktionen zur Authentifizierung und Autorisierung (Credentials, Rollen und Rechte).; Mehr zu diesem Thema findet ihr in Abschnitt 5.2 (Benutzerverwaltung).
Beschränkung: (englisch: constraint); Eine Regel, die die Wertemenge eines Attributs einschränkt. Ein Pflichtattribut ist beispielsweise derart eingeschränkt, dass der leere Werte nicht zugelassen ist.; Beschränkungen können zu Persistenzfehlern und/oder zu Validierungsfehlern führen.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Bestand: (englisch: stock); Die Menge, wie oft oder in welcher Größe ein bestimmtes im Produktkatalog gepflegtes Produkt noch verfügbar ist. Diese Menge ist in der für den Produkttyp definierten Einheit zu verstehen. Der Bestand ist eine Fließkommazahl.; Der Bestand kann entweder primär in der Datenbank der Anwendung gepflegt werden (lokaler Bestand), oder er wird von einer externen Quelle bezogen. Diese Quelle wird mit dem Bestandsadapter angebunden.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.14 (Bestandsverwaltung).
Bestandsadapter: (englisch: stock adapter); Eine Klasse, welche die Anbindung an eine externe Datenbasis für Bestände eines Produkts implementiert. Sie bietet desweiteren die Möglichkeit, die externe Datenbasis bei Änderungen des Bestandes zu aktualisieren.; Mehr zu diesen Thema findet ihr in Abschnitt 5.1.14 (Bestandsverwaltung).
Bestellposition: (englisch: order entry); Eine Zeile in einer Bestellung. Bestellpositionen können Produkte referenzieren (siehe Produktbestellposition), Versandkosten darstellen (siehe Versandkostenbestellposition), oder Rabatte, Aufschläge oder Anmerkungen repräsentieren (siehe Zusatzbestellposition).; Mehr zum Thema Bestellungen findet ihr in Abschnitt 5.3 (Bestellungsverwaltung).
Bestelltes Produkt: (englisch: ordered product); Ein bestelltes Produkt ist ein Element einer Produktbestellposition in einer Bestellung, also die Referenz auf entweder das Einzelprodukt, oder auf eins der Produkte des bestellten Produkt-Bundles.; Produktbestellpositionen bestehen aus einem oder mehreren bestellten Produkten, wobei die Bestellposition im Fall einer Bundle-Bestellung das gesamte Bundle inkl. der Gesamtanzahl darstellt, während das bestellte Produkt das Bundle-Element mit seiner Anzahl im Bundle repräsentiert.; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.1 (Bestellungen).
Bestellung: (englisch: order); Ein ausgelöster Kauf einer gewissen Produktmenge. Bestellungen referenzieren nicht nur Produkt- und Kunden-Daten, sondern enthalten weitere Informationen, in denen der Kauf oder die Produkte spezialisiert bzw. eingestellt werden.; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.1 (Bestellungen).
Bestellungsposition: (englisch: order entry); Eine Zeile in der Bestellung, bestehend aus dem bestellten Produkt, einer Menge und weiteren zur Bestellungsposition frei vergebbaren Eigenschaften. Die Menge ist hierbei in der Größenordnung der Einheit zu verstehen, die mit dem Produkt assoziiert ist.; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.1 (Bestellungen).
Bestellverwaltung: (englisch: order management); In der Bestellverwaltung werden Warenkörbe als Bestellungen persistiert, Zahlungsweisen und Zahlungen verwaltet, Bonitätsprüfung durchgeführt, Zahlungen angewiesen und Lieferungen verwaltet.; Mehr zu diesem Thema findet ihr in Abschnitt 5.3 (Bestellungsverwaltung).
Bibit: Bibit ist ein Dienstleister für die Durchführung von Zahlungen über Kreditkarte, Bankeinzug und anderen Zahlungswegen. Der Zahlungsadapter unterstützt unter anderem Authorize, Capture und Partial Capture.; Die Homepage von Bibit: http://www.bibit.com/; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.4 (Zahlungsadapter).
Bidirektionale Verschlüsselung: (englisch: bidirectional encryption); Bidirektionale Verschlüsselung ist ein Verfahren, bei dem das Klarwort mit einer mathematischen Funktion verlustfrei auf ein Cipher-Wort transformiert wird, so dass es möglich ist, mit demselben, oder aber einem anderen Schlüssel wie bei der Verschlüsselung, das Cipher-Wort wieder zum Klarwort zu entschlüsseln.; Sind die Schlüssel zum Ver- und Entschlüsseln identisch, wie es bei 3DES der Fall ist, spricht man von symmetrischer Verschlüsselung. Sind die Schlüssel unterschiedlich (z.B. RSA), spricht man von asymmetrischer oder Public-Key-Verschlüsselung.; Das Commerce-Framework verwendet symmetrische Verschlüsselung zum Speichern von Zahlungsweisen.; Das Gegenteil der bidirektionalen Verschlüsselung ist die unidirektionale Verschlüsselung. Mehr zum Thema Verschlüsselung findet ihr in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Bildattribut: (englisch: image attribute); Ein Bildattribut spezialisiert das Dateiattribut und bietet in der Administrationsoberfläche zusätzliche Funktionen an, wie das Komprimieren (Qualität) oder das Einstellen auf eine vorgegebene Bildgröße. Entsprechende Einstellungen werden im Produkttyp definiert. Über die Beschränkungen des Dateiattributs wird der Dateityp des Bildes (JPG, GIF, TIF, ...) eingestellt.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Binary-Distribution: Eine Binary-Distribution ist eine Distribution, die gebuildet und gepackaget ist, d.h. sie kann direkt auf die entsprechenden Web- und Applikations-Hosts deployt werden.; Binary-Distributionen sind für einen Betriebsdienstleister wie SinnerSchrader Betrieb (S2B) ein einfacher Weg, eine Version zu deployen, bieten jedoch auch weniger Transparenz über ihren Inhalt. Sie können über das Ant-Target dist-binary ausgelöst werden, sind aber auch Teil jedes One-Click-Deployments (Ant-Targets deploy und dist).; Source-Distributionen stehen hierzu im Gegensatz, da sie noch nicht gebuildet sind.; Weitere Informationen zum Thema Build, Distribution und Deployment findet ihr in Abschnitt 10.5 (Distribution).
Bonitätsprüfung: Ein Bonitätscheck ist die Überprüfung der Validität von Kunden-, Adress- und Zahlungsdaten. Es wird aufgrund diverser Kriterien eine Bewertung (Score) vergeben, sowie ggf. eine Liste von Alternativvorschlägen bei Mehrdeutigkeit geliefert.; Das Commerce-Framework unterstützt unter anderem Bibit und eScore.; Mehr zum Thema Bonitätsprüfung findet ihr in Abschnitt 5.3.3 (Adress- und Bonitätsprüfung).
Bounce-Management: Ein Bounce-Management ist dafür verantwortlich, Mails entgegenzunehmen, die zurückgekommen sind, weil sie entweder nicht zugestellt werden konnten oder weil der Kunde auf eine nicht zulässige Adresse geantwortet hat. Es soll den Kunden bzw. die Emailadresse bewerten, um ggf. in späteren Mailings diesen Kunden auszulassen.; Das Commerce-Framework enthält zur Zeit kein Bounce-Management, kann aber auf Basis von Velocity-Templates Mails versenden.; Mehr zum Thema Mailversand findet ihr in Abschnitt 7.3 (Mailversand).
Browser: Ein Browser ist eine Client-Anwendung zum Anzeigen und Herunterladen von Internetseiten und anderen entfernten Inhalten wie Dateien und Bildern, sowie zum Eingeben und Absenden von Formulardaten.; Browser senden Requests an den Web-Server oder Applikations-Server, der Server wiederum sendet Responses zurück an den Browser.; Weitere Informationen zum allgemeinen Setup von Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Bruttobetrag: (englisch: gross amount); Der Bruttobetrag ist der Geldbetrag eines Produkts oder einer Bestellung inklusive Mehrwertsteuer.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Build: Als Build bezeichnet man den Vorgang und das fertige Produkt, wenn die Quellen der Anwendung zum einen in eine Binärform übersetzt, und zum anderen Ressourcen aus den Quellordnern in ihre entsprechenden Zielordner kopiert werden, wobei entsprechend der aktuellen Konfiguration Platzhalter ersetzt werden können.; Ein Build wird mit Hilfe des Ant-Targets build ausgelöst. Targets wie java, resources und web sind Teil dieses Builds und können, um Zeit zu sparen, auch einzeln ausgelöst werden.; Weitere Informationen zum Thema Build, Distribution und Deployment findet ihr in Abschnitt 10.5 (Distribution).
Bundle: (englisch: bundle); Ein Bundle ist ein Zusammenschluss mehrerer Produkte mit einem gemeinsamen Preis.; Bundles werden über die Typisierung definiert und in der Bestellung gespeichert.; Mehr zum Thema Bundles findet ihr in Abschnitt 5.1.10 (Bundles), Abschnitt 5.1.13 (Preisberechnung) und Abschnitt 5.3.1 (Bestellungen), mehr zum Thema Typisierung findet ihr in Abschnitt 5.1.1 (Typisierung).
BusinessException: Eine der drei typischen Exception-Superklasse in S2I-Java-Projekten.; Eine BusinessException sollte immer dann geworfen werden, wenn die Operation aufgrund der übergebenen Parameter nicht ausgeführt werden kann, und dies keine Verletzung des Vertragsmodells darstellt (also keine RuntimeException, insbesondere kein Programmierfehler ist), sondern die Daten z.B. vom Benutzer eingegeben werden und fehlerhaft sind.; Mehr zum Thema Exception-Handling findet ihr in Abschnitt 11.1.8 (Exception-Handling).
Camel-Case: Eine gemischte Groß-/Kleinschreibung innerhalb eines aus mehreren Wörtern zusammengesetzten Bezeichners.; Der große Camel-Case für den Ausdruck "customer billing address" ist "CustomerBillingAddress", während der kleine Camel-Case "customerBillingAddress" ist.
Capture: Capture ist in der Kommunikation mit einem Zahlungsprovider wie Bibit oder eScore der Vorgang, bei dem ein zuvor mit Authorize reservierter Geldbetrag endgültig vom Kundenkonto abgebucht wird.; Ein Spezialfall des Captures ist der Partial Capture.; Mehr Informationen über Zahlungsadapter findet ihr in Abschnitt 5.3.4 (Zahlungsadapter).
Catalina-Base: Das Catalina-Base ist das projektabhängige Verzeichnis des Servlet-Containers Tomcat.; Tomcat teilt die mitgelieferten und teilweise zu administrierenden Dateien (Binärdateien, Konfiguration), sowie Temporärdateien und Log-Files in zwei Gruppen ein, Catalina-Base und Catalina-Home.; Das Catalina-Base ist Teil der Binary-Distribution einer Version der Web-Anwendung und wird bei jedem Deployment auf die jeweiligen Applikations-Hosts kopiert.; Mehr zu diesem Thema findet ihr in Abschnitt 10.5 (Distribution).
Catalina-Home: Das Catalina-Home ist das projektunabhängige Verzeichnis des Servlet-Containers Tomcat.; Tomcat teilt die mitgelieferten und teilweise zu administrierenden Dateien (Binärdateien, Konfiguration), sowie Temporärdateien und Log-Files in zwei Gruppen ein, Catalina-Base und Catalina-Home.; Das Catalina-Home wird von dem Betriebsdienstleister im Rahmen der Erstinstallation des Applikations-Hosts angelegt und anschließend in der Regel nicht mehr modifiziert.; Mehr zu diesem Thema findet ihr in Abschnitt 10.5 (Distribution).
Chained-Navigator: Einer der drei im Commerce-Framework bereits enthaltenen Navigatoren für Formularprozesse.; Der zeichnet sich im wesentlichen dadurch aus, dass Seiten sequentiell bearbeitet werden müssen. Eine fehlerhaft eingegebene Seite (entsprechend der Validierungsregeln) kann nicht übersprungen werden.; Weitere Navigatoren des Frameworks sind der Facultative-Navigator und der Facultative-Validating-Navigator. Es ist leicht möglich, einen vorhandenen Navigator zu erweitern oder einen neuen zu entwickeln.; Mehr zum Thema Navigatoren findet ihr in Abschnitt 6.1.3 (Navigator (Formularprozesse)).
CMS: (englisch: CMS); Die Komponente des Commerce-Framework, die mit der Produktverwaltung, speziell den typisierten Entitäten und einer Template-Sprache Seiten generiert.; Mehr zum CMS findet ihr in Kapitel 9 (Content-Pflege), mehr zum Thema Typisierung findet ihr in Abschnitt 5.1.1 (Typisierung).
Commons: Eine Sammlung verschiedener Open-Source-Komponenten für wiederkehrende Arbeiten bei der Java-Entwicklung. Wird von vielen Open-Source-Komponenten verwendet, unter anderem auch von dem Commerce-Framework und der Projektvorlage.; Die Homepage von Commons: http://commons.apache.org/
Commons Validator: Eine Komponente aus dem Apache-Jakarta-Projekt, die die Validierung von Formularen vereinheitlicht kapselt.; Struts verwendet Commons Validator, um Forms zu validieren.
Credentials: Ein Benutzerkennung und ein Passwort werden zusammen als Credentials bezeichnet. Hierüber ist eine Authentifizierung möglich. Benutzer, also Kunden und Redakteure haben Credentials.; Weitere Informationen zu Benutzern findet ihr in Abschnitt 5.2.1 (Benutzer), mehr zur Authentifizierung in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Crypter: Der Crypter ist eine Komponente des Commerce-Frameworks, mit der uni- und bidirektionale Verschlüsselung durchgeführt wird. Er kommt automatisch bei Passwörtern von Credentials, sowie bei Zahlungsweisen zum Einsatz, kann aber durch eine entsprechende Konfiguration (src/main/resources/conf/framework/crypter.xml) auch deaktiviert werden.; Mehr zu diesem Thema findet ihr in Abschnitt 4.4 (Verschlüsselung).
DAO: Der Zugriff auf die Datenbankschicht (Hibernate, JDBC, Datenbank) findet über DAOs statt. Sie enthalten Methoden zum Suchen nach Entitäten über verschiedene Kriterien, sowie zum Aktualisieren der Datenbank.; DAOs werden ausschließlich von Managern oder anderen DAOs verwendet.; Weitere Informationen zu diesem Thema findet ihr in Abschnitt 12.2 (Geschäftslogikmuster).
Dateiattribut: (englisch: file attribute); Ein primitives Attribut, in dem Bilder, Klänge, PDFs und sonstige Binärdaten gespeichert oder referenziert werden können.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Dateitransfer: (englisch: file transfer); Die Dateitransfer-Komponente bietet Funktionen zum automatisierten und asynchronen Upload und -Download beliebiger Dateien über FTP und SFTP an. Hierbei werden Dateinamenskreise beachtet, so dass zum einen nur bestimmte Dateinamen erzeugt bzw. eingelesen werden, zum anderen aber auch die Reihenfolge bis hin zur zyklischen Dateinamensvergabe beachtet wird. Der Dateitransfer kann mit der Komponente Excel- und CSV-Import und -Export kombiniert werden.; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 7.1 (Dateitransfer).
Datenbank-Host: Der Datenbank-Host ist ein Host, also eine physische Maschine, auf der ein Datenbank-Server (z.B. MySQL) betrieben wird. In einer Umgebung können mehrere Datenbank-Hosts existieren.; In diesem Dokument wird der Begriff Host für eine physische Maschine, der Begriff Server jedoch für die auf einem Host betriebene Software (z.B. Apache HTTPD oder Tomcat) verwendet. Diese Begriffe sind nicht zu verwechseln mit den Apache-Virtual-Hosts, welche durch den Apache HTTPD betriebene Anwendungen beschreiben.; Weitere Informationen zum allgemeinen Setup von Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Datenbank-Server: Ein Datenbank-Server (Datenbank-Management-System) ist ein Programm, in dem Datenbanken betrieben werden, z.B. MySQL, Oracle DBMS, PostgreSQL, uvm.; Datenbank-Server werden auf Datenbank-Hosts betrieben.; In diesem Dokument wird der Begriff Host für eine physische Maschine, der Begriff Server jedoch für die auf einem Host betriebene Software (z.B. Apache HTTPD oder Tomcat) verwendet. Diese Begriffe sind nicht zu verwechseln mit den Apache-Virtual-Hosts, welche durch den Apache HTTPD betriebene Anwendungen beschreiben.; Weitere Informationen zum allgemeinen Setup von Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Datumsattribut: (englisch: date attribute); Ein primitiver Attributtyp, in das ein Datum mit oder ohne Uhrzeit eingegeben werden kann.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Decoding: Decoding ist der Vorgang, den Zahlenwert (bzw. eine Folge von Zahlenwerten) wiederum in der Encoding-Tabelle herauszusuchen und durch in das Zeichen übersetzen. Kann die Zahlenfolge nicht verstanden werden, wird es durch einen Platzhalter (z.B. '?') ersetzt, bzw. es kommt zu einer Fehlermeldung.; Gegenteil: Encoding; Mehr Infos über mögliche Probleme und deren Lösungen findet ihr in Abschnitt 13.1.1 (Encoding-Probleme).
Deploy-Historie: (englisch: deploy history); Die Deploy-Historie ist eine automatisch von den Ant-Targets der Projektvorlage erzeugte Textdatei, in der alle Distributionen und Deployments verzeichnet sind.; Mehr zur Versionsplanung findet ihr in Abschnitt 10.5.2 (Versionsplanung).
Deployer: Der Deployer (szzdep) ist eine Rolle im Rahmen der Distribution über das One-Click-Deployment. Auf der Produktivumgebung kann nur der Deployer das Deployment-Skript starten und damit eine Version aktivieren. Er überwacht, startet und stoppt desweiteren den Applikations-Server.; Auf der Produktivumgebung ist der Benutzer szzdep außerdem der Besitzer des Applikations-Server-Prozesses.; Bei von SinnerSchrader betriebenen Anwendungen wird diese Rolle von dem SinnerSchrader Betrieb wahrgenommen.; Mehr zum Thema One-Click-Deployment findet ihr in Abschnitt 10.5.3 (One-Click-Deployment).
Deployment: Im engeren Sinn (wie er in diesem Dokument zur Begrifffindung verwendet wird) bezeichnet das Deployment den Vorgang, die durch das Packaging entstandene Binary-Distribution von dem Distributions-Host auf die Web- und Applikations-Hosts zu kopieren und dort zu aktivieren.; Im weiteren Sinn (wie er z.B. in den Ant-Targets deploy reflektiert), bezeichnet er den kompletten Vorgang, der für ein solches Deployment notwendig ist, inklusive Build, Packaging, Upload und eigentlichem Deployment (Aktivierung).; Weitere Informationen zum Thema Build, Distribution und Deployment findet ihr in Abschnitt 10.5 (Distribution).
Deployment-Skript: Das Deployment-Skript ist eine ausführbare Datei, meist ein Linux-Shell-Skript, welches die durch das Packaging entstandene Binary-Distribution von dem Distributions-Host auf die Web- und Applikations-Hosts kopiert und dort aktiviert.; Das Skript ist selbst Teil der Binary-Distribution.; Weitere Informationen zum Thema Build, Distribution und Deployment findet ihr in Abschnitt 10.5 (Distribution).
Development-Umgebung: (englisch: devel environment); Die Development-Umgebung ist eine Umgebung, die ausschließlich zu internen Zwecken den Entwicklern dient. Auf dieser von allen Entwicklern geteilten Umgebung kann das Zusammenspiel verschiedener Software-Komponenten, z.B. der Anwendung und dem CMS getestet werden.; Weitere Informationen zu Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Distribution: Der Begriff Distribution hat zwei Bedeutungen:; Zum einen bezeichnet man so das auslieferbare Endprodukt der Web-Anwendung, es kann unter anderem den Build, eine Server-Konfiguration, Deployment-Skripte, Installationsanleitungen, Dokumentation und andere Dateien enthalten, typischerweise als ein ZIP- oder Web-Archiv. Man unterscheidet Source- und Binary-Distribution. Den Vorgang, diese Distribution zu erstellen, nennt man Packaging.; Zum anderen nennt man aber auch das Verteilen der Anwendung von dem Distributions-Host auf alle Web- und Applikations-Hosts eine Distribution.; Weitere Informationen zum Thema Build, Distribution und Deployment findet ihr in Abschnitt 10.5 (Distribution).
Distributions-Host: Der Distributions-Host ist ein Host auf einer Umgebung, der von außen angesprochen werden kann, um eine Binary-Distribution einer Version abzulegen (Upload). Dies geschieht bei einem Hosting durch SinnerSchrader Betrieb (S2B) durch die Entwickler-Rolle (szzdev).; Von dem Distributions-Host kann die Version anschließend von der Deployer-Rolle (bei S2B szzdep) auf alle Web- und Applikations-Hosts deployt werden.; Weitere Informationen zum Thema Build, Distribution und Deployment findet ihr in Abschnitt 10.5 (Distribution).
Dohmen: Dohmen Solutions ist ein Fulfillment- und Scoring-Dienstleister. Bestellungen des Commerce-Frameworks können über eine Schnittstelle an Dohmen übertragen werden. Desweiteren können Adress- und Bonitäts-Checks über Dohmen realisiert werden.; Die Homepage von Dohmen lautet http://www.dohmen-solutions.de.
Domain-Object-Model: Ein Domain-Objekt-Model (DOM) ist ein Klassendiagramm, in dem die Objekte der Kundendomäne dargestellt sind.; Das DOM wird in der Analysephase der Konzeption erstellt. Es behandelt keine technischen Objekte, sondern besteht lediglich aus Begriffen, wie sie dem Kunden geläufig sind, wie z.B. Bestellung, Internetseite, Surfer oder Produkt.
Eclipse: Eclipse ist eine Open-Source-Entwicklungsumgebung (IDE) zur Herstellung, Pflege und Refaktorierung vor allem von Java-Anwendungen mit besonderem Focus auf leichte Erweiterbarkeit durch Plugins.; Die Homepage von Eclipse: http://www.eclipse.org/
Editierbar: (englisch: editable); Attribute von typisierten Entitäten können als editierbar oder nicht editierbar markiert werden. Wenn sie editierbar sind, werden sie mit Hilfe von Attributeditoren in der Administrationsoberfläche eingeblendet, können also je nach Rechten bearbeitet bzw. betrachtet werden.; Die Eigenschaft hat keine weitere Auswirkung auf die Persistenz, auf die Anwendungslogik oder auf sonstige Teile des Commerce-Frameworks. Sie wird lediglich zum Einblenden der Attributeditoren verwendet.; Mehr zu diesem Thema findet ihr in Kapitel 8 (Administration).
Einheit: (englisch: unit); Definiert die mathematische Einheit für die Menge des Produktbestandes und für Bestellungen eines Produkts. Beispiele für Einheiten sind Stück, Gramm und Meter.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.2 (Produkte und Kategorien).
Einzelpreis: (englisch: unit amount); Der Geldbetrag eines einzelnen Produkts einer Bestellposition in einer Bestellung, d.h. der Preis, den der Kunden in dem Mandanten etc. (Preisfabrik) bei einer Bestellmenge von 1 bezahlen müsste.; Der Einzelpreis, multipliziert mit der Menge, muss nicht notwendigerweise den Gesamtpreis ergeben.; Mehr zum Thema Preise findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Encoding: Encoding ist der Vorgang, eine fachliche Repräsentation der Zeichen einer Zeichenkette in einer Encoding-Tabelle herauszusuchen und in einen oder mehrere Zahlenwerte zu übersetzen. Ist ein Zeichen nicht enthalten, wird es durch einen Platzhalter (z.B. den Code für '?') ersetzt, bzw. es kommt zu einer Fehlermeldung.; Gegenteil: Decoding; Mehr Infos über mögliche Probleme und deren Lösungen findet ihr in Abschnitt 13.1.1 (Encoding-Probleme).
Entität: (englisch: entity); Oberbegriff für alle in der Datenbank persistierten Models, wie z.B. Produkte, Kategorien, Benutzer, Bestellungen uvm.; Die Entity-Klasse enthält eine id-Property mit passenden equals- und hashCode-Methoden und verwendet den Hibernate-ID-Generator 'native', wodurch ein sehr einfacher und damit wenig problematischer, rein technischer Primärschlüssel angelegt wird. Außerdem enthält die Klasse Conventience-Methoden zum Speichern und Löschen, sowie Attribute für den Zeitpunkt der Erstellung und der letzten Modifikation.; Mehr zum Thema Entitäten findet ihr in Abschnitt 4.1 (Entitäten).
Entitätseditor: (englisch: entity editor); Der Editor für typisierte Entitäten in der Administrationsoberfläche. Er definiert das Look and Feel beim Bearbeiten z.B. von Produkten und Kategorien. Innerhalb des Editors werden Attributeditoren für sämtliche editierbaren Attribute eingeblendet. Aus Architekturgründen ist die Administration inkl. aller Editoren eine getrennt Lösung in einer Schicht oberhalb des Commerce-Frameworks.; Mehr zu diesem Thema findet ihr in Kapitel 8 (Administration).
Entitätsgenerator: (englisch: entity generator); Ein Werkzeug im Commerce-Framework, mit dem typisierte Entitäten aus der Typdefinition (src/main/resources/conf/framework/entity-types.xml) generiert werden können.; Der Entitätsgenerator erzeugt die Java-Klassen, Hibernate-Mapping-Files und Formulare für die Administrationsoberfläche, so dass entsprechende Produkte und Kategorien sofort gepflegt werden können.; Mehr zum Entitätsgenerator findet ihr in Abschnitt 5.1.11 (Konfiguration und Generator), mehr zum Thema Typisierung findet ihr in Abschnitt 5.1.1 (Typisierung).
Entitätstyp: (englisch: entity type); Ein Entitätstyp ist die reflektive Beschreibung einer typisierten Entität, u.a. enthält er die Attribute, sowie Informationen über die Vererbung und die zulässigen enthaltenen Produkte und Kindkategorien. Produkttypen und Kategorietypen sind spezielle Entitätstypen.; Der Entitätstyp definitiert unter anderem auch, welche Beschränkungen eingehalten werden müssen, damit eine entsprechende Entität nicht als fehlerhaft eingestuft wird.; Mehr zum Thema Typisierung findet ihr in Abschnitt 5.1.1 (Typisierung).
Entwickler: (englisch: developer); Der Entwickler (szzdev) ist eine Rolle im Rahmen der Distribution über das One-Click-Deployment. Er hat die Aufgabe, eine Version zu erstellen und auf den Distributions-Host zu kopieren (Upload). Auf nicht-produktiven Umgebungen kann er diese Version desweiteren auf Web- und Applikations-Hosts mit Hilfe des Deployment-Skripts verteilen und aktivieren (Deployment). Auf der Produktivumgebung kann er dies nicht, dort wird die Aufgabe von dem Deployer wahrgenommen.; Auf nicht-produktiven Umgebungen ist der Benutzer szzdev außerdem der Besitzer des Applikations-Server-Prozesses.; Die Rolle Entwickler wird von Mitarbeitern der SinnerSchrader Technik wahrgenommen.; Mehr zum Thema One-Click-Deployment findet ihr in Abschnitt 10.5.3 (One-Click-Deployment).
eScore: eScore ist ein Produkt des Dienstleisters arvato infoscore zur Überprüfung der Validität von Kunden-, Adress- und Zahlungsdaten (Bonitätsprüfung).; Die Homepage von arvato infoscore: http://www.infoscore.de/; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.4 (Zahlungsadapter).
Excel- und CSV-Import und -Export: (englisch: Excel and CSV import and export); Diese Komponente ermöglich den Import und Export sowohl von nativen Excel-Dateien (XLS), als auch kommaseparierte Listen (CSV), auf Basis von JavaBeans. Hierbei ist es möglich, Validierungsregeln anzugeben, um fehlerhafte Dateien zu verhindern bzw. zu bemerken. Der Im- und Export kann mit der Dateitransfer-Komponente kombiniert werden.; Mehr zum Thema Excel und CSV findet ihr in Abschnitt 7.2 (Excel- und Text-Import und -Export).
Externer Schlüssel: (englisch: external key); Der externe Schlüssel ist ein Freifeld in typisierten Entitäten, das auf den Primärschlüssel eines Drittsystems verweist, dessen Produkttypen importiert worden sind. Da über diesen Schlüssel keinerlei Aussage getroffen werden kann, wird er weder als Pflichtattribut, noch als eindeutig definiert.; Mehr zu diesem Thema findet ihr in Abschnitt 4.1 (Entitäten).
Facultative-Navigator: Einer der drei im Commerce-Framework bereits enthaltenen Navigatoren für Formularprozesse.; Der zeichnet sich im wesentlichen dadurch aus, dass Seiten in beliebiger Reihenfolge bearbeitet werden müssen. Fehler in Seiten werden zudem erst zum Abschluss des Prozesses angezeigt.; Weitere Navigatoren des Frameworks sind der Chained-Navigator und der Facultative-Validating-Navigator. Es ist leicht möglich, einen vorhandenen Navigator zu erweitern oder einen neuen zu entwickeln.; Mehr zum Thema Navigatoren findet ihr in Abschnitt 6.1.3 (Navigator (Formularprozesse)).
Facultative-Validating-Navigator: Einer der drei im Commerce-Framework bereits enthaltenen Navigatoren für Formularprozesse.; Der zeichnet sich im wesentlichen dadurch aus, dass Seiten in beliebiger Reihenfolge bearbeitet werden müssen. Fehler in Seiten werden jedoch bereits beim Navigieren angezeigt.; Weitere Navigatoren des Frameworks sind der Chained-Navigator und der Facultative-Navigator. Es ist leicht möglich, einen vorhandenen Navigator zu erweitern oder einen neuen zu entwickeln.; Mehr zum Thema Navigatoren findet ihr in Abschnitt 6.1.3 (Navigator (Formularprozesse)).
Feature-Stopp: Ein Feature-Stopp ist eine Ansage innerhalb eines Entwicklungs-Teams dass auf einen bestimmen Branch keine neuen Features oder allgemeinen Verbesserungen, sondern nur noch notwendig Bugfixes committet werden dürfen.; Ein Feature-Stopp tritt im Rahmen einer Versionsplanung auf, um den Umfang der Änderungen einer Version gering zu halten. Dadurch ist es der Qualitätssicherung leichter möglich, eine Version freizugeben, wodurch sie kurzfristiger auf die Live-Umgebung deployt werden kann.; Mehr zum Thema Versionsplanung findet ihr in Abschnitt 10.5.2 (Versionsplanung).
Fehlerhafte Entität: (englisch: erroneous entity); Eine typisierte Entität (z.B. ein Produkt oder eine Kategorie), das in mindestens einem Attribut oder auf sonst eine Weise eine Beschränkung verletzt. Fehlerhafte Produkte werden beispielsweise im Shop nicht angeboten.; Es wird unterschieden zwischen Persistenzfehlern und Validierungsfehlern.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
File-Action: Eine spezielle vom Commerce-Framework abgebotene Struts-Action, mit der in Zusammenarbeit mit einem entsprechenden JSP-Tag Bilder und andere Binärinhalte leicht in JSPs eingebettet werden können.; Mehr zur Tag-Library des Commerce-Frameworks findet ihr in Abschnitt 6.4 (Tag-Library).
File-Data-Entity: Eine Entität, die die Binärdaten für ein Dateiattribut bzw. Bildattribut trägt.; Die Metadaten befinden sich als Komponente in Form einer File-Description in der typisierten Entität selbst, die File-Data-Entity ist ausgelagert, da typischerweise die Binärdaten erst zu einem späteren Zeitpunkt benötigt werden (z.B. wird das Bild eines <img>-Tags erst in einem zweiten Request geladen).; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.6 (Datei- und Bildattribute).
File-Description: Die Metadaten wie URL, ID der File-Data-Entity, Mime-Type etc. zu einem Dateiattribut oder Bildattribut.; Die Metadaten befinden sich als Komponente in Form einer File-Description in der typisierten Entität selbst, die File-Data-Entity ist ausgelagert, da typischerweise die Binärdaten erst zu einem späteren Zeitpunkt benötigt werden (z.B. wird das Bild eines <img>-Tags erst in einem zweiten Request geladen).; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.6 (Datei- und Bildattribute).
Fließkommazahlattribut: (englisch: float attribute); Ein primitiver Attributtyp für Zahlen mit fließenden Nachkommastellen.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Form: Struts-Forms werden automatisch von dem Action-Servlet von Struts verwaltet und mit den Daten des aktuellen Requests versehen. Sie spiegeln in vielen Fällen die Präsentation eines Models wider und delegieren zum Synchronisieren oftmals an Form-Filler.; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 12.1 (Präsentationsmuster).
Form-Filler: Form-Filler sind meist zustandslose Klasse, die aus Models Struts-Forms befüllen bzw. das Model nach der Bearbeitung wieder aktualisieren.; Form-Filler sind mit Value-Bean-Fillern verwandt, welche sich entsprechend um Value-Beans kümmern.; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 12.1 (Präsentationsmuster).
Formularprozess: (englisch: form process); Die gesamte Definition und Implementierung eines Prozesses der Formulareingabe wird unter dem Begriff Formularprozess (oder kurz Prozess) zusammengefasst. Ein Prozess umschließt alle Seiten, in denen der Benutzer Daten in Teilformulare des Prozessformulars eingibt, inklusive der Navigation von Seite zu Seite.; Wenn die Eingabe vollständig ist (was von diversen Faktoren abhängen kann) gilt der Prozess als abgeschlossen.; Ein Prozess besteht aus mehreren Seiten, diese wiederum aus Modulen. Innerhalb des gesamten Prozesses sind sowohl Seiten-, als auch Modulnamen eindeutig.; Weitere Informationen über Formularprozesse findet ihr in Abschnitt 6.1 (Formularprozesse).
Formularprozess-Komponente: (englisch: form process component); Die Formularprozess-Komponente bietet die Möglichkeit, ein Struts-Formular auf mehrere Seiten zu verteilen und ohne den Einsatz von restriktiven Maßnahmen wie Struts-Tokens dem Benutzer zu gestatten, vorwärts und rückwärts zu navigieren. Sie bettet sich nahtlos in die Struts-Actions, Struts-Forms, Struts-Validierung und Struts on Rails ein und ermöglicht ein konfiguratives Umpositionieren von Seiten, Seitenteilen, FormBeans, Validierungs-Regeln, JSPs und Anwendungslogik.; Mehr zu Formularprozessen findet ihr in Abschnitt 6.1 (Formularprozesse).
Ganzzahlattribut: (englisch: integer attribute); Ein primitiver Attributtyp für Zahlen ohne Nachkommastellen.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Geldbetrag: (englisch: currency amount); Ein Werteobjekt des Commerce-Frameworks, welches einen Geldbetrag (z.B. einen Preis eines Produkts oder eine Endsumme einer Bestellung) mit der dazugehörigen Währung kapselt und u.a. Rundungsfunktionen für die Nachkommastellen entsprechend der Währung anbietet.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Geldbetragattribut: (englisch: currency amount attribute); Ein primitiver Attributtyp für Geldbeträge mit Rundungsfunktionen für die Nachkommastellen entsprechend der dazugehörigen Währung.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Gesamtpreis: (englisch: total amount); Der Gesamtgeldbetrag einer Bestellposition in einer Bestellung, d.h. unter Berücksichtigung der Menge, sowie der für den Kunden, den Mandanten etc. gültigen Rabattierung (Preisfabrik).; Der Einzelpreis, multipliziert mit der Menge, muss nicht notwendigerweise den Gesamtpreis ergeben.; Mehr zum Thema Preise findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Geschäftslogikschicht: (englisch: business layer); Die Geschäftslogikschicht ist eine der zwei Schichten einer Standard-SinnerSchrader-Architektur.; In der Geschäftslogik werden die Anfragen des Benutzers aus fachlicher Sicht bearbeitet. Die Schicht überprüft die Benutzeranfrage semantisch, speichert, sucht und lädt mit Hilfe einer Datenbank (Persistenz), kontaktiert Drittsysteme und enthält Logik für alle Anwendungsfälle entsprechend des Fachkonzepts.; In der Geschäftslogik darf keine Präsentationstechnologie referenziert werden (z.B. HTTP-Session, Requests, etc.). Die Geschäftslogik darf auch nie die Präsentationsschicht kontaktieren oder sonst wie verwenden, nur umgekehrt. Entwurfsmuster wie Call-Backs sind natürlich zulässig, da hier keine Typreferenzierung von der Geschäftslogik zur Präsentation auftritt.; Innerhalb der Schichten werden bestimmte Entwurfsmuster verwendet. Eine Auflistung aller Muster, sowie ein Überblick über die Schichten und der Interaktion der Muster findet ihr in Kapitel 12 (Entwurfsmuster).
Hashing: (englisch: unidirectional encryption or hashing); Unidirektionale Verschlüsselung bzw. Hashing ist ein Verfahren, bei dem das Klarwort mit einer mathematischen Funktion auf einen Zahlenwert (Hashwert) aus einem kleineren Raum verdichtet wird.; Da bei der unidirektionalen Verschlüsselung Information verlorengeht und aufgrund der Beschaffenheit der Funktion, ist es nicht möglich, das Klarwort aus dem Hashwert zu errechnen. Die Funktion ist außerdem derart gewählt, dass es ohne Kenntnis des ursprünglichen Klarwortes schwer ist, ein Klarwort zu finden, welches auf diesen Hashwert reduziert werden kann.; Das Commerce-Framework verwendet unidirektionale Verschlüsselung zum Speichern von Passwörtern. Zur Überprüfung erfolgt erneut die Verschlüsselung der Eingabe, und ein Vergleich der Hashwerte.; Das Gegenteil der unidirektionalen Verschlüsselung ist die bidirektionale Verschlüsselung. Mehr zum Thema Verschlüsselung findet ihr in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Hauptpreisfabrik: Die Preisfabrik, die verwendet werden soll, wenn bei einer Preisberechnung keine Preisfabrik-ID spezifiziert worden ist.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Hauptwährungseinheit: (englisch: main currency unit); Innerhalb einer Währung ist die Haupteinheit die Einheit mit jeweils größerem Wert, z. B. Euro oder Dollar.; Gegenteil: Unterwährungseinheit; Mehr zum Thema Preisberechnung findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Hibernate: Ein Framework zur relationalen Persistenz von idiomatischen Java (objektrelationales Mapping). Es bietet ein objektrelationes Mapping an, welches sich durch starke Datenbankunabhängigkeit und eine hervorragende Unterstützung objektorientierter Ansätze auszeichnet. Es kommt u.a. für die Persistenz von Produkten, Kunden und Bestellungen zum Einsatz.; Bei der Arbeit mit Hibernate kommt es öfters zu Problemen, die auf einem falschen Verständnis über die Hibernate-Session beruhen. Daher ist es empfehlenswert, Abschnitt 13.2.2 (Hibernate) zu lesen. Auch die Hibernate-Dokumentation sollte vor der Arbeit mit Hibernate vollständig gelesen werden.; Die Homepage von Hibernate: http://www.hibernate.org/
Hibernate-Mapping: Das Hibernate-Mapping definiert, auf welche Weise eine Entität persistiert werden soll.; Ein Beispiel für eine Hibernate-Mapping-Datei mit optimistischem Locking findet ihr Abschnitt 13.2.1 (Optimistisches Locking).
Hibernate-Session: Die Hibernate-Session kaspelt eine Datenbankverbindung (JDBC-Connection) und alle Entitäten, mit der die Anwendung seit Beginn der Hibernate-Session Kontakt hatte.; Bei der Arbeit mit Hibernate kommt es öfters zu Problemen, die auf einem falschen Verständnis über die Hibernate-Session beruhen. Daher ist es empfehlenswert, Abschnitt 13.2.2 (Hibernate) zu lesen. Auch die Hibernate-Dokumentation (http://www.hibernate.org/) sollte vor der Arbeit mit Hibernate vollständig gelesen werden.
Host: In diesem Dokument wird der Begriff Host für eine physische Maschine, der Begriff Server jedoch für die auf einem Host betriebene Software (z.B. Apache HTTPD oder Tomcat) verwendet. Diese Begriffe sind nicht zu verwechseln mit den Apache-Virtual-Hosts, welche durch den Apache HTTPD betriebene Anwendungen beschreiben.; Mehr zu diesem Thema findet ihr in Abschnitt 10.5 (Distribution).
HQL: Die Hibernate-Query-Language (HQL) ist eine Datenbank-Management-System-unabhängige Sprache für Query-Operationen auf mit Hibernate persistierten Entitäten. Sie ist an SQL angelehnt, verwendet als Namen und Konstrukte aber nicht die Datenbankrelationen (Tabellennamen, Spaltennamen, Beziehungen), sondern das objektorientierte Modell (Klassennamen, Property-Namen, Beziehungen), und gestattet auch Zugriffskaskaden wie; where c.billingAddress.firstName = "Peter"
ID: (englisch: id); Eine über alle persistierten Entitäten eindeutige Ganzzahl, auf die referenziert werden kann. Bei verschiedenen Versionen derselben Entität bleibt diese Zahl konstant. Ids werden nicht wiederverwendet, wenn die entsprechenden Entitäten ungültig geworden sind.; Mehr zu diesem Thema findet ihr in Abschnitt 4.1 (Entitäten).
Identifizierung: (englisch: identification); Identifikation ist die Angabe der eigenen Benutzerkennung (Login). Die Kennung ist damit noch nicht authentifiziert, hierfür ist beispielsweise ein Passwort nötig.; Weitere Informationen zu Benutzern findet ihr in Abschnitt 5.2.1 (Benutzer), mehr zur Authentifizierung in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Importwurzel: (englisch: import root); Eine Produktkategorie, auf der ein Drittsystemimport über Push oder Pull definiert ist.; Mehr zum Thema Kategorisierung findet ihr in Abschnitt 5.1.2 (Produkte und Kategorien).
Injection: Injection (Dependency Injection) ist der Vorgang des SpringFrameworks, ein Spring-Bean einer anderen dadurch bekannt zu machen, dass das SpringFramework eine Setter-Methode der abhängigen Bean aufruft und die unabhängige Bean als Parameter übergibt.; Das SpringFramework kann hierdurch eine spezialisierte Implementierung dieser Bean übergeben (Proxy), wodurch AOP-Aspekte umgesetzt werden können (z.B. Hibernate-Sessions oder Transaktionen).; Benötigt eine Spring-Beans eine Funktion einer anderen Spring-Bean, darf sie daher keine statische Anhängigkeit zu ihr aufbauen, indem sie z.B. die andere Bean instanziiert oder eine Singleton-Methode (getInstance) verwendet, sondern muss stets eine Property vom Typ der anderen Bean besitzen. Entweder wird die andere Bean in der Spring-Konfiguration deklariert, oder man verwendet Auto-Wiring.
JUnit: JUnit ist ein Framework zum automatisierten Testen von Java-Anwendungen. Es lässt sich aufgrund einer sehr guten Unterstützung entsprechender Werkzeuge leicht in den Release-Prozess integrieren.; Die JUnit-Homepage: http://www.junit.org/; Mehr zum Thema Versionsplanung findet ihr in Abschnitt 10.5.2 (Versionsplanung).
Kanonischer Projektname: Der kanonische Name eines Software-Projekts ist seine techniscke Kurzbezeichnung und wird bei der Anlage des Projekts über den Projekt-Wizard festgelegt. Zumeist handelt es sich hierbei um eine von Sonderzeichen und Leerzeichen bereinigte Form des Projektnamen.; Der kanonische Projektname wird u.a. für Packages, Verzeichnisse und den Web-Kontext als Standard definiert.; Mehr zur Projektvorlage und zum Projekt-Wizard findet ihr in Kapitel 10 (Projektvorlage).
Kategorie: (englisch: category); Kategorien stellen Ordnungsselemente für Produkte, andere Kategorien sowie beliebige typisierte Entitäten dar. Der Produktkatalog ist eine baumförmige Struktur, die als Knoten aus Produkten und Kategorien besteht, wobei Produkte stets Blätter sind. Der oberste Knoten (Wurzelkategorie) ist eine nicht vom Redakteur oder Entwickler löschbare Systemkategorie, über die die darunterliegenden Knoten abgefragt und einsortiert werden können.; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Kategoriepfad: (englisch: category path); Ein Kategoriepfad ein String aus mehreren Codes von Kategorien, getrennt durch einen Blackslash, z.B. 'products\manufacturers\Siemens'. Kategoriepfade stellen eine Möglichkeit dar, eine Kategorie zu identifizieren.; Die Suche nach der entsprechenden Kategorie beginnt hierbei zunächst stets in der Wurzelkategorie.; Mehr zu Kategoriepfaden findet ihr Abschnitt 5.1.2 (Produkte und Kategorien).
Kategorietyp: (englisch: category type); Ein Kategorietyp komponiert Attribute für eine Kategorie. Er definiert, welche Attribute in der Entität mit für das Attribut validen Werten bestückt sein muss, um nicht z. B. als fehlerhafte Entität eingestuft zu werden.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Kompositionsattribut: (englisch: composition attribute); Ein Relationsattribut, bei der im Produkt ein oder mehrere Subprodukte gepflegt werden. Diese Subprodukte entsprechen einem im Attribut eingestellten Typ. Die Subprodukte sind eng an das Produkt gebunden. Sie werden über eine Funktion beim Editieren des Produktes angelegt und beim Löschen des Produktes mitgelöscht.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Konkrete Entitätsklasse: (englisch: concrete entity class); Eine der beiden von dem Entitätsgenerator erzeugten Klasse für einen Entitätstypen.; Der Entitätsgenerator erzeugt neben dem Hibernate-Mapping für jeden Entitätstyp eine abstrake und eine konkrete Klasse, wobei die konkrete Klasse von der abstrakten erbt. Grund hierfür ist, dass in der abstrakten Klasse sämtlicher generierter Code beheimatet ist, während die konkrete Klasse im Projekt mit weiteren Helpern und Geschäftslogik befüllt werden soll. Der Generator überschreibt beim nächsten Generieren lediglich die abstrakte Klassen, welche auch nicht modifiziert werden dürfen, die konkreten Klassen werden nur angelegt, wenn sie noch nicht existieren, und anschließend nicht mehr vom Generator angefasst. Er kann also beliebig oft aufgerufen werden.; In der Anwendung sollte stets nur der konkrete Typ verwendet werden, um auf die Methoden beider Klassen zugreifen zu können.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Kunde: (englisch: customer); Ein Benutzer, der im Shop einen Kauf auslöst oder eine Registration durchgeführt hat. Bestellungen referenzieren beispielsweise den Kunden, der die Bestellung ausgelöst hat.; Mehr zu diesem Thema findet ihr in Abschnitt 5.2.1 (Benutzer).
Lieferadresse: (englisch: shipping address); Die Adresse, die für die Lieferung der Produkte zu verwenden ist. Sowohl Kunden, als auch Bestellungen besitzen eine Lieferadresse, da diese bei einer Bestellung abweichen kann bzw. bei Adressänderungen die in alten Bestellungen verwendete Adresse archiviert bleiben muss.; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.5 (Lieferungen).
Lieferung: (englisch: shipping); Eine Lieferung ist eine Entität, die die physische Lieferung eines Teils einer Bestellung oder der gesamten Bestellung im Shop-System verzeichnet. Sie wird im Commerce-Framework als Shipping persistiert.; Mehr zum diesem Thema findet ihr in Abschnitt 5.3.5 (Lieferungen).
Live-Umgebung: (englisch: live environment); Die Live-Umgebung (auch Produktivumgebung genannt) ist die Umgebung, die der Öffentlichkeit (dem Endkunden) zugänglich gemacht wird. Nach der Definition einer Version, der Qualitätssicherung auf der Test-Umgebung und der Freigabe des Kunden auf der Stage-Umgebung, kann eine Version auf die Live-Umgebung deployt werden.; Weitere Informationen zu Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Locale: Eine Locale definiert eine geografische oder kulturelle Region, z.B. die USA, oder der englischsprachige Raum. Locales haben eine ID, welche sich aus der Sprache, optional dem Land und optional der Variante zusammensetzt, z.B. 'en_US'.; Die Mehrsprachigkeit in typisierten Entität (z.B. einem Produkt) verwenden Locales zur Definition der Sprache. Desweiteren ermöglicht das Locale-Attribut das Einstellen einer Locale in einer Entität zu einem bestimmten Zweck.; Mehr zum Thema Mehrsprachigkeit findet ihr in Abschnitt 5.1.8 (Mandanten und Sprachen), mehr zum Thema Locale-Attribut findet ihr in Abschnitt 5.1.4 (Primitive Attribute).
Locale-Attribut: (englisch: locale attribute); Ein primitiver Attributtyp, welcher eine Locale referenziert.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Log4J: Eine standardisierte Logging-Komponente ist für Debugging- und Monitoringzwecke, aber auch für Provisionierungen und für Data Mining notwendig. Die Open-Source-Komponente Log4J, welche ebenfalls im Apache-Projekt beheimatet ist, kommt als Logging-Komponente zum Einsatz.; Die Homepage von Log4J: http://logging.apache.org/log4j/
Lokaler Bestand: (englisch: local stock); Der lokale Bestand ist der Bestand eines Produkts, wie er aktuell der Anwendung bekannt ist. Er wird als Property localStock im Produkt persistiert.; Der lokale Bestand kommt nicht zum Einsatz, wenn der aktuelle Wert des Bestands stets über den Bestandsadapter aus einer externen Quelle bezogen und nicht lokal gecacht wird.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.14 (Bestandsverwaltung).
Lucene: Eine hochperformante Volltext-Suchmaschine u.a. für Websites und Datenbankentitäten, welche unter anderem phonemische und andere unscharfe Suchen ermöglicht. Sie kommt in dem Framework für die Shop- und Administrations-Suche zum Einsatz.; Die Homepage von Lucene: http://lucene.apache.org/java/docs/index.html; Mehr zur Suche auf typsierten Entitäten mit Hilfe eines Lucene-Indexes findet ihr in Abschnitt 5.1.12 (Produktsuche).
Lucene-Index: Ein Lucene-Index ist ein Index auf Basis der Suchmaschine Lucene. Er zeichnet sich durch eine tabellarische Struktur aus, dessen Zellen aus Texten bestehen.; Ein Lucene-Index verwendet keine Datenbank, Lucene implementiert eine speziell optimierte Dateipersistenz. Ein Index kann optional im RAM gecacht werden. Das Commerce-Framework bietet eine automatisierte Aktualisierung von Lucene-Indizes für typisierte Entitäten an.; Mehr zur Suche auf typsierten Entitäten mit Hilfe eines Lucene-Indexes findet ihr in Abschnitt 5.1.12 (Produktsuche).
Mailversand: (englisch: mail transport); Mit der Komponente Mailversand können E-Mails auf Basis von Plaintext- und HTML-Vorlagen unter Verwendung von Velocity versendet werden. Die Komponente bietet desweiteren die Möglichkeit, über das SpringFramework die konstanten Bestandteile der E-Mail (z.B. Subject, From, To, etc.) vorzukonfigurieren und nur die variablen programmatisch vorzugeben.; Außerdem können mit der Mailversand-Komponente Massen-Mailings verschickt werden, d.h. zeitlich geplante und auf mehreren Servern gleichzeitig verschickte große Mengen gleichförmiger Mails auf Basis von Vorlagen und Profildaten.; Es ist geplant, dass die Mailversand-Komponente zukünftig auch Bounce-Management anbietet.; Mehr zu diesem Thema findet ihr in Abschnitt 7.3 (Mailversand).
Manager: Manager sind in der Regel zustandslose Klassen die Geschäftslogik für einen Use-Case oder eine Gruppe verwandter Use-Cases kapseln, wie z.B. das Produkt-Management, Bestellungen oder eine Schnittstelle.; Manager stellen eine API u.a. zum Finden von Models, zum Speichern, sowie für diverse Prozess- und Schnittstellenoperationen zur Verfügung.; Weitere Informationen zu dem Thema findet ihr in Abschnitt 12.2 (Geschäftslogikmuster).
Manager-Locator: Um in der Präsentationsschicht oder einer anderen Klasse, die nicht durch Spring gemanaget wird, einen Einstieg in die durch Spring verwalteten Manager-Beans zu erhalten, kann man sich an den Manager-Locator wenden. Er entspricht dem J2EE-Muster "Service-Locator" und besitzt für jeden öffentlichen Manager eine Property, welche durch Spring gefüllt wird.; Manager-Locator werden nur von der Präsentationsschicht, sowie von Klassen verwendet, die nicht in Spring deklariert sind. Manager oder gar DAOs sollten den Manager-Locator nicht verwenden, da ansonsten Spring die Abhängigkeiten nicht richtig auflösen kann und dadurch uninitialisierte Beans auftreten können.; Weitere Informationen zu diesem Thema findet ihr in Abschnitt 12.2 (Geschäftslogikmuster).
Mandant: (englisch: client); Ein Kriterium, nach dem der Produktkatalog gruppiert und die Produktattribute und Web-Ressourcen spezialisiert werden können. Der ausgewählte Mandant wird in der Session verwaltet.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.8 (Mandanten und Sprachen).
Mandantenattribut: (englisch: client attribute); Ein Relationsattributtyp, welcher einen oder mehrere Mandanten referenziert.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Mandantenfähigkeit: (englisch (Adjektiv): client aware); Mandantenfähigkeit ist zum einen die Fähigkeit der Produktverwaltung im Commerce-Framework, Attributen je nach Mandant verschiedene Werte zuzuweisen. Zum anderen wird das Konzept des Mandanten durch eine entsprechend persistente Klasse, sowie durch das Mandantenattribut besonders gefördert.; Mehr zum Thema Mandanten und Sprachen findet ihr in Abschnitt 5.1.8 (Mandanten und Sprachen). Mehr zum Thema Attribute findet ihr in Abschnitt 5.1.3 (Attribute im Überblick).
Massen-Mailing: (englisch: mass mailing); Ein Massen-Mailing ist ein Auftrag an die Mailversand-Komponente, eine große Menge gleichförmiger E-Mails zeitlich geplant und auf Basis von Vorlagen und Profildaten zu verschicken. Dieser Versand kann im Cluster und unter Verwendung von Velocity-Templates erfolgen.; Mehr zum Massen-Mailing findet ihr in Abschnitt 7.3.2 (Massen-Mailings).
Maven: Maven ist ein Werkzeug zum Software-Management. Es löst u.a. die per Deklaration spezifizierten direkten und indirekten Abhängigkeiten zu Komponenten auf. Desweiteren bietet es eine Standard-Projektstruktur und vereinheitlichende Prozesse, von der Überprüfung und Kompilation der Komponente, bis hin zum Deployment und der Dokumentation. Erstellte Komponenten werden auf Maven-Repositories hochgeladen und auf diesen erwartet.; In der Projektvorlage wird Maven vor allem dafür verwendet, um die Komponenten-JARs aus dem Projekt zu verbannen. Die Projektvorlage verwendet Maven implizit in den [[Glossar:Ant|Ant]-Targets. Man muss und kann dort keine Maven-Goals direkt aufrufen. Anstattdessen verwendet man die gewohnten Ant-Targets.; Mehr zum Thema Maven in der Projektvorlage findet ihr in Abschnitt 10.2 (Maven-Integration) und die Homepage von Maven ist http://maven.apache.org/
Maven-Repository: Ein Maven-Repository ist ein Speicherort für Maven-Builds. Die S2I verwaltet ein Maven-Repository für alle Komponenten und Projekte, welches lesend unter http://maven und schreibend über SCP unter maven@maven:/home/maven/repository erreichbar ist.; Mehr zum Thema Maven in der Projektvorlage findet ihr in Abschnitt 10.2 (Maven-Integration) und die Homepage von Maven ist http://maven.apache.org/
Mehrsprachigkeit: (englisch (Adjektiv): localizable); Mehrsprachigkeit ist die Fähigkeit der Produktverwaltung im Commerce-Framework, Attributen je nach Sprache verschiedene Werte zuzuweisen.; Mehr zum Thema Mandanten und Sprachen findet ihr in Abschnitt 5.1.8 (Mandanten und Sprachen).
Mehrwertsteuer-Kennzeichen: (englisch: tax code); Der Code der für ein Produkt gültigen Mehrwertsteuer, im Gegensatz zum Mehrwertsteuersatz.; Beispiel: A1; Mehr zum Thema Produkte findet ihr in Abschnitt 5.1 (Produktverwaltung).
Mehrwertsteuersatz: (englisch: tax rate); Der Prozentwert der für ein Produkt gültigen Mehrwertsteuer, im Gegensatz zum Mehrwertsteuer-Kennzeichen.; Beispiel: 19; Mehr zum Thema Produkte findet ihr in Abschnitt 5.1 (Produktverwaltung).
Migration: Eine Migration ist die Überführung eines Systems passend zu einer bestimmten Version in einen Zustand, zu dem es zu einer anderen Version passt. Oftmals ist dafür notwendig, dass bei dem Deployment zusätzliche Maßnahmen durchgeführt werden, die z.T. mit dem Betriebsdienstleister koordiniert werden müssen. Hierzu gehören u.a. Datenbankmigrationen, CMS-Publikationen, Apache-RewriteRules oder Schnittstellenanpassungen.; Mehr zu diesem Thema findet ihr in Abschnitt 10.5.2 (Versionsplanung).
Model: (englisch: model); Modelle stellen die datentragenden Objekte einer Anwendung dar, die im Wesentlichen aus dem Domain-Object-Model (Unified Modelling) entstanden sind. Sie sind technischer als die DOM-Klassen und berücksichtigen auch nur noch die Webanwendung selbst.; Persistente Modelle werden Entitäten genannt.; Weitere Informationen zu diesem Thema findet ihr in Abschnitt 12.2 (Geschäftslogikmuster).
Modul: (englisch: module); Ein Modul ist ein Teil einer Seite in einem Formularprozess, der einen logischen Zusammenhalt halt.; Module dienen der Wiederverwendbarkeit von Java-Code, JSPs und Validierungsregeln, und um ein einfaches Verschieben innerhalb der Seite oder auf andere Seiten zu ermöglichen. Es ist sinnvoll, Module unter den Gesichtspunkten zukünftiger Anforderungen zu definieren. Sind sie zu klein gewählt, wird die Implementierung erschwert, sind sie zu groß, lassen sie sich nicht mehr gut wiederverwenden und umkonfigurieren. Ein sinnvolle Modulgröße sind beispielsweise eine Adresse oder die Bankdaten des Kunden.; Ein Prozess besteht aus mehreren Seiten, diese wiederum aus Modulen. Innerhalb des gesamten Prozesses sind sowohl Seiten-, als auch Modulnamen eindeutig.; Weitere Informationen über Formularprozesse findet ihr in Abschnitt 6.1 (Formularprozesse).
Module-Form: Eine Module-Form trägt die Daten zu einem Modul eines Formularprozesses, z.B. alle Felder einer Adresse oder einer Bankverbindung. Die Anwendung muss für jedes Modul von ModuleForm ableiten und die Felder des Moduls dort als Properties modellieren.; Eine Module-Form ist selbst wiederum eine Struts-Validator-Form, so dass die validation.xml für Module-Forms eingesetzt werden kann. Es ist hierbei sowohl möglich, für zwei verschiedene Module dieselbe Form-Klasse, aber unterschiedliche Validierungen anzugeben (z.B. eine Adress-Form, einmal nur valide ab 18 Jahren), als auch verschiedene Form-Klassen mit derselben Validierung. All dies wird über die Prozess-Konfiguration gesteuert.; Weitere Informationen über Formularprozesse findet ihr in Abschnitt 6.1 (Formularprozesse).
Module-JSP: Die Module-JSP enthält den JSP-Code zum Darstellen der Felder einer Module-Form innerhalb eines Formularprozesses. Er wird so unabhängig von der Seite wie möglich geschrieben, um ein einfaches Umkonfigurieren zu ermöglichen.; Weitere Informationen zu diesem Thema findet ihr in Abschnitt 6.1.2 (Modularisierung (Formularprozesse)).
Monitoring-Komponente: (englisch: monitoring component); Eine Commerce-Framework-Komponente, mit dessen Hilfe JVM- und Tomcat-Systemparameter wie Speicherbelegung, Tomcat-Sessions etc. gesammelt und an das Überwachungswerkzeug Munin weitergeleitet werden können.; Mehr zu der Monitoring-Komponente findet ihr in Abschnitt 4.5 (Monitoring).
Munin: Ein Linux-Überwachungswerkzeug, welches täglich, wöchentlich, monatlich und jährlich unterschiedlichste Health-Parameter wie CPU-Auslastung, Speicherbelegung innerhalb und außerhalb der VM, Tomcat-Sessions etc. des Systems sammelt und grafisch darstellt. Über diese Graphen wird die Suche nach einem Problem, welches sich durch Überlast, Speicherüberlauf oder ähnlichen Symptomen bemerkbar macht, vereinfacht.; Die Monitoring-Komponente des Commerce-Frameworks reichtert Munin mit JVM- und Tomcat-Daten an. Mehr zu der Monitoring-Komponente findet ihr in Abschnitt 4.5 (Monitoring).
Mutex: Ein Mutex (von "Mutual Exclusion") ist ein Objekt, welches von mehreren Beteiligten potentiell verwendet wird, bei dem jedoch sichergestellt ist, dass nie zwei Beteiligte gleichzeitig darauf zugreifen (pessimistisches Locking).; Die Komponente Mutex-Locking realisiert pessmistisches Locking mit Hilfe von eigens für diesen Zweck erzeugten Tabellen, in denen jeweils ein Datensatz enthalten ist. Dieser Datensatz stellt den Mutex dar.; Mehr zu diesem Thema findet ihr in Abschnitt 4.3 (Mutex-Locking).
Mutex-Locking: Mit Hilfe der Komponente Mutex-Locking kann auf einfache Weise pessimistisch gelockt werden. Durch AOP ist es lediglich notwendig, dass die zu schützenden Methoden das Wort 'Synchronized' enthalten und der Manager ein Interface implementiert. Die Komponente realisiert das Locking mit Hilfe von eigens für diesen Zweck erzeugten Tabellen, in denen jeweils ein Datensatz enthalten ist. Dieser Datensatz stellt einen Mutex dar.; Mehr zu diesem Thema findet ihr in Abschnitt 4.3 (Mutex-Locking).
Navigator: (englisch: navigator); Der Navigator ist verantwortlich für das Navigations- und Abschlussverhalten eines Formularprozesses. Er steuert, zu welchen Seiten der Benutzer zu einem gegebenen Zeitpunkt oder entsprechend seiner Historie navigieren darf, weiß, ob der Prozess bereits abgeschlossen ist und entscheidet, ob er ein weiteres Mal abgeschlossen werden kann (complete-Methode).; Die Navigator-Klasse bietet eine Java-API, um die Navigationsbefehle auszulösen. Mit Hilfe des Process-Handlers kann diese API auf HTTP-Requests gemappt werden. Dies geschieht bei der Verwendung des Struts-on-Rails-Ansatzes automatisch.; Das Framework bietet bereits drei Navigator-Implementierungen an, den Chained-Navigator, den Facultative-Navigator und den Facultative-Validating-Navigator. Ein weiterer Navigator bzw. eine leichte Änderung eines vorhandenen kann im Rahmen des Projekts realisiert werden.; Mehr zu Formularprozessen findet ihr in Abschnitt 6.1 (Formularprozesse).
Nettobetrag: (englisch: net amount); Der Nettobetrag ist der Geldbetrag eines Produkts oder einer Bestellung ohne Mehrwertsteuer.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Nummerngenerator: (englisch: number generator); Der Nummerngenerator erzeugt fortlaufende oder zufällig wirkende (aber niemals doppelt vergebene) Nummern. Dabei wird unter Verwendung der Datenbank clusterweit synchronisiert. Der Nummernkreis definiert den Aufbau dieser Nummer.; Mehr zum Thema Nummernkreise findet ihr in Abschnitt 4.2 (Nummernkreise).
Nummernkreis: (englisch: number range); Der Nummerkreis definiert den Aufbau einer durch den Nummerngenerator erzeugten Nummer, sowie gegebenenfalls eine entsprechende Verschleierung, damit aus einer einzelnen Nummer keine Schlüsse gezogenen werden können, beispielsweise der wievielte Kunde man ist.; Mehr zum Thema Nummernkreise findet ihr in Abschnitt 4.2 (Nummernkreise).
One-Click-Deployment: Ziel des One-Click-Deployments ist es, den Vorgang, eine bereits definierte Version zu deployen, maximal zu vereinheitlichen und zu vereinfachen. Dadurch ist es möglich, dass jeder Mitarbeiter, der bereits ein One-Click-Deployment in einem beliebigen Projekt durchgeführt hat, dies in jedem anderen auch tun kann.; Der Name resultiert aus dem Umstand, dass man beim Deployen lediglich ein Ant-Target aufrufen muss und die entsprechende Versionsnummer eingibt. Anschließend ist keine weitere Benutzerinteraktion seitens des Entwicklers (szzdev) notwendig. Lediglich beim Betriebsdienstleister besteht Handlungsbedarf (Rolle Deployer) (beim SinnerSchrader Betrieb szzdep), wenn der Entwickler keine neue Version deployen darf (z.B. auf Produktivumgebungen). Aber auch hier muss er lediglich mit einem einfachen Befehl die Version nur noch freigeben und damit aktivieren.; Weitere Informationen zum Thema Build, Distribution und Deployment findet ihr in Abschnitt 10.5 (Distribution).
Open Source: Eine Komponente wird als Open Source bezeichnet, wenn ihr Quellcode kostenlos und frei verfügbar ist, d.h. es ist dem Entwickler möglich, Einblick in den Quelltext zu haben, und er hat desweiteren die Erlaubnis, diesen Quelltext beliebig weiterzugeben oder zu verändern.; Eine genaue Definition von Open Source findet ihr hier: http://de.wikipedia.org/wiki/Open_Source
Optimistisches Locking: Beim optimistischen Locking ist es gestattet, dass es zwei Threads zunächst gestattet ist, eine Entität parallel zu lesen, weil davon ausgegangen wird, dass die Threads nur selten den Datensatz zurückschreiben möchten. Sollten beide Threads schreiben wollen, führt dies beim zweiten Schreiber zu einer Exception (bei Hibernate zu einer StaleObjectStateException).; Gegenteil ist das pessimistische Locking.; Mehr Informationen zu optimistischem Locking findet ihr in Abschnitt 13.2.1 (Optimistisches Locking).
Packaging: Packaging bezeichnet den bei der Distribution auftretenen Vorgang, die Anwendung zu builden und alle notwendigen Dateien, unter anderem eine Server-Konfiguration, Deployment-Skripte, Installationsanleitungen, Dokumentation und andere Dateien als ein ZIP-Archiv zu packen.; Weitere Informationen zum Thema Build, Distribution und Deployment findet ihr in Abschnitt 10.5 (Distribution).
Page-JSP: In der Page-JSP wird das Aussehen des Seitenrahmens innerhalb eines Formularprozesses definiert, d.h. die JSP enthält alles, was der Benutzer auf einer Seite sieht, außer den Formularen der Module selbst.; Sie kann also u.a. Navigationsreiter enthalten, die alle Seiten des Prozesses in verschiedenen Farben anzeigen (aktuell, bereits besucht, noch nicht betretbar, usw.), und sie kann Forwärts- und Zurück-, sowie Abschließen-Buttons enthalten. Vor allem aber enthält sie das form-Tag für die Process-Form, einen Hidden currentPage mit dem Namen der aktuellen Seite und eine Iteration über alle Module dieser Seite, in der sie die Module-JSPs inkludiert.; Weitere Informationen zu diesem Thema findet ihr in Abschnitt 6.1.2 (Modularisierung (Formularprozesse)).
pago: pago ist ein Dienstleister für die Durchführung von Zahlungen über Kreditkarte, Bankeinzug und anderen Zahlungswegen, sowie zur Überprüfung der Validität von Kunden-, Adress- und Zahlungsdaten (Bonitätsprüfung). Der Zahlungsadapter unterstützt unter anderem Authorize, Capture und Partial Capture.; Die Homepage von pago: http://www.pago.de/; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.4 (Zahlungsadapter).
Partial Capture: Ein Partial Capture ist ein Spezialfall eines Captures, bei dem nur ein Teil des Betrages gecapturet wird. Je nach Vertragsoptionen ist es in diesem Fall möglich, für ein Authorize mehrere Partial Captures auszuführen (z.B. für Abos). Allerdings ist zu beachten, dass die Frist des Authorize meist nur 28 Tage beträgt. Anschließend wird ein Capture nicht mehr garantiert, es muss ggf. ein neues Authorize versucht werden.; Mehr Informationen über Zahlungsadapter findet ihr in Abschnitt 5.3.4 (Zahlungsadapter).
Passwort: (englisch: password); Eine entweder von dem Benutzer oder dem System vergebene, geheime Zeichenfolge, die ihn zusammen mit der Benutzerkennung authentifiziert. Kennung und Passwort nennt man zusammen Credentials.; Weitere Informationen zu Benutzern findet ihr in Abschnitt 5.2.1 (Benutzer), mehr zur Authentifizierung in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Persistenz: (englisch: persistency); Persistenz ist das Speichern von Models in einer Datenbank oder einem anderen dauerhaften Medium. Objekte, die persistiert werden, werden in objektorientierten Programmiersprachen wie Java Entitäten genannt. Sie werden mit einer objektrelationalen Mapping-Komponente wie z.B. Hibernate gespeichert und geladen.
Persistenzfehler: (englisch: persistency problem); Ein Fehler beim Validieren einer typisierten Entität, aufgrund dessen sich die Entität nicht speichern lässt (z.B. ein zu langes Feld oder ein verletztes Not-null-Constraint).; Bei der Validierung wird unterschieden zwischen Persistenzfehlern und Validierungsfehlern.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
Pessimistisches Locking: Beim pessimistischen Locking wird bereits beim Lesen eines Datensatzes sichergestellt, dass nie zwei Threads auf derselben Entität gleichzeitig arbeiten, um einen späteren Konflikt zu vermeiden. Der zweite Thread muss warten, bis der erste seine Operation abgeschlossen hat. Es wird davon ausgegangen, dass parallele Arbeit selten geschieht und ein Warten akzeptabel ist.; Gegenteil ist das optimistische Locking.; Mehr Informationen zu pessimistischem Locking findet ihr in Abschnitt 4.3 (Mutex-Locking).
Pflichtattribut: (englisch: required attribute); Ein Attribut, dessen Wert nicht leer sein darf.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
POI: Ein Open-Source-Framework für die Bearbeitung von Office-Dokumenten (Word, Excel, ...) aus Java heraus.; Die Komponente Excel- und CSV-Import und -Export verwendet POI zum Auslesen und Erzeugen von nativen Excel-Dokumenten.; Die Homepage von POI: http://poi.apache.org/
Preisfabrik: (englisch: price factory); Die Preisfabrik ist verantwortlich für die Berechnung eines Preises für ein Produkt oder Produkt-Bundle, ggf. unter Berücksichtigung von der Menge (Rabattierung), dem Kunden oder Mandanten.; In einem Shop-System können mehrere Preisfabriken zugleich existieren, die unterschiedliche Preismodelle darstellen. Die einfachste Preiskalkulation besteht aus einem konstanten, nicht rabattierten Preis am Produkt. Alternativ kann die Anwendung die Klasse PriceFactory implementieren.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Preiskalkulation: Die Preiskalkulation berechnet den Preis eines Produkts oder Produkt-Bundles auf Basis einer für den entsprechenden Anwendungsfall passenden Preisfabrik, wodurch Kriterien wie der aktuelle Kunde, der Mandant oder die gewünschte Menge (Rabatte) berücksichtigt und zentralisiert werden können.; Mehr zur Preiskalkulation findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Primitives Attribut: (englisch: primitive attribute); Ein Attribut, dessen Werte keine Identität haben, also keine Objekte wie Produkte oder Kategorien darstellen. Zu den primitiven Attributtypen zählen u.a. Text, Zahlentypen und der Wahrheitswert.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Process-Action: Eine spezielle Struts-Action, welche mit Hilfe des Struts-on-Rails-Ansatzes die Arbeit mit den Formularprozessen erleichtert, da keine Action mehr deklariert werden muss.; Mehr Informationen zu Formularprozessen im allgemeinen findet ihr in Abschnitt 6.1 (Formularprozesse), mehr zu Rails in Abschnitt 6.2 (Struts on Rails) und mehr speziell zu Rails für Formularprozesse in Abschnitt 6.2.4 (Formularprozesse (Rails)).
Process-Form: Die Process-Form ist indirekt der Container für alle vom Benutzer eingegebenen Daten innerhalb des gesamten Formularprozesses. Die Klasse ProcessForm erbt direkt von der Struts-Action-Form. Sie aggregiert für jedes Modul des Prozesses eine entsprechende Module-Form. Hierbei ist die Property der Process-Form gleich mit dem Namen des Moduls in dem Prozess.; Process-Forms selbst tragen in der Regeln keine Daten, alle Daten sind in den entsprechenden Module-Forms enthalten, an die auch die Validierung delegiert wird. Die Process-Form wird zurückgesetzt, wenn der Prozess neu gestartet oder vorzeitig (z.B. aufgrund von Datenschutz oder Session-Entlastung) resettet wird.; Weitere Informationen über Formularprozesse findet ihr in Abschnitt 6.1 (Formularprozesse).
Process-Handler: Der Process-Handler ist eine Klasse der Formularprozess-Komponente, welche die über die HTTP-Schnittstelle ankommenden Anfragen des Benutzers analysiert und die Navigationsanweisung an die Java-API des Navigators weiterleitet. Desweiteren erzeugt der Process-Handler das Process-State-Value-Bean.; Mehr zu dem Process-Handler findet ihr in Abschnitt 6.1.4 (Process-Handler (Formularprozesse)).
Process-State-Value-Bean: Nach dem Aufruf der zum Request passenden Funktion des Navigators erzeugt der Process-Handler ein Request-Attribut 'processState', in das er Informationen über den aktuellen Zustand der Prozessnavigation (aktuelle Seite, mögliche Seiten, die Process-Form, etc.) ablegt.; Dieses Objekt ist eine Instanz der Klasse ProcessStateValueObject.; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 6.1.4 (Process-Handler (Formularprozesse)).
Produkt: (englisch: product); Produkte stellen in erster Linie Objekte dar, die ein Kunde in einem Shop erwirbt. Die Produktverwaltung stellt einen flexibel typisierbaren Produktstamm mit optionalem baumförmigen Produktkatalog zur Verfügung, der u.a. von dem Shop-Frontend angeboten und in der Administrationsoberfläche gepflegt werden kann.; Produkte besitzen einen Standardpreis (für einheitliche Preisberechnung ohne Staffeln etc.), einen Bestand und viele weitere Eigenschaften.; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Produktbestellposition: (englisch: product order entry); Eine Bestellposition in einer Bestellung, die entweder ein einzelnes Produkt bestellt, oder aber ein Produkt-Bundle.; Produktbestellpositionen bestehen aus einem oder mehreren bestellten Produkten, wobei die Bestellposition im Fall einer Bundle-Bestellung das gesamte Bundle inkl. der Gesamtanzahl darstellt, während das bestellte Produkt das Bundle-Element mit seiner Anzahl im Bundle repräsentiert.; Die Produktbestellpositionen enthalten ferner einen Einzelpreis und einen Gesamtpreis. Der Einzelpreis, multipliziert mit der Menge, muss nicht notwendigerweise den Gesamtpreis ergeben. Dies ist vor allem bei Mengenrabatten nicht der Fall.; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.1 (Bestellungen).
Produktion: (englisch: production); Ein Zugang zu dem Shop, in dem von jeder typisierten Entität (z. B. Produkt oder Kategorie) die jeweilige Produktivversion verwendet wird. Dies ist der Regelfall für die Verwendung des Shops durch Kunden.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
Produktivumgebung: (englisch: live environment); Die Produktivumgebung (auch Live-Umgebung genannt) ist die Umgebung, die der Öffentlichkeit (dem Endkunden) zugänglich gemacht wird. Nach der Definition einer Version, der Qualitätssicherung auf der Test-Umgebung und der Freigabe des Kunden auf der Stage-Umgebung, kann eine Version auf die Live-Umgebung deployt werden.; Weitere Informationen zu Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Produktivversion: (englisch: productive version); Eine spezielle Version einer typisierten Entität (z. B. Produkt oder Kategorie). Diese Version wird in der Produktion verwendet.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
Produktkatalog: (englisch: product catalog); Die baumförmige Organisation aller Produkte, Kategorien und sonstigen typisierten Entitäten des Shops.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.2 (Produkte und Kategorien).
Produktsuche: (englisch: product search); Die Produktsuche ist eine Komponente des Commerce-Frameworks, welche die Erzeugung und Aktualisierung eines Lucene-Indexes auf durch die Typisierung definierten Entitäten (z.B. Produkte und Kategorien automatisiert.; Mehr zur Produktsuche findet ihr in Abschnitt 5.1.12 (Produktsuche).
Produkttyp: (englisch: product type); Ein Produkttyp komponiert Attribute für ein Produkt. Er definiert, welche Attribute in der Entität mit für das Attribut validen Werten bestückt sein muss, um nicht z.B. als fehlerhafte Entität eingestuft zu werden.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Produktverwaltung: (englisch: product management); Anhand einer Typisierungssprache werden Produkte definiert. Das Framework erzeugt hieraus automatisch Java-Entitätsklassen, Hibernate-Mapping-Files und eine Produkt-Administrationsoberfläche.; Die Produktverwaltung ist mandanten- und mehrsprachfähig, verwaltet Dateiressourcen wie Bilder, bietet einen Rahmen für Bundles und Preiskalkulation und erzeugt und aktualisiert automatisch Lucene-Indizes zum phonetischen Suchen innerhalb von Produkten und Kategorien.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
Projekt-Wizard: (englisch: project wizard); Ein Eclipse-Plugin zum Anlegen von neuen S2I-J2EE-Projekten auf Basis der Projektvorlage, in der Platzhalter für Namen und verwendete Technologien enthalten sind. Der Wizard erzeugt mit Hilfe von Daten, die dem Benutzer abgefragt werden, ein neues S2I-Projekt, welches inkl. aller Komponenten, dem Build-Prozess und dem Deployment auf die finalen Hosts sofort einsatzbereit ist.; Um ein neues Projekt anzulegen ist sowohl der Wizard, als auch die Vorlage notwendig.; Der Wizard kann entweder hier gedownloadet werden, oder aber ihr fügt die Eclipse-Update-Site http://dev.s2neueinformatik.de/EclipseUpdateSite zu eurem Eclipse hinzu. Wenn ihr das Plugin direkt runterladet, entpackt das ZIP ins Eclipse-Verzeichnis. Alternativ ist der Wizard auch über das CVS erhältlich: common/commerce/wizard.; Die Projektvorlage kann entweder hier gedownloadet werden, oder ihr checkt sie über das CVS aus: common/commerce/template.; Mehr zum Projekt-Wizard findet ihr in Abschnitt 10.6 (Projekt-Wizard).
Projektfamilie: Die Projektfamilie ist die Zusammenfassung mehrerer Projekte, die einen gemeinsamen Projektfamilienverantworten haben. In der Regel entspricht eine Projektfamilie einem Kunden. Das Projektfamilienkürzel besteht aus drei Buchstaben (z.B. 'SUZ' oder 'EMI'). Der Langname der Projektfamilie besteht aus dem Kürzel, einem Unterstrich, sowie dem nicht abgekürzten Namen des Kunden bzw. dem ansonsten die Familie bezeichnenden Namen, ohne Leerzeichen (z.B. 'SUZ_SüddeutscheZeitung').; Projektfamilien werden von der Geschäftsführung vergeben und als Ordner im S2I-Share unter '10-Projekte' angelegt.
Projektname: Ein Projektname ist ein innerhalb einer Projektfamilie vergebene Name für ein organisatorisches oder Software-Projekt. Der Projektname wird von dem Projektfamilienverantwortlichen vergeben.; Er wird zusammen mit der Projektnummer als Ordner in der Projektfamilie angelegt (z.B. '20-Mediathek'), welche wiederum im S2I-Share unter '10-Projekte' liegt.
Projektnummer: Eine Projektnummer ist ein innerhalb einer Projektfamilie vergebene, bei 20 beginnende Nummer für ein organisatorisches oder Software-Projekt. Die Projektnummer wird von dem Projektfamilienverantwortlichen vergeben.; Sie wird zusammen mit dem Projektnamen als Ordner in der Projektfamilie angelegt (z.B. '20-Mediathek'), welche wiederum im S2I-Share unter '10-Projekte' liegt.
Projektvorlage: (englisch: project template); Eine J2EE-Projektvorlage, in der Platzhalter für Namen und verwendete Technologien enthalten sind. Der SinnerSchrader-Project-Wizard, ein Eclipse-Plugin, erzeugt mit Hilfe von Daten, die dem Benutzer abgefragt werden, ein neues SinnerSchrader-Projekt, welches inkl. Deployment sofort einsatzbereit ist.; Um ein neues Projekt anzulegen ist sowohl der Wizard, als auch die Vorlage notwendig.; Die Projektvorlage kann entweder hier gedownloadet werden, oder ihr checkt sie über das CVS aus: common/commerce/template.; Der Wizard kann entweder hier gedownloadet werden, oder aber ihr fügt die Eclipse-Update-Site http://dev.s2neueinformatik.de/EclipseUpdateSite zu eurem Eclipse hinzu. Wenn ihr das Plugin direkt runterladet, entpackt das ZIP ins Eclipse-Verzeichnis. Alternativ ist der Wizard auch über das CVS erhältlich: common/commerce/wizard.; Mehr zur Projektvorlage und dem Projekt-Wizard findet ihr in Kapitel 10 (Projektvorlage).
Präsentationsschicht: (englisch: presentation layer); Die Präsentationsschicht ist eine der zwei Schichten einer Standard-SinnerSchrader-Architektur.; Die Präsentation realisiert das Frontend zu den projektspezifischen Use-Cases und interagiert mit dem Benutzer. Sie fungiert als Übersetzer der entsprechenden Präsentationstechnologie, meist HTTP, zu Java-API-Methoden aus der Geschäftslogik. Sie nimmt Requests entgegen, validiert Eingaben, verwaltet die Benutzer-Session (HTTP-Session), bereitet Entitäten aus der Geschäftslogik auf (Formatierung, Gruppierung, Sortierung, etc.) und kann Caching enthalten.; Innerhalb der Schichten werden bestimmte Entwurfsmuster verwendet. Eine Auflistung aller Muster, sowie ein Überblick über die Schichten und der Interaktion der Muster findet ihr in Kapitel 12 (Entwurfsmuster).
Public-Key-Verschlüsselung: (englisch: asymmetric encryption bzw. public key encryption); Asymmetrische oder Public-Key-Verschlüsselung ist eine Art von bidirektionaler Verschlüsselung, bei der die Schlüssel zum Ver- und Entschlüsseln unterschiedlich sind, so dass zum Schlüsseltausch zu keinem Zeitpunkt ein geheimer Kanal zwischen Sender und Empfänger existieren muss.; RSA ist ein asymmetrisches Verfahren.; Das Gegenteil der asymmetrischen Verschlüsselung ist die symmetrische Verschlüsselung. Mehr zum Thema Verschlüsselung findet ihr in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Publizieren: (englisch: publish); Bei der Publikation wird in einer typisierten Entität (z. B. Produkt oder Kategorie) eingestellt, dass die neueste Vorschauversion auch produktiv sein soll. Es können auch mehrere Entitäten oder der gesamte Produktkatalog publiziert werden.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
Quartz: Quartz ist eine sehr flexible Scheduling-Komponente, mit der Jobs automatisiert gestartet werden können. Sie unterstützt eine Notation ähnlich dem Linux-Befehl cron, sowie die Wiederaufnahme verpasster Jobs bei Server-Stopps oder Überlastung, da optional eine Datenbank konfiguriert werden kann.; Die Homepage von Quartz: http://www.opensymphony.com/quartz/; Eine alternative Lösung für einfache Fälle stellen Timer dar.; Mehr zum Thema Quartz, und wie ihr damit Manager-Methoden aufruft, findet ihr in Abschnitt 10.4 (Timer und Quartz).
Rechnungsadresse: (englisch: billing address); Die Adresse, die für die Rechnungsstellung zu verwenden ist. Sowohl Kunden, als auch Bestellungen besitzen eine Rechnungsadresse, da diese bei einer Bestellung abweichen kann bzw. bei Adressänderungen die in alten Bestellungen verwendete Adresse archiviert bleiben muss.; Mehr zu diesem Thema findet ihr in Abschnitt 5.2.1 (Benutzer).
Recht: (englisch: permission); Ein Recht definiert eine für eine Rolle eines Redakteurs (bzw. Administrators) zulässige Operation.; Neben Rechte zum Anlegen, Bearbeiten, Löschen und Ansehen von Kundendaten, Bestellungen, Redakteuren etc. werden die Rechte für allem in der Typisierung, also bei Produkten, Kategorien und anderen typisierten Entitäten eingesetzt. Diese sogenannten typisierten Rechte werden auf Typebene eingestellt.; Mehr zu Rollen und Rechten findet ihr in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Redakteur: (englisch: editor); Ein Redakteur hat Zugang zu der Administrationsoberfläche des Commerce-Frameworks. Je nach zugeteilten Rechten kann er Produkte pflegen, Mandanten und Sprachen anlegen, Typen definieren, Redakteure verwalten und Einstellungen vornehmen.; Mehr zu diesem Thema findet ihr in Abschnitt 5.2 (Benutzerverwaltung).
Relationsattribut: (englisch: relation); Ein Attributtyp, bei dem andere Produkte referenziert werden. Zu den Relationen zählen die Assoziation und die Komposition.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Request-Handling-Action (RH-Action): Request-Handling-Actions (RH-Actions) haben die Aufgabe, die Anfrage eines Browsers (Request) entgegenzunehmen. Sie validieren die Formulardaten und führen die Operation aus, die der Benutzer gewünscht hat. Sie übersetzen also den Request in einen Java-API-Aufruf der Geschäftslogik. Anschließend wird zu einer View-Preparing-Action (VP-Action) weitergeleitet, die die nächste Seite anzeigen soll.; RHActions werden in der Regel mit Submit-Buttons oder Links verbunden, die eine Operation ausführen (z.B. Hinzufügen oder Löschen im Warenkorb), während VP-Actions mit einer Seite assoziiert werden (z.B. Anzeigen des Warenkorbs). Es kann daher mehrere RH-Actions pro Seite geben (in der Regel aber nur maximal eine pro Form), jedoch gibt es typischerweise nur eine VP-Action für diese Seite.; Der einfachste Weg, RH-Actions zu verwenden, ist mit Hilfe von Abschnitt 6.2 (Struts on Rails).; Weitere Informationen zu Präsentationsmustern findet ihr in Abschnitt 12.1 (Präsentationsmuster).
Rewrite-Engine: Die Rewrite-Engine ist eine Komponente des Commerce-Frameworks, mit der technische URLs wie '/mobile/MobileDetailsVPAction.do?manufacturer=Nokia&mobile=3210' automatisch und mit minimalem Konfigurationsaufwand (Rewrite-Rules) in leicht lesbare und von Suchmaschinen wie Google hoch bewertete URLs (z.B. '/mobile/Nokia/3210') konvertiert und zurückkonvertiert werden.; Aus Sicht der Anwendung tauchen nur technische, aus Sicht eines Browsers bzw. einer Suchmaschine nur gut lesbare URLs auf. Um dies zu bewerkstelligen, kommt eine Tag-Library und ein HTTP-Filter zum Einsatz. Durch die Rewrite-Engine kann auch in bereits umgesetzten Projekten Suchmaschinenoptimierung betrieben werden.; Mehr zu diesem Thema findet ihr in Abschnitt 6.7 (Rewrite-Engine). Zusätzlich kann es interessant sein, den Search-Bot-Filter einzusetzen.
Rewrite-Rule: Eine Rewrite-Rule definiert für die Rewrite-Engine, auf welche Art technische URLs in gut lesbar und von Suchmaschinen hoch bewertete URLs umgewandelt werden sollen, und umgekehrt.; Mehr zu diesem Thema findet ihr in Abschnitt 6.7 (Rewrite-Engine).
Rolle: (englisch: role); Eine Rolle fasst eine Teilmenge aller möglichen Rechte für Redakteure zusammen und gestattet dadurch, leicht Redakteure zu einer Rolle hinzuzufügen und ihnen damit mehrere verwandte Rechte gemeinsam zuzuweisen, ohne die Rechte selbst editieren zu müssen (z. B. Eintritt eines neuen Redakteurs in die entsprechende Firma).; Mehr zu diesem Thema findet ihr in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
RuntimeException: Eine der drei typischen Exception-Superklasse in S2I-Java-Projekten.; Eine RuntimeException muss in der Methoden, in der sie auftritt, weder deklariert, noch behandelt werden. Sie dient daher Problemen, mit denen der Programmierer nicht rechnen muss, wie beispielsweise Programmierfehlern.; Mehr zum Thema Exception-Handling findet ihr in Abschnitt 11.1.8 (Exception-Handling).
Scheduling: Mit Scheduling bezeichnet man die Technik, Jobs zu automatisieren, indem eine Scheduling-Komponente wie Quartz oder Timer die Anwendung, z.B. einen Manager in regelmäßigen Abständen oder zu bestimmten Zeitpunkten aufruft.; Weitere Funktionen eines Schedulings können Cluster-Fähigkeit mit Persistenz, Thread-Pooling und Reporting und sein.; Mehr zum Thema Scheduling findet ihr in Abschnitt 10.4 (Timer und Quartz).
Schwache Typisierung: (englisch: weak typing); Beschreibt den Umstand, dass die fachlichen (für das Kundenprojekt definierten) Produkt- und Kategorietypen als abstrakte Beschreibung in der Datenbank persistiert sind und darüber zur Runtime Validitätschecks durchgeführt werden können. Die Java-API und das Datenbankschema sind jedoch abstrakt. Schwache Typisierung kommt beim Commerce-Framework nicht zum Einsatz, da dieser Ansatz fehleranfälliger ist.; Gegenteil: starke Typisierung; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Search-Bot-Filter: Suchmaschinen erkennen oftmals die Java-Session-ID nicht als zu ignorierenden Parameter, sondern als Teil der URL. Da die erste Seite jeder Session auch bei eingeschalteten Cookies Session-IDs enthält, werden auf diese Weise viele fachlich identische Seiten als eigenständige Seiten in den Suchindex aufgenommen. Hierdurch verschlechtert sich das Ranking enorm.; Um diesem Problem entgegenzuwirken, kann der Search-Bot-Filter des Commerce-Frameworks in die Web-Applikation eingefügt werden. Er sorgt auf der anderen Seite dafür, dass keine Session-IDs indiziert werden, da dies zu massivem Doppellisting von Seiten und damit zu schlechten Rankings führt. Außerdem signalisiert der Filter dem Search-Bot, bereits vorhandene Session-ID-Listings wieder zu entfernen.; Mehr zu diesem Thema findet ihr in Abschnitt 6.6 (Search-Bot-Filter). Zusätzlich kann es interessant sein, die Rewrite-Engine einzusetzen.
Seite: (englisch: page); Eine Seite stellt einen Teil des Formularprozesses dar, der von dem Benutzer auf einmal bearbeitet werden kann. Seiten können nur betreten werden, wenn der Navigator dies zulässt.; Ein Prozess besteht aus mehreren Seiten, diese wiederum aus Modulen. Innerhalb des gesamten Prozesses sind sowohl Seiten-, als auch Modulnamen eindeutig.; Weitere Informationen über Formularprozesse findet ihr in Abschnitt 6.1 (Formularprozesse).
Server: In diesem Dokument wird der Begriff Host für eine physische Maschine, der Begriff Server jedoch für die auf einem Host betriebene Software (z.B. Apache HTTPD oder Tomcat) verwendet. Diese Begriffe sind nicht zu verwechseln mit den Apache-Virtual-Hosts, welche durch den Apache HTTPD betriebene Anwendungen beschreiben.; Mehr zu diesem Thema findet ihr in Abschnitt 10.5 (Distribution).
Servlet-Container: Ein Servlet-Container ist der Teil eines Applikations-Servers, welcher Servlets verwaltet, HTTP-Requests entgegennimmt und HTTP-Responses an den Browser sendet.; Der Tomcat ist ein Beispiel für einen Applikations-Server, der nur einen Servlet-Container bereitstellt.; Mehr zu diesem Thema findet ihr in Abschnitt 10.5 (Distribution).
Session-Hijacking: Unter Session-Hijacking versteht man den (unerlaubten) Vorgang, z.B. durch Abhören der Request-Response-Kommunikation die Session-ID eines anderen Benutzers zu erlangen und sich dadurch als dieser Benutzer auszugeben. Hierdurch ist es möglich, auf Daten dieses Benutzers zuzugegreifen bzw. in seinem Namen Handlungen durchzuführen.; Wie sich Session-Hijacking verhindern lässt, findet ihr in Abschnitt 13.1.2 (Session-Hijacking).
Singleton-Typ: (englisch: singleton type); Singleton-Typen sind eine spezielle Art der Entitätstypen. Sie werden wie Entitätstypen in der src/main/resources/conf/framework/entity-types.xml deklartiert und über den Entitätsgenerator erzeugt, und sie leiten auch von TypedEntity direkt ab.; Allerdings sorgt das Commerce-Framework bei Singleton-Typen dafür, dass stets nur eine Instanz dieser Klasse persistent ist. Diese Datenbank-Row wird beim Start der Anwendung angelegt, wenn sie noch nicht exisitert. Ein statischer Getter in der Klasse hilft, die eine Instanz zu laden. Sie kann wie jede andere Entität modifiziert und gespeichert werden.; Mehr zu Singleton-Typen findet ihr in Abschnitt 5.1.9 (Singleton-Typen und Auto-Instanzen).
SOAP-Schnittstellen: (englisch: SOAP interfaces); Das Commerce-Framework bietet SOAP-Schnittstellen zum Zugriff auf die Produkt-, Bestell- und Benutzerverwaltung, sowie auf den Mailversand an, wodurch Drittsysteme leicht integriert werden können.; Mehr zu den SOAP-Schnittstellen des Frameworks findet ihr in Abschnitt 7.4 (SOAP-Schnittstellen), mehr zu der Administrationsoberfläche in Kapitel 8 (Administration).
Source-Distribution: Eine Source-Distribution ist eine Distribution, in der lediglich die Quellen einer bestimmten Version der Anwendung enthalten sind.; Source-Distributionen können von dem Kunden selbständig gebuildet werden und erlauben ihm so eine größere Transparenz bei auf der anderen Seite größerem Aufwand und notwendigem technischen Verständnis.; Binary-Distributionen stehen hierzu im Gegensatz, da sie bereits gebuildet sind.; Weitere Informationen zum Thema Build, Distribution und Deployment findet ihr in Abschnitt 10.5 (Distribution).
Sprache: (englisch: language); Ein Kriterium, nach dem die Produktattribute und Web-Ressourcen spezialisiert werden können. Die ausgewählte Sprache wird in der Session verwaltet.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.8 (Mandanten und Sprachen).
Spring-Bean: Eine Spring-Bean ist eine JavaBeans-konforme Instanz, welche über eine entsprechende Konfiguration dem SpringFramework bekannt gemacht worden ist. Spring-Beans werden niemals von der Anwendung instanziiert, da Spring ansonsten kein AOP hinzufügen kann.
SpringFramework: Ein AOP-fähiger Container zur Integration von Komponenten über Konfigurationsdateien.; Aspektorientierte Programmierung (AOP) schafft eine Trennung orthogonaler Konzepte, welche mit rein objektorientierten Mitteln sich zuvor nicht trennen ließen. Vor allem für Transaktionssteuerung und Datenbankverbindungen bieten sich AOP-Interceptors an. AOP wird im Commerce-Framework durch das SpringFramework realisiert, welches gut mit Hibernate integriert.; Die Homepage vom SpringFrameworks: http://www.springframework.org/; Informationen zu Problemen bei der Verwendung von AOP mit dem SpringFramework findet ihr in Abschnitt 13.3.2 (AOP-Probleme).
sslext: sslext ist eine Erweiterung zu Struts, mit dessen Hilfe HTTP-/HTTPS-Übergänge transparent und nur durch Konfiguration realisiert werden können.; sslext ist in der Projektvorlage bereits enthalten.
Stage-Umgebung: (englisch: stage environment); Die Stage-Umgebung ist eine Umgebung, auf der der Kunde testen kann, ob die von ihm gewünschten Funktionen fehlerfrei und wunschgemäß umgesetzt worden sind. Nach der Definition einer Version und der Qualitätssicherung auf der Test-Umgebung wird die freigegebene Version auf diese Stage-Umgebung deployt, und der Kunden wird um entsprechende Freigabe gebeten.; Weitere Informationen zu Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Standardpreis: (englisch: default price); Ein Attribut jedes Produkts, in dem ein Preis gespeichert werden kann. Für eine einfache Preisbereichnung ohne Staffelung etc. kann die Standardpreisfabrik verwendet werden, welche auf diese Eigenschaft zugreift. Durch diesen Mechanismus ist sowohl eine sehr einfache, als auch eine komplexe Preisfindung möglich.; Mehr zu diesen Thema findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Standardpreisfabrik: (englisch: default price factory); Eine Preisfabrik, die nur auf den Standardpreis des Produkts zurückgreift und linear summiert (keine Staffelung etc.). Dadurch ist eine sehr einfache Preisfindung möglich.; Die Standardpreisfabrik ist in der Projektvorlage bereits als Hauptpreisfabrik konfiguriert.; Mehr zu diesen Thema findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Starke Typisierung: (englisch: strong typing); Beschreibt den Umstand, dass die fachlichen (für das Kundenprojekt definierten) Produkt- und Kategorietypen mit Hilfe des Generators zur Development-Time in echte Java- und Datenbanktypen generiert werden. Zudem werden Validitätschecks zur Runtime durchgeführt.; Gegenteil: schwache Typisierung.; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Steuersatz: (englisch: tax rate); Ein Steuersatz definiert den prozentualen Aufschlag auf den Nettobetrag, um den Bruttobetrag zu errechnen. Bei Bestellungen werden Steuersatz und Bruttobetrag eingefroren, damit bei Preis- oder Steueränderungen in alten Bestellungen alte Werte verzeichnet bleiben.; Mehr zum Thema Geldbeträge findet ihr in Abschnitt 5.1.13 (Preisberechnung), mehr zum Thema Bestellungen in Abschnitt 5.3 (Bestellungsverwaltung).
Struts: Ein Open-Source-Framework für Servlet/JSP-Anwendungen, welches auf dem Model-View-Controller (MVC) Design-Paradigma basiert.; Es ist ein De-facto-Standard für JSP-Webanwendungen und bietet die Dienste Formular-Population, Formular-Validierung und Aktionssteuerung, sowie Taglibs für das Rendern der JSPs an.; Die Homepage von Struts: http://struts.apache.org/
Struts on Rails: Die zentralen Leitsprüche von Ruby on Rails sind "Convention over configuration" und "Don't repeat yourself". Es wird also angestrebt, wiederkehrende technische Aufgaben und Muster so weit wie möglich nicht immer wieder umsetzen oder konfigurieren zu müssen, sondern anstattdessen lieber eine vereinheitlichende Konvention zu finden, die dann generisch umgesetzt wird, so dass man sich auf die reinen fachlichen Anforderungen konzentieren kann.; Struts on Rails ist eine Erweiterung für Struts, die dasselbe Ziel verfolgt und beispielsweise hilft, auf die redundante Struts-Konfiguration vollständig verzichten zu können, und dabei noch zudem weniger Code in den Actions und Forms realisieren zu müssen.; Weitere Informationen zu Struts on Rails findet ihr in Abschnitt 6.2 (Struts on Rails).
Subtyp: (englisch: sub type); Ein Entitätstyp, der von einem anderen Typen, einem Supertypen, erbt.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Suchmaschinenoptimierung (SEO): (englisch: search engine optimization); Suchmaschinen wie Google bewerten technische URLs wie '/mobile/MobileDetailsVPAction.do?manufacturer=Nokia&mobile=3210' schlechter, da sie davon ausgehen, dass die Seite von dem Benutzerverhalten abhängt. Daher ist es sinnvoll, dass trotz einer Struts-Action und/oder einer JSP die URL möglichst gut lesbar und nicht technisch erscheint (z.B. '/mobile/Nokia/3210').; Die Rewrite-Engine des Commerce-Frameworks löst dieses Problem mit minimalem Konfigurationsaufwand und nahezu komplett transparent für die Anwendung, den Browser und Suchmaschinen. Aus Sicht der Anwendung tauchen nur technische, aus Sicht eines Browsers bzw. einer Suchmaschine nur gut lesbare URLs auf. Um dies zu bewerkstelligen, kommt eine Tag-Library und ein HTTP-Filter zum Einsatz.; Der Search-Bot-Filter sorgt auf der anderen Seite dafür, dass keine Session-IDs indiziert werden, da dies zu massivem Doppellisting von Seiten und damit zu schlechten Rankings führt. Außerdem signalisiert der Filter dem Search-Bot, bereits vorhandene Session-ID-Listings wieder zu entfernen.; Mehr zu diesem Thema findet ihr in Abschnitt 6.7 (Rewrite-Engine) und Abschnitt 6.6 (Search-Bot-Filter).
Supertyp: (englisch: super type); Ein Entitätstyp, von dem ein anderer Typ, ein Subtyp, erbt.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Symmetrische Verschlüsselung: (englisch: symmetric encryption); Symmetrische Verschlüsselung ist eine Art von bidirektionaler Verschlüsselung, bei der die Schlüssel zum Ver- und Entschlüsseln identisch sind.; Das Commerce-Framework verwendet symmetrische Verschlüsselung zum Speichern von Zahlungsweisen.; Das Gegenteil der symmetrischen Verschlüsselung ist die asymmetrische Verschlüsselung. Mehr zum Thema Verschlüsselung findet ihr in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Systemkategorie: (englisch: system category); Eine nur in der Administrationsoberfläche dargestellte Kategorie, die die Produkte nach semantischen Aspekten gruppiert. Systemkategorien können nicht editiert werden. Zu den Systemkategorien gehören z. B. "alle Produkte", "fehlerhafte Produkte", aber auch der Wurzelknoten der Benutzerkategorien ("Kategorien").; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.2 (Produkte und Kategorien).
szzadm: Der Administrator (szzadm) ist eine Rolle im Rahmen der Distribution über das One-Click-Deployment. Er ist für die Wartung der Host-Hardware, sowie für die Installation und Pflege der Software unabhängig von der gehosteten Anwendung verantwortlich (z.B. Installation des Betriebssystems und des Tomcats, Anlegen von Benutzern, etc.).; Mehr zum Thema One-Click-Deployment findet ihr in Abschnitt 10.5.3 (One-Click-Deployment).
szzdep: Der Deployer (szzdep) ist eine Rolle im Rahmen der Distribution über das One-Click-Deployment. Er startet das Deployment-Skript für eine Version auf einer Umgebung, wodurch diese Version auf alle Web- und Applikations-Hosts verteilt und aktiviert wird (Deployment).; Mehr zum Thema One-Click-Deployment findet ihr in Abschnitt 10.5.3 (One-Click-Deployment).
szzdev: Der Entwickler (szzdev) ist eine Rolle im Rahmen der Distribution über das One-Click-Deployment. Er hat die Aufgabe, eine Version zu erstellen und auf den Distributions-Host zu kopieren (Upload). Wenn er nicht zusätzlich die Rolle Deployer besitzt, kann er diese Version jedoch nicht auf Web- und Applikations-Hosts verteilen und deployen.; Mehr zum Thema One-Click-Deployment findet ihr in Abschnitt 10.5.3 (One-Click-Deployment).
Tag-Library: Das Commerce-Framework enthält eine Tag-Library (Funktionen und Tags), um u.a. auf Action-Messages vereinfacht zugreifen zu können, um Rollen und Rechte von Benutzern abzufragen bzw. zu fordern, und um Exceptions geeignet versteckt in Fehlerseiten unterzubringen. Auch eine Rewrite-Engine zur Suchmaschinenoptimierung wird hierüber realisiert.; Mehr zu diesem Thema findet ihr in Abschnitt 6.4 (Tag-Library).
TechnicalException: Eine der drei typischen Exception-Superklasse in S2I-Java-Projekten.; Eine TechnicalException sollte immer dann geworfen werden, wenn die Operation z.B. aufgrund eines Fehlers in einem Drittsystem oder in einem Geräts des Applikations-Hosts nicht ausgeführt werden kann. TechnicalExceptions sind Probleme, mit denen der Aufrufer rechnen muss, die aber nicht direkt von einem Menschen, sondern einer Maschine verursacht worden sind.; Mehr zum Thema Exception-Handling findet ihr in Abschnitt 11.1.8 (Exception-Handling).
Test-Umgebung: (englisch: test environment); Die Test-Umgebung ist eine Umgebung, die zur Qualitätssicherung einer Version dient. Nach der Definition einer Version wird die QS beauftragt, die in der Versionshistorie verzeichneten Änderungen zu testen und ggf. auch einen allgemeinen Funktions- oder Performanztest durchzuführen.; Weitere Informationen zu Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Textattribut: (englisch: text attribute); Ein primitiver Attributtyp für beliebige Texte (Strings).; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Textlistenattribut: (englisch: text list attribute); Ein primitiver Attributtyp für Listen beliebiger Texte (Strings).; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Timer: Der Timer ist eine einfache, in Java bereits enthaltene Scheduling-Komponente, mit der Jobs automatisiert gestartet werden können. Sie unterstützt lediglich feste zeitliche Abstände zwischen Ausführungen, ist jedoch auf der anderen Seite leicht konfigurierbar.; Eine flexiblere Lösung stellt Quartz dar.; Mehr zum Thema Timer, und wie ihr damit Manager-Methoden aufruft, findet ihr in Abschnitt 10.4 (Timer und Quartz).
Tomcat: Tomcat ist die Referenz-Implementierung eines J2EE-konformen Servlet-Container. Tomcat ist Open-Source.; In einem typischen S2I-Java-Web-Projekt ist der Tomcat die bevorzugte Wahl, da unter Verwendung der in der Projektvorlage enthaltenen Technologien ein EJB-Container, wie er im Tomcat nicht enthalten sich, gar nicht notwendig ist.; Die Homepage vom Tomcat: http://jakarta.apache.org/tomcat/
Typisierte Entität: (englisch: typed entity); Oberbegriff für alle Entitäten, die durch einen Typ spezifiziert werden. Hierzu zählen u.a. Produkte und Kategorien. Typisierte Entitäten besitzen starke Typisierung.; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Typisiertes Recht: (englisch: type permission); Ein typisiertes Recht ist ein spezielles Recht, welches eine für eine Rolle eines Redakteurs (bzw. Administrators) zulässige Operation auf einer typisierten Entität, z.B. einem Produkt oder einer Kategorie definiert.; Mehr zu Rollen und Rechten findet ihr in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Typisierung: (englisch: typing); Die Typisierung ist eine Komponente der Produktverwaltung, welche über eine einfache Konfiguration ermöglicht, Entitäten und dazugehörige Hibernate-Mapping-Files zu erzeugen, sowie automatisch typspezifische Formulare in der Produktadministration anzubieten.; Die Typisierung kann desweiteren reflektiv verwendet werden, d.h. es ist möglich, die Attribute eines Entitätstyps auszulesen.; Mehr zur Typisierung findet ihr in Abschnitt 5.1.1 (Typisierung).
Umgebung: (englisch: environment); Eine Umgebung ist die Gesamtheit aller Hosts (Distributions-Host, Web-Hosts, Applikations-Hosts, Datenbank-Hosts, etc.), die einem gemeinsamen Zweck dienen, z.B. zum Testen seitens des Kunden oder als Produktivumgebung.; Der Projekt-Wizard erzeugt aus der Projektvorlage, sofern keine Anpassungen vorgenommen worden sind, die Umgebungen Development, Test, Stage und Live.; Zur Einsparung von Ressourcen ist es technisch möglich und unter gewissen Umständen sinnvoll, Hosts und Server in verschiedenen Umgebungen wiederzuverwenden.; Weitere Informationen zu Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Unidirektionale Verschlüsselung: (englisch: unidirectional encryption bzw. hashing); Unidirektionale Verschlüsselung bzw. Hashing ist ein Verfahren, bei dem das Klarwort mit einer mathematischen Funktion auf einen Zahlenwert (Hashwert) aus einem kleineren Raum verdichtet wird.; Da bei der unidirektionalen Verschlüsselung Information verlorengeht und aufgrund der Beschaffenheit der Funktion, ist es nicht möglich, das Klarwort aus dem Hashwert zu errechnen. Die Funktion ist außerdem derart gewählt, dass es ohne Kenntnis des ursprünglichen Klarwortes schwer ist, ein Klarwort zu finden, welches auf diesen Hashwert reduziert werden kann.; Das Commerce-Framework verwendet unidirektionale Verschlüsselung zum Speichern von Passwörtern. Zur Überprüfung erfolgt erneut die Verschlüsselung der Eingabe, und ein Vergleich der Hashwerte.; Das Gegenteil der unidirektionalen Verschlüsselung ist die bidirektionale Verschlüsselung. Mehr zum Thema Verschlüsselung findet ihr in Abschnitt 5.2.2 (Authentifizierung und Autorisierung).
Unterwährungseinheit: (englisch: fraction currency unit); Innerhalb einer Währung ist die Untereinheit die Einheit mit jeweils kleinerem Wert, z. B. Cent zum Euro oder Pfennig zur Mark.; Gegenteil: Hauptwährungseinheit; Mehr zum Thema Preisberechnung findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Upload (Distribution): In der Distribution bezeichnet man den Vorgang, eine Version von dem Entwickler-Host auf den Distributions-Host zu kopieren, als Upload. Dies geschieht bei einem Hosting durch SinnerSchrader Betrieb (S2B) durch die Entwickler-Rolle (szzdev).; Von dem Distributions-Host kann die Version anschließend von der Deployer-Rolle (bei S2B szzdep) auf alle Web- und Applikations-Hosts deployt werden.; Weitere Informationen zum Thema Build, Distribution und Deployment findet ihr in Abschnitt 10.5 (Distribution).
Validierungsfehler: (englisch: validity problem); Ein Fehler beim Validieren einer typisierten Entität, aufgrund dessen sich die Entität zwar noch speichern lässt (z.B. ein zu kurzes Feld oder ein verletzter regulärer Ausdruck). Fehlerhafte Produkte werden beispielsweise im Shop nicht angeboten.; Bei der Validierung wird unterschieden zwischen Persistenzfehlern und Validierungsfehlern.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
Value-Bean: Value-Beans sind Kapseln mehrerer zusammenhängender Daten, die durch eine JSP präsentiert werden sollen, beispielsweise alle bereits formatierten Eigenschaften eines Produkts.; Value-Beans werden oftmals in Listen oder andere Value-Beans aggregiert. Sie werden typischerweise durch Value-Bean-Filler erzeugt, der die für die Bean z.B. aus einem Model liest, welches über einen Manager von der Geschäftslogik bereitgestellt wurde.; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 12.1 (Präsentationsmuster).
Value-Bean-Filler: Value-Bean-Filler sind meist zustandslose Klasse, die aus Models Value-Beans erzeugen.; Die Models sollten nicht direkt in die JSP reingereicht werden, da es ansonsten zu einer unvollständigen Trennung von Präsentation und Geschäftslogik kommt und dadurch use-case-abhängige Formatierungen in die Geschäftslogik gelegt werden. Außerdem ist es möglich, dass die JSP aufgrund von verzögerten DB-Zugriffen und Exceptions bei Transformationen mit einer nur zum Teil dargestellten Seite abbricht.; Value-Bean-Filler sind mit Form-Fillern verwandt, welche sich entsprechend um Struts-Form kümmern.; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 12.1 (Präsentationsmuster).
Velocity: Velocity ist eine vom Anwendungsfall unabhängige Open-Source-Template-Engine, mit der u.a. das Commerce-Framework Mail-Templates dynamisiert und die auch von dem Projekt-Wizard verwendet wird.; Die Homepage von Velocity: http://velocity.apache.org/; Mehr zur Projektvorlage und dem Projekt-Wizard findet ihr in Kapitel 10 (Projektvorlage).
Vererbung: (englisch: inheritance); Wenn ein Subtyp von einem Supertyp erbt, übernimmt er alle Attribute des Supertyps und ermöglicht Relationen, die auf einen Typ festgelegt sind, auch die entsprechenden Subtypen zu akzeptieren.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Versandkosten: (englisch: shipping cost); Versandkosten sind in einer Bestellung speziell ausgewiesene Kosten, die aufgrund der bevorstehenden Lieferaufwände entstehen. Im Commerce-Framework werden sie in einer Versandkostenbestellposition persistiert.; Mehr zum diesem Thema findet ihr in Abschnitt 5.3.1 (Bestellungen) und Abschnitt 5.3.5 (Lieferungen).
Versandkostenbestellposition: (englisch: shipping cost order entry); Eine Bestellposition in einer Bestellung, die Versandkosten repräsentiert.; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.1 (Bestellungen).
Version (Distribution): Eine Version ist ein in sich geschlossener Gesamtstand der Anwendung. Typischerweise wird zu einem bestimmten Zeitpunkt der zu diesem Zeitpunkt im Repository befindliche Stand (Revisionen) aller Dateien mit einem Repository-Tag versehen, um diesen Stand einzufrieren. Kommt es zum parallelen Erstellen bzw. Pflegen mehrerer Versionen, ist zudem ein Branching notwendig.; Durch eine Version ist es möglich, denselben Stand zunächst intern durch die Qualitätssicherung zu testen (Test-Umgebung), um ihn anschließend auf die Stage-Umgebung dem Kunden bereitzustellen und nach Abnahme auf die Live-Umgebung zu deployen.; Versionen werden mit einem Versionsnummern-Schema markiert, z.B. 2.13.4.; Mehr zum Thema Versionen findet ihr in Abschnitt 10.5.2 (Versionsplanung).
Version (Entität): (englisch: versioned entity); Eine Version ist eine zusätzliche Property einer sogenannten versionierten Entität, um optimistisches Locking über Hibernate zu realisieren. Dadurch ist es nicht mehr möglich, dass zwei Lese-Schreib-Zyklen zu Datenverlust führen. Der zweite Schreiber erhält eine entsprechende Exception (eine StaleObjectStateException) und die Anwendung kann den Benutzer auffordern, den Datensatz noch einmal zu bearbeiten.; Mehr zum Thema Entitäten findet ihr in Abschnitt 4.1 (Entitäten).
Versionierte Entität: (englisch: versioned entity); Versionierte Entitäten sind Entitäten, die zusätzlich eine version-Property enthalten, um optimistisches Locking über Hibernate zu realisieren. Dadurch ist es nicht mehr möglich, dass zwei Lese-Schreib-Zyklen zu Datenverlust führen. Der zweite Schreiber erhält eine entsprechende Exception (eine StaleObjectStateException) und die Anwendung kann den Benutzer auffordern, den Datensatz noch einmal zu bearbeiten.; Mehr zum Thema Entitäten findet ihr in Abschnitt 4.1 (Entitäten).
Versionshistorie: (englisch: version history); Die Versionshistorie ist eine automatisch von den Ant-Targets der Projektvorlage erzeugte Textdatei, in der alle Änderungen und Versionen verzeichnet sind.; Mehr zur Versionsplanung findet ihr in Abschnitt 10.5.2 (Versionsplanung).
Versionsnummer: Um eine Version zu benennen und sie mit den anderen Versionen in Bezug setzen zu können, erhält eine Version eine Nummer. Diese Versionsnummer besteht aus drei Teilen, major.minor.build, z.B. 1.4.13. Die Nummern werden entsprechend der Wichtigkeit der Änderung erhöht.; Versionsnummern müssen nicht in einer strengen zeitlichen Reihenfolge verlaufen. Dies ist vor allem dann nicht der Fall, wenn ein Bugfix auf einer Live-Version (z.B. 1.3.13 auf 1.3.14) umgesetzt wird, während eine neuere Version (z.B. 1.4.0) noch in der Entwicklung bzw. im Test ist.; Mehr Informationen zum Thema Versionsplanung findet ihr in Abschnitt 10.5.2 (Versionsplanung).
Versionsplanung: Bei der Versionsplanung wird entschieden, zu welchem Zeitpunkt eine Version auf dem Repository der Anwendung definiert werden soll, welche Versionsnummer sie bekommt und wann diese Version auf welche Umgebung deployt wird.; Die Projektvorlage unterstützt die Versionsplanung, indem sie Ant-Targets zum Dokumentieren (comment-version), zum Erstellen (create-version) und zum Distributieren bzw. Deployen (dist und deploy) anbietet. Bei Erfolg wird zudem eine entsprechend E-Mail an eine definierte Verteilerliste geschickt, in der unter anderem die Versionshistorie enthalten ist.; Mehr Informationen zum Thema Versionsplanung findet ihr in Abschnitt 10.5.2 (Versionsplanung).
Verwerfen: (englisch: rollback); Beim Verwerfen wird in einer typisierten Entität (z. B. Produkt oder Kategorie) eingestellt, dass die produktive Version auch in der Vorschau angezeigt werden sein soll, wodurch nicht-produktive Änderungen verworfen werden. Es können auch mehrere Entitäten oder der gesamte Produktkatalog verworfen werden.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
View-Preparing-Action (VP-Action): View-Preparing-Actions (VP-Actions) haben die Aufgabe, eine einzelne Seite zur Darstellung vorzubereiten. Sie fügen beispielsweise dynamische Texte oder mögliche Selector-Optionen zum Request hinzu, stellen ein Produkt dar oder bereiten ein Menü vor. Sie nehmen vor allem keine Formulardaten entgegen oder validieren diese. Hierfür sind Request-Handling-Actions (RH-Actions) zuständig.; VP-Actions werden in der Regel mit einer Seite verbunden (z.B. Anzeigen des Warenkorbs), während RH-Actions mit Submit-Buttons oder Links assoziiert werden, die eine Operation ausführen (z.B. Hinzufügen oder Löschen im Warenkorb). Es kann daher mehrere RH-Actions pro Seite geben (in der Regel aber nur maximal eine pro Form), jedoch gibt es typischerweise nur eine VP-Action für diese Seite.; Der einfachste Weg, VPActions zu verwenden, ist mit Hilfe von Abschnitt 6.2 (Struts on Rails).; Eine detailliertere Beschreibung von RH- und VP-Actions findet ihr in Abschnitt 12.1 (Präsentationsmuster).
Vorschau: (englisch: preview); Ein Zugang zu dem Shop, in dem von jeder typisierten Entität (z. B. Produkt oder Kategorie) die jeweilige Vorschauversion verwendet wird. Dies ist nützlich, um vor einer Publikation sicherzustellen, dass das gewünschte Ergebnis erzielt wurde.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
Vorschaufähig: (englisch: stageable); Vorschaufähige Attribute speichern zwei Versionen ihres Wertes, die Vorschauversion und die Produktivversion. Beim Publizieren wird die Vorschau- in die Produktivversion kopiert, beim Verwerfen umgekehrt.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
Vorschauversion: (englisch: preview version); Eine spezielle Version einer typisierten Entität (z. B. Produkt oder Kategorie). Diese Version wird in der Vorschau verwendet.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
Wahrheitswertattribut: (englisch: boolean attribute); Ein primitiver Attributtyp, bei dem "ja" oder "nein" ausgewählt wird.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Warenkorb: (englisch: cart); Ein in der HTTP-Session gespeichertes Objekt, in dem ein Kunde Produkte sammelt, bevor der eine Bestellung auslöst. Warenkörbe referenzieren nicht nur Produktdaten, sondern enthalten weitere Informationen, in denen der Kauf oder die Produkte spezialisiert bzw. eingestellt werden.; Mehr zu diesem Thema findet ihr in Abschnitt 6.8 (Warenkorb).
Web-Host: Der Web-Host ist ein Host, also eine physische Maschine, auf der ein Web-Server (z.B. Apache HTTPD) betrieben wird. In einer Umgebung können mehrere Web-Hosts existieren.; In diesem Dokument wird der Begriff Host für eine physische Maschine, der Begriff Server jedoch für die auf einem Host betriebene Software (z.B. Apache HTTPD oder Tomcat) verwendet. Diese Begriffe sind nicht zu verwechseln mit den Apache-Virtual-Hosts, welche durch den Apache HTTPD betriebene Anwendungen beschreiben.; Weitere Informationen zum allgemeinen Setup von Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Web-Server: Ein Web-Server ist ein Programm, welches statische Inhalte effizient an Clients (z.B. Browser) ausliefern kann, z.B. Apache HTTPD. Web-Server werden zudem zum Load-Balancen auf mehrere Applikations-Server verwendet.; Web-Server werden auf Web-Hosts betrieben.; In diesem Dokument wird der Begriff Host für eine physische Maschine, der Begriff Server jedoch für die auf einem Host betriebene Software (z.B. Apache HTTPD oder Tomcat) verwendet. Diese Begriffe sind nicht zu verwechseln mit den Apache-Virtual-Hosts, welche durch den Apache HTTPD betriebene Anwendungen beschreiben.; Weitere Informationen zum allgemeinen Setup von Umgebungen findet ihr in Abschnitt 10.5 (Distribution).
Wiki-Updater: Die Kapitelnavigation, die Verlinkung zwischen Abschnitten, die Druckversion und das zusammengeführte Glossar werden automatisch generiert, in dem das Tool Wiki-Updater ausgeführt wird. Es analysiert das Inhaltsverzeichnis und sortiert alle dort erwähnten Kapitel und Abschnitte anhand der Listenaufzählung.; Die Druckversion wird außerdem mit einem Deckblatt (inkl. Vorwort) und einem Abspann (inkl. Notizbögen) angereichtert.; Den Wiki-Updater ruft ihr über das Ant-Target 'update-dev-toc' im Commerce-Framework-Projekt auf.
Wirecard: Wirecard ist ein Dienstleister für die Durchführung von Zahlungen über Kreditkarte, Bankeinzug und anderen Zahlungswegen. Der Zahlungsadapter unterstützt unter anderem Authorize, Capture und Partial Capture.; Die Homepage von Bibit: http://www.wirecard.de.; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.4 (Zahlungsadapter).
WorldPay: Worldpay ist ein Dienstleister für die Durchführung von Zahlungen über Kreditkarte, Bankeinzug und anderen Zahlungswegen. Der Zahlungsadapter unterstützt unter anderem Authorize, Capture und Partial Capture.; Die Homepage von Worldpay: http://www.worldpay.de/; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.4 (Zahlungsadapter).
Wurzelkategorie: (englisch: root category); Eine vom System automatisch angelegte und nicht durch Redakteure oder den Entwickler löschbare Kategorie. Alle Kategorien sind unterhalb dieses Wurzelknotens in dem Stamm einsortiert.; Mehr Informationen zu diesem Thema findet ihr in Abschnitt 5.1.1 (Typisierung).
Währung: (englisch: currency); Definiert die Einheit für einen Geldbetrag (z. B. im Geldbetragattribut), sowie die Anzahl der Nachkommastellen. Sie zergliedert sich in Hauptwährungseinheit und Unterwährungseinheit.; Mehr zum Thema Produktverwaltung findet ihr in Abschnitt 5.1 (Produktverwaltung).
Währungsattribut: (englisch: currency attribute); Ein primitiver Attributtyp, welcher eine Währung referenziert.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Währungsumrechner: (englisch: currency converter); Ein Währungsumrechner konvertiert einen Geldbetrag von einer Währung in eine andere. Er wird benötigt, wenn beispielsweise die Preise mehrerer Produkte addiert werden müssen, wie es bei Bestellungen und bei der Standardpreisfabrik notwendig ist.; Mehr zum Thema Währungsumrechner findet ihr in Abschnitt 5.1.13 (Preisberechnung).
Zahlung: (englisch: payment); Eine Zahlung ist die Nutzung einer Zahlungsweise, z.B. in einer Bestellung. Es wird hierbei jedoch vernachlässigt, dass ggf. mehrere Zahlungsausführungen notwendig sind.; Eine Zahlungsweise beinhaltet lediglich die Zahlungsart (Kreditkarte, Nachnahme, etc.) und die entsprechend notwendigen Daten (Kontonummer, Kreditkartennummer, etc.), während eine Zahlung zusätzlich den Geldbetrag enthält, um beispielsweise ein Produkt zu bezahlen. Kommt es nun zum Geldtransfer, wird von der Zahlungsausführung gesprochen. Insbesondere beim Partial Capture können mehrere Ausführungen für eine Zahlung auftreten.; Mehr zum Thema Zahlungen findet ihr in Abschnitt 5.3.2 (Zahlungsweisen und Zahlungen).
Zahlungsadapter: (englisch: payment adapter); Der Zahlungsadapter ist eine Abstraktion zur einheitlichen Durchführung von Zahlungen über Kreditkarte, Bankeinzug und anderen Zahlungswegen, sowie zur Überprüfung der Validität von Zahlungsdaten (Bonitätsprüfung).; Der Zahlungsadapter unterstützt unter anderem Authorize, Capture und Partial Capture. Zur Zeit ist er für die Dienstleister bzw. Dienste eScore (InfoScore), Bibit, WorldPay und pago implementiert.; Mehr zu Zahlungsadaptern findet ihr Abschnitt 5.3.4 (Zahlungsadapter).
Zahlungsart: (englisch: payment type); Eine Zahlungsart definiert, auf welchem Weg der fällige Betrag von dem Kunden an den Shop-Betreiber übermittelt wird (z.B. Kreditkarte, Lastschrift, Rechnung etc.). Konkrete Zahlungsinformationen wie Kontonummer und Bankleitzahl werden in der Zahlungsweise definiert.; Eine Zahlungsweise beinhaltet lediglich die Zahlungsart (Kreditkarte, Nachnahme, etc.) und die entsprechend notwendigen Daten, während eine Zahlung zusätzlich den Geldbetrag enthält, um beispielsweise ein Produkt zu bezahlen. Kommt es nun zum Geldtransfer, wird von der Zahlungsausführung gesprochen. Insbesondere beim Partial Capture können mehrere Ausführungen für eine Zahlung auftreten.; Mehr zum Thema Zahlungen findet ihr in Abschnitt 5.3.2 (Zahlungsweisen und Zahlungen).
Zahlungsausführung: (englisch: performance); Die Zahlungsausführung ist die kleinste Einheit bei der Durchführung einer Zahlung.; Eine Zahlungsweise beinhaltet lediglich die Zahlungsart (Kreditkarte, Nachnahme, etc.) und die entsprechend notwendigen Daten, während eine Zahlung zusätzlich den Geldbetrag enthält, um beispielsweise ein Produkt zu bezahlen. Kommt es nun zum Geldtransfer, wird von der Zahlungsausführung gesprochen. Insbesondere beim Partial Capture können mehrere Ausführungen für eine Zahlung auftreten.; Mehr zum Thema Zahlungen findet ihr in Abschnitt 5.3.2 (Zahlungsweisen und Zahlungen).
Zahlungsweise: (englisch: payment method); Definiert die Informationen, die zu einer Zahlungsart wie z.B. Kreditkarte, Lastschrift, Rechnung usw. relevant sind.; Eine Zahlungsweise beinhaltet lediglich die Zahlungsart (Kreditkarte, Nachnahme, etc.) und die entsprechend notwendigen Daten, während eine Zahlung zusätzlich den Geldbetrag enthält, um beispielsweise ein Produkt zu bezahlen. Kommt es nun zum Geldtransfer, wird von der Zahlungsausführung gesprochen. Insbesondere beim Partial Capture können mehrere Ausführungen für eine Zahlung auftreten.; Mehr zum Thema Zahlungen findet ihr in Abschnitt 5.3.2 (Zahlungsweisen und Zahlungen).
Zeitzonenattribut: (englisch: time zone attribute); Ein primitiver Attributtyp, welcher eine Zeitzone referenziert.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Zuordnungsattribut: (englisch: text map attribute); Dieses Attribut gestattet es, beliebige, in dem Produkttyp nicht festgelegte Namen-Werte-Paare abzulegen. Dadurch ist es möglich, flexibel auf Produktebene Eigenschaften festzulegen, da im Gegensatz dazu Attribute für alle Produkte gleich sein müssen. Sowohl der Name, als auch der Wert wird als Textfeld eingegeben.; Mehr zu diesem Thema findet ihr in Abschnitt 5.1.3 (Attribute im Überblick), Abschnitt 5.1.4 (Primitive Attribute), Abschnitt 5.1.5 (Relationsattribute) und Abschnitt 5.1.6 (Datei- und Bildattribute).
Zusatzbestellposition: (englisch: additional order entry); Eine Bestellposition in einer Bestellung, die einen Rabatt, einen Aufschlag oder eine betragsneutrale Anmerkung repräsentiert.; Mehr zu diesem Thema findet ihr in Abschnitt 5.3.1 (Bestellungen).
Zusatzkosten: (englisch: extra charge); Zusatzkosten definieren weitere Positionen, die den Gesamtpreis einer Bestellung erhöhen (z.B. für Versandkosten etc.) oder verringern (z. B. für Rabatte).; Mehr zum Thema Bestellungen findet ihr in Abschnitt 5.3.1 (Bestellungen).

Von "http://dev.sinnerschrader.de/CommerceWiki/index.php/Glossar"

Glossar

aus CommerceWiki, dem Wiki zum S2I-Commerce-Framework und der S2I-Software-Standardisierung

Views

'Persönliche Werkzeuge

Navigation

Suche

Spezialseiten

Seitenfunktionen