Managing properties in the database

You can use the database to store properties, and then manage the properties in the System Administration Console.

Properties

The properties are defined and published in IBM Sterling® Order Management System to control the business operations. Properties are also used to set the connection parameters to the various middleware applications in the IBM Sterling Order Management System deployment and also in the integration with other Enterprise Applications.

You can customize the default behavior by modifying the values of the properties to suit your technical and business needs. These properties are categorized and stored in respective property installation files (.in files). The actual property files are generated during the IBM Sterling Order Management System installation with the values set in the sandbox.cfg file. Typically, changes to properties are not done in the default property files; instead they are overridden in the customer_overrides.properties file.

Limitations of managing properties in files

Currently the properties used by the IBM Sterling Order Management System platform and applications are file based. This mechanism does not allow changes to properties at runtime. The JVMs must be restarted if you want to modify a property value.

The value of a property remains the same for application server and all agent or integrations servers and also for all the users. Though server level property overrides can be achieved by specifying a separate vendor file that points to a different customer_overrides.properties file while initializing the JVM, it is practical only in a On-Premise installation of IBM Sterling Order Management System.

Properties are not all alike; they are different in initialization, consumption, and modification. The current approach of publishing .in files does not articulate its characteristics, when and where it is read, whether it can be modified, or if the modified value comes into effect immediately.

All the properties, which you can modify, can be managed using System Administration Console user interface.

Property handling through Database

A metadata is defined for every property to describe its characteristics.
A command line script is introduced to load both the metadata and the property declaration to the database.
The property retrieval logic has been modified to look up the property in the database first and fall back on files only if the property is not found in database..
A Property Management user interface is added to interact with the database, so that you can add, change, or delete property assignments. The operations that are permissible on a property, based on its metadata, are allowed from the user interface. You can use the same user interface to set server and user-level property override values.
Another command line script is introduced to import the file system overrides, such as specifications in the customer_overrides.properties file. This will set the value of the property is database so that customer specifications are read correctly on retrieving property values.
The db-cache mechanism is used to broadcast changes to property values to all live Sterling™ Order Management System JVMs.

Property retrieval logic flow

The following diagram describes the logic flow when retrieving properties:

The Property metadata modeling

The PLT_PROPERTY_METADATA table stores the characteristics of a property and defines the following attributes:

Table 1. Property metadata table
Column Name	Description
CATEGORY	The category that the property belongs to. For example, yfs or jdbc.
BASE_PROPERTY_NAME	The name of the property.
PROPERTY_TYPE	Indicates whether it is defined in the default property files or a custom property. Indicated as SYSTEM or CUSTOM.
DATA_TYPE	The java type of data that is held by this property.
MODIFIABLE	Indicates whether the property can be modified or overridden.
MODIFIABLE_AT_RUNTIME	Specifies whether this property can be modified once the application is up and running and comes into effect immediately.
PERMISSIBLE_VALUES	The data that this property can hold. This will be stored as XML.
DESCRIPTION	Stores the property description.
SERVER_OVERRIDE	Specifies whether this property is overridden by an application server, agent or integration server.
USER_OVERRIDE	Specifies whether this property is overridden for a logged in user.

The Property modeling

The PLT_PROPERTY table stores factory settings and runtime changes such as setting property values, or defining server and user overrides. It persists the following property information:

Column Name	Description
CATEGORY	The category that the property belongs to. For example, yfs or jdbc.
BASE_PROPERTY_NAME	The name of the property.
FACTORY_VALUE	The default value of the property.
PROPERTY_OVERRIDE	Specifies who has overridden the property. A value of 'BASE' indicates the base property. Allowed values are BASE, SERVER and USER.
PROPERTY_OVERRIDE_NAME	The overridden name of the property. This value is blank for base properties.
PROPERTY_VALUE	The value of the property.
USER_COMMENT	To store comments when modifying or overriding a property.

Property file tagging

The properties continue to be stored by default. A set of well-defined tags are introduced to set the characteristics of properties, while defining them in property files and to load them to the database more effectively. These tags typically signify the property name, possible values, factory value, description, and other defining values.

For example:


## PROPERTY_START
## PROPERTY_NAME: yantra.hm.purge.interval
## DATABASE_SUPPORT: Y
## EXTENDED_PROPERTY: N
## MODIFIABLE: Y
## MODIFIABLE_AT_RUNTIME: N
## SERVER_OVERRIDE: N
## USER_OVERRIDE: N
## PROPERTY_GROUP: System management - health monitor
## PROPERTY_TYPE: Integer
## PROPERTY_DESCRIPTION
## Health monitor purge interval in days. System default value used for purging heartbeat,
## snapshot, and page cache records.
## If this value is not specified, the default value is 30 days.
#yantra.hm.purge.interval=
## PROPERTY_END

Where:

PROPERTY_NAME

The name of the property. In this sample, the name of the property is yfs.config.password.noprompt.

DATABASE_SUPPORT

Indicates whether a property is supported in the database. Properties that are required in production are loaded to the database.

The default value is Y.

EXTENDED_PROPERTY

Indicates whether a property is overridden. If set to Y, then all tags do not need to be documented again, instead just the value. This tag is not saved in the database.

MODIFIABLE

Required: Indicates whether a property can be modified. If not, then the property is not to be modified or overridden. Such properties are for information purposes only.

If a property is marked as not modifiable, no other tags are honored. These properties cannot be modified or overridden from any user interface and its value cannot be changed with the manageProperties tool.

The default value is Y.

MODIFIABLE_AT_RUNTIME

Required: Indicates whether a property can be modified at runtime. Properties which require a server restart should be marked as not modifiable at runtime.

SERVER_OVERRIDE

Required: Indicates properties for which different agents can have different values. If set to Y, different servers can have different values.

USER_OVERRIDE

Required: Indicates properties for which different Users can have different values. If set to Y, different users can have different values.

PROPERTY_GROUP

The property group. In this sample, the property group is user interface.

PROPERTY_TYPE

The property type. In this sample, the property type is boolean.

PROPERTY_PERMISSIBLE_VALUES

The property permissible values. In this sample, the property permissible values are Y, N.

PROPERTY_DESCRIPTION

The property description.

Properties that are tagged as DATABASE_SUPPORT='N' will not be loaded to the database. Instead, they are listed in the filesystem.properties file. If an entry for the property is found in the filesystem.properties file, it will not be looked for in the database.

The following properties are not stored in the database by default:

JDBC and log properties
sandbox.cfg
servers.properties
vendor.properties
security.properties
logfilter.properties
logCodes.properties
logMessageCodes.properties
tuning.properties

The JDBC properties are required before a connection is established with the database and therefore can never be stored in database. Similarly, log properties are not stored in the database. The sandbox properties are required for installation and are used to generate other properties, and are not stored in the database.

The DATABASE_PROPERTY_MANAGEMENT property is introduced in the sandbox.cfg file to enable property management in the database throughout IBM Sterling Order Management System. This is set to false out of the box but enabled by default for IBM Sterling Order Management System offering on Cloud.