In der DataEngine, speziell im Administrationsbereich, haben Sie die Möglichkeit, Marini Custom-Konfigurationen zu verwalten. Diese Funktion bietet einen zentralen Ort zur Speicherung von benutzerdefinierten Konfigurationen, die von Marini-Modulen oder benutzerdefinierten Funktionen verwendet werden. Dieses Dokument wird Sie durch die verschiedenen Abschnitte der Marini Custom-Konfigurationen führen, einschließlich der mass-transfer-scheduler, postal-code-lookup, name-workflow , webhook, detailview-report und mpdf Konfigurationen.
Mass Transfer Scheduler
Einleitung
Der Abschnitt mass-transfer-scheduler ermöglicht das Hinzufügen von Massenübertragungsplänen in DataEngine. Diese Zeitpläne werden verwendet, um Datensätze basierend auf bestimmten Bedingungen zu verarbeiten, die verschiedene Aktionen auslösen können, wie das Speichern von Datensätzen und das Ausführen von Workflows.
Konfigurationsbeispiel
Hier ist ein Beispiel für die Konfiguration des mass-transfer-scheduler:
{
"mass-transfer-scheduler": [
{
"module": "core_Contacts",
"fieldName": "process_status_c",
"fieldValue": "hubengine",
"fieldValueNew": ""
},
{
"module": "core_Accounts",
"fieldName": "process_status_c",
"fieldValue": "hubengine",
"fieldValueNew": "",
"modifyDate": false
}
]
}
In diesem Beispiel werden zwei Massenübertragungspläne für die Module core_Contacts und core_Accounts hinzugefügt. Sie werden alle Datensätze mit process_status_c auf hubengine verarbeiten und den Wert auf einen leeren String setzen. Diese Aktion löst das Speichern dieser Datensätze aus und führt anschließend alle mit den Datensätzen verknüpften Workflows aus. Beim zweiten Scheduler ist zusätzlich die Option modifyDate auf false gesetzt (Neu ab DE 24.07.6). Dadurch wird bei diesen Datensätzen nicht das Änderungsdatum und Author geändert. Je nach Workflows kann es trotzdem vorkommen, dass sich das Änderungsdatum ändert, falls dieser den gleichen Datensatz bearbeitet.
Nachdem ein Massenübertragungsplan über die benutzerdefinierte Konfiguration hinzugefügt wurde, stellen Sie sicher, dass er in der Admin-Ansicht unter Zeitpläne aktiviert ist.
Wichtiger Hinweis: Bei Verwendung desselben Moduls, fieldName und fieldValue stellen Sie sicher, dass die Reihenfolge der Einträge nicht geändert wird. Andernfalls wird der zugehörige Zeitplan nach dem Speichern der Konfiguration möglicherweise nicht wie erwartet ausgeführt.
Postleitzahl-Lookup
Einleitung
Der Abschnitt postal-code-lookup wird in Verbindung mit dem Modul Postal Code Package (Version 1.0.5 oder höher) verwendet. Das Modul verwendet automatisch die Felder postalcode und country, um Stadt- und Staatsinformationen nachzuschlagen. Wenn diese Feldnamen in Ihrer Konfiguration unterschiedlich sind, können benutzerdefinierte Feldzuordnungen zur benutzerdefinierten Konfiguration hinzugefügt werden. Dies ist besonders nützlich, wenn die automatische Feldsuche von postalcode für das Modul deaktiviert werden muss.
Konfigurationsbeispiel
Hier ist ein Beispiel für die Konfiguration des postal-code-lookup:
{
"postal-code-lookup": [
{
"module": "full_example_Contacts",
"postalCodeField": "zipcode",
"cityField": "city",
"countryField": "country",
"stateField": "state",
"districtField": "district",
"defaultCountry": "US",
"countryCodeMapping": {
"D": "DE",
"USA": "US"
}
},
{
"module": "minimal_example_Contacts",
"postalCodeField": "zipcode",
"cityField": "town",
"countryField": "nation"
}
]
}
Dieses Beispiel ermöglicht die Konfiguration benutzerdefinierter Zuordnungen für den Postleitzahl-Lookup, einschließlich der Definition benutzerdefinierter Feldnamen und der Spezifikation des Standardlandes und der Ländercode-Zuordnungen.
Hinweis: Änderungen an dieser Konfiguration erfordern nach dem Speichern der Konfiguration einen Quick Repair and Rebuild-Vorgang.
Name Workflow
Einleitung
Der Abschnitt name-workflow wird in Verbindung mit dem Modul NameWorkflow verwendet. Anstelle von Workflows, die umfangreiche Prozessaufzeichnungseinträge generieren, ist dieses Modul so konzipiert, dass es basierend auf bestimmten Kriterien einen Namen zu einem Datensatz hinzufügt. Diese Konfiguration ist schlüsselwertbasiert, wobei der Schlüssel der Name des Moduls ist und der Wert angibt, wie der Name für den Datensatz generiert wird.
Konfigurationsbeispiel
Hier ist ein Beispiel für die Konfiguration des name-workflow:
{
"name-workflow": {
"core_Contacts": {
"value": "{first_name} {last_name}",
"emptyValue": "Kein Name erforderlich",
"onlyIfEmpty": true
},
"minimal_example_Contacts": {
"value": "{first_name} {last_name}"
},
"more_examples": {
"value": "Erstellter Benutzer-ID: {created_by} Erstellter Benutzername: {created_by_name}"
},
"more_examples_2": {
"value": "Name des ersten Verwandten: {test_test_drama_move_1}"
}
}
}
Diese Konfiguration ermöglicht es Ihnen, festzulegen, wie der Name des Datensatzes generiert werden soll. Es ist möglich, Feldwerte des Datensatzes im Namen zu verwenden, indem Sie den Feldnamen in geschweiften Klammern verwenden. Wenn ein
Beziehungsfeld als Ersatz verwendet wird, wird der Name des zugehörigen Datensatzes verwendet.
Wenn der Wert am Ende leer ist, wird der Name auf den Wert von emptyValue gesetzt, wenn dieser festgelegt ist. Wenn onlyIfEmpty auf „true“ gesetzt ist, wird der Name nur festgelegt, wenn er leer ist, und wird nicht aktualisiert, wenn der Name bereits festgelegt ist.
WebHook
Einleitung
Der Abschnitt webhook wird in Verbindung mit dem Modul Webhook Integration verwendet. Er ermöglicht das Festlegen benutzerdefinierter Zuordnungen für Webhooks in DataEngine. Jeder Eintrag ordnet Felder für bestimmte Eingabe-JSON-Daten zu. Diese Zuordnung ist besonders nützlich, wenn die automatisch generierten Feldnamen zu lang sind oder wenn die Feldnamen vom Modul nicht zugelassen werden.
Konfigurationsbeispiel
Hier ist ein Beispiel für die Konfiguration des webhook:
{
"webhook": {
"test_test": {
"testarray": "properties_testarray_3_la",
"properties_testarray": "properties_testarray_1"
}
}
}
Diese Konfiguration ordnet Felder für Eingabe-JSON-Daten zu und gibt an, welche Felder von der Webhook-Integration verwendet werden sollen.
Reports für DetailView Pages
Einleitung
Der Abschnitt detailview-report bietet die Möglichkeit, Reports zu DetailView-Ansichten eines Moduls hinzuzufügen. Bei den eingebundenen Reports wird die ID des aktuell angezeigten Eintrags als Filter gesetzt, sofern die ID als Parameter im Report freigegeben ist. Diese Funktion ermöglicht die Anzeige spezieller Reports für den aktuellen Eintrag direkt auf der DetailView-Ansicht.
Es stehen zwei Slots zur Verfügung – belowContent und sidebar. belowContent befindet sich zwischen der DetailView und den SubPanels, während sidebar eine zusätzliche rechte Sidebar ist, die in diesem Fall eingeblendet wird und eine Breite von 25% hat. Jeder Slot kann mehrere Reports beinhalten und ist in ein 12er Grid aufgebaut, ähnlich dem Dashboard.
Konfigurationsbeispiel
Hier ist ein Beispiel für die Konfiguration des detailview-report:
{
"detailview-report": {
"test_test": {
"belowContent": [
{
"id": "7f08139b-0ac0-9f9f-8006-656f37a8ff55",
"onlyCharts": true,
"charts": [
"Anmeldung pro Tag"
],
"layout": {
"x": 0,
"y": 0,
"w": 3,
"h": 4
}
},
{
"id": "3cfdfcc0-18e2-c60a-7d8d-656f3af1a62b",
"onlyCharts": true,
"charts": [
"Durchschnitt"
],
"layout": {
"x": 6,
"y": 0,
"w": 6,
"h": 4
}
}
],
"sidebar": [
{
"id": "7f08139b-0ac0-9f9f-8006-656f37a8ff55",
"onlyCharts": false,
"charts": [],
"layout": {
"x": 0,
"y": 0,
"w": 12,
"h": 4
}
},
{
"id": "3cfdfcc0-18e2-c60a-7d8d-656f3af1a62b",
"onlyCharts": false,
"charts": [],
"layout": {
"x": 0,
"y": 4,
"w": 12,
"h": 4
}
}
]
}
}
}
Diese Konfiguration fügt je zwei Reports zu beiden Slots für das Modul test_test hinzu. Die Reports in belowContent zeigen nur die Diagramme an (onlyCharts: true), während die Reports in der sidebar nur die Tabellen anzeigen (onlyCharts: false und charts: []). Die Layout-Anweisungen ermöglichen eine benutzerdefinierte Anordnung der Reports, wobei die Höhe dynamisch angepasst wird, um Überlappungen zu vermeiden.
Hinweis: Es ist zu beachten, dass die Seitenladezeit zunimmt, wenn mehr Reports hinzugefügt werden. Daher sollte die Anzahl der hinzugefügten Reports sorgfältig abgewogen werden.
Möchte man die Breite der Sidebar ändern, kann dies über Custom CSS gelöst werden.
Hier das Beispiel für 25% Spaltenbreite:
.bootstrap-container.expandedSidebarRight {
width: 75%;
}
#right-sidebar {
width: calc(25% - 25px);
}
#buttontoggle-right {
right: calc(25% - 25px);
}
@media (min-width: 1200px) {
.bootstrap-container.expandedSidebarRight.expandedSidebar {
width: 55%;
}
}
@media (min-width: 1230px) {
.bootstrap-container.expandedSidebarRight.expandedSidebar {
width: 57%;
}
}
@media (min-width: 1300px) {
.bootstrap-container.expandedSidebarRight.expandedSidebar {
width: 58%;
}
}
@media (min-width: 1400px) {
.bootstrap-container.expandedSidebarRight.expandedSidebar {
width: 59.2%;
}
}
@media (min-width: 1500px) {
.bootstrap-container.expandedSidebarRight.expandedSidebar {
width: 60.2%;
}
}
@media (min-width: 1600px) {
.bootstrap-container.expandedSidebarRight.expandedSidebar {
width: 61.2%;
}
}
@media (min-width: 1800px) {
.bootstrap-container.expandedSidebarRight.expandedSidebar {
width: 62.2%;
}
}
@media (min-width: 1900px) {
.bootstrap-container.expandedSidebarRight.expandedSidebar {
width: 63.2%;
}
}
@media (min-width: 2100px) {
.bootstrap-container.expandedSidebarRight.expandedSidebar {
width: 64.2%;
}
}
@media (min-width: 2300px) {
.bootstrap-container.expandedSidebarRight.expandedSidebar {
width: 65%;
}
}
Reports für Listview Seiten
Neu ab DataEngine 24.07.5
Einführung
Der Abschnitt listview-report bietet die Möglichkeit, Berichte zu ListView-Seiten eines Moduls hinzuzufügen. Im Gegensatz zu DetailView-Seiten, bei denen die ID des aktuell angezeigten Eintrags als Parameter übergeben wird, erhalten ListView-Berichte keinen spezifischen Datensatz als Parameter. Stattdessen gibt es eine experimentelle Option namens addListViewQuery, die den aktuellen Filter der ListView dem Bericht hinzufügt. Dadurch können die Berichte den gefilterten Datensatz widerspiegeln, der in der ListView angezeigt wird. Es sollte jedoch beachtet werden, dass diese Funktion in einigen speziellen Fällen, wie z.B. bei der Verwendung von Filtern über Beziehungen, möglicherweise nicht wie erwartet funktioniert.
Drei Slots sind verfügbar – aboveContent und belowContent. aboveContent befindet sich zwischen der Überschrift und der ListView-Tabelle. belowContent befindet sich unterhalb der ListView und dem Massenbearbeitungsformular. Jeder Slot kann mehrere Berichte enthalten und ist in einem 12-Spalten-Raster strukturiert, ähnlich wie das Dashboard.
Konfigurationsbeispiel
Hier ist ein Beispiel für die listview-report Konfiguration:
{
"listview-report": {
"test_test": {
"aboveContent": [
{
"id": "1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p",
"onlyCharts": true,
"charts": [
"Verkäufe pro Region"
],
"layout": {
"x": 0,
"y": 0,
"w": 6,
"h": 4
},
"addListViewQuery": true,
"chartOptions": {
"height": 350,
"hideSingleChartTitle": true
}
},
{
"id": "2b3c4d5e-6f7g-8h9i-0j1k-2l3m4n5o6p7q",
"onlyCharts": true,
"charts": [
"Umsatz pro Produkt"
],
"layout": {
"x": 6,
"y": 0,
"w": 6,
"h": 4
},
"addListViewQuery": true
}
],
"belowContent": [
{
"id": "3c4d5e6f-7g8h-9i0j-1k2l-3m4n5o6p7q8r",
"onlyCharts": false,
"charts": [],
"layout": {
"x": 0,
"y": 0,
"w": 12,
"h": 4
},
"addListViewQuery": true
},
{
"id": "4d5e6f7g-8h9i-0j1k-2l3m-4n5o6p7q8r9s",
"onlyCharts": false,
"charts": [],
"layout": {
"x": 0,
"y": 4,
"w": 12,
"h": 4
},
"addListViewQuery": true
}
]
}
}
}
Diese Konfiguration fügt zwei Berichte zu beiden Slots für das Modul test_test hinzu. Die Berichte im belowContent zeigen nur die Diagramme an (onlyCharts: true), während die Berichte in der sidebar nur die Tabellen anzeigen (onlyCharts: false und charts: []). Die Layout-Anweisungen ermöglichen eine benutzerdefinierte Anordnung der Berichte, wobei die Höhe dynamisch angepasst wird, um Überlappungen zu vermeiden. Die Option addListViewQuery ist aktiviert, um die aktuellen ListView-Filter in die Berichte zu übernehmen. Mittels chartOptions kann der Chart Title deaktiviert werden ("hideSingleChartTitle": true) und die Höhe der Charts ("height": 350 in px, Standard 250) angepasst werden.
Hinweis: Es ist wichtig zu beachten, dass die Ladezeit der Seite zunimmt, je mehr Berichte hinzugefügt werden. Daher sollte die Anzahl der hinzugefügten Berichte sorgfältig abgewogen werden. Darüber hinaus sollte die experimentelle Natur der addListViewQuery-Option berücksichtigt und deren Funktionalität gründlich getestet werden, insbesondere in Szenarien, die komplexe Filter über Beziehungen beinhalten.
NTILE
Neu ab DataEngine 24.01.1
Einleitung
Der Abschnitt ntile ermöglicht das Anwenden der NTILE-Funktion auf Datensätze. NTILE ist eine SQL-Fensterfunktion, die eine Menge von Zeilen in eine angegebene Anzahl von Segmenten aufteilt, basierend auf einer bestimmten Reihenfolge. Als Ausführungszeitpunkt muss ein existierender Scheduler ausgewählt werden. Dies kann entweder ein spezieller NTILE Scheduler (Process NTILE) sein, der nur hier konfigurierte NTILE Funktionen zum Zeitpunkt ausführt. Alternativ kann ein Process AOW Workflow (Custom In Scheduler) ausgewählt werden. Dann wird die NTILE Funktion nach dem Workflow des Schedulers ausgeführt.
Konfigurationsbeispiel
Hier ist ein Beispiel für die Konfiguration der NTILE-Funktion:
{
"ntile": [
{
"module": "core_Contacts",
"sourceField": "lastBillDate",
"targetField": "score",
"ntile": 5,
"order": "asc",
"scheduler": "2a6de0bc-b723-1e9c-1666-604f1b909e42"
}
]
}
Diese Konfiguration führt die NTILE-Berechnung für das Modul core_Contacts durch. Die Datensätze werden in 5 gleichgroße Segmente basierend auf dem Feld lastBillDate unter Berücksichtigung der aufsteigenden Reihenfolge aufgeteilt. Die Segmentnummer (1-5) wird dann im Feld score gespeichert. Der gesamte Prozess wird durch einen Scheduler mit der angegebenen ID gesteuert.
mpdf
Neu ab DataEngine 24.06.2
Einleitung
Der Abschnitt mpdf ermöglicht die Konfiguration von Einstellungen für die PDF-Generierung mithilfe der mPDF-Bibliothek. mPDF ist ein PHP-Bibliothek, die HTML zu PDF konvertiert und zahlreiche Anpassungsoptionen bietet. Alle verfügbaren mPDF-Variablen können auf der mPDF-Referenzseite unter https://mpdf.github.io/reference/mpdf-variables/overview.html nachgeschlagen werden.
Konfigurationsbeispiel
Hier ist ein Beispiel für die Konfiguration der mPDF-Einstellungen, um eine benutzerdefinierte Schriftart hinzuzufügen:
{
"mpdf": {
"default_font": "helvetica",
"fontDir": [
"custom/fonts"
],
"fontdata": {
"helvetica": {
"R": "Helvetica.ttf"
}
}
}
}
Diese Konfiguration setzt die Standardschriftart auf helvetica. Der Schriftartpfad wird auf custom/fonts festgelegt, und die Helvetica.ttf-Datei wird als reguläre (R) Schriftartdatei für die Helvetica-Schriftart angegeben. Die Schriftart muss über den Support hochgeladen werden.