Property Management
Introduction
There are two ways to specify the application’s properties: using a file located in the application’s file system, or via the generic Properties HTTP API resource. The latter is useful for customers that do not have direct access to the file system. Both ways support creating new properties and updating existing ones, even while the application is running. Take special care when changing properties in the middle of processing because it may affect the outcome. This document describes the property management mechanism in detail.
Properties File
The application startup parameter specifies the filename and path (see the Installation Guide for details). The system reads and loads all properties in the file list during the application’s startup process. From then on, there are file checks for modifications at a regular interval (that is, every ten minutes). Once there is a modification, the properties reloads and immediately takes into effect.
Resource
The Property Definitions lists definitions of all properties currently active on the application. The properties API adds and modifies properties that are not already in the aforementioned file list. See the "HTTP API" section in the Developer Guide for more details on generic resources. Following is an example to add a property:
POST http://[hostName]:[portNumber]/[api-context-root]/generic/properties
{
"name": "<propertyname>",
"value": "<propertyvalue>"
}
Following are the steps to modify a property:
-
Search for the property ID using the following example:
POST http://[hostName]:[portNumber]/[api-context-root]/generic/properties/search { "resource": { "q": "name.like('<propertyname>')" } }
This returns a list of properties with their <propertyID>.
-
Use the <propertyID> to modify a property. For example:
PUT/PATCH http://[hostName]:[portNumber]/[api-context-root]/generic/properties/<propertyID> { "name": "<propertyname>", "value": "<propertyvalue>" }
A property
entity comprises a name
, value
, and environment
attribute.
The first two are self-explanatory. Third one is useful to show the specific environment to which it applies.
An environment-specific property takes precedence over a property without an environment.
Essentially, the system processes properties in the following order:
-
File
-
Property with a matching environment
-
The property without an environment
The property’s environment value matches against the value set for the system property ohi.environment.identifier
.
Example
The following example shows how the application resolves the properties from various sources. Consider the content of the properties file is:
PROP_1=A PROP_2=B
And consider using the resource to create the following properties that are now present in the database:
Environment | Name | Value |
---|---|---|
ENV_1 |
PROP_2 |
C |
ENV_1 |
PROP_3 |
D |
ENV_2 |
PROP_3 |
E |
PROP_3 |
F |
|
ENV_2 |
PROP_4 |
G |
PROP_4 |
H |
Now, on environment ENV_1
, the following is how the properties resolve:
Name | Value | Explanation |
---|---|---|
PROP_1 |
A |
Only present in the properties file. |
PROP_2 |
B |
A matching environment-specific value exists in the database, but the value specified to the file takes precedence. |
PROP_3 |
D |
Database that is for |
PROP_4 |
H |
Uses the generic value as environment-specific value exists, but refers to a different environment. |