History
History maintains a record of all previous setting versions used over time. Configuration options allow the user to enable or disable specific setting types from being recorded in the History database. Disabling this feature can be useful to save storage space for setting types that don’t require a history trail.
Each setting version stored in History includes the following information at a minimum:
-
The date and time the setting became active (activeFromDate) and inactive (activeToDate)
-
Information on how the setting was created
-
The creator of the setting
-
The creation date-time
-
All relevant payload fields
The History API returns setting versions in based on the order they were added to the History collection. The activeFromDate of a setting provides the date-time when the setting version was activated. A setting version automatically expires, when a new setting version replaces it. All used setting versions have a status = ACTIVE.
| Scheduled settings are not stored in History until the scheduled date-time is reached. |
Deleted Settings
When a setting is deleted, the History API displays two entries for the most recent setting version. One entry has status = ACTIVE and another has status = INACTIVE. This is the only time a record with status = INACTIVE is created.
Both entries will have identical information except for the status and createdDate fields. The createdDate field reflects the exact date-time of the status change.
If a deleted setting is re-created with the same processing entity and routing BIC (resulting in the same unique logic key), the setting version number resets to 1.
Previous setting versions in History are not removed, meaning at least two versions will exist in the History database. These versions will have different activeFromDate and createdDateTime values.
The optional processingEntity parameter, if provided in the request, ensures that only the setting’s owning Processing Entity can fetch the setting history.
|
Indexes
Default indexes for settings-history collection:
ipf.dps.mongodb.index-config.history {
index-1 = ["processingEntity:ASC"]
index-2 = ["entityId:ASC"]
}
These indexes are configurable with property ipf.dps.mongodb.index-config.history. More on indexes on DPS Index Creation.