Integration in prod instance


(Sonita) #1

I , the integration between SN and PD is working perfectly in our DEV instance, now i want to test that in PROD , and i noticed , all the incidents are still creating in DEV. not sure what needs to be changed, Any help would be appreciated.

(Nadine Javier) #2

Hi Sonita! Are you using the same PagerDuty service to communicate with PROD and DEV?

(Sonita) #3

Hi Nadine! what do you mean by same pagerduty service?
I think yes as I did the exact same thing in prod . Not sure what I need to change so I can see the incidents getting created in PROD too

(Demitri Morgan) #4

Hi Sonita,

The reason for this is that the ServiceNow webhooks in PagerDuty, if set up for the development instance, will still be pointed to that instance after migrating to production.

There are a few ways around this situation. The following is by no means all of them but the easiest ones I can think of:

  • Create dedicated assignment groups, configuration items and services / escalation policies that are used for testing workflows in dev for the integration; provision all of your production business services into PagerDuty from production and use just the dedicated services/EP’s in PagerDuty for testing and development.
  • Clear out the PagerDuty Webhook field of the objects in ServiceNow (CI’s or assignment groups, depending on which mapping type you are using). Provided the app is configured correctly, it will automatically provision a separate webhook next time an incident is triggered from ServiceNow. If you are migrating data from prod to dev for testing, you can enforce this by setting up a clone data preserver such that the webhook field is excluded / left blank in the target instance when cloning.
  • Perform a bulk URL switcheroo in the configurations of the extensions using a bit of automation via the REST API

If taking the third option, note:

  • The set of extensions you’ll want to operate on can be obtained through the Extensions Index with parameter extension_schema_id=PAD6MYW for ServiceNow v5 (or P6MB86H for v4).
  • Each extension object should have a config property that is itself an object containing a target property. That is the URL to the ServiceNow instance, which you can set to one or the other.
  • One can also set the properties snow_password and snow_user in the config object to swap out the ServiceNow user and and password used for authenticating in the API on the ServiceNow end, if your password for webhooks differs between prod and dev.
  • The request to update an extension will be PUT /extensions/{extension-id}

(Sonita) #5

Thank you so much for your response Demitri. very helpful

(system) closed #6

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.