Allow one instance of ServicePulse to be preconfigured with multiple instances of ServiceControl

[udidahan]

A customer has requested this feature, with the following context:

Today we deploy an instance of ServicePulse for each environment so users don’t have to keep track of the SC urls themselves. I know technically users can change it in ServicePulse but it’s just for that user. The idea here is the platform ops team could just support one instance of ServicePulse and let users pick which environment they want in it.

[janv8000]

Something like the following using the scu and mu querystring params?:

ServicePulse MSMQ
ServicePulse ASB

[DavidBoike]

@janv8000 I think the idea is more to have a preconfigured list on the server like:

// instances-config.json
[
  {
    "name": "msmq",
    "serviceControlUrl": "https://servername:33333/api/"
    "monitoringUrl": "https://servername:33633"
  },
  {
    "name": "asb",
    "serviceControlUrl": "https://servername:33335/api/"
    "monitoringUrl": "https://servername:33634"
  }
]

And then have ServicePulse URLs like: https://servername:9090/?instance=asb or even https://servername:9090/i/asb with a dropdown shown in the ServicePulse UI to be able to quickly change between them.

[kbaley]

Chatted with @TravisNickels and had some thoughts we wanted to capture.

First, the monitoringUrl setting in app.constants.json is already an array and I assume that was to pave the way for supporting multiple monitoring instances. As a first pass, we could do the same for serviceControlUrl. For the display name for these instances, we could query ServiceControl. Not super efficient so maybe we could include the name in there similar to what David suggested above.

Once the environments are defined, I think the configuration page would list the contents of this file with Test buttons nexxt to each URL but without the ability to add or change them. I.e. the only way to edit the environments is to update the app.constants.json file (or whatever file we store this info in). For now, SP is just static files so I don't think we have the ability to update this file centrally in its current form. At the moment, any changes to the configuration are stored locally on the user's machine.

On each page, we would display a dropdown of the environments pulled from the config file. We would also store the most recently used environment in local storage so it would be saved across sessions and across different pages in the app. If there's no most recently used value, just pick the first in the list.

If the most recently used value isn't in the list of configured environments (e.g. if it was removed or changed), then pick the first environment in the list instead and updated the MRU value in local storage.

This removes the ability for users to configure their local version of ServicePulse on the fly but it always seemed unintuitive to be able to enter a new URL and have that affect only your instance anyway. Presumably, with a centralized configuration of the different environments, this wouldn't be necessary.

[johnsimons]

Merging details from #2035, raised by @ramonsmits

Bonus points if the UI could have a clear identification of which environment is selected. For example

• Have the whole UI have a different 1 or 2 pixel width border color (red, green, purple, etc.), or
• When triggering actions it lists the enviroment like "Retry message on Production", or
• When triggering actions you can a confirmation dialog, or
• List the active environent in the browser title