Page History
Uit de specs
As project, I want to be able to keep my old dossier entries when replacing the dossiermanager with the new aggregate functionality.
Introduction
In 9.4 we introduced aggregates to are now more and more enthusiastic about this feature. From one project we know they only want to use it, when can the new aggregate solutionId is not relevant
- A project that wants to migrate
The idea is that a project
- has to make an exposed migration flow.
- In this flow you first call the
AQ_DossierManagerto load the existing dossier into the profile. - The
- next step is to use the
AQ_Aggregate_Createservice to create a new aggregate entry. Like this, a project 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_SetRequestParametersservice. - 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.
Id is relevant
- A project that wants to migrate has to make an exposed migration flow.
- In this flow you first call the
AQ_DossierManagerto 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), we would
- like to start with an empty aggregate database, and use aggregate Ids that match the
- Ids as for the dossiers.
- For this, a
- service is available,
AQ_Aggregate_Migrate.
Specifications
- A new service is created This is a copy of the
AQ_Aggregate_MigrateThis is a copy ofCreateservice and has the same parameters than theAQ_Aggregate_Createservice, with one addition: a parameter calledDossierIdInput. - It This is not part of the aggregate pluginThis , 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.
- You may even go so far and convert it to .Net by hand, and not add it to the .Net conversion scripts. .
- This parameter
DossierIdInputThis service has the same parameters than theAQ_Aggregate_Createservice, with one additionA new parameter is added, calledDossierIdInputIt is of type expression The expression and should return an integer - At runtime, the new aggregate entry is created under this Id Any unexpected behavior, results in an error at runtimeFor example that the supplied a positive integer. If not, an error is thrown. If the Id already exists, or is a negative number
- an error is thrown.
Wij zijn idd aan het werken aan functionaliteit welke de overgang makkelijker gaat maken. Deze wil ik graag aan je toetsen. Er komt natuurlijk nog een uitgebreide handleiding over hoe dit zou moeten.
We maken een nieuwe AQ_Aggregate_Migrate service, welke hetzelfde doet als de create service, maar je kan zelf het id bepalen van de nieuwe entry in de db (error als al bestaat). Om nu alle dossiers in 1 klap over te zetten naar aggregates, ga je dus een flow maken, waarin je met de dossier manager een dossier met ID X inlaadt, en deze dan als aggregate met hetzelfde ID X wegschrijft. Door de IDs hetzelfde te houden hoeven referenties naar dat ID in externe modules/systemen niet geupdate worden. Door het zo te doen, kan je dus evtl ook een dossier splitsen in meerdere aggregates als je dat zou willen, of extra meta data toevoegen welke je nu niet hebt met de dossiermanager. Nu moet je nog deze flow aanroepen voor elk dossier dat je hebt, en het ID parsen als onderdeel van de URL. Dat kan je via de BB_SetRequestParameters service binnen halen. Wij kunnen geen generieke code maken welke voor je over de dossierdatabase loopt en de url aanroept, omdat hier te veel project specifieke keuzes in zitten. Je hebt bij voorbeeld verschillende dossier types in je database, en dan moet voor elk dossier type een andere migratie flow aangeroepen worden. Dus dat is dan het enige wat je zelf zou moeten doen. Deze migratie is dus niet lazy, en kan in 1 keer gebeuren.
Als je het lazy zou willen, zou dat dus in je model zelf kunnen regelen. Dus zolang je geen aggregate ID hebt lees je een dossier in en schrijf je een aggregate weg en verwijder je het dossier. Als je wel al een aggregate id hebt, lees je het aggregate id gewoon in. Ik zou dan echter niet de migrate service willen gebruiken, maar gewoon de create, omdat je toch al op productie draait, zou je dan alle IDs kunnen updaten naar een nieuw ID. Je zult dan zien dat in de loop der tijd je dossiers minder en minder worden. Wat ik wat minder mooi vindt is dat dit migratie model dan gewoon op productie staat, en daar best een tijd moet blijven staan.
Step-by-step guide
| type | note |
|---|
| UI Expand | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
| Include Page | ||||
|---|---|---|---|---|
|
Overview
Content Tools