This post is part of the series Forced Root Cause Monitoring via Mashups and Modal Popups
To not feel lost or out of context, it's recommended to read the main post first.
Testing the Mashups
- Open the rcp_MashupMain in a new browser window
- For this test I find it easier to have the rcp_AlertThing and the Mashup in two windows side-by-side to each other
- The Mashup should be completely empty right now
- Nothing in the historic table (Grid)
- The Selected Reason is blank
- The Checkbox is false
- In the rcp_AlertThing switch the trigger to false
The following will now happen
- The new value will be automatically pushed to Mashup
- The checkbox will switch to true
- The validator now throws the TRUE Event, as the condition is met and the trigger is indeed true
- The TRUE Event will invoke the Navigation Widget's Navigate service and the modal popup will be opened
- The user now only has the option to select one of the three states offered by the Radio Button selector, everything else will be greyed out
![](https://support.ptc.com/images/cs/articles/2018/11/1542208522l3ve/Test_PopupActive.png)
- After choosing any option, the SelectionChanged Event will be fired and trigger setting the selectedState as well as closing the popup
- The PopupClosed Event in our MashupMain will then be fired and populate the selectedState parameter into the textbox (just for display) and will also call the SetProperties service on our Thing, updating the selectedReason with the selectedState parameter value
- Once the property is set and persisted into the ValueStream via the SetProperties' ServiceInvokeCompleted Event, we clear the trigger (back to false) and update the Grid with the new data
- In the AlertThing, refresh the properties to actually see the trigger false and the selectedReason to whatever the user selected
![](https://support.ptc.com/images/cs/articles/2018/11/1542208535aUbR/Test_ValuePersisted.png)
- Note: When there is a trigger state and the trigger is set to true the popup will always be shown, even if the user refreshes the UI or the browser window. This is to avoid cheating the system by not entering a root cause for the current issue. As the popup is purely depending on the trigger flag, only clearing the flag can unblock this state.
The current logic does not consider to close the popup when the flag is cleared - this could however be implemented using the Validator's FALSE Event and adding additional logic