Any recommendations on creating App Services in bulk from script (migration from custom table)?

Tom Sienkiewicz
Mega Sage

Hi Everyone,

I need to migrate Business Apps and Application Services from a custom table to OOTB. 

 

For Application Services, there are relationships defined already to CIs, but there is no concept of "Entry point" today. I am thinking about migrating those to the cmdb_ci_service_discovered table (the "Manual" type of App Service) via script and then re-pointing the CMDB Relationships from custom to this OOTB table. One concern I have is when creating  a new Manual App Service via the CSDM wizard, it asks to provide the parent CI/Entry point. Would the above approach still work or am I missing some extra updates that need to happen behind the scenes?

 

Another approach I might consider is to use the Dynamic CI group-based App Services, but this would essentially require to create a dedicated group for each App Service and then add all current CIs to such group. Seems even more complex than the above.

 

Also some of the App Services would not have any CI relationships for now. But I'd still like to have them to be selectable in ITSM processes. Is the above Manual type also a good choice for such App Service "shells"?

 

Any feedback highly appreciated!

1 ACCEPTED SOLUTION

That used to be the baseline table name in previous releases but just looking at my PDI it is "Application Service". The database internal name is cmdb_ci_service_auto.

 

You cannot select this as an option in the App Service Wizard so you may need to open up create access to the table. The New button under both CSDM > Manage Technical Services > Application Service and Configuration > Application Services > Application Service takes you to the App Service Wizard.

View solution in original post

7 REPLIES 7

Mathew Hillyard
Mega Sage

Hi @Tom Sienkiewicz,

Customers who have had ServiceNow a long time often approach a CSDM engagement with records sitting in Automated Business Service table, as this was the origin of the App Service table, from Event Management, that later got promoted to a parent table.

 

If you don't have any CI Relationships then it makes sense to put the placeholder record in Automated Business Service for now, so every record is in the same table/class, they're identified as some type of App Service, then once the CMDB is populated and you're able to hook things up, assign a population method using the App Service Wizard (Under the CSDM > Manage Technical Services > Application Service module). This even applies to Dynamic CI Groups. Note that once saved this will change the record class from Automated Business Service to the class based on the population method chosen.

For Service Mapping this is also an available population method in the App Service Wizard (Top-Down Discovery), but there is extra work to be done within the Service Mapping app to establish, validate and approve the service map and boundaries.

Hi @Mathew Hillyard , just to be sure as I don't seem to have the table "Automated Business Service" in my PDI (assuming there might be some change in naming convention), is this the cmdb_ci_service_auto?

cheers!

That used to be the baseline table name in previous releases but just looking at my PDI it is "Application Service". The database internal name is cmdb_ci_service_auto.

 

You cannot select this as an option in the App Service Wizard so you may need to open up create access to the table. The New button under both CSDM > Manage Technical Services > Application Service and Configuration > Application Services > Application Service takes you to the App Service Wizard.