Sidd,
Generally speaking, the auto-deletion of Production records due to the deletion of the corresponding Staging records is not directly supported by the EnterWorks platform. It's necessary to either implement a trigger that acts on the deletion action on the Staging repository, or set up a Scheduled Export that invokes a stored procedure that cleans up orphaned Production repository records.
The reason the deletion is not automatic is that in most scenarios, records are not deleted but rendered inactive/disabled via changing attribute(s) so that those changes can be promoted and then syndicated to downstream systems. If the record is deleted from Production, there's no way to convey that deletion in syndications other that an implied deletion if the syndication is always a full export.
The cleanup by trigger would require implementing some Java code that would need to be compiled into a JAR file that would need to be deployed to each of the EnableServer services. The advantage of the trigger solution is that it it's immediate.
The cleanup by stored procedure invoked by Scheduled Export doesn't require any coding/deployment but just the creation of the Scheduled Export that invokes the already-existing stored procedure:
-- Cleanup Orphaned records from Production repository that have been deleted from Staging before the cutoff time
-- CleanupOrphanedRecordsForRepository <productionRepositoryName>,<stagingRepositoryName>,<numberOfMinutes>,<displayAttributes>
--
-- <productionRepositoryName> - name of production repository in which to find orphaned records
-- <stagingRepositoryName> - name of staging repository for <productionRepositoryName>
-- <numberOfMinutes> - number of minutes an orphaned record had to have been deleted from Staging to be cleaned up
-- <displayAttributes> - comma-delimited list of attributes to display for orphaned records. No details displayed if null
--
-- Example call: CleanupOrphanedRecordsForRepository N'PIM_Product_Production','PIM_Product_Staging',30,'SKU Group,SKU Group Auto-Id'
-Brian
------------------------------
Brian Zupke | Senior Technical Support Engineer
Winshuttle North America | 9099009179
------------------------------
Original Message:
Sent: 12-04-2020 16:09
From: Sidd Shenoy
Subject: Unlinking and Promotions
Thanks Howard. Yes just breaking the link between parent and child, which in turn automatically deletes the link record connecting the 2.
Best,
Sidd
Original Message:
Sent: 12/4/2020 4:05:00 PM
From: David Howard
Subject: RE: Unlinking and Promotions
Hi Sidd. I will run this past some folks on the team. It appears as though the promotion up to production is smooth but there needs to be a bit of a process to ensure deleted links triger a deletion in production as well. Are you using a physically deleting the 'linked' record, just breaking the link between it and a parent, correct?
@Najmul Hasan, @Daniel Okine, @John Jones, any thoughts on what Sidd might review on this?
------------------------------
David Howard | Solution Engineer
Winshuttle North America | 240-534-3511
Original Message:
Sent: 11-12-2020 15:14
From: Sidd Shenoy
Subject: Unlinking and Promotions
Hi all. Here's another interesting situation we've run into. We have a Product repo which is linked to an author repo. In the product record linked section, we've enabled the "Add link" and "remove link" buttons:
If you click the "Add link", it automatically creates a record in the link table that connects products to authors. And if you click the "unlink" button, it deletes the link record. So far so good! Here's the issue:
1) You link product P1 to Author A1
2) The link record gets promoted from Staging to Production
3) You remove the link between P1 and A1
4) The link record gets deleted in Staging but STILL exists in production.
We have multiple such scenarios (product to contacts, product to price, product to collateral, etc.) which all suffer from this issue. How have your teams worked around this problem? Any help would be appreciated!
------------------------------
Sidd Shenoy | Senior Director Enterprise Master Data
Thomson Reuters | 6465402371
------------------------------