Vorbehandlung
Datenmapping-Regeln
Konfigurieren Sie benutzerdefinierte Zuordnungen für die Datenumwandlung
Datenmapping-Regeln (Custom Mappings) ermöglichen die automatische Transformation und Anreicherung des Payloads für einen Request gleich zu Beginn des Render-Prozesses. Sie werden nach Priorität ausgeführt und können Daten extrahieren, umwandeln oder ganze neue Felder und Objekte generieren, die anschließend in Templates, Komponenten und Validatoren verfügbar sind. Einzelne PHP-Konfigurationen lassen sich im Bereich Custom Mapping testen ausprobieren, bevor sie hier produktiv angelegt werden.
Daten-Integrität und Vereinheitlichung
Achtung! Mappings verändern den Payload für einen Request. Dies kann zu unerwartetem Verhalten in Integrationen oder den Templates, ihren Komponenten und Validatoren führen, wenn nicht alle Elemente korrekt konfiguriert sind.
Dafür können Mappings komplexe Datenlogik zentral verwalten. Die Regeln werden automatisch bei jedem Rendering ausgeführt und können beispielsweise Brand-IDs extrahieren oder Mailserver-Identifier setzen - also je nach Anforderung ihrer Systeme Daten verfügbar machen.
Diese Seite zeigt eine Liste aller Elemente, und darüber diverse Aktionen, die du ausführen kannst:
Springe zu:
Datenmapping-Regeln-Liste
Die Übersicht zeigt alle konfigurierten Mapping-Regeln mit ihren Metadaten, Prioritäten und Aktivierungsinformationen.
ID, Aktiv ab
| ID | Identifier | Gruppen-Identifier | Aktiv ab | Aktiv | Wert |
|---|---|---|---|---|---|
| identifier_name | Null | Aktiv |
ID
Eindeutige Nummer zur internen Identifikation des Datenmapping-Regels.
Identifier
Eindeutiger Name des Datenmapping-Regels für Rendering und API-Aufrufe.
Eindeutiger Name für eine optionale Gruppierung von verwandten Datenmapping-Regeln. Elemente einer Gruppe werden gemeinsam verarbeitet und optionale Validatoren können dabei einzelne Elemente aktivieren oder ignorieren.
Aktiv ab
Startdatum eines Datenmapping-Regels. Datenmapping-Regels werden erst ab diesem Datum beim Rendern beachtet.
Aktiv
Schnellübersicht, ob das Datenmapping-Regel derzeit freigegeben ist. Deaktivierte Elemente behalten ihre Historie, werden aber nicht mehr automatisch verwendet.
Wert
Der Dateneintrag des Datenmapping-Regels. Kann Text, Zahlen, Bedingungen oder andere Daten enthalten, die in Vorlagen verwendet werden.
Name, Beschreibung, Priorität
Name | Beschreibung | Priorität |
|---|---|---|
| MaloIdentNegativ | Extrahierung der DenyReason für den Negativ Fall des MaloIdent… | 2 |
Priorität
Die Priorität bestimmt die Ausführungsreihenfolge der Mapping-Regeln. Niedrigere Zahlen werden zuerst ausgeführt. Regeln mit Priorität 1 werden vor Regeln mit Priorität 2 verarbeitet. Bei gleicher Priorität ist die Ausführungsreihenfolge nicht garantiert.
Aktiv, Erstellt am, Aktualisiert am
| Validatoren | Pausiert | Aktiv | Erstellt am | Aktualisiert am |
|---|---|---|---|---|
| Null | NO | Ja | ||
| missing_street | YES | Nein |
Zugewiesene Validierungsregeln für das Datenmapping-Regel. Prüfen Ihre Bedingungen vor der Verarbeitung und aktivieren/deaktivieren das Rendering entsprechend.
Temporäre Deaktivierung des Datenmapping-Regels. Pausierte Elemente werden nicht verarbeitet.
Aktivierungsstatus des Datenmapping-Regels. Nur aktive Elemente werden beim Rendern berücksichtigt.
Erstellt am
Zeitstempel der Datenmapping-Regel-Erstellung.
Aktualisiert am
Zeitstempel der letzten Änderung. Zeigt wann Datenmapping-Regel-Konfiguration zuletzt bearbeitet wurde.
Mandant
| Umgebungs-Mandant | Standard für Umgebungs-Mandanten | Benutzerdefinierte ID | Farbe |
|---|---|---|---|
| (1880) Submarke 1 | NO | Null | |
| Null | YES | <<payload.value>> |
Zugeordneter Mandant des/der Datenmapping-Regel. Ermöglicht Mandanten-spezifische Konfiguration.
Kennzeichnet Datenmapping-Regel als Standard und vererbt (verfügbar) für alle Umgebungs-Mandanten.
Optionale benutzerdefinierte Kennung nach dem Rendering für externe Systeme. Wird als Referenzen des/der Datenmapping-Regel bei Callbacks übergeben und beherrscht Vorlagen-Syntax inkl. Zugriff auf Payload-Daten.
Visuelle Kennzeichnung für schnelle Identifikation des/der Datenmapping-Regel. Vor allem nützlich für Dashboard-Statistiken und Charts.
Kontext-Aktionen
Aktions-Dropdown
Aktions-Dropdown
Klicken Sie auf das Drei-Punkte-Menü am Ende jeder Zeile für Aktionen mit dem jeweiligen Datenmapping-Regel.
Anzeigen
Öffnet eine reine Detailansicht der kompletten Meta-Informationen und Einstellungen des Datenmapping-Regel.
Ändern
Öffnet das Bearbeitungsformular für alle Einstellungen und den Upload einer neuen Datenmapping-Regel-Version.
Löschen
Entfernt das Datenmapping-Regel dauerhaft aus dem System. Diese Aktion kann nicht rückgängig gemacht werden.
Spalten konfigurieren
Passen Sie die Anzeige der Datenmapping-Regel-Liste für bessere Übersichtlichkeit an. Spalten können per Drag-and-Drop neu angeordnet und über Checkboxen ein-/ausgeblendet werden.
Für mich anwenden : Spalten-Konfiguration wird nur für Ihren Account gespeichert und beeinflusst andere Benutzer nicht.
Als Standard anwenden : Konfiguration wird für alle Benutzer der Instanz übernommen und als neue Standard-Ansicht gesetzt.
Benutzerdefinierte Zuordnung erstellen
Aktions-Buttons zum Speichern und Verwalten der Datenmapping-Regel-Konfiguration.
Verwenden Sie "Erstellen und weiteres Element hinzufügen" für effizientes Batch-Erstellen mehrerer Elemente.
Das Erstellungsformular ist in drei Tabs unterteilt: Details für Metadaten (Name, Beschreibung, Priorität, Aktiv ab, Aktiv), Bedingung für die optionale Ausführungsbedingung mit Test-Funktion sowie Code für den PHP-Code, der bei erfüllter Bedingung ausgeführt wird.
Eindeutige Bezeichnung für diese Mapping-Regel zur Identifikation in der Übersicht.
Interne Beschreibung eines/r Datenmapping-Regel für Identifikation und bessere Übersicht bzw. Dokumentation. Diese Beschreibung wird im Output.Rocks-Backend verwendet und nicht im Output angezeigt.
Beschreibungen sollten kurz und prägnant sein, um Übersichtlichkeit zu gewährleisten. Längere Erklärungen sollten im Feld 'Kommentar' platziert werden.
Bestimmt die Ausführungsreihenfolge der Mapping-Regeln. Niedrigere Zahlen werden zuerst ausgeführt.
Startdatum des Datenmapping-Regels. Datenmapping-Regele werden erst ab diesem Datum beim Rendern beachtet.
Die Aktiv-Checkbox ermöglicht eine sofortige De-/Aktivierung unabhängig vom Datum.
Vor-Terminierung: Mit diesem Feld können Datenmapping-Regele vor-terminiert werden. Setzen Sie ein zukünftiges Datum, um das Element automatisch ab diesem Zeitpunkt zu aktivieren.
Mehrere Elemente mit gleichem Identifier: unterschiedliches 'Aktiv ab' staffelt die Version; bei einer Anfrage gilt das aktive Element mit dem spätesten Aktiv ab (nicht Erstell- oder Änderungsdatum).
Zuordnung zu einem spezifischen Umgebungs-Mandanten oder Standard-Verwendung für alle Mandanten.
Aktiv
Aktiviert oder deaktiviert die Mapping-Regel. Inaktive Regeln werden während des Rendering-Prozesses nicht ausgeführt.
Wichtige Hinweise zur Ausführung
- Mapping-Regeln werden vor der Template-Auswahl ausgeführt (Timing: nach start, vor map)
- Mehrere Mappings werden nach Priorität (ASC) nacheinander ausgeführt
- Jedes Mapping kann Request-Daten ändern (nächste Mappings sehen die Änderungen)
- MappedData wird in
data['or']gemerged und steht in Templates unter<<or.*>>zur Verfügung - Mapping-Regeln können Template-Identifier ändern (dynamisches Template-Routing)
- Request-Änderungen werden geloggt und sind für nachfolgende Schritte sichtbar
Return-Format (Pflicht)
Der PHP-Code MUSS folgendes Format zurückgeben:
return [
'request' => $request, // Array mit allen REQUEST_FIELDS (auch wenn unverändert)
'mappedData' => $mappedData, // Array (wird in data['or'] gemerged)
];Fehlerbehandlung: ParseError → "Custom code parsing error", ErrorException → "Custom code related error", Throwable → "Custom code error", Falsches Return-Format → Validierungsfehler
Datenmapping-Regeln in Workflows
Datenmapping-Regeln werden automatisch während des Rendering-Prozesses ausgeführt und ermöglichen komplexe Datenverarbeitung vor der Template-Auswahl.
Typische Anwendungsfälle
- Brand-ID-Extraktion: Ermittlung der Brand-ID aus verschiedenen Payload-Quellen und Bereitstellung unter
<<or.brandId>> - Mailserver-Routing: Dynamische Zuordnung von E-Mail-Servern basierend auf Brand-ID oder anderen Request-Parametern
- Fehlerinformationen-Extraktion: Parsing von Validierungsfehlern oder Prozess-Status-Meldungen für Template-Verfügbarkeit
- Dynamisches Template-Routing: Änderung des Template-Identifiers basierend auf Payload-Daten oder Validierungs-Ergebnissen
- Datenanreicherung: Ergänzung von Rendering-Daten mit berechneten Werten oder Lookup-Ergebnissen
Verwandte Backend-Bereiche
- Vorlagen: Mapping-Regeln können Template-Identifier ändern und so dynamisches Routing ermöglichen
- Validierungen: Bedingungen folgen derselben Syntax wie Validierungen
- E-Mail-Vorlagen: Mailserver-Identifier können durch Mapping-Regeln gesetzt werden
Funktionsreferenzen
- Output.Rocks-Objekte: MappedData steht in Templates unter
<<or.*>>zur Verfügung - Expression Language: Bedingungen verwenden Symfony Expression Language mit verfügbaren Variablen
data,metadata,request,standard