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

Los siguientes pasos describirán lo que es necesario para que los servicios se trasladen de DPS v1 to 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 de forma predeterminada. En DPS v2 se pueden crear índices 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 útil 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

DPS v2 puede proporcionar notificación después de que se realice cierta operación en una configuración. Estos notifications están deshabilitados 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 notifications habilitado- Si debe enviar Kafka notifications cuando se crea, actualiza o elimina una configuración. Está desactivado por defecto ya que DPS v1 no tenía esta funcionalidad. 
Kafka necesita ser implementado para enviar/recibir notifications. Ejemplo de cómo configurar kafka tema y notifications:
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 notifications se puede encontrar aquí xref:getting-started/integration/dps-api-client-notification.adoc[Notificación al Cliente de DPS]

== Consultas de Conector y Directas

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

La descripción detallada sobre cómo importar estos se puede encontrar aquí.xref:getting-started/integration/client-library.adoc[Conectores e Implementaciones Directas]
La sugerencia es utilizar DPS v2 interfaces 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

 DPS v2 introduce scheduled configuraciones y usos Persistencia Scheduler para su mantenimiento. Con el fin de 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):
[source,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:
[source,shell]

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.