Guía de migración de DPS v1 a DPS v2

Los siguientes pasos van a describir lo que es necesario para que los servicios se trasladen de DPS v1 a DPS v2.

Elimine los módulos no utilizados

Módulos de repositorio utilizados anteriormente por DPS v1,setting-<setting-name>-repository deben ser eliminados de los proyectos ya que ya no se utilizan en DPS v2. Toda la configuración está ahora bajo módulos de dominio.setting-<setting-name>-domain.

Crear índices

En DPS v1 los índices para cada configuración se proporcionaron listos para usar. En DPS se pueden crear índices v2 a través de HOCON config. Para cada configuración, debe crearse un conjunto de índices a través de reference.conf de un módulo de dominio.

ipf.dps.mongodb.index-config.<setting-type> {
    index-1 = ["status:ASC"]
    index-2 = ["processingEntity:ASC"]
    index-3 = ["values.payload.field1:ASC"]
    index-4 = ["values.payload.field2.field3:ASC"]
}

Los campos que están bajo la carga de configuración deben ser referidos como values.payload.<field-name> bajo índices.

El Creación del Índice DPS La página contiene más información sobre la creación de índices.

Notifications

DPSv2 puede proporcionar notificaciones después de que se realice cierta operación en una configuración. Estas notificaciones están deshabilitadas por defecto y se pueden configurar con las siguientes propiedades:

ipf.dps.notification-service.enabled = true # notification for all CRUD operations are sent
ipf.dps.notification-service.send-notifications-for-scheduled-settings = true # notification for all operation on scheduled settings are sent

También puede definir sus propias propiedades para habilitar/deshabilitar la notificación para cada definición de configuración.

    @Value("${ipf.service.should-save-history.dpssampe-setting:true}")
    private boolean historyEnabled;

    @Value("${ipf.service.should-send-notification.dpssample-setting}")
    private boolean notificationsEnabled;

    @Bean
    public SettingDefinition<DpsSampleSetting> dpsSampleSettingDefinition() {
        return SettingDefinition.<DpsSampleSetting>builder()
                .settingType(DpsSampleSetting.SETTING_TYPE)
                .collectionName("setting-" + DpsSampleSetting.SETTING_TYPE)
                .idFunction(setting -> setting.getProcessingEntity() + "-" + setting.getPayload().getFullName())
                .historyEnabled(historyEnabled) (1)
                .notificationsEnabled(notificationsEnabled) (2)
                .payloadClass(DpsSampleSetting.class)
                .payloadExample(payloadExample())
                .searchableFieldsClass(DpsSampleSettingSearchableFields.class)
                .searchableFieldsExample(dpsSampleSettingQueryExample())
                .build();
    }

1	historia habilitada- Si se debe rastrear el historial de los cambios de configuración o no. Está habilitado por defecto.
2	notificaciones habilitadas- Si enviar Kafka notificaciones cuando se crea, actualiza o elimina la configuración. Está desactivado por defecto ya que DPS v1 no tenía esta funcionalidad.

Kafkanecesita ser implementado para enviar/recibir notificaciones. Ejemplo de cómo configurar el tema de kafka y las notificaciones:

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
}

Más información sobre cómo implementar el punto final de recepción para estos Kafka las notificaciones se pueden encontrar aquí Notificación al Cliente de DPS

Consultas de Conector y Directas

La mayoría de los servicios que utilizaron DPS v1 implementó sus propios conectores y consultas directas. DPS v2 proporciona estos de forma predeterminada.

Se puede encontrar una descripción detallada sobre cómo importar estos aquí.Conectores e Implementaciones Directas La sugerencia es utilizar DPS interfaces v2 en lugar de custom implementaciones de servicio para evitar cualquier mala configuración.

El mejor enfoque sería cambiar custom implementaciones de servicio para utilizar DpsSearchClientPort,DpsCrudClientPort,DpsHistoryClientPort y otras interfaces proporcionadas, y para configurar propiedades específicas (conector o directo) como se describe en la página suministrada arriba.

Bases de datos

DPSv2 introduce configuraciones programadas y utiliza el Programador de Persistencia para su mantenimiento. Para configurar adecuadamente la persistencia scheduler hay una necesidad de crear dos nuevas colecciones y sus índices. La siguiente configuración debe ser añadida a su base de datos (ejemplo cosmos-schema.yaml):

- name: jobSpecification
  throughput: 400
  default_ttl_seconds: 3600 # should be tied to deleteTime
  additional_indexes:
    - keys:
        - deleteTime
      unique: false-keys:
        - _id.jobSpecificationId
        - _id.lastUpdated
      unique: false-name: jobExecutionStatus
  throughput: 400
  default_ttl_seconds: 3600 # should be tied to deleteTime
  additional_indexes:
    - keys:
        - deleteTime
      unique: false-keys:
        - _id.jobSpecificationId
        - _id.lastUpdated
      unique: false

MongoDB

Desde DPS v2 utiliza flujos de cambios,MongoDB debe tener un conjunto de réplicas para que los flujos de cambios funcionen. Esto es más una nota para la configuración de pruebas BDD (local) que para la configuración de producción (que siempre tendrá un conjunto de réplicas configurado).

El siguiente script debe ser añadido a los volúmenes del contenedor ipf-mongo:

# Initiate replication on the MongoDB node

mongo --eval "rs.initiate()"

until mongo --eval 'rs.status()' | grep -q PRIMARY
do
  echo "Waiting for replication elections to finish..."
  sleep 1s
done

echo "Election is done, populating initial test data.."
sleep 2s

y command: --replSet test --bind_ip_all debe ser añadido a la configuración del contenedor ipf-mongo.