This post is quite long, has various chapters and you might get bored reading it.
If you just want a summary read the "Use case" and "Conclusion" chapter - and maybe the "Required Logic" chapter, because I made a cool graph for it. The rest is all about implementation...
I recently had the opportunity to deliver a ThingWorx training for Saint Gobain.
One of the use cases for their ThingWorx application is monitoring machine errors and outages on the production line. If an outage or error status is triggered, the machine operator will see a popup on the monitoring screen where he is forced to select a root cause. This root cause will then be persisted in ThingWorx for more data transformation, analytics and reporting - like cost analysis or optimization opportunities.
During the training we were also discussing on how such a forced root cause monitoring can be implemented via Mashups and the usage of modal popups.
I've compiled the details into this post as it might also interest other developers.
The ThingWorx Entities I'm using in this example can be downloaded from here
Note: I'm using the word "Alert" here - but not in the context of a ThingWorx Property Alert... just beware to not be confused due to the wording.
One of the requirements for Saint Gobain's IoT Solution was an interactive alert monitoring directly in the factory on the production machines. Let's say the machine has stopped, the root cause should be recorded. For this an interactive popup will be displayed on the machine's monitoring display and an employee has to choose the root cause from a pre-defined list.
This could be planned outages, e.g. for maintenance or unplanned outages, e.g. material jam.
The root cause will then be recorded and a history of outage causes can be stored in a ThingWorx value stream. This can then be later analyzed with e.g. ThingWorx Analytics capabilities to understand and optimize the machine's production capabilities and efficiency.
As the root cause must be entered, the popup will be forced to be displayed when a certain condition / criteria is met - and it will only disappar when a root cause is chosen. The user should not be able to interact with any other elements of the Mashup and not be able to just close the popup. The popup will close itself and reset the initial condition once the root cause has been identified and chosen.
Note: Just to make it easier to manage and export Entities, I will add all of the created elements in a new Project called RootCausePopups. All of the elements will have a "rcp_" added in front of their name - just to make it easier for me to find and identify them.
If you found this interesting (and actually made it to the end of this post) - feel free to play with this concept a bit more...
The dependencies might seem a bit difficult, but it should be easy to implement and to adjust to your own ideas and requirements.