Why does the business app has new install_status values that differ from the rest of cmdb_ci?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2024 04:01 AM - edited 07-24-2024 06:09 AM
In our effort to align to CSDM we migrated our application services to the cmdb_ci_business_app table.
I know that the install_status is deprecated: https://docs.servicenow.com/bundle/washingtondc-servicenow-platform/page/product/configuration-manag...
But for now we still have to use it as we plan to migrate to the CSDM Life Cycle maybe next year. Unfortunately (?) our CAB decided we should only use ootb from now on as much as possible.
I couldn't find much but it seems other customers also have run into problems: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0962866
There's also a weird ootb business rule on business app "Reset stale retired status value" that basically migrates the Retired Value on Insert/Update from 7 to 3. This design decision needs explanation by servicenow.
Why is that a problem for us? Over the years several teams (that are also long gone) implemented some dashboards, reports, notifications, acl, scripts, scheduled jobs, interfaces etc. on the more generic class cmdb_ci. This was never a problem since all child ci classes used the same install_status values. Now we'd have to refactor all of them just so we adhere to the "ootb choices" by servicenow.
You can see here that it is only different on business app
https://[yourinstancename].service-now.com/sys_choice_list.do?sysparm_query=nameINjavascript%3AgetTableExtensions('cmdb')%5Eelement%3Dinstall_status%5Elanguage%3Den%5ElabelSTARTSWITHRetired&sysparm_view=
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2024 04:19 AM
It may be faster to ask this question on NowSupport. They have direct access to the teams responsible for this. Any answer from a non-ServiceNow employee will be a guess (or someone that ran into the same). I understand your issue, but you will just be fortunate if one of those few people that can give the correct answer is indeed reading this.
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2024 05:24 AM
I think I'll do this and will keep you updated in this post. Maybe other people have the same problem and will find my post.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-26-2024 12:37 AM
If you get the answer, don't forget to mark your reply as solution, so the post can be found under 'solved'
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2024 08:24 AM
Paki - If you are using Business Applications they are going to be different because they are not meant for Operational use for 'is it installed / is it running / etc.) . These are not intended to track the same type of data as an Application Service so they would have a different type of lifecycle.
Reading the KB article you linked, note that it is updating the Status field when the Operational Status is changed.
My guess is that was to handle reporting that depended in Status, but the UI was showing Operational Status. I wouldn't be surprised that this was added back when Business Apps were a new concept and they had a lot of customers dependent on the status field.
Pre-CSDM, there was a lot of customers hacking their CMDB to account for Bus Apps, when they were only available in ITBM (now known as SPM).
Steve