:note: This wiki entry mostly focuses on the logic part of a rule.

All rules are defined in a rules array as follows:

{
   "rules":
   [
   ]
}

The simplest rule example I can think of is to test that true is true:

{
    "rules":
    [
        {
            "id": "SIMPLEST_RULE",
            "name": "Simplest Rule",
            "test": [
                true,
                true
            ]
        }
    ]
}

The next simplest rule example I can think of is to check that "a" equals "a".

{
    "rules":
    [
        {
            "id": "SIMPLE_OPERATION",
            "name": "Simple Operation",
            "test": [
                {
                    "==": [
                        "a",
                        "a"
                    ]
                },
                true
            ]
        }
    ]
}

The next step is to nest operations so that the output of the inner operation becomes the input of the outer operation:

{
    "rules":
    [
        {
            "id": "NESTED_OPERATIONS",
            "name": "Nested operations",
            "test": [
                {
                    "if": [
                        {
                            "<": [
                                1,
                                2
                            ]
                        },
                        "smaller",
                        "equalorgreater"
                    ]
                },
                "smaller"
            ]
        }
    ]
}

For other JSONLogic operators see https://jsonlogic.com/operations.html.

Let's see how to apply JSONLogic to a given Fabric item or the parent CI\CD folder for a number of Fabric items depending on what path we point the PBI Inspector V2 to. In the rule below, the empty var path (i.e. {"var": ""}) references the root item as per the item path specified. If the item under inspection is not a json file, JSON metadata about the item will be returned (such as the item's file path) otherwise the json content of the item will returned.

{
    "rules":
    [
        {
            "id": "ROOT_FABRIC_ITEM",
            "name": "Root Fabric Item",
            "test": [
                {
                    "var": ""
                },
                {}
            ]
        }
    ]
}

Rules that target Power BI reports benefit from a part query helper so that most parts can be accessed through keywords such as Report, Pages, Visuals, Bookmarks, etc.

When pointing to a Power BI Report path, the following rule is applied iteratively across each report page thanks to the use of the "Pages" part iterator. This rule checks that each page's display name is "My page display name", clearly that's unlikely to be the case so this test will likely fail.

{
    "rules":
    [
        {
            "id": "ITERATIVE_RULE",
            "name": "Iterative rule",
            "part": "Pages",
            "test": [
                {
                    "var": "displayName"
                },
                "My page display name"
            ]
        }
    ]
}

By contrast the rule logic below combines all pages display names in an array. This rule uses the "part" operator within the test logic as opposed to the outer "part" iterator.

{
    "rules":
    [
        {
            "id": "RETURN_PAGE_NAMES",
            "name": "Return page names",
            "test": [
                {
                    "map": [
                        {
                            "part": "Pages"
                        },
                        {
                            "var": "displayName"
                        }
                    ]
                },
                ["Page 1", "Page 2", "Page 3"]
            ]
        }
    ]
}

Fabric rules do not (yet) benefit from the part query helper enjoyed by Power BI rules, instead various files (or folders) within a given Fabric item definition or across definitions can be referenced with a regular expression to match the desired file or folder paths (note that folders are separated by column characters instead of backslashes \ or slashes /). For example, if we want to match all copyjob-content.json across all CopyJob in our CI/CD folder we can just specify the part iterator as "part": "copyjob-content.json"

{
    "rules":
    [
        {
            "id": "CHECK_COPYJOB_JOBMODE",
            "name": "Iterate through each CopyJob definition file and check that the JobMode is Batch.",
            "itemType": "CopyJob",
            "part": "copyjob-content.json",
            "test": [
                {
                    "var": "properties.jobMode"
                },
                "Batch"
            ]
        }
    ]
}

Otherwise if we want to retrict our test to copyjob-content.json within a specific CI/CD subfolder, we could define this regular expression to match the items' file path (folders are column separated):

"part":"folder1:.*:copyjob-content.json"

or

"part":"folder1:.*:copyjob-content\.json$"

to match a Fabric item path such as (on Windows):

C:\fabricproject\folder1\copyjob1.CopyJob\copyjob-content.json

or on Linux:

/home/fabricproject/folder1/copyjob1.CopyJob/copyjob-content.json

[Tutorial material to be continued...]