Variants
Variants enable you to create alternative versions of the same eliminator or test, depending on previous test responses. This is a very common and useful pattern in troubleshooting.
Click on the internet node to select and zoom in on it.
Use the mouse wheel to zoom out (with the internet fault group still selected).
On the right hand side of the editor select the Eliminators tab and use the pulldown menus to select the activity eliminator variant.
The editor should look like the screenshot below
For example, the internet eliminator has activity and type variants. The goal of the internet eliminator is to run tests that either ELIMINATE internet-related faults from consideration, or SCOPE the fault as definitely being internet-related. But there's more than one way to do this, depending on the results of previous tests (or in chatbot terms the answers to previous questions).
When an eliminator or test with multiple variants is evaluated (see Inference to understand the order of evaluation through the fault containment hierarchy) the first condition of each variant is evaluated to determine which variant is fully evaluated and returns the eliminator or test result. The first condition of a variant must be a variant condition with a result clause that is a logic expression instead of a ?variable assignment. The variable in the logic expression must have the same name (prefixed with a ?) as the label of the variant condition test.
If the internet eliminator is being evaluated it's because previous tests have not eliminated a network fault from consideration (so it could be an internet or cellular network fault). In the internet eliminator activity variant the variant condition evaluates the network type test to determine which type of network is being used, by looking at the problem symptoms obtained by previous query tests, and returns "internet" or "cell". If the network type equals "internet" the activity eliminator variant is selected for full evaluation and evaluates its remaining conditions. The internet activity test is a synthetic test that returns TRUE if other tests show there is some internet activity. If there is activity then the internet fault group (and all its sub-faults) can be ELIMINATED, otherwise the fault can be SCOPED to be contained within the internet fault group.
Use the pulldown menus to select the internet eliminator type variant.
The editor should look like the screenshot below
The internet eliminator type variant evaluates the same network type test in its variant condition but itsresult logic expression is "". That empty string means "evaluate this variant if no other variant condition evaluates as TRUE". The internet eliminator activity variant evaluates if the network type is "internet", so the network eliminator type variant evaluates if the network type is anything else - in which case it returns ELIMINATED (see theresultclause). That makes sense because if there aren't any Internet-related symptoms then it can't be an internet fault.
Another way to understand variants is to look at the code eXvisory dev generates from your deep logic network. Every time you press Save in eXvisory dev it generates Java code that implements all the diagnostic logic you have entered and makes it available via a cloud-hosted REST API.
Click on the Admin pulldown menu in eXvisory dev.
Right-click on Rules menu item and Open Link in New Tab.
The page that opens should contain all the Java code generated from your fault containment hierarchy (and its underlying deep logic network).
Use browser search to find "internet_eliminator_test".
If you have programming experience you should be able to see how the activity and type variants are evaluated in this Java code snippet. First the shared variant condition is evaluated, and if it returns "internet" the activity variant is evaluated, otherwise the type variant is evaluated.
public Object internet_eliminator_test() throws ExvisoryException {if (internet_eliminator_test.asserted != null)return internet_eliminator_test.asserted;​Object _type = network_type_test();​if (eq(_type, "internet")) {internet_eliminator_test.setVariant("activity");Object _activity = internet_activity_test();// ELIMINATED if there is internet activity, SCOPED if notif (is(_activity))return internet_eliminator_test.assertResult(Eliminator.Result.ELIMINATED);elsereturn internet_eliminator_test.assertResult(Eliminator.Result.SCOPED);}else {internet_eliminator_test.setVariant("type");// ELIMINATED if symptoms not related to Internetreturn internet_eliminator_test.assertResult(Eliminator.Result.ELIMINATED);}}
Variants are subject to several constraints:
The variant condition must be the first condition (of eliminator or test variants).
The variable in the variant condition's result expression must have the same name (prefixed with a ?) as the label of its test.
There can only be one variant condition. If you need more complex logic to decide which variant to evaluate - use a synthetic test as the variant condition.
Variants must refer to the same test in their variant condition (with mutually exclusive results).
If you define less than two variants an exception will be thrown when the variant evaluates.
Only one eliminator or test variant can ever be fully evaluated.
One of the eliminator or test variants must be evaluated.
Keep all variants simple enough to explain easily in their comments.
​
