1 2 Previous Next 18 Replies Latest reply on Jul 9, 2020 9:26 AM by Samo Puharic

    Do not delete CIs created by ADDM >= v10.2

      Share This:

      In ADDM v10.2 it looks like ADDM keeps its own 'shadow copy' of the CIs in the dataset you are syncronizing to. I believe this has been done to speed up syncronization. A consequense of this is that if you delete a CI in your import dataset (e.g with a recon job) when the host is not aged out in ADDM, ADDM fails to update the CI next syncronization since it does not exist, and will not create a new CI (as it would previously do). To fix a situation like this, you have to make ADDM rebuild the whole 'shadow copy'.

      Can others verify this also?

        • 1. Re: Do not delete CIs created by ADDM >= v10.2
          Devendra Yadav

          without being specific to ADDM, in general one should never delete data from Source/Import dataset till the time it's exists in golden dataset. this helps in backtracking the CI's history. if you pick a CI is golden dataset you can trace and find what data has came from which source dataset.

           

          Best Practice for ADDM is - Don't do any update or delete in dataset configured for ADMM let ADDM manage data in that dataset.

           

          Thanks,

          Devendra

          • 2. Re: Do not delete CIs created by ADDM >= v10.2

            Hi Devendra and thanks for your quick reply,

            There are scenarios where I believe you need to delete/purge data from import datasets. For instance when ADDM ages out a host and sends a Status=Delete to the dataset. If ADDM later re-discover the same host, it gets treated as a new host there. If you have not deleted/purged the CI in the imprto dataset, a syncronize will then either fail or create a duplicate (depending on which Atrium version you are on).

            • 3. Re: Do not delete CIs created by ADDM >= v10.2
              Duncan Grisby

              As Devendra says, in general, you should not manually edit any import dataset in CMDB, because doing so is likely to confuse the provider's knowledge of what it has previously stored in its dataset. A purge after handling a marked as deleted CI is not, however, a manual edit, so it is fine to do that.

               

              To handle manual edits, ADDM has a resync feature. If you do delete CIs, or otherwise change the ADDM dataset, you should use resync to get it back into synchronization.

              • 4. Re: Do not delete CIs created by ADDM >= v10.2
                Devendra Yadav

                Purge is part of reconciliation engine process , once ID and merge is done purge can run and it will not cause any issue. while running purge best thing is have verify in target enabled so only those CIs get purged for which MAD value is updated to target dataset and you don;t land is situation where ci got purged from source but it's still live in target dataset.

                 

                Thanks,

                Devendra

                • 5. Re: Do not delete CIs created by ADDM >= v10.2

                  But we (and I guess many other customers also) can not just delete CIs in target/gold dataset because ADDM says so. We are obliged to keep the CIs in BMC.ASSET for some years after the actual items is disposed of.

                  Of course, I could have a seperate dataset where i kept the disposed CIs, but that is both not very user friendly in the ITSM UI, and also presents difficulities when a CI that was supposed to be disposed is rediscovered.

                  This is a fundemental difference between ADDM and the CMDB; ADDM is a "live" tool, aging out what it does not find anymore, and then treats rediscovered items as new ones. CMDB is a tool used by many processes, som needing historical data. The only thing ADDM really knows is wether the CI is not discovered, it does not know if the CI is disposed of. My opinion is that ADDM should not be allowed to set MAD=Yes. It should tell the CMDB how many unsuccsessfull attempts it has in scanning the host and the time of these attempts. This should be syncronized to dedicated attributes on the CIs in the CMDB, and then the CMDB should decide the aging based on the need of the customers of the CMDB-data.

                  • 6. Re: Do not delete CIs created by ADDM >= v10.2
                    Duncan Grisby

                    The approach you describe is the intent of the MarkAsDeleted field. A provider (any provider, not just ADDM) is meant to set MarkAsDeleted to Yes if it thinks a CI no longer exists. It is then up to the merge rules as to how that is handled in ASSET. As you say, it is normal to keep CIs in ASSET after they have been deleted by the provider, rather than blindly deleting them just because a provider says so.

                    • 7. Re: Do not delete CIs created by ADDM >= v10.2

                      The MAD=Yes gets merged OOB with all other attributes to the golden dataset. ADDM should not be allowed to say that a CI in the golden dataset should be marked as deleted. It is of cource possible to have the MAD attribute to not update the golden dataset, but setting MAD=Yes also triggers the Status attribute to be set to Delete, and this might overwrites a status set by other processes.

                      The only thing ADDM knows is wether itself has scanned the item or not, not that it should be deleted in the golden dataset.

                      • 8. Re: Do not delete CIs created by ADDM >= v10.2
                        Gustavo del Gerbo

                        Johannes, you can set the ADDM precedence rule for Merging to a low number for the MAD attribute so that if ADDM decides to put a Yes there then that Yes is not merged to ASSET. Your CI will remain there and you can mark it as deleted through other processes.

                        • 9. Re: Do not delete CIs created by ADDM >= v10.2

                          Hi Gustavo,

                          Yes, that was what I meant saying "It is possible to have the MAD attribute to not update the golden dataset", but since setting MAD=Yes also sets Status=Delete, it does not help much, since we do not want to set the ADDM precedence rule to not update the Status attribute. If we did that, a rediscovered CI would never change Status to Deployed (if it for instance was changed to Disposed). Therefor I still believe ADDM should only tell  the CMDB what it knows, i.e. whether the CI is scanned or not.

                          (The workaround for this issue is to run the purge job before the merge job.)

                          • 10. Re: Do not delete CIs created by ADDM >= v10.2
                            Carey Walker

                            Interesting discussion here.

                             

                            In various environments I've worked in, we find the behaviour between the MAD flag (going to Yes) and the CI status (going to Delete), really annoying.

                             

                            I think this is actually where the problem lies for this scenario.

                             

                            I agree with Duncan's view above that ADDM, or any other discovery source, should use the MAD flag as it does. What I'd prefer to see is that it then becomes the choice of each customer to define what process they wish to see follow from there.

                             

                            The majority of customers will, I believe, want to use that MAD flag to detect when this has happened and do what makes sense for them. They DON'T want the CI status set to Delete. The more common requirement would be to see this CI set to Disposed or similar (maybe a custom status like Decommissioned) since this is typically what ADDM is telling us. This would certainly be an Asset Manager's requirement. You simply don't delete a CI when you need an AM view of the world.

                             

                            Since the physical item in question here may come back into discovery scope later (either a CI with the same name, OR a CI with an new name but the same physical characteristics like serial number etc.) the process followed here may need to include renaming the MAD CI as well as setting its status as suggested above.

                             

                            So, in summary, I'd vote that ADDM should continue doing exactly what it does, and that we should look at how we can define what happens to the CI status in this case, rather than the current workflow.

                            1 of 1 people found this helpful
                            • 11. Re: Do not delete CIs created by ADDM >= v10.2

                              Hi Carey:)

                              I'll agree that if the MAD-flag is originally intended for the source data to own, it make sense that ADDM uses this when the host is aged out there. But as you say, this should not trigger the Status to be set to Delete in the CMDB. Futhermore, there should have been an OOB aging functionality within the CMDB to automatically change the Status based on certain qualifications. (We have made this, but it got pretty complicated when we upgrader from 7 to 8, and the AST:Attributes was introduced:)

                              Regarding ADDM: I think the syncronization ADDM->CMDB should send successfull/unsuccessfull scan attempts including the time of these. This is definately interesting information for some consumers of the CMDB data.

                              • 12. Re: Do not delete CIs created by ADDM >= v10.2
                                Gustavo del Gerbo

                                The MAD flag affecting the Status of the CI is in fact an Asset Management functionality and Asset Management brings the workflow for it. The CMDB does not react to the MAD flag being moved around, and in fact I believe the above mentioned workflow should (or in other case I would suggest AST may have a defect) affect ONLY BMC.ASSET records and not any other records. The functionality should be easily changeable if one customizes or alter this workflow piece/s.

                                • 13. Re: Do not delete CIs created by ADDM >= v10.2
                                  Carey Walker

                                  Hi Gustavo

                                   

                                  As you've suggested, the functionality (MAD and Status) is only evident when you have AM in the mix (the MAD flag can be updated on the CMDB forms or by an integration like ADDM), but it only affects the status of CIs in BMC.ASSET as you've suggested, so all is well on that front. I think the ideal would be to have the behaviour configurable, so each customer can choose. One option would be to have a choice of the status value you want set when MAD is set, perhaps also with an option not to update Status at all. i.e. leave it up to the customer to determine the best approach for their requirements.

                                  • 14. Re: Do not delete CIs created by ADDM >= v10.2
                                    Petrus Johansson

                                    Further along those lines, when a CI is updated to Delete staus,all ITSM relationships are removed which is bad.

                                    1 of 1 people found this helpful
                                    1 2 Previous Next