Adding a table to the database SCSM

Roman_Nepomniashchii

I need to add a table to the database SCSM. I never did it, tell me who knows about it. The standard database of the SCSM can be expanded with tables?

Adam_Dzyacky

At the end of the day it is just another SQL database so I guess you could add your own tables. The bigger question is how this could impact your support agreements with Microsoft. The second question is what is the intent or end goal of performing such a task?

So speaking in terms of a more "supported" nature and depending on what you're looking to add you could achieve extensions to the platform via management packs that either extend core classes in SCSM or designing your wholly own custom management pack. In either case, both of these would extend the platform in a supported fashion.

Justin_Workman

Adam is on the right track.  I'm not sure what you're after, but I'd be willing to bet it could be done by either extending an existing class or creating a new class both via authoring and importing custom management packs.

Roman_Nepomniashchii

Adam_Dzyacky said:

At the end of the day it is just another SQL database so I guess you could add your own tables. The bigger question is how this could impact your support agreements with Microsoft. The second question is what is the intent or end goal of performing such a task?

So speaking in terms of a more "supported" nature and depending on what you're looking to add you could achieve extensions to the platform via management packs that either extend core classes in SCSM or designing your wholly own custom management pack. In either case, both of these would extend the platform in a supported fashion.

Justin_Workman said:

Adam is on the right track.  I'm not sure what you're after, but I'd be willing to bet it could be done by either extending an existing class or creating a new class both via authoring and importing custom management packs.

I need to do version control with this. I create a table in which I specify the version of my releases (customizations) that are applied to the database. At the next release version will be checked. That's why I need a table. Is this possible?

Justin_Workman

As you modify your customizations, you can increment the version of your Management Pack that they're stored in.  I think this will allow for the version control you're after?

Tom_Hendricks

I agree with the other responses above--yes, you can definitely add a management pack with the end goal of having it generate SQL tables (which it would) and also make it possible for the data in those tables to participate in SCSM views, type projections for forms, powershell, etc.  In many cases I would recommend it.  Some other ways this might benefit you:

• Defining as a management pack means it will also become part of your data warehouse tables (NOT necessarily the cubes unless you include that in your management pack too)
• You could relate this object to others, such as who performed the release, the CR/RR ticket(s) pertaining to the release, etc.
• If you ever rebuild / migrate your current SCSM deployment to a new one (vs. in-place upgrade) this would come along with everything else that you are migrating, instead of being a stray table that you need to remember to include by other means

But if your end goal is, for example, simply to have a column or two of data available for each version that javascript (or other) code could easily read, then maybe a table is the best way to go for you.  This really comes down to a matter of preference, but I would suggest creating your own database for this and potentially other custom tables, on the same DB server as your ServiceManager database.  This way, you do not have to worry about any support issues that may or may not exist if you put your table in the ServiceManager DB, you get nearly all the benefits of having it there (e.g. you can join it to tables in ServiceManager in a query, if you need to), and a separate database is not likely to get left behind in a migration, because it will be seen by everyone.  While I do not think that the SCSM installer overwrites or deletes any custom objects during an in-place upgrade, who is to say that future versions will not do this?

Like so many other things with Service Manager, there is no single correct answer to this.  There are usually several, and you need to weigh the pros and cons of each to determine which is best for your own situation. 

Roman_Nepomniashchii

Justin_Workman said:

As you modify your customizations, you can increment the version of your Management Pack that they're stored in.  I think this will allow for the version control you're after?

this is true but I mean the settings that are stored not in the MP

Roman_Nepomniashchii

Tom_Hendricks said:

I agree with the other responses above--yes, you can definitely add a management pack with the end goal of having it generate SQL tables (which it would) and also make it possible for the data in those tables to participate in SCSM views, type projections for forms, powershell, etc.  In many cases I would recommend it.  Some other ways this might benefit you:

• Defining as a management pack means it will also become part of your data warehouse tables (NOT necessarily the cubes unless you include that in your management pack too)
• You could relate this object to others, such as who performed the release, the CR/RR ticket(s) pertaining to the release, etc.
• If you ever rebuild / migrate your current SCSM deployment to a new one (vs. in-place upgrade) this would come along with everything else that you are migrating, instead of being a stray table that you need to remember to include by other means

But if your end goal is, for example, simply to have a column or two of data available for each version that javascript (or other) code could easily read, then maybe a table is the best way to go for you.  This really comes down to a matter of preference, but I would suggest creating your own database for this and potentially other custom tables, on the same DB server as your ServiceManager database.  This way, you do not have to worry about any support issues that may or may not exist if you put your table in the ServiceManager DB, you get nearly all the benefits of having it there (e.g. you can join it to tables in ServiceManager in a query, if you need to), and a separate database is not likely to get left behind in a migration, because it will be seen by everyone.  While I do not think that the SCSM installer overwrites or deletes any custom objects during an in-place upgrade, who is to say that future versions will not do this?

Like so many other things with Service Manager, there is no single correct answer to this.  There are usually several, and you need to weigh the pros and cons of each to determine which is best for your own situation. 

thanks for your expanded response