Everyone, I wanted to send a quick response to this note as it is describing something that is completely inconsistent with expectations and with what we are in fact seeing happening in customer sites.
An upgrade of the CMDB does not remove ANY classes or attributes you may have added to the system (OK, if you have added a custom attribute to a class that is being removed, there is an issue but even there, we have logic that is set up to not remove the class and to leave it as a custom class because it sees that there is an extension if possible). We have many customers who have extended the class structure -- everything from adding new items to base element to adding new classes to adding attributes to existing classes. They have no issue with those extensions or customizations during an upgrade. We do not delete custom extensions. Now, we do suggest you really check to see if you need a customization before making it, but if you do the work and find you do need the extension, it is fully supported and upgrades work just fine. Where there are some issues and some rework was needed in the past is with Asset views and layouts. When the CMDB extended something in the release, new Asset views would be created and when you upgrade, they overwrite the views you have. This means that you could end up with issues of your extended fields "disappearing" from the Asset views. They are still there in the CMDB. All the data is still present in them. But, the fields don't show on the Asset views. You would need to go back and update your Asset views for the classes to get your custom fields to show again. With the overlay feature of the 7.6.04 release, you can control this problem. There will be additional improvements in upcoming releases to make this even easier. And, over the next couple releases, some restructuring of the way Asset Management works to eliminate the issue completely by streamlining the interaction of Asset and CMDB. But, these are all details to clean up an annoying maintenance issue for the layout of screens. To my knowledge, we have not lost any custom fields or classes for any customers. If anyone has seen that occur during an upgrade, this should be immediately reported to the support team and worked as a bug. As other users have posted to this thread, they have extended the base class and gone through several upgrades with no issues or problems with any customization/extension of the class model -- including extensions to base element. I just wanted to get a note out there clarifying what the expectations are and noting that we do not have any issues with customers in general loosing custom/extended classes or attributes. You can safely extend attributes and classes in the CMDB and they will be held across upgrades. (still do verify that you really need the extensions before you make them of course) Doug Mueller ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of John Doe Sent: Saturday, July 23, 2011 10:39 AM To: arslist@ARSLIST.ORG Subject: Re: Adding Custom Attributes to Base Element ** Let me explain how this will work, for those of you who have not gone through an upgrade. The reason best practice is to add a custom class (outside of BMC.CORE) and add your own attributes to that custom class, with custom field ID ranges is because when you upgrade it will only keep these additions made this way. That's why I stated "I'd recommend you do not add them to Base Element. Instead create your own custom Class and add those attributes to that class. Otherwise, your next upgrade will be a nightmare." When you upgrade (which is inevitable) the Common Data Model is constantly changed and adapted. They will completely restructure all of the classes in BMC.CORE. Therefore, if you add custom fields to Base Element the upgrades will "remove" them. I have been through several upgrades and personally witnessed this. Obviously, if you have hundreds of thousands of records in these attributes you are up a creek with out a paddle. Patches sometimes will remove custom fields too. I know the road you are wanting to go down seems easier right now. But it will be a "nightmare" in the future. I would also recommend reading the book about How to Create a CMDB from the ground up. I have been through that mistake also. Take care and obviously your environment and situations will dictate your decisions. Good luck. ________________________________ From: Mahesh <mchand...@gmail.com> To: arslist@ARSLIST.ORG Sent: Friday, July 22, 2011 2:35 PM Subject: Re: Adding Custom Attributes to Base Element ** One of the best practice with regards to customization is having a custom field ID range. Also, whenever you extend the data model, BMC recommends usage of a custom namespace instead of BMC.CORE . Thanks Mahesh On Fri, Jul 22, 2011 at 1:58 PM, pritch <pri...@ptd.net<mailto:pri...@ptd.net>> wrote: I've had the same experience as Victor noted. I've added them with no problem - did need to work them forward through the joins. The only thing I'll add is to watch Field ID's. If the field ID that is used (generated or otherwise) is also used in another form feeding the same join, the field ID of one of those items on the join can change. If that happens and you build workflow to process the field, it can have some type mismatch issues (ie one is an integer and the other a date field). At least that's what we've seen. ----- Original Message ----- From: "Victor Olufowobi" <vic...@klub.chip.pl<mailto:vic...@klub.chip.pl>> To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Sent: Friday, July 22, 2011 2:21:23 PM Subject: Re: Adding Custom Attributes to Base Element ** Since these attributes need to apply to all further subclasses I don't think creating a custom class is a good idea. I have added a few attributes myself to Base Element without any issues. The time needed for the attributes to propagate to all existing subclasses depends on your system and the number of subclasses you have. You still need to modify the AST forms for the new attributes to be available in the required classes. Victor. On Fri 22/07/11 18:11 , "Alejandro Canon" aca...@extensionsa.com<mailto:aca...@extensionsa.com> sent: ** John, Thanks for your recommendation. That custom class you mention should be a subclass of Base Element (BE), right? I´m asking that because I don't see how a custom subclass of Base Element can propagate attributes to all existing subclasses in CDM. I was thinking creating a custom namespace and adding attributes in BE but stored in custom namespace. Alejandro. De: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] En nombre de John Doe Enviado el: Viernes, 22 de Julio de 2011 12:00 Para: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Asunto: Re: Adding Custom Attributes to Base Element ** Alejandro, I'd recommend you do not add them to Base Element. Instead create your own custom Class and add those attributes to that class. Otherwise, your next upgrade will be a nightmare. From: Alejandro Canon To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Sent: Friday, July 22, 2011 10:57 AM Subject: Adding Custom Attributes to Base Element ** Listers, ARS 7.6.04 SP1 CMDB 7.6.04 ITSM 7.6.04 I need to add about ten (10) attributes (common to all kind of CIs) to BaseElement. I've read some threads (dated about 2009) recommending to NOT ADD attributes in Base Element Class, because of known errors in Asset - CMDB Sync process. What's your experience about that? Understanding CDM Model is based in CIM Model I think there shouldn't be problems in adding fields to Base Element class. Believe me if I'm telling you I've reviewed all BaseElement attributes from BMC.CORE and BMC.AM<http://BMC.AM> namespaces and I have no match for these 10 attributes required. I guess a known issue could be extense time you may have to wait after saving changes in CDM, because custom attributes in Base Element must be propagated to all subclasses. Regards, Alejandro _attend WWRUG11 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com<http://www.wwrug.com> ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> attend wwrug11 www.wwrug.com<http://www.wwrug.com> ARSList: "Where the Answers Are" _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
