2 of 2 people found this helpful
Orphaned records cleanup in target server for data that were allowed to be deleted in Source server by ITSM functionality
The strong recommendation is that NO Administrator activities – creating/modifying forms, workflow and no data deletion activities (like dropping users, changing support groups e.t.c) should be done in current production environments during delta period, as all these will affect the upgrade done on the staging server.
Also “soft” deletion is the prolific model officially designed for in all the applications.
Hard deletes are possible, but they require they are administrative tasks that should not be done during delta period.
However we looked into the areas and the forms where we do hard deletes via functionality, to support orphan records deletion, so the below process can be followed.
Issue to get orphaned records:
· We cannot search with any date as there is no way to know when a record is deleted, so we need to do a full REVERSE compare of all the records in the form, this way we will know the records in the form that are there in the destination server but not there in the source server and we need to delete those records.
· We also have to ensure these records are not the ones created by the upgrade.
· Also we do not want to compare all forms as that will take forever and we can safely ignore if there are additional orphaned records in a backend form that does not affect any functionality.
So this is the suggested approach:
1. Identified key forms from ITSM that need to be cleaned up if records were deleted from them in the current production server. We do not allow to delete data from transactional forms and so I have not included them. I have included the relationship (associations) forms as we do allow hard deletes directly/via workflow, although this does not cause any functional issues I still added them to clean up. Customer can also add a form to the list if they know they have records to be cleaned up in that form.
2. The compare script below will do a reverse compare and give us an output compare xml missing report (which will have a list of record IDs which are not there in source/current production server)
3. Then the migrator delete script will have to be executed with compare report as the input parameter, which will delete the records based on the record IDs in the compare missing report.
The forms included in the attached xml file for compare and delete orphans are:
"CTM:People Permission Groups"
"CTM:Support Group Association"
"PBM:Known Error Associations"
1. Create a new folder under migrator installed directory.
2. Copy the attached Find_orphans_Package.xml & Find_orphans.xml to that folder.
3. Make a copy of the file - Find_orphans.xml
4. Run the below command from command prompt form the migrator installer directory
5. The Find_orphans.xml will be over-written with the results. The result will show all the IDs that are missing (no more) in your old production.
Migratorcli Reverse compare Script
migratorcli" -c -s "DESTINATION SERVER (new production)" -d "SOURCE SERVER" -u "Demo" -p "PASSWORD" --tcpport "TCP PORT" --dst_user "Demo" --dst_password "DEST PASSWORD" --dst_tcpport "DEST TCPPORT" -g "<MIGRATOR INSTALLED FOLDER>\migrator configuration.xml" --package "NEW FOLDER PATH>\Find_orphans_Package.xml" --layout 1 --logfile ".\orphans_compare.html" --missing
Migratorcli Delete script
migratorcli --delete -d DESTINATION SERVER -u Demo -p PASSWORD -t TCPPORT --difference "THE MISSING REPORT XML FILE THAT WAS GENERATED BY THE ABOVE STEP" --logfile "NEW FOLDER PATH\Find_orphans_results.html" --layout 1 --level 1