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 Integration Point 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:

1. 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>.

2. 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:

1. File

2. Property with a matching environment

3. The property without an environment

The property’s environment value matches against the name of the application’s database. Determine this by running:

select ora_database_name from dual

This query is only available on-premises.

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:

Table 1. Example

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:

Table 2. Resolving Property from Various Sources

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 ENV_1, ENV_2, and without an environment. So, the matching environment-specific value takes precedence.
PROP_4	H	Uses the generic value as environment-specific value exists, but refers to a different environment.