Esta página no está disponible actualmente en Español. Si lo necesita, póngase en contacto con el servicio de asistencia de Icon (correo electrónico)

CPS - Notifications

Custom Processing Settings overrides the default DPS v2 notification mechanism with a custom Kafka-based implementation. Instead of using the standard DpsCrudNotification type, CPS implements CpsNotificationServiceKafkaAdapter which sends CpsCrudNotification messages via Kafka.

The notifications are sent when the change to a setting becomes active or the setting is deleted.

Custom Notification Implementation

The CpsNotificationServiceKafkaAdapter implements DpsNotificationServicePort and provides:

  • Custom notification model: Uses CpsCrudNotification instead of the standard DpsCrudNotification

  • Kafka-based delivery: Notifications are sent via Kafka topics using SendConnector

  • Selective notification: Only sends notifications for CREATED, UPDATED, and DELETED actions (scheduled actions are skipped)

  • Flattened payload structure: Extracts and flattens the setting value from the nested structure for easier consumption

Notification Structure

The CpsCrudNotification contains:

Field Description

logicalUniqueKey

Unique identifier combining processingEntity and setting name

settingType

The type of setting ("customprocessingsettings")

action

CRUD action performed: CREATED, UPDATED, or DELETED

processingEntity

The processing entity to which the changed dynamic configuration belongs.

payload

Flattened notification payload containing:

- settingCategory: Category of the setting - settingName: Name of the setting - settingFormat: Format type (BOOLEAN, STRING, NUMBER, STRING_ARRAY, NUMBER_ARRAY) - settingValue: The actual setting value (extracted from the nested structure)

Configuration

Notifications can be enabled/disabled at the setting level. Notifications are enabled by default:

ipf.cps.should-send-notification.custom-processing-settings = true

When enabled, the CpsNotificationServiceKafkaAdapter will send Kafka messages to the configured topic for all CREATE, UPDATE, and DELETE operations on Custom Processing Settings. Following configurations for Kafka send connector is provided:

# Configruration for the Kafka send connector and transport for CPS notifications
ipf.cps.dynamic-settings {
  notification-service {
    kafka {
      producer {
        # Kafka topic for CPS CRUD notifications
        topic = CPS_CRUD_NOTIFICATION
        # restart settings for producer recovery
        restart-settings = ${common-flow-restart-settings}
        kafka-clients {
          group.id = cps-crud-notification-group
        }
      }
    }
  }
}

To use the Kafka notification service, include the following dependency:

<dependency>
    <groupId>com.iconsolutions.ipf.cps</groupId>
    <artifactId>cps-dynamic-settings-notification-service-kafka</artifactId>
</dependency>

The module provides Spring Boot autoconfiguration and will automatically override the default DPS notification service when present on the classpath.

Corresponding Kafka receive connector is provided out of the box with following dependency:

<dependency>
    <groupId>com.iconsolutions.ipf.cps</groupId>
    <artifactId>cps-client-notification-kafka</artifactId>
</dependency>

Configuration for this receive kafka connector is:

# Configruration for the Kafka receive connector and transport for CPS notifications
ipf.cps-api {
  client.notification {
    kafka {
      consumer {
        # Kafka topic for CPS CRUD notifications
        topic = CPS_CRUD_NOTIFICATION
        # restart settings for consumer recovery
        restart-settings = ${common-flow-restart-settings}
        kafka-clients {
          # consumer group ID
          # if we want multiple nodes to be able to receive all CPS notifications, consumer group id needs to be setup differently for each node in deployment
          group.id = cps-crud-notification-group
        }
      }
    }
  }
}

It is important to note that if there is a need for multiple nodes to be able to receive all of these notifications, consumer group id needs to be setup differently for each node in deployment. For example, if there are 3 different nodes deployed, there would need to be 3 different kafka consumer groups defined. This way each node is going to receive all CPS notifications.

In order to handle received CpsCrudNotification, clients can implement provided CpsCrudNotificationHandlerPort.