Define Model APIs
To add a new Model API, select "Model" under "Rest APIs" and click "Add Model API Resource" from context menu or toolbar:
Platform provides a standard implementation to read or write models. Alternately, the developer can provide a custom implementation if they want to add custom levels or fields which are not actually on a model. (The developer can extend the Platform's standard implementation class and use the utility methods provided there to speed up their implementation.)
Level
The Level section is used to define the "levels" (i.e. parent/child relationships) of the model, and the fields within each level. The developer can define as many levels as they want, but there can be at most 1 root level. The developer can also add a custom level or custom fields within any level as long as they provide a custom implementation.
When adding MDF fields, they will be added under the following hierarchy <Level> -> MDFs -> <ModulePrefix>. The same hierarchy will be maintained in the JSON Object passed through REST.
KeyObject
The KeyObject section is used to define the Natural Key fields for a root level. This is used to uniquely identify a record from the database. For the standard implementation, the developer should add all the root level model's NK fields. If the developer is using any other combination of fields, they will have to provide a custom implementation.
The developer can add fields to the KeyObject section by clicking the "Add" button. This will open a pop-up dialog containing only Natural Key fields from root level defined in the level section of the "Definition" tab.
KeyObjects are not overridable by higher module.
Search
The Search section is used to define a set of "queries" which can be used to lookup models from the database. The developer can add as many searches, adding as many search fields as desired within each.
To add a search, the developer should need to click the "Add" button in the Search tab. This will open a pop-up where the developer provides a name and optional description. The name will be automatically prefixed by the module prefix to avoid name conflicts across modules.
Once the search is added, the developer can add search fields by clicking the "Add" button in the detail section. This will open a pop-up dialog containing fields from the root level. The developer can also add fields from other levels by selecting a child level from the drop-down. Also, the developer can add custom fields from the same dialog.
The Searches added in lower-level modules are not overridable in higher-level module. However, higher-level modules can always add new searches.
Required
By default, all search fields are optional except the model Natural Key fields. The developer can change any field to Required, Optional or RequiredGroup.
Required: Field will be required; user will need to provide the field value in the input JSON when invoking a model search API.
Optional: Field will be optional; if user provides a value in the input JSON, it will be used by the query to filter the records. Otherwise, it will not be used in the query.
RequiredGroup: The developer must provide a RequiredGroup name. The developer can then apply the same group name to multiple fields to put all those fields within the group. When invoking a model search API, the user will be required to provide at least value for 1 of the fields in each RequiredGroup.
Config
By default, wildcard characters are not supported for search fields. A developer can configure the STRING field for supporting leading and trailing wildcards and minimum wildcard characters by clicking on the Config column.
Write
The Write section is used to define levels and fields for persisting models to the database. The developer can define as many resource actions as they wish. These do not correspond directly to model actions but are unique names that hold the levels and fields along with the model action.
To add a resource action, the developer should click the "Add" button in the Write tab. This will open a pop-up where the developer must provide a name and optional description, and select one of the actions for the root level model. The name will automatically be prefixed by the module prefix to avoid name conflicts across modules.
When the developer clicks the OK button, this will copy all levels and its fields from the "Level" section to the created resource action. If a model action is selected, then the field mask will be based on the mask selected in the action. If a model action is not selected, an OPTIONAL mask will be used for all fields by default.
Once the resource action is created, the developer can choose the levels and fields which are copied from the level section.
