Configuring Domain Service
Defining the Relationship
Let's imagine I need to define a constraint between 2 columns of the quote - column "Type" and column "Horsepower".
The constraint logic is defined as follows :
| OP | TYPE | OP | HORSEPOWER |
|---|---|---|---|
| = | Sedan | = | 100hp |
| = | Sedan | = | 110hp |
| = | SUV | = | 110hp |
| = | SUV | = | 150hp |
Preparing the Data
This table needs to be translated into the following JSON format:
JSON table
"SUV"
]
},
{
"values": [
"110hp"
]
}
],
[
{
"values": [
"SUV"
]
},
{
"values": [
"150hp"
]
}
]
]
}In the column Def section, the columns are defined with:
- var: Id of the column. This Id has to be the same as the one defined in the Quote model
- type: Type of the column (STRING, INTEGER, BUSINESS_VALUE_IDENTIFIER, BIG_DECIMAL, LONG, PERCENTAGE, BOOLEAN, CURRENCY, DATE_TIME, LOCAL_DATE, LOCALE, UNIT_OF_MEASUREMENT)
BUSINESS VALUES
For BUSINESS_VALUE_IDENTIFIER type, the value format is specific:
"values": [{
"name": "siName",
"type": "SI",
"namespace": "workspace"
}
]
or
"values": [{
"name": "dimensionName",
"type": "DIMENSION"
}
]| OPERATOR | DESCRIPTION |
|---|---|
| EQ | Equals : = |
| N_EQ | Not equals : != |
| LT | Lower Than : < |
| GT | Greater Than : > |
| LE | Lower Equal Than : <= |
| GE | Greater Equal Than : >= |
| IN | In |
| N_IN | Not In |
| BETWEEN | Between : <= X <= |
| R_BETWEEN | Right Between : < X <= |
| L_BETWEEN | Left Between : <= X < |
| S_BETWEEN | Strict Between : < X < |
| SUBSTRING | Substring |
| N_SUBSTRING | Not substring |
| N_BETWEEN | Not Between |
How to use Performance Quoting APIs
DEFINING THE RELATIONSHIP
Let's imagine you need to define a constraint between two columns of the quote = column "Type" and column "Horsepower."
The constraint logic is defined as follows:
| OP | TYPE | OP | HORSEPOWER |
|---|---|---|---|
| = | Sedan | = | 100hp |
| = | Sedan | = | 110hp |
| = | SUV | = | 110hp |
| = | SUV | = | 150hp |
PREPARING THE DATA
This table needs to be translated into the following JSON format:
{ "operator": "EQ", //The operator used for all columns (can be define at ColumnDef level) "columnDef": [ { "var": "CarType", //Id of the column in the quote model: CarType "type": "STRING" //Type of the column }, { "var": "Horsepower", //Id of the column in the quote model: Horsepower "type": "STRING" //Type of the column } ], "rows": [ [ { "values": [ "Sedan" //Value for first line, first column ] }, { "values": [ "100hp" //Value for first line, second column ] } ], [ { "values": [ "Sedan" //Value for second line, first column ] }, { "values": [ "110hp" //Value for second line, second column ] } ], [ { "values": [ "SUV" ] }, { "values": [ "110hp" ]
} ], [ { "values": [ "SUV" ] }, { "values": [ "150hp" ] } ] ] }
In the column Def section, the columns are defined with:
- var: ID of the column. This ID has to be the same as the one defined in the Quote model.
- type: Type of the column (STRING, INTEGER, BUSINESS_VALUE_IDENTIFIER, BIG_DECIMAL, LONG, PERCENTAGE, BOOLEAN, CURRENCY, DATE_TIME, LOCAL_DATE, LOCALE, UNIT_OF_MEASUREMENT)
In the rows section, the values for each column are defined.
Business Values
For BUSINESS_VALUE_IDENTIFIER type, the value format is specific:
"values": [{ "name": "siName", "type": "SI", "namespace": "workspace" } ]
or
"values": [{ "name": "dimensionName", "type": "DIMENSION" } ]
Operators Available
| OPERATOR | DESCRIPTION |
|---|---|
| EQ | Equals : = |
| N_EQ | Not equals : != |
| LT | Lower Than : < |
| GT | Greater Than : > |
| LE | Lower Equal Than : <= |
| GE | Greater Equal Than : >= |
| IN | In |
| N_IN | Not In |
| BETWEEN | Between : <= X <= |
| R_BETWEEN | Right Between : < X <= |
| L_BETWEEN | Left Between : <= X < |
| OPERATOR | DESCRIPTION |
|---|---|
| S_BETWEEN | Strict Between : < X < |
| SUBSTRING | Substring |
| N_SUBSTRING | Not substring |
| N_BETWEEN | Not Between |
MAKING THE RELATIONSHIP/CONSTRAINT AVAILABLE TO THE DYNAMIC DOMAIN SERVICE
Publishing the table
This step allows you to push the data into the PROS platform. To push/load, the domain /model/admin/domain/{domainName}/upload must be used.
In the server response part, the following information is provided:
Keep the domainFileIdentifier
When a domain file is uploaded, the domainFieldIdentifier has to be used to activate it. This information is only available in the request response. Indeed, the API backup allows you to retrieve only tables that are/were activated.
Activating the table
Once the JSON file is pushed into PROS Cloud, it needs to be flagged as "Active" to create the relationship table and make it available as a constraint in the Dynamic Domain service.
Technical Versioning
Each time a new table/relationship (identified by its name) is Activated, it comes out on top of the previous one (i.e. a new revision/snapshot of the table is created). There is one one revision that is active for a given relationship table. If no active relationship is found, the Dynamic Domain service will return no domain. More details on the publishing/versioning mechanisms can be found below.
The API /model/admin/domain/activate must be used. The name of the table (domainName) as well as its ID (domainFieldIdentifier) are used to activate the constraint domain.
Publishing and Activating immediately
To accelerate the deployment process, you can also leverage the pushAndActivate API that will load the data and automatically activate the constraint once the data is loaded.
Activating several dependent relationships
When a constraint is defined by several tables (e.g. 1 relationship exists between a variable "Incoterm" and a "Route," and another relationship exists between "Route" and "Means of transportation," all tables may have to be activated at once to guarantee the consistency of the overall relationship between all variables. In that case, all table swill be uploaded individually, but the activation must happen simultaneously by leveraging the /model/admin/domain/activate API that will take the LIST of domainFieldIdentifiers as a parameter.
RESTORING AN OLD REVERSION OF THE DOMAIN
It may happen that the active version of a relationship table needs to be fixed.
- Either a new version of the table needs to be pushed and activated;
- Or a previous reversion/snapshot of the table can be reactivated.
To do so, the user can list all revisions of a given domain, thanks to the API
/model/admin/domain/{domainName}/
Then with the copyAndActivate API the user is able to restore a backup by using the same environment ("dev" environment in the following example):
Publishing Mechanism in Depth
The APIs upload and activate are mainly used when you need to publish several tables at the same time. The domains will be uploaded thanks to the upload API, and then when all domains are ready to be activated, the activate API allows you to activate a list of domains at the same time.
When some tables are uploaded, old ones are still active and used by the service. New files are added in the file system, but there is no update on the database side.
Once tables are activated, they are available. Indeed, the activation will add new records in the database. The service is now leveraging the files uploaded previously.
If one table has to be pushed, the API pushAndActivate can be used. Each time a table is pushed in the service, a new version of this table is created and activated. The old one is kept as a backup. The backups API allows you to retrieve all versions of a given table.
A new file is added in the file system, and a new record is automatically created on the database side. The old revision is not removed from the system.
A table can be copied from one environment to another. This API can also be used to activate a backup version (to restore an old version). In that case, there is a new file in the file system. A new record is added in the database to reactivate an old version.