When using the sdgtw probe with ServiceNow shouldn't I be able to resolve an incident created by the sdgtw probe and it will acknowledge the associated alarm that the incident was created from?
In the configuration GUI I have the check box checked to allow automatic acknowledge of the alarm that is used to create the incident, when that incident is closed in ServiceNow, however it just seems to not work. Is there some other raw config key or something I need to add to make this work?
You are correct - if you have the sdgtw probe configured to "Auto Close Alarm", then when the incident is closed/resolved in ServiceNow, the corresponding UIM alarm will be closed. If this is not occurring, then there are 4 reasons why this is not occurring:
1. The obvious answer is that you have not selected the "Auto Close Alarm" option from the sdgtw node on the probe's Configure page opened from Admin Console. This must be selected for this to work.
2. The incident is created in ServiceNow by the user configured in the ServiceNow service desk connection profile. If you log into ServiceNow with that user and close/resolve the incident, the UIM alarm will not be close - this is the default behavior of the probe. If you want the UIM alarm to be closed when the corresponding incident is closed/resolved by the user that created in incident, then you need to change the setting of the acknowledge_alarm_when_incident_resolved_by_any_user key in the setup section to true from the sdgtw probe's Raw Configure GUI.
3. The Service Desk time is behind the sdgtw probe system time and you have not configured the time difference (in minutes) in the "Time difference between Service Desk and CA UIM(minutes)" field from the sdgtw node on the Probe's Configuration page opened from Admin Console. For example, if the Service Desk time is in the PST time zone and the sdgtw probe system time is in the EST time zone, then you need to configure the 180 minute difference.
4. This is not as common, but in some ServiceNow applications, the mapping of the incident status field in ServiceNow has been customized. By default, the probe uses the standard ServiceNow incident status value mappings:
New = 1Active = 2Awaiting Problem = 3Awaiting User Info = 4Awaiting Evidence = 5Resolved = 6Closed = 7
If these values are customized to different values, it is necessary to configure the customized status field mappings in the probe. For example, if the incident status field mappings in ServiceNow are customized to the following:
New = 1 In Progress = 2 On Hold = 3 Resolved = 6 Closed = 7
Canceled = 8
Then, you must set the sn_customized_status key in the probe to match the customized incident status value mappings in ServiceNow for proper incident handling:
sn_customized_status = New=1,In Progress=2,On Hold=3,Resolved=6,Closed=7,Canceled=8
You will also need to set the value for the key sn_close_incident_state_value if you want to use a different incident status field value for closed incidents (other than Closed or Resolved). For example, using the customized status field mappings above, if you want to use Canceled as the closed incident state (status) value, then you would set the following key value in the probe:
sn_close_incident_state_value = Canceled
All of this is documented in the following sections of the sdgtw probe's AC Configure Wiki Document:
sdgtw AC Configuration->(For version 1.20 and later) Advanced Preconfigurationsdgtw AC Configuration->(Optional) Configure General Properties