DPS Notification Service

Notifications are sent after certain operations are done against settings.

Notifications are disabled by default. To enable them, property ipf.dps.notification-service.enabled needs to be set to true.

We now support only CRUD operations notifications. So, after create, update, and delete operation, a notification is sent.

Here is the example of the DpsCrudNotification message:

{
  "settings": "settingType",
  "logicalUniqueKey": "logicalUniqueKey",
  "action": "CREATED"
}

Here is the example of the DpsNotificationServicePort interface:

public interface DpsNotificationServicePort {

    CompletionStage<Void> sendSettingCrudNotification(String logicalUniqueKey, String settingType, DpsCrudNotification.CrudNotificationAction action);

}

When creating a setting that requires an approval, the corresponding notification will not be sent at the moment of creation. It’ll be sent when the setting is approved.

DPS Notification Service Kafka

This is the kafka implementation of the DPS Notification service. All notifications are sent to a dedicated kafka topic.

Here is the example of hocon configuration for DPS Notification Service Kafka

ipf.dps {
  notification-service {
    enabled = true
    kafka {
      producer {
        topic = DPS_CRUD_NOTIFICATION
        restart-settings = ${common-flow-restart-settings}
        kafka-clients {
          group.id = dps-crud-notification-group
        }
      }
    }
  }
}

common-flow-restart-settings {
  min-backoff = 1s
  max-backoff = 5s
  random-factor = 0.25
  max-restarts = 5
  max-restarts-within = 10m
}

Custom implementations (override the default)

DPS allows downstream services to provide their own implementation of DpsNotificationServicePort. If a bean of that type is present in the application context, DPS will use it instead of the built-in Kafka/No-op adapters.

How it works

DPS provides two default adapters, (Kafka and No-op) via autoconfiguration.

Those beans are declared with @ConditionalOnMissingBean(DpsNotificationServicePort.class).

Therefore, any user-provided bean of type DpsNotificationServicePort automatically takes precedence.

Interaction with `ipf.dps.notification-service.enabled`

true → DPS would create the Kafka adapter unless you provide a custom bean.

false → DPS would create the No-op adapter unless you provide a custom bean.

Custom bean is present → custom implementation is used regardless of the property value.

Backward compatibility

Existing consumers using Kafka or No-op continue to work with no changes.

Properties remain the same:

ipf.dps.notification-service.enabled=true|false

ipf.dps.notification-service.send-notifications-for-scheduled-settings=true|false