Documentation for a newer release is available. View Latest

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

Los siguientes pasos describen lo necesario para que los servicios migren de DPS v1 a DPS v2.

Eliminar módulos no utilizados

Los módulos de repositorio usados previamente por DPS v1, setting-<setting-name>-repository deben eliminarse de los proyectos ya que ya no se usan en DPS v2. Toda la configuración ahora está bajo los módulos de dominio setting-<setting-name>-domain.

Crear índices

En DPS v1 los índices para cada configuración se proporcionaban listos para usar. En DPS v2 los índices pueden crearse a través de configuración HOCON. Para cada configuración debe haber un conjunto de índices creados a través del 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 el payload de la configuración deben referirse como values.payload.<field-name> en los índices.

La página DPS Index Creation contiene más información sobre la creación de índices.

Notificaciones

DPS v2 puede proporcionar notificaciones después de que se realice cierta operación sobre una configuración. Estas notificaciones están deshabilitadas por defecto y pueden configurarse 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 notificaciones 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	history enabled - Si rastrear el historial de cambios de la configuración o no. Está habilitado por defecto.
2	notifications enabled - Si enviar notificaciones Kafka cuando la configuración es creada, actualizada o eliminada. Está deshabilitado por defecto ya que DPS v1 no tenía esta funcionalidad.

Kafka debe desplegarse para enviar/recibir notificaciones. Ejemplo de cómo configurar el tópico 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 sobre cómo implementar el endpoint de recepción para estas notificaciones Kafka puede encontrarse aquí DPS Client Notification

Conectores y consultas directas

La mayoría de los servicios que usaban DPS v1 implementaron sus propios conectores y consultas directas. DPS v2 los proporciona listos para usar.

Una descripción detallada de cómo importarlos puede encontrarse aquí Connector and Direct Implementations La sugerencia es usar las interfaces de DPS v2 en lugar de implementaciones personalizadas del servicio para evitar cualquier mala configuración.

El mejor enfoque sería cambiar las implementaciones personalizadas del servicio para usar DpsSearchClientPort, DpsCrudClientPort, DpsHistoryClientPort y otras interfaces proporcionadas, y configurar propiedades específicas (connector o direct) como se describe en la página indicada arriba.

Bases de datos

DPS v2 introduce configuraciones programadas y usa Persistence Scheduler para su mantenimiento. Para configurar adecuadamente el persistence scheduler es necesario crear dos nuevas colecciones y sus índices. La siguiente configuración debe agregarse 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

Dado que DPS v2 usa change streams, MongoDB debe tener replica set para que los change streams 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á replica set configurado).

El siguiente script debe añadirse 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 añadirse a la configuración del contenedor ipf-mongo.