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 und detailview-report 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": ""
}
]
}
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.
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%;
}
}
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.