The Match Each Row rules allow checks to be made against every row in the result set. Arbitrary boolean expressions can be constructed in the Match Each Row rules by using AND and OR between clauses, parenthesis to enclose sets of clauses, and arbitrary operators including equality and non-equality.
You must avoid anything but simple alias.field=matchvalue clauses in the MatchEachRow expression if you want an remedy to be generated automatically, because the introduction of OR clauses or non-exact match operations (e.g. non-equal comparisons such as > or <, or LIKE or ~) will cause the possible remedy to be generated to be ambiguous (i.e. multiple remedies become possible, and if non-exact match operators are used the values to be used in the remedy are not even clearly specified).
In the example of the Match Each Row Test, two Queries are used. The Primary Query is listed first, and has a Join list of the following illustrated in Match Each Row query.
This creates a table as OspfRouterSettings. The column for this Query is just the “basic” projection for the OspfRouterSettings router alias. There are no Selection clauses.
The second query is used to populate variables from the Device’s properties. It has an even simpler Join list, as illustrated in Match Each Row — second query.
This creates a table of Device properties. We choose the Device’s basic projection for the columns to be retrieved. We also click the Options Tab check box “Limit query to device under test”. This causes an implicit selection to be inserted when the query is run as part of a compliance test, as shown in Device properties table.
This selection clause selects rows based on the variable compliance.DeviceId, which in the context of running an Attributed Compliance Test is set to the (Long) id of the Device that is being tested. The second query is then getting the Device properties of the Device being tested.
The second query also has the following definitions in the Variable’s tab, as shown in Device property definitions displayed in the Variable tab.
The Query Variables tab will produce two variables, FixedIp; a fixed String value of 100.100.100.100, and ManagementIp; the cell value in row 0 of our result set from the ManagementIp column.
As the query’s selection criteria are set to return only a single row consisting of the Device being tested, the ManagementIp variable is the Device under test’s ManagementIp address.
The MatchEachRow rules now check that every OspfRouterSettings instance has a RouterId property equal to the Device’s Management Ip, as shown in Match Each Row checking OspfRouterSettings instances.
This single rule checks that the PrimaryQuery’s OspfRouterSettings router.RouterId property is equal to the ${ManagementIp} variable which for the router that is being tested in this example is 172.17.0.70. When this test is applied to a Device, here is the Result View that is computed:
The yellow highlighted result set line indicates a failure in the match each row expressions, because the RouterId of our OSPF instance is configured to 172.17.0.199, and not our management IP address of 172.17.0.70. The generated blue line indicates what the contents should be updated to, and shows the correct IP address of 172.17.0.70, which was the Device’s management IP address.
The blue generated update row can only be generated if the result of evaluating the boolean Match Each Row expression is unambiguous. For example, if our Match Each Row expression had been the following, as illustrated in Match Each Row results when boolean expression is unambiguous.
The correction would be ambiguous and the blue updated row would not be generated.
You can make complex boolean expressions in the Match Each Row rules just like you can in the Query Selection tab, however if a failure occurs you will not get any information other than the result of applying the boolean expression to a particular row failed.