Skip to main content

Selective XTVALUEMAP in Snapshot Management

When executing load cycles, we are using Snapshot Management to copy XTVALUEMAP from the MIGRATE database to the SRCCONSTRUCT database. This allows us to work off a snapshot of value mapping, freezing the entries and limiting risk to the load cycle from users making last minute changes or changes too late.

This all works great and works as designed. The challenge we have is when one object or one check table had entries updated in Value Mapping after the initial snapshot was taken and the load cycle started, there is no great way to bring just those entries into SRCCONSTRUCT. The only option available in ADMM is to copy over the entire table again. This reintroduces the risk we were trying to avoid.

The scenario where this happened is we are midway through a Mock 2 load cycle and are working on the sales orders object. There were new entries mapped in the TVAK table value mapping that we needed to bring in, and the client PMO approved this. We then used Snapshot Management to refresh, but this brought in unwanted changes from the TVPT value mapping. The MM team had already stated working on changes for the next load cycle and were putting in new TVPT value mappings for Mock 3, and we brought those into sales orders for Mock 2. This resulted in a bunch of manual SQL we had to do to restore it, and then going forward if we encounter this scenario again we can't really use Snapshot Management any more and have to do manually in SQL as well.

This request would be to have an option when copying down XTVALUEMAP from the MIGRATE db to only pull one table - this would eliminate the risk and avoid all manual SQL.

Status: Planned1 comment

Log in to comment and vote

Comments1

  • John Munkberg

    Team•

    Oct 23, 2024

    Because both CONSTRUCT and SRCCONSTRUCT exist in the working database, any developer can access that data directly, or refresh the full table via Replicate, or build a selective replication to refresh part of the table, or just create an UPDATE rule directly. Because ETL tasks support rules or replications you can accomplish what you need in the existing product.

    Perhaps we could add a feature to Migrate to “Refresh T005 Value Mapping”? That might be best implemented as a Stored Procedure in MIGRATE: migrate.dbo.syn_refresh_valuemapping @TARGET_DATASOURCE, @SOURCE_DATASOURCE, @CHECKTABLE

    That gets us closer - but would need a way to pass a parameter to a RULE in Migrate - else you would need to put a wrapper procedure around this procedure to specify the variables…

    OK - talked myself into creating a Feature Request with engineering to investigate this idea some more…