Issue Description:
Interface has been trying to get to a point where they can use the Web Client full time for alarm handling. They have seen several issues that have become critical to resolve.
- Broker was not checking the max alarms MMoption and enforcing it
- Alarms are becoming allocated to users but not available to be handled. This seems to be due to a router error and being in auto-get. It tries to get the alarm but fails leaving the alarm allocated but not on the screen.
- Router errors would prevent the alarm from being handled in the Web Client. This is things like getting the accounting service tickets. It should not block alarm handling.
- The Web Client was not doing the roll-up alarm queue view quite right when higher priority alarms come in
- The contact action for an email contact point was making multiple calls for scripts. This leads to the correct one being overridden. Additionally, action pattern editing was not repopulating the selected script.
- There seems to be a way in the web client for a contact action to get stuck even if they hit the continue button. Somewhere between the button click and the log line being updated, it fails. This results in the client not thinking the contact action is finished. The dialer has been cleared out so they can't continue on.
Solution:
We had to do quite a few changes for this.
- The back end changes are to allow the broker to enforce the max alarms limit. This is per client session. It will feed the reason back out to the client and log it. It will also now catch a re-cache change for this option as well.
- We added code that if the alarm get allocated but then fails to load the alarm in the API, it will send a call to the AppServer releasing the alarm so that it can become available again
- We added code to allow the alarm handling to continue if the router returns an error getting the service tickets.
- We added additional logic in the web client to handle this unique combination of senarios. It will now show only the one rolled-up line
- We fixed the Action pattern edit by triggering the code to filter the script options. The script type was set but since it had not change, it was not triggering the code to populate the next box. We also fixed the double call for scripts that was causing the script not to show in the alarm.
- We added checks for failures and do the clean-up of the dialer state so that it is not left in a hung state.
Apply Fix:
- Run MWC installer on web servers
- Rename ManagedImports.dll and copy in new file
- Rename MMonitor.exe and copy in new Broker file
- Rename Broker.exe and copy in new Broker file
- Rename AppServer.exe and copy in new Broker file
- Use Services to restart MMonitor
- Do a Broker and AppServer restart
DevOps Work Item:
BUG 13515
BUG 13516
BUG 13551
BUG 13486
BUG 13536
