I also have done may upgrades on both Windows/SQL Server and Solaris/Oracle 
systems and have never experienced any loss of custom attributes.

 

Some of the upgrades do overwrite AST forms thereby losing custom attributes 
from these forms but these cases are well documented in the upgrade documents 
and the effects are easy to mitigate.

 

I’d add further that it’s good practice not only to use bespoke namespaces and 
custom field id’s but also to use attribute names that won’t ever be 
overwritten should BMC ever decide to add an attribute that you have added (I 
always add a customer-related prefix, e.g. IBM_WarrantyEndDate).

 

John, could you point to the documentation that states that it is BMC best 
practice never to add bespoke attributes to BMC classes which is what I 
understand you are saying. If a new attribute was required for, say, the 
Computer System class how would you add that in your CMDB such that a user 
would easily be able to see a Computer System CI with this new attribute data?

 

Of course, if a developer adds a field directly to one of the CMDB forms (eg 
BMC.CORE:BMC_BaseElement) then that could potentially be affected by upgrades. 
As we all know, attributes should only be added through ‘legal’ means (Class 
Manager or CMDB api (eg cmdbdriver)).

 

In the past BMC has extended the CMDB by the use of extension packs (eg for 
integration with BMC Foundation/Topology Discovery). As far as a future upgrade 
is concerned the classes and attributes added by these extensions are just the 
same as bespoke customer classes and attributes. I’ve upgraded such systems 
also without unexpected loss of attributes.

 

Cheers

 

Peter

 

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of John Doe
Sent: 24 July 2011 14:26
To: arslist@ARSLIST.ORG
Subject: Re: Adding Custom Attributes to Base Element

 

** 

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 <jason.mil...@gmail.com>
To: arslist@ARSLIST.ORG
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 <hornetl...@yahoo.com> 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 <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> 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>
To: 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 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] 
En nombre de John Doe
Enviado el: Viernes, 22 de Julio de 2011 12:00
Para: 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
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"

Reply via email to