Custom Config

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-workflowwebhook and detailview-report 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.

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,
                    "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.
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%;
    }
}

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.

Marini Systems GmbH | Contact SupportMarini Website | Privacy Statement | Legal