How to populate Relevant CI and Members of Dynamic CI groups based on selected service offering

[swapnaja jagada]

Hello ServiceNow Expertise,

Can you please help me with optimize solution to populate Relevant CI's and Members of Dynamic CI groups based on selected service offering on incident form.

Currently we are doing through script include but it is taking time to load the CI's (which can be between 50k to 70 k).

Prio response will be appreciated. Thank you in advance.

[EricDohr]

 I want to make sure I understand the ask but is this a correct interpretation of your inquiry? 

• In the event an incident record is created, if the field Service Offering is populated and Configuration Item is empty, limit the options for Configuration Item to be one of the following
• Dynamic CI Groups are the child CI Relationship of a Technical Service Offering
• CIs that are contained by a Dynamic CI Group where the Dynamic CI Groups are the child CI Relationship of a Technical Service Offering

Other things to consider

• If a Service Offering is populated, that Service Offering could have a CI relationship with an Application Service which is not part of a Dynamic CI Group.  This would be an applicable CI to consider.
• Would you want logic built out that if a CI is populated and an Offering is to be populated, there is dynamic logic with that field?  Almost a reverse scenario?
• Are there specific scenarios where the offering would not be populated first?  For instance, are you using ITOM?
• If you have a large volume of CIs to filter through, have you considered focusing on specific classes or adopting the principal class concept?

[Barry Kant]

Good day,

the way I understand it is that you take the Service Offering as 'filter' for the impacted CI(s). 

when it is a Business initiated incident the Business Service Offering is the starting point and for applications there is not much more needed to select as in general the End User doesn't know the CI level (unless it is about owned assets).
when it is a Technical initiated incident then the Technical Service Offering is the input:
- event mgmt

- vendor ticktet

- 2nd line incident

event mgmt and vendor tickets are probably automated, but 2nd line ticket might be the use case here. 
The Technical Service Offering is the starting point and is supporting xx nr of CIs. In this case 50.000-70.000. 
In CSDM the idea is to link those CIs via Dynamic CI Groups, however these are topped to 10.000. 

I haven't done it, but I think technically you can add the downstream relation in the svc_ci_assoc table (by your own logic), and then the filter query will be:

All CIs where service_id = Technical service Offering. That is a straight forward query on a flat table. You skipping Dynamic CI Groups that way (used for Data Synchronization and potentially unpacking CIs in Change Mgmt --> but with 50.000-70.000 child CI's I don't think that is a valid scenario. 
I think it should be a join table as you need to select the ci_id from the svc_ci_assoc table to select the c mdb_ci record. If that is not done via a join query then the query will be something like:
ci IN (1,2,50.000) which is stretching the limits I guess. 

The back end query needs to work where the Service Offering is selected from Business side as well as from Technical side. (I guess) so that might be less straight forward. (check cmdb_rel_ci table as well as svc_ci_assoc table. 

 

Alternatively is to breakdown the Technical Service Offerings in smaller groups that contain less CIs so the Dynamic CI Groups can be used. (still the filtering itself will be somewhat similar)

BR,

Barry

[Jim Zeigler1]

Hi swapnaja,

Can you provide more background on the type of incident your seeing. From your description, I suspect the issue is with a Service Offering in the Service Catalog(e.g., poorly designed forms or a Service Offering that failed to create a Request). I don't see how this kind of incident would have anything to do with operational CIs in the infrastructure because the Service Catalog executes only on the ServiceNow infrastructure supporting the instance.

If there is an issue with the execution of one of the operational Application Services triggered by the Service Offering (e.g. Failed Server Backups, broken server Builds,...). In this case, the incident should reference ITOM Application Services (Server Backup jobs or Orchestration Services) that run on Hardware Infrastructure CIs. Typically there would be a service map that shows which monitored operational CIs are alerting. From the Application Service, you can tell which Business Applications provided the failing code if the alerts are coming from Applications, not Hardware CIs.

I've never seen an incident where the service field of the incident form was used to reference a non-operational SPM Catalog Service Offering. My understanding is that the service and Configuration items fields on the incident form were intended to only reference operational CIs related to the incident.  In most implementations I've seen, the reference qualifier for the Service and Configuration Item fields prevents SPM services and Business Applications from appearing in the drop down list because they aren't monitored and don't have any operational status. 

As Barry mentioned, if you know the Dynamic CI Group, you can get its CIs from the svc_ci_assoc table and populate the drop down list of CIs.  I don't see how you could get them from an SPM service entered into the service field because operational CIs below the Service level should never be related directly to an SPM service (per the Suggested Relationship table).