Semarchy xDM version 4.x Upgrade Check List
The goal of this document is to estimate the cost of the upgrade to Semarchy xDM version 4.x from a previous release. It lists all the important points necessary to be focused on.
This check list is not a guide explaining the upgrade process, so before to upgrade, we strongly recommend that you read the upgrade guide: https://www.semarchy.com/doc/semarchy-xdm/semug.html
A Microsoft Word version of this document is also available : Semarchy xDM v4 Upgrade Checklist
General Information
- Customer Name:
- Semarchy Version:
Technical Environment
| Component | Name | Version | Comments |
|---|---|---|---|
Web Browser | |||
Oracle Database | |||
Application Server | |||
Authentication Method (AD, LDAP, role mapping, etc.) | |||
ETL/ESB/Data Integration/Middleware | |||
| Other components... | |||
| ... | |||
| ... |
MDM Hub Information : <Hub Name>
Repeat this section for each MDM hub of the customer.
General Information
- Hub Name:
- Domain (B2B, B2C, Product, etc):
Publishers
The list of publishers is important to identify for example if one of the publishers is dedicated to the data entry
| Name | Description |
|---|---|
Entities
The number of entities in the model is critical to estimate the time required to review display cards, collections and forms after the upgrade.
ID Matching Entities
- Number of ID Matching entities:
Fuzzy Matching Entities
In version 4, data entry on Fuzzy matching entities changes. If the customer performs data entry on fuzzy matching, you have to review the current usage and define how to implement similar or better capabilities in version 4 (for example, using Override, Data-Entry Based Golden Records, etc.)
Number of fuzzy matching entities:
- Does the customer processes allow user creation on Fuzzy Matching entities? If yes, does it use a dedicated data entry publisher?
- Does the customer processes allow user edit on Fuzzy Matching entities? If yes, does it use a dedicated data entry publisher?
In version 4.x, DE Based and Master Based Golden Records do not match. This feature is in the road map, but not planned yet.
Customer authoring records in a fuzzy matched entity and expecting them to match with records consolidated from publisher should be aware that this feature is not available in version 4.
Recursive entities
Without the support of hierarchies in steppers, the user experience to author data in a recursive entity is entirely different from the v4 experience.
- Does the model contain recursive entities?
Form Views
Version 4 offers a lot of features to design nicer flows (multiple tabs, embedded collections, etc). The Form Views using the Flow layout are automatically migrated to simple Forms and simply need reviewing. Forms view using Grid layout are upgrade also to simple (Flow-like) forms and require an actual re-design effort.
- Number of Flow Form Views:
- Number of Grid Form Views:
Workflows
Simple Workflows (single task)
Single task Workflows can be replaced by one step steppers with direct actions. They are upgraded manually using the workflow upgrade wizards.
- Number of simple data entry worklows (one task):
- Number of simple duplicate management workflows (one task):
Complex Workflows (multi-tasks)
Multi-tasks workflows are upgraded into version 4.x complex workflows, into which a stepper is attached to each task.
- When a workflow uses more than one business view in a task, the upgrade process will only create a stepper for the first business view and attach it to the task. These special cases have to be considered individually.
- Duplicate management workflows involving multiple tasks and roles are not supported and must be converted as duplicate managers and duplicate management actions.
| Workflow Name | Number of tasks | User Roles | Business View(s) |
|---|---|---|---|
Web Services
SOAP web services are deprecated in version 4 and replaced by a REST API. The goal of this section is to estimate the time to migrate from SOAP web services calls to REST API calls.
List in the table below all the detailed web services uses:
| Web Service Name | Use Cases | Number of Different Calls |
|---|---|---|
PL/SQL
The PL/SQL functions must be reviewed must be rewieved for columns deprecated in v4 (for example: B_BRANCHID, B_FROMEDITION, B_TOEDITION)
Generate the model documentation with version 4 to review the list of columns available in the upgraded data structures.
List the PL/SQL functions used in the model:
| Name | Use Case | Requires update Y/N |
|---|---|---|
SQL Hooks
Similarly to the PL/SQL functions, the SQL Hooks must be rewieved for columns deprecated in v4 (for example: B_BRANCHID, B_FROMEDITION, B_TOEDITION)
List the SQL Hooks functions used in the model's jobs:
| Name | Use Case | Requires update Y/N |
|---|---|---|
Error Management
Pre-consolidation (SE_)
In version 4, errors are now automatically deleted when the record data is fixed. So if this deletion process is managed in v3 with a specific script, it must be reviewed after the upgrade.
- Does a specific developement exist to manage the errors deletion?
Post-consolidation (GE_)
In version 4, the management of the Post-Consolidation errors changes. The golden record with errors are not removed but created with a B_ERROR_STATUS = 'ERROR', even if a validation error is detected.
Therefore all the queries and API calls that consume Golden records should filter B_ERROR_STATUS != 'ERROR' or B_ERROR_STATUS is null if the need is to retrieve only the valid Golden Records.
- Does the model contain Post-Consolidation validation?
- Are there any queries/calls that consume golden records?
| Name | Technology | Must Add a filter on B_ERROR_STATUS Y/N |
|---|---|---|
Integration
In version 4, the B_BRANCHID column no longer exists in the SD_ tables. All integration mappings loading the SD_ tables and all the metadata definitions of SD_ tables have to be reviewed.
All integration tools
Some mappings to SD_ tables may change to SA_ tables. All mappings must be reviewed for their use of added or removed system fields.
- Number of SD_ tables in target in mappings:
- Number of mappings that must be reviewed:
When upgrading from version 4.1 to version 4.2, all SD_* tables for basic entities are renamed to to SA_*.
Make sure that the customer is aware that not only will ETL jobs need updating, but they should double check they have all their existing data in the transfer process. In addition to back ups, they should perhaps get at least a count so they can compare count numbers before and after.
Integrations with Semarchy Integrator
The Semarchy template must be upgraded, with the new template available from support team.