Phase 2 — Migration per Aggregation Definition
In the standard upgrade scenario, most of the configuration required to use the integrated DAM is handled automatically during the upgrade process. This significantly reduces the amount of manual configuration required by the customer.
What Happens During the Upgrade
During the upgrade, the system attempts to automatically create the required parameter record. This automated step is intended to minimize manual setup and ensure that the integrated DAM can be used with minimal customer intervention. In most cases, this automatic configuration succeeds.
When Is Manual Configuration Required?
The manual configuration steps described in the main instruction are only required if the upgrade process could not create the parameter record automatically. This can occur, for example, if the existing SX configuration was not set up according to the standard configuration guidelines.
| If the parameter record was: • Not created, you must configure the implementation manually by starting at Step 1 |
Using the Integrated DAM (Standard Scenario)
If the parameter record was generated automatically during the upgrade, follow these steps to use the integrated DAM:
1. Disable the ContainerSX
Disable the ContainerSX (registered on the Data Aggregation definition BO) that was previously used for the old DAM.
2. Disable the ReportSX
Disable the ReportSX (registered on the Data Aggregation definition BO) associated with the old DAM setup.
3. Link the Definition to the Parameter Record
Link the relevant definition to the parameter record that was generated during the upgrade.
After completing these steps, the integrated DAM is active and ready for use.
Step 1 — Capture existing SX parameters
In Field definer :
1. Open the UDBO where ContainerSX is registered and copy the full parameter block.
2. Do the same for ReportSX.
3. Store both parameter sets so you can paste them into the new BO.
| Migration relies on manual copy/paste; the system does not provide an automated transfer. |
Step 2 — Create a Data aggregation parameters record
In the DAM TSI, open the Aggregation definition and navigate to the Aggregation parameters step. Create a new record in the Data aggregation parameters BO and complete the fields:
• Container parameters: paste the full ContainerSX parameter block
• Report parameters: paste the full ReportSX parameter block
• Data aggregation properties reference: select the same record used in the current SX setup
• Standard system fields are populated as usual
Each Aggregation definition requires one parameters record.
Step 3 — Link the Aggregation definition to the new parameters
Open the Aggregation definition BO and set the Data aggregation parameters (AggregationParametersRef) field to the new Data aggregation parameters record. Save the record.
Behavior before feature switch activation:
• If the field is empty → DAM uses old SX behavior
• If the field is filled → DAM uses new product behavior
After activating the improved feature '
Disable Data Aggregation Manager SXs'
• The reference becomes mandatory
• SX execution is disabled
Step 4 — Deactivate conflicting SX registrations
If the Aggregation parameters (AggregationParametersRef) field is filled but SX registrations still exist on the same BO, the system shows an error. To resolve this:
1. In Field definer , deactivate ContainerSX and ReportSX from the Aggregation definition UDBO.
2. Save the BO definitions.
3. Ensure the Aggregation parameters (AggregationParametersRef) field is filled correctly.
The system may show a warning if other SXes remain. These can remain until the improved feature is activated.
Step 5 — Configure the BOM to replace ContainerSX
The old ContainerSX logic (AI/AU triggers) is replaced by the action Create/Update aggregation data records (BOMCreateUpdateAggregationDataRecords).
On the Aggregation definition BO:
• Add the action to the layout.
• Choose how it is triggered:
◦ Make it a manual action
◦ Automate it through an Action definition + Alert condition for scheduled runs
Step 6 — Confirm statemodel triggers for ReportSX
ReportSX continues to be triggered by status changes, as configured in Data Aggregation Properties. Verify:
• Trigger statuses are correctly defined in Data aggregation properties
• The Aggregation definition BO contains all required statuses
• Users or automated processes can move the record to the trigger status
The parameter execute.on.status.change becomes obsolete; ReportSX is always triggered by status changes in the new solution.
Step 7 — Functional testing
For each migrated definition:
1. Create or update an Aggregation definition in DAM.
2. Click the Create/Update aggregation data records action and verify the Aggregation data level is built correctly.
3. Change the status to the ReportSX trigger status.
4. Confirm that:
◦ Data and Details levels are created as expected
◦ Aggregated values match previous SX behavior
◦ Status behavior remains correct
If possible, compare with a non-migrated environment to validate results.