Hi John, You make a good point. Some of us have had really good success with more "standard" setups if you will. While I am not sure why some other combinations would have different CMDB/CDM upgrade behaviors it does seem Win/SQL behave the best (I hear you laughing Chris S, or maybe it is a groan).
Trying it out first on a valid dev/test system and having good backups of production that allow for roll back is implied in many of the statements made on the list. I am hoping that is a no brainer for anybody doing this type of work (although I realize Remedy is sometimes dropped into people's lap with various experience). My recollection of the best practices is from reading the documentation a few years ago. I don't remember it how you describe but maybe it is time I read the latest documentation. It seems absurd that BMC would suggest building all new classes if you need some common attributes added to multiple classes (however I have heard stranger things). Although when I read the quote "Also, whenever you extend the data model, BMC recommends usage of a custom namespace instead of BMC.CORE" I see that being true for adding a new class of Phone, Kitchen Appliance or Submarine; not an attribute of "Our Company's Unique Identifier That Doesn't Fit Into Any Existing ID Field In The CDM But Must Be Documented In All CI Records." Good discussion, thanks! Jason On Sun, Jul 24, 2011 at 6:26 AM, John Doe <[email protected]> wrote: > ** > Gentlemen, > > I have learned, from my own personal experiences, CMDB upgrading success > depends very heavily on your environment. That, of course, is only my > opinion. Which is based on the facts of every different environment > upgrade. I usually don't have many problems with my SQL Server, VM > systems. I will certainly grant that. However, it's when your environment > is out of this ordinary that you will most likely see the error. Taking a > Solaris/Oracle (SPARC) system from 7.5 to 7.6.04 SP1, or a Linux/Oracle > (Red Hat) or a Sybase system from 7.5 to 7.6.04 SP1, has (in my experience) > erased custom fields added to Base Element. I have filed many cases with > BMC over the years for this. Coupling these many cases and others, has > resulted in BMC official best practice guidance. You will see this in > various Admin guides and white papers. > > You will find with 7.0/6.3 upgrades, it is a challenge, at best. I do > agree that if you have a Sql Server, MS VM 08 system, with a 7.5 or greater > CMDB you might be ok. However, I would ensure it is accomplished on a like > test environment prior to production installation and everything can be > restored back. Not just a VM backup but a DB recovery method also. > > To instill this, at the end of my post I wrote "your environment and > situations will dictate your decisions." > > Your Post: It sounds like your suggestion would equate to creating a whole > new custom CMDB structure in a custom namespace instead of using the BMC > one. The way I read it he wants to use many of the classes in the CDM but > just needs a few new attributes that apply to all classes. > > Yes you are correct and that is because it is a BMC best practice. > > " 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 ." > > I am simply going by BMC recommendations here. Which are applicable to his > requirements. I agree it is the long way around. Your Post: " I am > thinking there are a number of people on this list (including myself) who > have upgraded with custom attributes in Base Element without any issue. " > which I can understand and agree with you on that. However, it is BMC, not > I, who have made this a best practice. Likely, because there are many more > on the side of bad than good of adding these classes directly to Base > Element. I will say, the bad, is these fields surviving during an upgrade. > Which is the reasoning behind the best practice. It is why I posted "I > know the road you are wanting to go down seems easier right now." > > I only offer friendly advice from someone who has been down this road every > possible way. Thank you Jason for stating the other side of the coin, it is > very applicable for that environment. > > > > > ------------------------------ > *From:* Jason Miller <[email protected]> > *To:* [email protected] > *Sent:* Sunday, July 24, 2011 1:26 AM > > *Subject:* Re: Adding Custom Attributes to Base Element > > ** I am thinking there are a number of people on this list (including > myself) who have upgraded with custom attributes in Base Element without any > issue. We have taken ours from 7.5 -> 7.6 -> 7.6 p1 -> 7.6 p2 -> 7.6.03 -> > 7.6.04 SP1 without any issue. That said I wouldn't be surprised if there > would be an issue if you had a CMDB that originated with CMDB version 1 or 2 > and tried to bring it up to 7.6.xx. Those were the CMDB learning years and > it has come a long way since then. I think you are probably OK if you are > starting with a fairly recent version of the CMDB. > > > I don't see how adding a custom class outside of BMC.CORE is going to help > Alejandro > accomplish his goal. It sounds like your suggestion would equate to > creating a whole new custom CMDB structure in a custom namespace instead of > using the BMC one. The way I read it he wants to use many of the classes > in the CDM but just needs a few new attributes that apply to all classes. > > Jason > > > On Sat, Jul 23, 2011 at 10:39 AM, John Doe <[email protected]> wrote: > > ** > 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 <[email protected]> > *To:* [email protected] > *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 <[email protected]> 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" <[email protected]> > To: [email protected] > 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" [email protected] 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: > [email protected]] En nombre de John Doe > Enviado el: Viernes, 22 de Julio de 2011 12:00 > Para: [email protected] > 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: [email protected] > 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 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 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"_ _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" > > > _attend WWRUG11 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"_ > > > _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"
