1 2 Previous Next 27 Replies Latest reply on Aug 8, 2013 5:50 PM by Carey Walker

    CMDB V8.x and lifecycle attributes

    Carey Walker
      Share This:

      Currently in the middle of planning for our 7.6.x to 8.1 upgrade.


      I've read the various docs around the changes in the CMDB for 'lifecycle attributes' and generally understand what's happening. What I'm missing is the big-picture understanding I like to think I have now for the end-to-end implications of these changes. Things like custom attributes, discovery integrations, normalization  reconciliation etc which all have the potential to be impacted. If there is something in the 8.1 docs that covers this in an overview/summary then hopefully someone can point me there. In the apparent absence of that, here's the first set of notes of my understanding (or perhaps confusion ) and questions for the 8.1 experts out there..


      • lifecycle attributes are now removed from the CMDB class forms and placed on a new form called AST Attributes. This form is joined (based on RE ID) with the relevant CMDB class form to present the complete 'asset' view in the AST:XX form.
      • the list of attributes deemed 'lifecycle' that were removed are listed in the CMDB V8.1 docs
      • some attributes possibly considered as 'lifecycle' were kept on the class forms for a variety of reasons, and these are also listed in the V8.1 docs
      • when adding custom attributes in the new environment, we'll need to first determine whether these are 'lifecycle' type attributes or regular CMDB attributes. The latter are handled as they always were. For the former, the docs say To store lifecycle data for a CI, you must add a field on the AST:Attributes form that is installed by BMC Remedy IT Service Management version 8.0 and later. First question here - how?? Is this done via Developer Studio?? I've hunted for where this process is explained but so far no joy.
      • when adding custom attributes via Class Manager, you specify a namespace. Is BMC.AM as a namespace still relevant? What happens if I add a custom attribute in that namespace?? In my test 8.1 build, if I look at BaseElement I can still see attributes belonging to BMC.AM namespace. These are the lifecycle attributes mentioned above that have remained in the CMDB class forms?? I was thinking that the BMC.AM namespace would have disappeared?
      • For integration tools like AIE and AI, are there any things to look out for. Example, I have an AIE job that loads data into ComputerSystem class form. If that job currently provides a value for a 'lifecycle' attribute (for whatever reason) the job would not work now since that attribute is not on this form any more. Do i have to now have pairs of AIE jobs, one for the regular CMDB attributes in the CMDB class form and one for the attributes that now live on the AST:Attributes form? I understand the intended distinction between lifecycle attributes (not typically discoverable) and CMDB attributes, but AIE and AI can be used for many different purposes, so finding a mix of lifecycle and non-lifecycle attributes in a single AIE job, say, is a possibility.
      • Normalization Engine. V8.1 allows us to define custom normalization rules (great new feature). It seems that lifecycle attributes may not be able to participate in this feature? Again, it may be that this is intended since these types of attributes would not typically need normalization.
      • Reconciliation Engine. In a similar vein, do lifecycle attributes need to participate in the recon. process?? Seems not, as one of the benefits of this new approach is to remove the need for processing of these types of attributes.
        • 1. Re: CMDB V8.x and lifecycle attributes

          Wow all are excellent points. I hope some one from BMC would respond to this and provide some guidance.

          We also have similar ambiguity around life cycle attributes,AI and Reconciliation jobs.

          They removed Status from CMDB and made it part of AST:Attributes.

          We discover or load some CIs from ordering, asset mgmt systems. We use this data for impact analysis.

          Since Status is not part CMDB any more we are are thinking whether we have to have individual AI jobs to load  BMC_ComputerSystem for CI data and AST:Attributes form for CI  Status and also two difference reconciliation jobs for status related reconciliation.

          • 2. Re: CMDB V8.x and lifecycle attributes
            Laurent Matheo

            Ok discard the two posts I posted earlier, I'm amazed at the garbage I can post sometimes


            So I tried something, instead to import to BMC.CORE:BMC_ComputerSystem, I imported into the AST:ComputerSystem this csv file using Data Import:

            Status and Floor are on AST:Attributes:





            As you can see it worked, it added data to BMC.CORE:ComputerSystem and AST:Attributes:





            In my previous post (the garbage one), I imported the csv file into BMC.CORE:BMC_ComputerSystem directly and it created the record fine BUT then the values in AST:Attributes were the "default" values:




            It created the record in BMC.CORE:BMC_Computer System with status "2":




            But the status in "AST:ComputerSystem" is Deployed (3):



            Because it's simply the default value in AST:Attributes form:


            And there is a record for it (but with default values):


            1 of 1 people found this helpful
            • 3. Re: CMDB V8.x and lifecycle attributes
              Laurent Matheo

              There is an interesting post from Doug Mueller here on the CMDB API where he talks briefly about the AST:Attributes:

              CMDB 8.0 API

              As far as I understand it, the API "sorts it out" (?).


              Perhaps indeed the only way to add an attribute "AST" is to enter it manually in AST:Attributes (dev studio), anyway you can't find "Floor" for example or other "AST:Attributes" attributes in the class manager.


              Perhaps another step would be to give the list those attributes into the class manager (perhaps in another color or something) and to add the possibility to add one "ast:attributes" from the class manager (?).


              Btw when you update the "status" in the "AST:ComputerSystem" it seems it updates the record in "AST:Attributes" but it doesn't update the one in "BMC.CORE:BMC_ComputerSystem" which is in fact stored in "BMC.CORE:BMC_BaseElement".

              1 of 1 people found this helpful
              • 4. Re: CMDB V8.x and lifecycle attributes

                That kind of works but

                1) The AST forms does not expose all the fields in the BMC.CORE forms.

                    So you cannot import all the CI data through AST forms or we need to add all fields used in cmdb dataload to add it           to AST views.

                2) We have to discard the OOTB AI jobs or CMDB AI plugins which point to BMC.CORE forms and create our own AI jobs..

                3) BMC always said never import data directly into AST dataset. Now it is  kind indirectly saying you can now import some data to AST forms directly.

                4)Some of the fields (ex:Status) cannot be now part of custom or standard reconciliation jobs.

                   So we need to write the reconciliation logic into the AI jobs before loading.


                Again I am not saying it is all bad, it is just different approach and BMC  might have thought through all of these and it would be helpful if they provide some kind of whitepaper or a blog addressing these.

                • 5. Re: CMDB V8.x and lifecycle attributes
                  Laurent Matheo

                  Well I'm not a CMDB guy so you know... Sometimes I don't follow the "best practices"


                  Let's see if Doug Mueller or Anand Ahire can help you on this.

                  • 6. Re: CMDB V8.x and lifecycle attributes
                    Carey Walker

                    Thanks for the above comments all.


                    I've read the posts from Doug on this and understand the concept (and think it's a very sensible move).


                    It was more an understanding of the operational implications I needed clarity on, and the documentation isn't 100% there yet for these.


                    Summarizing what we've seen above and what I've observed since my original post...


                    1. The API clearly understands the new structure, and the imports Laurent experimented with also help show what's going on 'under the covers'. The AST:ComputerSystem import correctly handles the placement of the relevant attributes on the right underlying forms - BMC_ComputerSystem (or probably more correctly BMC_BaseElement and BMC_ComputerSystem_) and AST:Attributes. When you view the result on AST:ComputerSystem, the join of the underlying forms gives you the right answer.


                    However, I was still confused by the first attempt, the import on BMC_ComputerSystem. I understand that when you import into BMC_ComputerSystem (not AST:ComputerSystem) the lifecycle attributes have nowhere to go in theory. I also understand that every record in BMC_ComputerSystem will have a corresponding record in AST:Attributes, linked via RE ID. I had assumed that the import ignores the lifecycle attribute in this case (BMC_ComputerSystem import), but goes ahead and creates almost a 'dummy' AST:Attributes record to complete the picture. That dummy has only the RE ID of the other BMC_ComputerSystem and default values for other attributes (like Status=3). I'm just guessing here and will be pleased to be corrected. The confusion was why you see a status on the report for CI 123456 of 2???? The answer seems to be that the status field (field id 7) is still on the BMC_ComputerSystem form, but you never see it now because all references to it (and the other lifecycle attributes) are removed from the base class forms. Obviously the report fields selection dialogue still shows these fields.... The import happily populated that attribute when you imported into BMC_ComputerSystem and hence you can see it on a report (even if nowhere else )


                    I'm still looking for someone to explain what we do if we decide we need to add a custom attribute that is deemed to be a 'lifecycle' attribute. Understand that it needs to go onto the AST:Attributes form, however what is the process to achieve this? IS it simply a case of adding via Dev Studio?? Or is there another method provided now?


                    There are also still several questions from my original post that I'd love to hear expert answers to.



                    • 7. Re: CMDB V8.x and lifecycle attributes
                      Carey Walker

                      IS there someone from BMC Atrium product area that can look at these posts and help clarify for us?? Please!

                      • 8. Re: CMDB V8.x and lifecycle attributes
                        Laurent Matheo

                        I guess that the buyout is quite disturbing the BMC guys...

                        Let's try to ping Anand Ahire again

                        • 9. Re: CMDB V8.x and lifecycle attributes
                          Jarl Groneng

                          A webinar earlier this year they (BMC) explained that new attributes should be added using the class manager. And those attributes then goes into the CMDB classes. Just like before.

                          • 10. Re: CMDB V8.x and lifecycle attributes
                            Carey Walker



                            Unfortunately it's not the same as before. I can add a new attribute to the Class Manager in 8.1, no problem. But as you say, it just goes into the CMDB classes. What I'm talking about is a lifecycle attribute that the new approach requires us to NOT add to the CMDB forms. It should be added to the AST:Attributes form. Adding via Class Manager won't do this. Or at least I haven't figured out how to make do this!

                            • 11. Re: CMDB V8.x and lifecycle attributes
                              Jarl Groneng

                              From how I understand this, is that your own lifecycle attributes should still go in the CMDB. Yes, it gets messy with some lifecycle attributes in AST and some in CMDB.


                              It seems that it is missing something here. Maybe version 8x will address this even more? So we can add lifeycle attributes to AST and CMDB attributes to the CMDB.

                              • 12. Re: CMDB V8.x and lifecycle attributes
                                Carey Walker

                                In the BMC docs, when it discusses this, it very clearly says that you need to decide whether you are adding a lifecycle attribute or a regular CMDB attribute. If it's a lifecycle attribute they sayvery definitely that you should add that attribute to the AST:Attributes form.


                                So, just looking for official feedback on how.

                                • 13. Re: CMDB V8.x and lifecycle attributes

                                  The structure pre 8.0 confused the configuration management and asset management portions of the solution too much.  They should be very closely aligned with each other but not intimate.  We went too far with the intimate.


                                  The Configuration is stored in the CMDB.  There are versions of configuration and current and future states and that is all about what the item really is or will be.


                                  The Asset Management portion is the lifecycle.  It is a single lifecycle regardless of versions or anything else of the configuration.


                                  These were split in 8.0 into two tables from one table but kept closely linked by the reconciliation ID.


                                  The Configuration is the CMDB records.  To update or manage or manipulate the CDMB, you use the Class Manager.  You manage your configuration.


                                  To update the Asset Management functionality (lifecycle attributes) you are managing an AR System application just like any other ITSM application.  So, you would go into Dev Studio and manage the form (AST:Attribute) in this case just like you would any other ITSM form.


                                  Now, after you do something to the AST:Attribute form, you need to get the new field to be included on the joins that the Asset application builds between the various CMDB classes and AST:Attribute.  You either do that manually or by using the syncUI utility.


                                  (An aside -- I fervently hope that in the future, the UI structure is changed so that the asset component and the CMDB component are two closely aligned screens that together form a single UI vs. the current join model.  Much more flexible and much less overhead for management and maintenance.)



                                  Other topics that I think you already have addressed.


                                  Yes, AI can be used (8.0 and later) to update non-CMDB forms so you can load the lifecycle data from outside if you have it.  You need to get the config data in and get the items Reconciled Identified to get a reconciliation ID first, but then you can load that data.


                                  No, you cannot use the Normalization Engine to work the lifecycle attributes.  You need to create AR System filters to do that because it is not data in the CMDB but is an AR System application form.

                                  • 14. Re: CMDB V8.x and lifecycle attributes
                                    Carey Walker



                                    Thanks for the information.


                                    We've done some further 'playing' and have the end-to-end process pretty well nailed now.


                                    One item of clarification please from your post.


                                    You mention that after adding the new lifecycle attribute to AST:Attributes (which we do with Dev Studio) you can then get that attribute onto the required AST forms either manually (we've done that) or using SyncUI. We don't see SyncUI doing anything new in our 8.1 environment, compared to earlier 7.6.x environments. i.e. it is still all about getting new CMDB class form attributes onto the AST forms - it's not apparently aware of the AST:Attributes form.

                                    Reading your post I had thought (optimistically) that perhaps SyncUi was NOW also going to pull new attributes from AST:Attributes as well as any from the BMC.COREclassforms, but unless I've missed something, that's not happening. Can you clarify? Thanks.

                                    1 2 Previous Next