3 Replies Latest reply on Feb 27, 2014 7:09 PM by Murali Viswanathan

    How to handle record deletion in DDM

    Karthik Nagaramu
      Share This:

      Hi,

       

      We are in the process of upgrading our system from 7.1 to 8.1. And we are using the DDM to migrate the data from 7.1 to 8.1

      But does DDM handle the records which are deleted in source. Will it delete the record in destination.

      Like say people permission is removed from source will it remove the same in destination when we perform DDM?

      Any help is appreciated.

       

      Regards,

      Karthik

        • 1. Re: How to handle record deletion in DDM
          Ashok Kumar Jha

          Tagging in Murali to get his view on this. Murali Viswanathan

          • 2. Re: How to handle record deletion in DDM
            Murali Viswanathan

            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:

             

            "CFG:BroadcastHistory"                               

            "CTM:People"                                                 

            "CTM:People Permission Groups"               

            "CTM:Support Group Association"             

            "CTM:SupportGroupFunctionalRole"           

            "User"                                                               

            "AST:CMDB Associations"                             

            "CHG:Associations"

            "HPD:Associations"                                       

            "PBM:Known Error Associations"                 

            "PBM:Investigation Associations" 

            "RMS:Associations"

            “AST:Asset People”                                       

             

            Steps

             

            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

            2 of 2 people found this helpful