Connect Microsoft Power BI to QPR ProcessAnalyzer

This guide explains how to connect Microsoft Power BI to QPR ProcessAnalyzer using the Power Query Web.Contents function. It walks you through creating the data source, building the semantic model, setting privacy levels, defining column data types, and producing the first report.

The connection works by authenticating against the QPR ProcessAnalyzer REST API to obtain an access token, then running an expression query against a selected model to retrieve data as a table.

Overview

The connection is built in the Power Query editor. The query performs three steps:

1. Get an access token: sends the username and password to the token endpoint and reads the returned access token.
2. Run an expression query: sends a QPR ProcessAnalyzer query to the api/expression/query endpoint using the access token.
3. Parse and shape: converts the returned data into a Power BI table.

Create Data Source and Semantic Model

Follow these steps to create the data source and the semantic model:

1. Open the Power BI Desktop or Power BI Service.
2. On the Home ribbon, click Get data → Blank query. The Power Query editor opens with a new empty query.
3. Delete any existing content and paste the script below. Configure, username, password, model ID, the actual query and column data types to the script.
4. Click Next.
5. Click Configure Connection.
6. Click Edit connection.
7. Select that Authentication kind is Anonymous, and Privacy level is Public or Organizational as appropriate for your organization.
8. Click Connect.
9. Click Create a report.
10. Specify a name for the semantic model, and click Create.

Power Query Script Example

let
    // ================= Configuration =================
    Url  = "https://server.onqpr.com/qprpa/",
    UserName = "qpr",
    Password = "demo",
    ModelId  = 123,
    RequestBody = [
        Dimensions = {
            [
                Name       = "Company Code",
                Expression = "Column(""Company Code"")"
            ]
        },
        Values = {
            [
                Name                = "Count",
                AggregationFunction = "count"
            ]
        },
        Ordering = {
            [
                Name      = "Count",
                Direction = "Descending"
            ]
        },
        Root             = "Cases",
        ModelId          = ModelId,
        ContextType      = "model",
        ProcessingMethod = "dataframe"
    ],

    // ================= Step 1: Get access token =================
    TokenBody = Uri.BuildQueryString([
        grant_type = "password",
        username   = UserName,
        password   = Password
    ]),
    TokenResponse = Web.Contents(
        Url,
        [
            RelativePath = "token",
            Headers = [
                #"Content-Type" = "application/x-www-form-urlencoded",
                #"Accept"       = "application/json"
            ],
            Content = Text.ToBinary(TokenBody)
        ]
    ),
    TokenParsed = Json.Document(TokenResponse),
    AccessToken = TokenParsed[access_token],

    // ================= Step 2: Run query =================
    QueryResponse = Web.Contents(
        Url,
        [
            RelativePath = "api/expression/query",
            Headers = [
                #"Content-Type"  = "application/json",
                #"Accept"        = "application/json",
                #"Authorization" = "Bearer " & AccessToken
            ],
            Content = Json.FromValue(RequestBody)
        ]
    ),
    Parsed = Json.Document(QueryResponse),
    AsTable = Table.FromRecords(Parsed),

    // ================= Step 3: Set column types =================
    TypedTable = Table.TransformColumnTypes(
        AsTable,
        {
            {"Company Code", type text},
            {"Count",        Int64.Type}
        }
    )
in
    TypedTable

Column Data Types

The data type for each column in the returned data needs to be specified correctly. The following example script shows how to convert each data type used by QPR ProcessAnalyzer.

TypedTable = Table.TransformColumnTypes(
	AsTable,
	{
		{"TextColumn", type text},
		{"IntegerColumn", Int64.Type},
		{"DecimalColumn", type number},
		{"DateColumn", type date},
		{"BooleanColumn", type logical}
	}
),

Create Report

When the data source and the semantic model are in place, you can continue with creating the first report:

1. From the Visualizations pane, select a visual, for example a bar chart.
2. From the Data pane, drag fields onto the visual:
   • Drag Company Code to the Y-axis (or Axis).
   • Drag Count to the X-axis (or Values).
3. Adjust formatting (title, colors, data labels) in the Format pane.
4. Save the report: File → Save As.

Limitations

When implementing this integration, be aware of the following limitations.

Refreshing Data

Data shown in Power BI is a snapshot taken at the time of the last data load. It is not a live connection to QPR ProcessAnalyzer. The data is updated when a refresh is performed, either:

• Manual refresh: In Power BI Service, open the semantic model, and press the Refresh button. In Power BI Desktop, click Refresh on the Home ribbon.
• Scheduled refresh: Power BI Service allows to schedule an automatic refresh. Open the semantic model and press the arrow down below in the Refresh button and press Schedule refresh.

Shared QPR ProcessAnalyzer Credentials

The connection authenticates using a single set of QPR ProcessAnalyzer credentials embedded in the query, rather than each report user's individual account. This has important consequences:

• All Power BI users effectively see data through the same QPR ProcessAnalyzer account, regardless of who they are.
• User-specific permissions and per-user access restrictions defined in QPR ProcessAnalyzer are not applied to individual Power BI users.
• Any access control must be handled on the Power BI side (for example, workspace permissions or row-level security), not through the QPR ProcessAnalyzer.

Filtering Behavior

Filters applied to cases or events on the QPR ProcessAnalyzer side cannot be applied through this integration. The query retrieves data according to the defined dimensions and values without any interactive source-level filtering.

• Only filtering performed on the Power BI side (slicers, visual filters, page/report filters) takes effect.
• This means the full result set defined by the query is always retrieved before Power BI filtering is applied, which can affect the volume of data transferred and report performance.
• To limit data at the source, you must change the query itself rather than rely on interactive filtering.