Versions Compared

Old Version 9

changes.mady.by.user Unknown User (d.necas-niessner)

Saved on

compared with

New Version Current

changes.mady.by.user Tijmen Daatselaar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

In Blueriq aggregates are the out of the box way to realize persistency. These aggregates will replace the existing dossier manager. Projects that use the dossier manager might want the existing dossier entries from the production environment to be migrated to aggregates. This migration needs to be easy and configurable. Configurable for instance because a dossier will be split into more aggregates or because migration needs to be done lazily. Another possibility is that the Id of the aggregate needs to be the exact Id of the dossier, since the Id might play a role in other parts of the application.

Panel

In this How-to

Table of Contents

This how-to concerns this content migration, by modeling a flow that migrates a dossier to an aggregate. Three scenarios will be discussed.

Id is not relevant

When dossiers need to be migrated to aggregates and the Id of the newly created aggregates is not relevant in other parts of the model, follow these steps:

  • A project that wants to migrate has to make an exposed migration flowcreate a Baas or custom service.
  • This service should be called for every dossier Id in the database.
  • In this flow you first service you then call the AQ_DossierManager to load the existing dossier into the profile.
  • The next step is to use the AQ_Aggregate_Create service to create a new aggregate entry. Like this, a project team can define itself exactly how dossiers are migrated, extra metadata can be added, dossiers can be split, etc.The flow is exposed, and should be called for every dossier Id in the database. It can be passed as parameter in the URL, and retrieved from there with the BB_SetRequestParameters service.
Info

The code to query the dossier database, to select the applicable Ids, and passing them one by one to the exposed flow is left to the project team.

Id is relevant

When dossiers need to be migrated to aggregates and the Id of the newly created aggregates is relevant in other parts of the model, follow these steps:

  • A project that wants to migrate has to make an exposed migration flow.
  • In this flow you first call the AQ_DossierManager to load the existing dossier into the profile.
  • As the dossier Id might be stored in many surrounding systems (such as in the profile of the process engine), it is necessary to start with an empty aggregate database and use aggregate Ids that match the dossier Ids.
  • For this, a service is available, AQ_Aggregate_Migrate.
  • This is a copy of the AQ_Aggregate_Create service and has the same parameters, with one addition: a parameter called DossierIdInput.
  • It is not part of the aggregate plugin, nor is not included in the standard package delivered to projects. Projects need to ask for the dll or jar when they want to migrate.
  • This service should not be included in the regular model, and only used once for migrating.
  • This parameter DossierIdInput is of type expression and should return a positive integer. If not, an error is thrown. If the Id already exists, an error is thrown.
  • The flow is exposed, and should be called for every dossier Id in the database. It can be passed as parameter in the URL, and retrieved from there with the BB_SetRequestParameters service.
  • The code to query the dossier database, to select the applicable Ids, and passing them one by one to the exposed flow is left to the project.

Lazy migration

In a situation where it is not preferred to execute a migration flow for each dossier (irrelevant of the fact whether the dossier Id needs to be preserved or not), a flow can be created to mimic lazy migration. All that needs to be done in this situation is add a condition that checks upfront if the Id of a dossier that is to be read already exists in the aggregate database. If so, the aggregate is read, if not the dossier is read and migrated to an aggregate and the dossier is deleted. After that, the normal flow continues with the aggregate. In this situation, the AQ_Aggregate_Create service can be used when the new aggregate Ids may differ from the dossier Ids, but also the AQ_Aggregate_Migrate can be used when the Id of the aggregate must match the Id of the dossier.
The downside of this scenario is that this migration flow will exist for quite a long time in the production environment.

Include Page_survey_surveyplease contact support about the possibilities.