In this segment, we’ll explore the concept of data sourcing within a UI schema, focusing on how and where data is obtained. Typically, data in a UI schema is gathered from a collection. There are various types of data sources:

1. Remote: This involves obtaining data from a server located elsewhere.
2. Resource: These are predefined static collections integrated within the schema. They are commonly used for Enumerations or as fixed collections in UI components like comboboxes.

Data sources are configured in a key element of the schema named “datasources”. This element houses a series of data source collections. Since a single user interface may need to access multiple data collections for user interactions, this arrangement facilitates the management and utilization of these diverse data sources.

Resource data source

The provided example illustrates a basic schema featuring a resource data source. This represents a static set of records available for use within the UI as needed.

{
    "datasources": [
        {
            "id": "my_collection"
            "resource": [
                { "id": 1000, "title": "Series" }
                { "id": 1001, "title": "Parallel" }
            ]
        }
    ],
    
    "body": { ... }
}

Remote data source

{
    "datasources": [
        {
            "id": "my_collection",
            "remote": "entity_name",
            "action": "GetMyCollection"
        }
    ],
    
    "body": { ... }
}

Defining a remote data source you need to at minimum define:

1. id: This serves as the unique identifier for the data source. It’s utilized by the background systems to retrieve the data source’s definition when there’s a need to access the relevant data.
2. remote: This specifies the name of the entity on which an action will be performed to obtain the data.
3. action: This refers to the specific action that needs to be executed to fetch the data.

These are the core parameters but there are additional optional parameters you may want to take note of.

1. parameters: This is a dictionary that defines the parameters for a fetch operation. Each key-value pair represents a specific property and its corresponding value that will be used in the fetch process.
2. querystring: This parameter sets up a filter for data retrieval from the server. The structure of the querystring is dictated by the server’s specifications, and it is essential to refer to the server documentation for correct usage. For instance, “$filter=code eq 123” is an example of a querystring that filters data based on a specific code.
3. ignoreInflation: This boolean property defaults to ‘false’. In this context, ‘inflation’ refers to the process of fetching field definitions from the server and integrating them into the client-side data source. These field definitions are crucial for understanding the data types of fields in the data source. They are also used in certain visualizations and in determining the functionalities available for editing cells in a data grid. Setting this property to ‘true’ bypasses the fetching of field definitions, which can be useful when these definitions are not required, thereby avoiding unnecessary server requests.
4. delay-fetch: Another boolean property, defaulting to ‘false’, which controls the timing of data fetching in the data source. Its behavior varies depending on its usage:
   • If a component uses the data source and ‘delay-fetch’ is ‘true’, the data is lazily loaded when the component is activated.
   • If the data source is not tied to a component but ‘delay-fetch’ is ‘true’, data loading still occurs lazily but requires explicit action, like a custom process defined in the process API.
   • If a component uses the data source and ‘delay-fetch’ is ‘false’, the data is preloaded when the component becomes active.
   • If the data source is not used by a component and ‘delay-fetch’ is ‘false’, the data is fetched during the initial startup phase.

{
    "datasources": [
        {
            "id": "my_collection",
            "remote": "entity_name",
            "action": "GetMyCollection",
            "parameters": {
                "SiteType->Id": "@dataModel.selectedIds[0]"
            },
            "queryString": "$filter=code eq 123",
            "ignoreInflation": true,
            "delay-fetch": true
        }
    ],
    
    "body": { ... }
}

In the given example, the value of the parameter “SiteType->Id” is extracted from schema variables during runtime. This is done by the system to enable specific features within the schema through these variables. Here, a scenario is presented where a user makes a selection in a visualization interface, and this selection is then communicated to the data source definition as an updated schema variable.

This approach enhances the flexibility of lazy loading. It allows for an interpretation of user intent in real-time, incorporating updated environmental data when necessary. This method effectively tailors data retrieval to current user interactions and context.

When you define parameters and a query string, the fetch URL is modified accordingly. For instance, it would be structured as: ".../parameter1/parameter2/parameter3?querystring".

Primary Actions

Until now, our focus has been primarily on the aspect of fetching data from data sources. However, it’s important to note that these data collections often come with the possibility of executing custom actions, which are also a significant part of their functionality.

Available actions are:

1. create: Add a new record to this collection.
2. update: Modify an existing record within the collection.
3. delete: Remove an existing record from the collection.
4. batch-create: Add multiple records to the collection in a single operation.
5. batch-update: Modify multiple records within the collection simultaneously.
6. batch-delete: Remove multiple records from the collection in one action.

The “primaryActions” property on the data source intent definition outlines the main actions. This property is structured as a dictionary, where each key represents the name of an action, and its corresponding value is an object that defines the attributes of that action.

{
    "datasources": [
        {
            "id": "my_collection",
            "remote": "entity_name",
            "action": "GetMyCollection",
            "primaryActions": {
                "create": {
                    "action": "CreateMyItem"
                },
                "update": {
                    "action": "UpdateMyItem",
                },
                "delete": {
                    "action": "DeleteMyItem",
                    "parameters": {
                        "MyItem->Id": "@dataModel.selectedIds[0]"
                    }
                },
                "batch-create": {
                    "action": "BatchCreateMyItems"
                },
                "batch-update": {
                    "action": "BatchUpdateMyItems"
                },
                "batch-delete": {
                    "remote": "MyCustomDeleteEntity",
                    "action": "BatchDeleteMyItems"
                },
            }
        }
    ],
    
    "body": { ... }
}

In these examples, the primary focus is on specifying the action to be executed. Additionally, these definitions can include parameters and a ‘remote’ property, in cases where the action needs to be performed on a different entity.

Enum data source

{
    "datasources": [
        {
            "id": "my_collection",
            "type": "enum",
            "remote": "RegularAssetTask",
            "ignoreInflation": true,
            "field": "inspectionType"
        }
    ],
    
    "body": { ... }
}

An enum data source is a type of remote data source configured with its type set as “enum”. In this setup, field definitions are not a concern, hence they are set to be ignored. It’s important to note that within this configuration, a specific field is designated, indicating which field in the collection should be utilized as the enum value.