-
Notifications
You must be signed in to change notification settings - Fork 14
Customization File
Various aspects of a Harmony Core environment can be customized by crating a Customization File, which is a JSON file named HarmonyCoreCustomization.json that must be placed either in the current directory during code generation, or as an alternative, in the same folder as the CodeGen templates that you are using.
The customization file must contain a JSON object:
{
}
You can then customize various aspects of your Harmony Core environment by adding specific named properties to the object. Examples of doing so can be found below.
To customize relation names you must add a property named CustomRelations to the JSON object. This property must be an array of objects, each of which provides a custom name for a relationship, like this:
{
"CustomRelations": [
{
"FromStructure": "CUSTOMERS",
"FromKey": "CUSTOMER_NUMBER",
"ToStructure": "ORDERS",
"ToKey": "CUSTOMER_NUMBER",
"RelationName": "CustomerOrders",
"RelationType": "D",
"RequiresMatch": false,
"ValidationMode": "None",
"CustomValidatorName": "",
"BackRelation": "ORDERS-CUSTOMERS-CUSTOMER_NUMBER-CUSTOMER_NUMBER"
},
{
"FromStructure": "CUSTOMERS",
"FromKey": "FAVORITE_ITEM",
"ToStructure": "ITEMS",
"ToKey": "ITEM_NUMBER",
"RelationName": "CustomerFavoriteItem",
"RelationType": "C",
"RequiresMatch": false,
"ValidationMode": "ValuePresent",
"CustomValidatorName": "",
"BackRelation": "ITEMS-CUSTOMERS-ITEM_NUMBER-FAVORITE_ITEM"
},
{
"FromStructure": "CUSTOMERS",
"FromKey": "CUSTOMER_NUMBER",
"ToStructure": "CUSTOMER_NOTES",
"ToKey": "CUSTOMER_NUMBER",
"RelationName": "CustomerNotes",
"RelationType": "D",
"RequiresMatch": false,
"ValidationMode": "None",
"CustomValidatorName": "",
"BackRelation": "CUSTOMER_NOTES-CUSTOMERS-CUSTOMER_NUMBER-CUSTOMER_NUMBER"
}
]
}
You can add any number of objects to the array to customize any number of relationships. The FromStructure
, FromKey
, ToStructure
and ToKey
properties are used to identify a repository relation and the values must be specified exactly as defined in the repository, and must be in upper case.
This optional property can be used to customize the name of the navigation property that is added to data model classes to expose the relation. By default, the navigation property will be named REL_<ToStructureName>, but when overridden will be set to REL_<RelationName>.
This optional property can be used to override the Harmony Core relation type for the relationship, in the event that CodeGen identifies an incorrect relation type. The relation types are:
Type | Name | Description |
---|---|---|
A | Many to One to Many | Many records in the "from" file are associated with a single record in the "to" file and vice versa. |
B | One to One to One | Each record in the "from” file is associated with one record in the "to” file and vice versa. |
C | One to One | Each record in the "from” file is associated with one record in the "to” file, but there is no reverse relationship. |
D | One to Many to One | Each record in the "from” file is associated with one or more records in the "to” file and vice versa. |
E | One to Many | Each record in the "from" file is associated with one or more records in the "to" file, but there is no reverse relationship. |
This optional property was previously used to define whether a relation required validation. When set to true validation would always be attempted. When set to false validation would only be attempted when a non-space (alpha) or non-zero (decimal) value was present in the source field. This mechanism proved to be insufficient to correctly perform validation in several possible scenarios and has been replaced by the ValidationMode property (see below).
If RequiresMatch is not present then a default value of false is used.
If RequiresMatch is present and true, and ValidationMode is not present, the ValidationMode is set to Always.
If RequiresMatch is present and false, and ValidationMode is not present, the ValidationMode is set to Never.
We recommend removing all instances of RequiresMatch and replacement with an appropriate ValidationMode property.
This optional property defines what validation is performed when processing inbound data and when the ENABLE_RELATIONS_VALIDATION setting is enabled. Possible values for this property are:
Value | Meaning |
---|---|
None | No validation should ever be performed. |
ValuePresent | Validation should be performed only if a non-blank (alpha) or non-zero (numeric) value is present in the source field. |
Always | Validation should always be performed, regardless of the value in the source field. |
CustomCode | Validation will be performed by custom code named in the CustomValidatioName property. |
This optional property will be used to name a custom validation mechanism that will be used to validate relation data. This mechanism has not yet been defined.
This optional property can be used to specify the "back relation" that defines a relationship BACK from the "to structure" to the "from structure". If specified, the format of the value of the property should be like this:
A-B-C-D
Where
A = the name of the structure that the backward relation originates from (i.e. the outward relations "ToStructure").
B = the name of the structure that the backward relation targets (i.e. the outward relations "FromStructure").
C = the name of the key that the back relation originates from (i.e. the outward relations "ToKey").
D = the name of the key that the back relation targets (i.e. the outward relations "FromKey").
For example, for a relation from CUSTOMERS.FAVORITE_ITEM (structure.key) to ITEMS.ITEM_NUMBER (structure.key), the back relation specification would be:
"BackRelation": "ITEMS-CUSTOMERS-ITEM_NUMBER-FAVORITE_ITEM"
All of these names should be specified EXACTLY as defined in the repository and must be in uppercase.
-
Tutorial 2: Building a Service from Scratch
- Creating a Basic Solution
- Enabling OData Support
- Configuring Self Hosting
- Entity Collection Endpoints
- API Documentation
- Single Entity Endpoints
- OData Query Support
- Alternate Key Endpoints
- Expanding Relations
- Postman Tests
- Supporting CRUD Operations
- Adding a Primary Key Factory
- Adding Create Endpoints
- Adding Upsert Endpoints
- Adding Patch Endpoints
- Adding Delete Endpoints
-
Harmony Core Code Generator
-
OData Aware Tools
-
Advanced Topics
- CLI Tool Customization
- Adapters
- API Versioning
- Authentication
- Authorization
- Collection Counts
- Customization File
- Custom Field Types
- Custom File Specs
- Custom Properties
- Customizing Generated Code
- Deploying to Linux
- Dynamic Call Protocol
- Environment Variables
- Field Security
- File I/O
- Improving AppSettings Processing
- Logging
- Optimistic Concurrency
- Multi-Tenancy
- Publishing in IIS
- Repeatable Unit Tests
- Stored Procedure Routing
- Suppressing OData Metadata
- Traditional Bridge
- Unit Testing
- EF Core Optimization
- Updating a Harmony Core Solution
- Updating to 3.1.90
- Creating a new Release
-
Background Information