Dynamic Processing Settings v2 - Changes & Fixes

Implemented client library for DPS. DPS has generic API and with this client library DPS provides all applications to use it. It is implemented for CRUD and Search APIs. There are two ways how they can be implemented: via connectors or directly. When we use it via connectors we need to set client-type to be connector (that is also default value for connectors). If you want to use it directly, you should set client-type to direct (which is also default value when we are using direct approach).

Added /setting-objects/schemas endpoint for getting payload and searchable fields schemas for all available setting objects. Also implemented client connectors for it.

SettingsTypeIdResolver used for custom JSON (de)serialization. Response contains @type field which contains information about generic type instead of having className field with fully qualified class name. All settings have to set @SettingTypeId annotation with unique value. This value is set as @type field in JSON response.

dynamic-processing-settings-client-notification-port module that represents an interface for receiving dps notifications

dynamic-processing-settings-client-notification-kafka module that represents implementation for receiving dps notifications via kafka

DpsCrudNotification type in dynamic-proessing-settings-model

Error handling is compatible with DPS V1

Approval API response contains new fields (approvalType, recordType, createdDate)

deletedBy query parameter to the DELETE Setting API and the corresponding field on SettingDTO

processingEntity as an optional query parameter for GET Approvals API

Get approvals endpoint response extended to include the differences between persisted settings and approved settings.

Approval Document (DB) structure has changed, old fields (approvedBy, rejectedBy, approvedReason, rejectedReason) are replaced by new fields (createdDate, resolvedBy, resolvedReason, resolvedDate, resolvedStatus)

CRUD service v1 backward compatibility.

DPS v2 can work with settings created by DPS v1 without any DB migration. It is necessary to configure DPS v2 with information on how to convert the v1 data structure to v2 for each setting definition. Configuration is done via property ipf.dps.settings.<setting-definition>. More details can be found in Configuration

Search implementation which can return currently active setting value or setting value which is scheduled to be active in the future. Which value will be returned depends on the query parameter atTime. If the atTime parameter points to a time when the current value is active, then the current value will be used. If the atTime parameter points to a time in the future when the scheduled value will be active, then the scheduled value will be used. This parameter is optional. If not set, the current time is used.

dynamic-processing-settings-notification-service with api module dynamic-processing-settings-notification-service-port and kafka implementation dynamic-processing-settings-notification-service-kafka for crud operations notifications

in the dynamic-processing-settings-repository-mongo there is DpsIndexCreator bean that creates indexes per setting type based on hocon config

Added History service implementation

deletedBy field to the Setting document

processingEntity as an optional parameter for GET Approvals

activeFromDate is the parameter available in both create and update setting requests. This value tells us when the setting is active from. In case when this value is not provided in a request, the service will set current date at the moment of either creating or updating the setting.