In DataEngine, specifically within the Admin View, you have the capability to manage Marini Custom Configurations. This feature provides a centralized location to store custom configurations used by Marini modules or custom functions. This document will guide you through the different sections of Marini Custom Configurations, including the mass-transfer-scheduler, postal-code-lookup, name-workflow, webhook, detailview-report, and mpdf configurations.
Mass Transfer Scheduler
Introduction
The mass-transfer-scheduler section allows you to add Mass Transfer Schedulers to DataEngine. These schedulers are used to process records based on specific conditions, which can trigger various actions, such as saving records and executing workflows.
Configuration Example
Here’s an example of the mass-transfer-scheduler configuration:
{
"mass-transfer-scheduler": [
{
"module": "core_Contacts",
"fieldName": "process_status_c",
"fieldValue": "hubengine",
"fieldValueNew": ""
},
{
"module": "core_Accounts",
"fieldName": "process_status_c",
"fieldValue": "hubengine",
"fieldValueNew": ""
}
]
}
In this example, two Mass Transfer Schedulers are added for the core_Contacts and core_Accounts modules. They will process all records with process_status_c set to hubengine and set the value to an empty string. This action triggers a save for these records and subsequently executes all workflows associated with the records. In the second scheduler, the option modifyDate is additionally set to false (new from DE 24.07.6). As a result, the modification date and author will not be changed for these records. Depending on the workflows, it can still happen that the modification date changes if the same record is edited.
After adding a Mass Transfer Scheduler via the custom config, make sure to enable it in the Admin View under Schedulers.
Important Note: When using the same module, fieldName, and fieldValue, ensure that the order of the entries is not changed. Otherwise, after saving the config, the related scheduler may not run as expected.
Postal Code Lookup
Introduction
The postal-code-lookup section is used in conjunction with the Postal Code Package module (version 1.0.5 or higher). The module automatically uses the fields postalcode and country to lookup city and state information. If these field names are different in your setup, custom field mappings can be added to the custom config. This is particularly useful when the automatic field lookup of postalcode for the module needs to be disabled.
Configuration Example
Here’s an example of the postal-code-lookup configuration:
{
"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"
}
]
}
This example allows you to configure custom mappings for postal code lookup, including defining custom field names and specifying the default country and country code mappings.
Note: Changes to this configuration require a Quick Repair and Rebuild operation after saving the config.
Name Workflow
Introduction
The name-workflow section is used in conjunction with the NameWorkflow module. Instead of adding workflows that generate extensive process audit entries, this module is designed to add a name to a record based on specific criteria. This configuration is key-value based, where the key is the name of the module, and the value specifies how the name for the record is generated.
Configuration Example
Here’s an example of the name-workflow configuration:
{
"name-workflow": {
"core_Contacts": {
"value": "{first_name} {last_name}",
"emptyValue": "No need for a name",
"onlyIfEmpty": true
},
"minimal_example_Contacts": {
"value": "{first_name} {last_name}"
},
"more_examples": {
"value": "Created User ID: {created_by} Created User name: {created_by_name}"
},
"more_examples_2": {
"value": "Name of the first related: {test_test_drama_move_1}"
}
}
}
This configuration allows you to specify how the name of the record should be generated. It’s possible to use field values of the record in the name by using the field name in curly braces. If a relation field is used as a replacement, the name of the related record is used.
If the value at the end is empty, the name will be set to the value of emptyValue if it is set. If onlyIfEmpty is set to true, the name will only be set if it’s empty and will not be updated if the name is already set.
WebHook
Introduction
The webhook section is used in conjunction with the Webhook Integration module. It allows you to define custom mappings for webhooks in DataEngine. Each entry maps fields for specific input JSON data. This mapping is particularly useful when the automatically generated field names are too long or if the field names are not allowed by the module.
Configuration Example
Here’s an example of the webhook configuration:
{
"webhook": {
"test_test": {
"testarray": "properties_testarray_3_la",
"properties_testarray": "properties_testarray_1"
}
}
}
This configuration maps fields for input JSON data, specifying which fields should be used by the webhook integration.
Reports for DetailView Pages
Introduction
The section detailview-report provides the capability to add reports to DetailView pages of a module. In the included reports, the ID of the currently displayed entry is set as a filter if the ID is released as a parameter in the report. This feature allows the display of specific reports for the current entry directly on the DetailView page.
Two slots are available – belowContent and sidebar. belowContent is located between the DetailView and the SubPanels, while sidebar is an additional right sidebar that is displayed in this case and has a width of 25%. Each slot can contain multiple reports and is structured in a 12-column grid, similar to the dashboard.
Configuration Example
Here is an example of the detailview-report configuration:
{
"detailview-report": {
"test_test": {
"belowContent": [
{
"id": "7f08139b-0ac0-9f9f-8006-656f37a8ff55",
"onlyCharts": true,
"displayDecription": true,
"charts": [
"Registration per Day"
],
"layout": {
"x": 0,
"y": 0,
"w": 3,
"h": 4
}
},
{
"id": "3cfdfcc0-18e2-c60a-7d8d-656f3af1a62b",
"onlyCharts": true,
"charts": [
"Average"
],
"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
}
}
]
}
}
}
This configuration adds two reports to both slots for the module test_test. The reports in belowContent display only the charts (onlyCharts: true), while the reports in sidebar only display the tables (onlyCharts: false and charts: []). The layout instructions allow a custom arrangement of reports, with the height dynamically adjusted to avoid overlap. With displayDescription (ab DE 24.10.1) it is possible to show or hide the description of the report inside the Dashlet.
Note: It is important to consider that the page loading time increases as more reports are added. Therefore, the number of added reports should be carefully weighed.
If you wish to change the width of the sidebar, this can be achieved through Custom CSS.
Here is an example for a 25% column width:
.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 for Listview Pages
New in DataEngine 24.07.5
Introduction
The section listview-report provides the capability to add reports to ListView pages of a module. Unlike DetailView pages where the ID of the currently displayed entry is passed as a parameter, ListView reports do not receive a specific record as a parameter. Instead, there is an experimental option called addListViewQuery which adds the current filter of the ListView to the report. This allows the reports to reflect the filtered data set displayed in the ListView. However, it should be noted that in some special circumstances, such as when using filters over relations, this feature may not work as expected.
Three slots are available – aboveContent and belowContent. aboveContent is located between the heading and the list view table. belowContent is located below the ListView and MassEdit form. Each slot can contain multiple reports and is structured in a 12-column grid, similar to the dashboard.
Configuration Example
Here is an example of the listview-report configuration:
{
"listview-report": {
"test_test": {
"aboveContent": [
{
"id": "1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p",
"onlyCharts": true,
"charts": [
"Sales per Region"
],
"layout": {
"x": 0,
"y": 0,
"w": 6,
"h": 4
},
"addListViewQuery": true,
"chartOptions": {
"height": 250,
"hideSingleChartTitle": false
}
},
{
"id": "2b3c4d5e-6f7g-8h9i-0j1k-2l3m4n5o6p7q",
"onlyCharts": true,
"charts": [
"Revenue per Product"
],
"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
}
]
}
}
}
This configuration adds two reports to both slots for the module test_test. The reports in belowContent display only the charts (onlyCharts: true), while the reports in sidebar only display the tables (onlyCharts: false and charts: []). The layout instructions allow a custom arrangement of reports, with the height dynamically adjusted to avoid overlap. The addListViewQuery option is enabled to incorporate the current ListView filters into the reports.
Note: It is important to consider that the page loading time increases as more reports are added. Therefore, the number of added reports should be carefully weighed. Additionally, be aware of the experimental nature of the addListViewQuery option and test its functionality thoroughly, especially in scenarios involving complex filters over relationships. With chartOptions the title can be hidden ("hideSingleChartTitle": true) and the height of the chart ("height": 350 in px, default 250) can be adjusted.
NTILE
New in DataEngine 24.01.1
Introduction
The ntile section allows the application of the NTILE function to datasets. NTILE is a SQL window function that divides a set of rows into a specified number of segments based on a specified order. As an execution time, an existing scheduler must be selected. This can be either a specific NTILE scheduler (Process NTILE), which executes only NTILE functions configured here at the specified time. Alternatively, a Process AOW Workflow (Custom In Scheduler) can be selected. In this case, the NTILE function is executed after the scheduler’s workflow.
Configuration Example
Here is an example configuration of the NTILE function:
{
"ntile": [
{
"module": "core_Contacts",
"sourceField": "lastBillDate",
"targetField": "score",
"ntile": 5,
"order": "asc",
"scheduler": "2a6de0bc-b723-1e9c-1666-604f1b909e42"
}
]
}
This configuration performs the NTILE calculation for the core_Contacts module. The records are divided into 5 equally sized segments based on the lastBillDate field in ascending order. The segment number (1-5) is then stored in the score field. The entire process is controlled by a scheduler with the specified ID.
mpdf
New from DataEngine 24.06.2
Introduction
The mpdf section allows for the configuration of settings for PDF generation using the mPDF library. mPDF is a PHP library that converts HTML to PDF and offers numerous customization options. All available mPDF variables can be looked up on the mPDF reference page at https://mpdf.github.io/reference/mpdf-variables/overview.html.
Configuration Example
Here is an example of configuring mPDF settings to add a custom font:
{
"mpdf": {
"default_font": "helvetica",
"fontDir": [
"custom/fonts"
],
"fontdata": {
"helvetica": {
"R": "Helvetica.ttf"
}
}
}
}
This configuration sets the default font to helvetica. The font directory is set to custom/fonts, and the Helvetica.ttf file is specified as the regular (R) font file for the Helvetica font. The font must be uploaded through support.