Zum Hauptinhalt springen
Die global.config ist die subshop-übergreifende Konfigurationsdatei eines Shops. Was hier steht, gilt für alle Subshops gemeinsam. Eine abweichende Einstellung auf Subshop-Ebene ist nicht vorgesehen, dafür ist die Shopkonfiguration shop.config zuständig. Im Auslieferungszustand eines Shops gibt es diese Datei nicht. Sie entsteht erst, wenn eine Funktion sie braucht, und sie enthält dann auch nur die Abschnitte dieser Funktionen. Es gibt keine Standardfassung, die man vollständig ausfüllen müsste. Referenz: Shopkonfiguration shop.config

Die Datei anlegen

Die global.config liegt im Online-Servicebereich im Dienst “Konfiguration” direkt unter “Global”. Um sie anzulegen, klicken Sie rechts neben dem Wort “Konfigurationen” auf das Symbol “neue Konfiguration anlegen” und geben der neuen Konfiguration den Namen global. Die Endung ergänzt das System selbst. 20180724 Global Config Danach liegt eine leere Konfigurationsdatei vor, in die Sie die benötigten Abschnitte eintragen.

Wer die Datei liest

Die global.config wird nicht nur vom Shopsystem selbst ausgewertet. Je nach Abschnitt liest sie ein anderes Programm, und das erklärt, warum sich manche Änderungen sofort auswirken und andere erst mit dem nächsten Lauf eines Hintergrundprogramms. Das Shopsystem liest die global.config bei Bedarf innerhalb eines Seitenaufrufs. Änderungen an den Abschnitten, die das Shopsystem auswertet, greifen deshalb unmittelbar. Die Abschnitte für Importe, Auswertungen und die Gutscheinverwaltung werden erst beim nächsten Lauf des jeweiligen Programms oder beim nächsten Aufruf der jeweiligen Seite im Servicebereich gelesen.

Common

Der Abschnitt sammelt einzelne Grundeinstellungen, die zu keinem eigenen Abschnitt gehören.
In der Altdokumentation steht unter ProductData-ResetOnEmptySetDefinition die Beschreibung eines anderen Parameters. Dort wird der Input-Zähler für Formularfelder erklärt, und auch die dort genannten Werte yes, test und no gehören zu diesem anderen Parameter. Gemeint ist FORMTagsResetInputCounter. Beide Parameter sind oben getrennt beschrieben. ProductData-ResetOnEmptySetDefinition kennt nur yes und no und hat mit Formularen nichts zu tun.
FORMTagsResetInputCounter ist vor allem auf Seiten sinnvoll, die Produktdaten dynamisch vorladen, beispielsweise über CAT-AdvData oder CAT-LoadData. Liegen dort mehrere Produktformulare auf einer Seite, dann können sich die fortlaufend vergebenen Feldnamen überschneiden und Eingaben dem falschen Formular zugeordnet werden. Mit test schalten Sie die Umstellung zunächst nur im Testmodus des Shops scharf und prüfen die Auswirkung, bevor Sie auf yes gehen.

Conversions

Legt fest, ob die Zusatzeingaben zu Produkten hex-kodiert in die Bestelldaten übergeben werden. Das ist dann nötig, wenn die Eingaben Zeichen enthalten können, die das Format der Bestelldaten stören, beispielsweise Zeilenumbrüche.
Es gibt genau 20 Zusatzeingabefelder je Produkt, deshalb endet die Reihe bei 20. Ein einzeln gesetzter Parameter gewinnt immer, auch wenn er none sagt und die Vorgabe hex lautet. Jeder Wert außer hex wird als none gelesen. Die kodierten Werte stehen in den Bestelldaten im Block ExtraInput_<Nummer> der jeweiligen Position. Die empfangende Warenwirtschaft muss die Kodierung kennen und rückgängig machen.

ProductDataFieldInjection

Setzt Produktdatenfelder für Testszenarien, ohne dass die Daten aus der Warenwirtschaft geändert werden müssen. Damit lassen sich Produktinformationen kurzfristig ergänzen, überschreiben oder leeren.
Wegweiser: Anreichern von Produktdaten für Testszenarien

Unterabschnitt +InjectData

Jeder Unterabschnitt +InjectData beschreibt eine Regel. Sie können beliebig viele davon anlegen.
Fehlt ProductPattern-List oder ist der Wert leer, dann wird die gesamte Regel übersprungen. Das geschieht ohne Fehlermeldung im Shop.ForceOverwrite = yes wirkt sich auf Laufzeit und Leistungseinheitenverbrauch aus, weil für jedes erfasste Produkt zusätzlich geprüft und geschrieben werden muss. Setzen Sie den Parameter nur dort, wo das Überschreiben wirklich gebraucht wird.

Unterabschnitt +SetData

Innerhalb von +InjectData legen Sie mit beliebig vielen Unterabschnitten +SetData fest, welche Felder welchen Wert bekommen.

Muster für ProductPattern-List

PN: prüft die Produktnummer, PI: den Produktindex. Als Platzhalter steht * für beliebig viele Zeichen und ? für genau ein Zeichen. Der Abschnitt wird nur ausgewertet, wenn die Funktion für den Shop freigeschaltet ist. Ist sie das nicht, dann protokolliert das Shopsystem einen Fehler und überspringt den gesamten Abschnitt. Die Freischaltung erhalten Sie über Ihren WEBSALE Ansprechpartner.

SpecialUserCodes

Füllt Suffixfelder der Rechnungsadresse automatisch, wenn der Kunde einen vordefinierten Code eingibt oder über einen Link mit dem passenden Parameter in den Shop kommt. Damit lassen sich Kunden beispielsweise bei der Registrierung einer Kundengruppe oder einem Vertriebskanal zuordnen. Der Kunde gibt dabei nur einen lesbaren Alias ein. Welcher technische Wert daraus wird, steht ausschließlich in dieser Konfiguration und ist für den Kunden weder sichtbar noch beeinflussbar.
Gibt der Kunde XXL ein, dann steht anschließend im Suffixfeld 13 der Rechnungsadresse der Wert gold. Der Vergleich der Eingabe unterscheidet nicht zwischen Groß- und Kleinschreibung. Ein Eintrag mit +Input = XXL greift deshalb auch bei der Eingabe xxl. Eine zweite +Input-Zeile für dieselbe Schreibweise in anderer Groß- und Kleinschreibung ist unnötig. Mehrere +Input-Zeilen brauchen Sie nur für wirklich verschiedene Aliasnamen.
Ein Suffixfeld, das bereits einen Wert enthält, wird nicht überschrieben. Die Eingabe läuft dann auf einen Fehler. Dasselbe gilt, wenn die Eingabe zu keinem Eintrag passt.
Die Funktion arbeitet nur für angemeldete Kunden. Bei einem Treffer schreibt das Shopsystem den Wert in die Rechnungsadresse und speichert diese. Schlägt dabei die Adressprüfung oder das Speichern fehl, dann werden alle in diesem Aufruf gesetzten Suffixwerte wieder zurückgenommen. Für das Eingabefeld und die Rückmeldungen im Template steht die Tag-Familie SUC- zur Verfügung.

SpecialW2PConditions

Legt fest, unter welchen Bedingungen ein als “bedingt Web-to-Print-fähig” gekennzeichnetes Produkt tatsächlich Web-to-Print-fähig ist. Geprüft werden Suffixfelder der Rechnungsadresse des Kunden.

Werte für Type

Das folgende Beispiel macht ein bedingt Web-to-Print-fähiges Produkt verfügbar, sobald eines der beiden Felder Suffix15 oder Suffix16 der Rechnungsadresse gefüllt ist.
Wegweiser: Web-to-Print-Produkte Die Bedingungen werden bei jedem Seitenaufruf aus der Konfiguration gelesen, unabhängig davon, ob im Warenkorb überhaupt ein bedingt Web-to-Print-fähiges Produkt liegt. Halten Sie den Abschnitt deshalb knapp. Die Einrichtung stimmen Sie mit Ihrem WEBSALE Ansprechpartner ab.

SubShopMapping

Fasst Subshops zu Gruppen zusammen und legt fest, wie Produkte und Kategorien zwischen den Subshops einer Gruppe einander zugeordnet werden. Darauf baut beispielsweise die automatische Erzeugung der hreflang-Attribute auf.
Die Pfadangaben zu den Zuordnungslisten stimmen Sie mit der WEBSALE Technik ab, damit die Dateien an der erwarteten Stelle liegen und zum richtigen Zeitpunkt gelesen werden. Wegweiser: Automatische Erzeugung des hreflang-Attributs

TopSeller

Steuert zwei Funktionen, die sich den Abschnitt teilen, aber unabhängig voneinander sind: die Sortierung nach Topsellern und die Funktion “Top-30-Produkte”.
Allow bezieht sich ausschließlich auf “Top-30-Produkte”. Die Sortierung nach Topsellern bleibt davon unberührt und wird allein über NumDays und die Sortierung im Template gesteuert. Ein Allow = no schaltet die Topseller-Sortierung also nicht ab.
Die Auswertung läuft in einem Hintergrundprogramm. Eine geänderte Einstellung wirkt sich erst aus, wenn dieses Programm das nächste Mal läuft und die Tabelle neu aufbaut. Wegweiser: Sortierung nach Topseller, Top-30-Produkte

ChargeLabel

Legt fest, ob beim Anlegen einer Gutschein-Charge ein Label angegeben werden muss.
Wegweiser: Gutscheine anlegen und importieren

ChargeLabelValues

Füllt die Auswahlliste, aus der beim Anlegen eines Gutscheins oder einer Gutschein-Charge das Label gewählt wird.
Wegweiser: Gutscheine anlegen und importieren

VoucherNumberCharacters

Schließt einzelne Zeichen von der automatischen Erzeugung der Gutscheinnummern aus. Sinnvoll ist das bei Zeichen, die beim Abtippen leicht verwechselt werden, beispielsweise 1 und I.
Mehr als 10 ausgeschlossene Zeichen werden nicht angenommen. Die Gutscheinverwaltung zeigt beim Generieren eine Fehlermeldung und verwendet nur die ersten 10 Einträge der Liste.
Der Gutschein-Generator verwendet ohnehin nur einen Teil des Alphabets. Die Ziffer 0 und die Buchstaben O, W und X kommen in erzeugten Gutscheinnummern nicht vor. Diese Zeichen auszuschließen ändert deshalb nichts. Die Verwechslungsgefahr zwischen 0 und O besteht bei erzeugten Nummern also gar nicht. Die Einstellung gilt plattformweit für alle Shops und Subshops. Sie wirkt nur auf automatisch erzeugte Nummern. Eine von Hand vergebene Gutscheinnummer wird davon nicht eingeschränkt.

Abschnitte für Importe und Fremdsysteme

Diese Abschnitte gehören zu Schnittstellen und werden nicht vom Shopsystem, sondern von den jeweiligen Importprogrammen gelesen. Hier stehen nur die Parameter, die im Shop sichtbar werden.

CustomerImportPro

Betrifft den Kundenimport, insbesondere die Umwandlung von Zeichensätzen.

ProductImportPro

Betrifft den Produktimport, unter anderem die Umwandlung von Zeichensätzen.

ImportCharsetConvertMap

Legt die Zeichensatz-Umwandlungstabelle für die Importe fest. Der Abschnitt kann mehrfach vorkommen und wird deshalb mit einem Pluszeichen geschrieben.

FuturaECS

Betrifft ausschließlich das Warenwirtschaftssystem Futura.

Weitere Abschnitte

Das Shopsystem wertet in der global.config vier weitere Abschnitte aus. Sie gehören zu Funktionen, die gesondert freigeschaltet und gemeinsam mit WEBSALE eingerichtet werden.
Richten Sie diese Abschnitte nicht ohne Abstimmung mit Ihrem WEBSALE Ansprechpartner ein. Zwei der vier Funktionen greifen in die Preisermittlung beziehungsweise in den Zahlungsvorgang ein, und sie setzen eine Freischaltung voraus, ohne die der Abschnitt wirkungslos bleibt.

TaxCases

Definiert Ländergruppen, auf die sich die Steuerfall-Schnittstelle bezieht. Die Gruppen werden in zwei Unterabschnitten gebildet, einmal nach Lieferland und einmal nach Herstellungsland.

PaymentBruteForceProtection

Sperrt Zahlungsarten nach wiederholt fehlgeschlagenen Zahlungsversuchen, getrennt nach Sitzung und nach IP-Adresse, und kann zusätzlich ein Captcha erzwingen.
Ein Eintrag der Sperrzeitenliste besteht aus der Zahl der Fehlversuche und der Sperrdauer in Sekunden, beide in runden Klammern und durch einen Doppelpunkt getrennt. Mehrere Einträge werden aneinandergereiht.
Es gilt immer der Eintrag mit der höchsten erreichten Schwelle. Eine Sperrdauer über 48 Stunden wird auf 48 Stunden gekürzt. Der Wert permanent wirkt nur in der Sitzungsliste. Eine IP-Adresse wird nie dauerhaft gesperrt, auch wenn permanent konfiguriert ist.

ProductDataJSONInterface

Beschreibt, aus welcher Datei und welchem Datenfeld die kundenspezifischen Rabattkategorien gelesen werden.

CustomOfferAPI

Hinterlegt das Geheimnis für die Schnittstelle der kundenspezifischen Angebote.
Das Geheimnis steht im Klartext in der Konfiguration. Behandeln Sie die global.config entsprechend und geben Sie Auszüge daraus nicht weiter.