3 Replies Latest reply on Sep 19, 2017 6:37 PM by Carey Walker

    Ast:Attributes - having some issues

    Ryan Wiltshire

      This is probably a common thread but here we go.

       

      I am migrating data from CMDB version 7.6 into a new version 9 instance.  I have wrapped my head around the data model changes that moved some attributes from BMC.Core into AST:Attributes.  I don't see the benefit but I understand the model at least.

       

      My data migration is using AI jobs to export select data from v7 into a staging data set in v9. I am keeping reconciliation identity the same to make merge easier.

       

      I initially tried to import the AST data directly into AST:Attributes. I set the qualification to use reconciliation identity. I also mapped instanceid. I found that instanceid was nulled out on create. Once the BMC.Core record merged, the instanceid did not get set for these records either. I ended up with errors about submitter mode when attempting updates in the web front end for the CI.  I assume some workflow tried to create/update the attributes record and failed.

       

      I then turned my attention to AST:LoadAttributes. Using this form I get the data in and functioning without errors after reconciliation occurs. I again set the qualification to reconciliation identity and updated instanceid. After reconciliation, the LoadAttributes record gets pushed to Attributes with all the right values.

       

      Question(s):

      Is there a way to load data directly to AST:Attributes? Or is using the AST:LoadAttributes form the best practice method from BMC? Outside a data migration, I have a few import data jobs that feed from sources that would update AST fields like Asset Tag. I would be happy to know the best practice approach before getting too far into the process.

       

       

      Thanks

        • 1. Re: Ast:Attributes - having some issues
          Carey Walker

          Hi Ryan

           

          Using AST:LoadAttributes is definitely the recommended way to achieve this. All the workflow to make this hang together is now built into the process, so you will find this more robust.

           

          One other observation. Re-using the recon.ids from V7 may not be such a great idea. Generally these GUID type identifiers which the system generates , are only guaranteed to be unique within an AR Server instance. So it is possible (probably remotely) that you may generate a recon.id in V9 that duplicates one brought across from V7. I know this is a pain, given the alternative is to run a somewhat redundant ID activity using the recon. engine, but will keep it clean.

          2 of 2 people found this helpful
          • 2. Re: Ast:Attributes - having some issues
            Ryan Wiltshire

            Thanks Carey.

             

            For the reconciliation comment, you mean CMDB keeps a running list of reconciliation identities? I had though recon id is unique by data set and enforced at some level.

             

            To some clarity, we are migrating from a well used v7 instance to an empty v9 instance. I didn't expect any issues with bringing over recon id to make merging and carrying over other data like asset people etc... easier.  I was/am hoping to avoid writing recon rules for my v7 data.

            • 3. Re: Ast:Attributes - having some issues
              Carey Walker

              Sorry for delay - been travelling a bit.

               

              Re recon. ids - no the CMDB doesn't keep a running list as such, whenever a new recon. id is needed it uses some algorithm to generate it - and that algorithm uses some local AR server attributes to generate the RE ID. I am saying that by copying RE IDs from V7, instead of letting the V9 Recon process generate them as part of the migration, then you have a small risk of duplication. The cleanest approach would be to move the V7 data to a staging dataset in the V9 environment, with RE IDs set to 0, then run a recon job to ID them and merge to golden dataset. End result is the same but there is no risk of dupe recon. ids being created.

               

              If you haven't seen any issues to date, then perhaps you can relax and just take this as something to keep in the back of your mind (and avoid writing RE jobs etc for all of this)