At the moment, at migrate time, the addition of add or remove elements is not allowed - only the update of properties within the existing elements is allowed.
Breakdown
- ACm-Runtime: Change the in validation in migrate POST to allow new elements. If a UUID element id do not match, it will be insert into the instance as new element, it will allow to add and remove elements. ACM-runtime will understand new and removed elements matching with the element-id of the migration with the old instance.
- Participant-intermediary: in migrate merge, If a UUID element id do not match, it will be insert into the instance as new elementit will merge properly elements and properties
- Participant: participant has the responsibility to deploy the new element elements and undeploy the removed elements during migration
Unresolved question:
- Participant may needs a flag to understand when an element is new.
- It will possible to understand new and removed elements matching with the element-id of the migration with the old instance
- this functionally could be implemented after new/old properties functionality (The participant needs to be aware of both the old properties and the new)
| Code Block | ||
|---|---|---|
| ||
void migrate(CompositionElementDto compositionElement, CompositionElementDto compositionElementTarget,
InstanceElementDto instanceElement, InstanceElementDto instanceElementMigrate) throws PfModelException; |
Note
The composition in/outProperties are connected to the element definition, so when an element is removed means that in/outProperties of the old composition will continue to stay available till that composition is primed.
The instance in/outProperties are connected to the instance element, so when an element is removed means that in/outProperties will be removed, and after the migration they will be not available anymore.