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

[Tom Sienkiewicz]

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!

[Mathew Hillyard]

Hi @Tom Sienkiewicz 

I've actually just posted a large developer blog (as non-SN people can only create developer blogs) on doing a migration from custom service management to CSDM. There is a chunky section on Application Services that is worth a read.

Link: https://www.servicenow.com/community/developer-blog/csdm-migration-from-custom-service-management/ba... 

Hope it helps!

Mat

[Marshall Parker]

In the Application Service hierarchy, there are a few different classes to leverage depending on how the App Service will be populated & maintained. (SN Docs)

When you have existing data in another table that uses CI Relationships, I would recommend you use the  Dynamic Service method which maps to the CI class:  Calculated Application Service [cmdb_ci_service_calculated]

This type of application service requires you to maintain the traditional CI Relationships [cmdb_rel_ci] and then service populater creates entry points to build the service map based on all of the level 1 relationships where the Application Service is a parent.

This method works well for scripting a conversion of the data to move it from an old table to the correct Application Service table. One pointer is that there are a few default fields that you should probably populate in your script to ensure the service populator works correctly .. trial and error I found using this combination:

1. Populator Status [populator_status] = Ready [value 1]
2. Service Populator [service_populator] = 11f01e3dc3f23300daa79624a1d3ae32 [hard coded sys_id for the ServiceNow code that performs the entry point population]
3. Metadata [metadata] = {"levels":"3"} [key-value pair for # of levels of related CIs to include in the service map]
4. Type [type] = Dynamic [value 5]

[Mathew Hillyard]

@Marshall Parker 

Those are the correct scripted values - in the Application Service Wizard you can modify the Levels parameter individually per App Service (which controls the levels in the CMDB hierarchy that will be sync'ed to the Application Service map - the default is 3 but anywhere between 1-8 is possible).

It's also worth mentioning that it doesn't just create Entry Points for the direct child CIs of the App Service - it also creates a network of Manual Endpoints to relate CIs in the Application Service Map and additional CI Relationships. This can surprise some people who don't expect additional CI Rels.

@Tom Sienkiewicz I don't think "Manual" App Services are used anymore. Mapped Application Services are used but as per my linked article I wouldn't recommend using them due to the manual overhead in keeping the App Service map up to date when CI Relationships change. I concur - without Service Mapping, Calculated App Services are the way to go.

Hope this helps!
Mat

[Tom Sienkiewicz]

Thanks to both of you for the input!

when thinking about "empty" App Services, so that we can still use those in processes today / rationalize the Business Apps, but those App Services will be empty for now (no CI relationships), I don't think they could be created in the Calculated table, right?

Would a feasible solution be to put them into the parent cmdb_ci_service_auto class for now, and update the population method later, depending on which way we go with those (Tag/Pattern etc.)?