New API modes and verbs on WebData for 10.1.5: GraphQL endpoint consumption, MCP client sessions, and the full REST verb set.
Reference → Modules → Reports → UI → WebData → GraphQL and MCP Client
New in 10.1.5. The API dropdown on the WebData grid adds GraphQL and McpHttp alongside REST, and REST gains PUT, PATCH, and DELETE verbs. Existing solutions open with API=REST and unchanged behavior.
A WebData row now represents one of three protocols: REST (the default), GraphQL, or an MCP server over HTTP. The protocol is set by the API column on the grid. Each mode exposes its own script methods. Calling a method from the wrong mode throws InvalidOperationException, so miswiring surfaces immediately at design and test time.
For base WebData configuration (Name, Encoding, DefaultURL, Authorization, Headers, Editor, File Operations, Padding), see Reports WebData Reference.
API Dropdown Values
| Value | Use when | Script methods |
|---|---|---|
| REST | You consume or expose a REST API. | GetRequestAsync, PostRequestAsync, PutRequestAsync, PatchRequestAsync, DeleteRequestAsync. |
| GraphQL | You consume a GraphQL endpoint. | QueryAsync(), QueryAsync(variablesJson). |
| McpHttp | You consume an MCP server over HTTP (tool discovery and tool calls). | ListToolsAsync, CallAsync(), CallAsync(argumentsJson). |
Mode guard: invoking a GraphQL or MCP method on a REST row, or any cross-mode combination, throws InvalidOperationException with the offending method name and the actual row mode.
REST Verbs (PUT, PATCH, DELETE)
In addition to the existing GetRequestAsync and PostRequestAsync, three new verb methods are available on REST rows.
PUT
Replace a resource with the Editor body.
await @Report.WebData.API.PutRequestAsync();
PATCH
Apply a partial update to a resource.
await @Report.WebData.API.PatchRequestAsync();
DELETE
Remove a resource.
await @Report.WebData.API.DeleteRequestAsync();
All three respect the row's Authorization, Headers, and Editor body exactly like POST. Response handling is identical to the existing verbs (see Reports WebData Reference).
GraphQL
Set API to GraphQL. The query text lives in the WebData Editor body. Variables are authored in the Editor and overridden at runtime when needed.
// Run the Editor query unchanged
string json = await @Report.WebData.GraphAPI.QueryAsync();
// Override variables at runtime
string variables = "{ \"plantId\": \"Plant1\", \"limit\": 25 }";
string json2 = await @Report.WebData.GraphAPI.QueryAsync(variables);
// Inspect the response
@Tag.GraphResponse = json2;
A GraphQL response with errors[] at HTTP 200 is returned as-is. Your script decides how to react. HTTP-level failures (non-2xx) surface as exceptions identical to REST.
MCP Client (HTTP)
Set API to McpHttp. The row represents an MCP client session. Configure the server URL in DefaultURL. The runtime opens the session on first call, reuses it for five minutes of idle time, and closes it on runtime stop or after the idle window.
// Discover available tools
string toolsJson = await @Report.WebData.McpServer.ListToolsAsync();
@Tag.AvailableTools = toolsJson;
// Call a tool with the Editor-body arguments
string result1 = await @Report.WebData.McpServer.CallAsync();
// Override arguments at runtime
string args = "{ \"target\": \"Plant1/Tank1\", \"mode\": \"read\" }";
string result2 = await @Report.WebData.McpServer.CallAsync(args);
A server returning HTTP 404 triggers automatic session re-init and one retry. Any other HTTP error surfaces as an exception. The session is disposed on OnStop of the Report runtime, so no background HTTP state survives across runtime restarts.
The MCP client speaks streamable-HTTP with JSON-RPC 2.0 framing. Authorization and Headers on the WebData row flow into every request, so bearer tokens and custom headers work exactly like REST.
Migration
Existing WebData rows open with API=REST and unchanged behavior. No property-level migration is required. Setting the API value to GraphQL or McpHttp is a one-click change on the grid.
In this section...