Upgrade App Broker without ServiceNow connection in Dev

[a_cutler2]

Beginning the upgrade process from 2018R1 to 2019R1 in dev, we had to reconnect ServiceNow to App Broker because it had been disconnected in that environment months ago. The customer would like to test the ServiceNow connection by executing and end-to-end request and deployment in the environment to ensure we have as close to an identical situation to the production environment as possible, but completing an end-to-end test is proving to be difficult because there have been so many duplicate assets added to that environment in the last few months that we haven't been able to complete a deployment as of yet. My question is - how important is it, in general, to be able to have a completely functioning ServiceNow connection to App Broker when testing an upgrade? Would it be risky to still upgrade the development environment while this issue exists? Just wondering if we should delay the scheduled upgrade due to this, or if problems related to this almost never occur during and upgrade and we should just move forward regardless. 

[jdempsey]

Sorry, I'm not following the scenario.  I'm not sure why having an active/valid ServiceNow connection would be required simply to upgrade App Broker from one version to the next.  Even from a testing perspective after upgrading, you could create a test request without ServiceNow just within the App Broker UI to verify that the connections to FNMS (if relevant) and SCCM (or other deployment system) are working.  If you actually want to test the ServiceNow workflow, then of course you'd need a "good" working environment.

When you say you have a bunch of duplicate assets, what do you mean by that?

[a_cutler2]

Thanks Jim. I got some clarification of what's going on here - we were originally connecting dev AB to qa SN, but since we finished testing a while ago somebody has reconnected dev AB to dev SN (instead of qa). The duplicate devices are in SN dev, so we kept running into errors when trying to test. Also most/all catalog items in AB dev are not correct anymore as all of the dev stuff was cleared out when AB was connected to qa for testing. So basically the dev environment is a mess and it would take quite a bit of effort to get it up and running normally again, just to test the AB upgrade there. I'm just looking for advice on whether or not it should be considered "required" to test to a granular level like that in dev prior to performing an upgrade in production.

[jdempsey · Accepted solution]

It is generally a best practice to maintain a development environment and a production environment (often customers have even more non-prod environments for various purposes, but really not essential for App Broker).  With any upgrade, it's advised to test the upgrade in a non-production environment first and then implement in production when you're satisfied the new release hasn't broken anything (not just that the installer completed without errors).  That said, since most upgrades of App Broker don't change anything in ServiceNow, that piece of the puzzle isn't really super important from an upgrade testing perspective.  You could test most functions of App Broker by submitting a request within the App Broker web UI, or you could simulate submitting a request from ServiceNow by using a tool like Postman or SoapUI to make the same REST calls that ServiceNow would (these calls are documented here).