Skip to content

Querying the GraphQL Content service with Powershell

Dominic Cronin edited this page Dec 31, 2019 · 6 revisions

Introduction

This script demonstrates how you can call Tridion's GraphQL Content API from the Windows Powershell. Using this script and modified versions of it, you can query a Content Delivery environment for it's content. This cookbook recipe does not attempt to teach you GraphQL, or the schema which defines the API. There are other resources for that. Here, the goal is simply to show the mechanics of calling the service, and retrieving the data. It is quite possible that you are already familiar with other tools for this, but a little redundancy is no bad thing, and there will undoubtedly be cases where this approach is useful.

Script

You can download the script here: Demo-ContentQueries.ps1

Running the script

From the folder where you have downloaded the script, you can call it like this:

PS > .\Demo-ContentQueries.ps1 -discoveryURL http://cd.local:8082/discovery.svc -client_id cduser -client_secret CDUserP@ssw0rd

If the client Id and secret are still at their default values, you can omit these parameters.

Discussion

The script begins with various utility functions. Towards the bottom, you can see the query $getDxaPages. This is a modified version of one of the samples from docs.sdl.com. The system used for developing the script has an unmodified DXA demo site, which is published from publication 5, so the query filters on that, and also specifies namespace 1, referring to Sites content rather than Docs.

The process of establishing an OAuth token is hopefully fairly standard, although with a slight deviation, in that the ContentServiceCapability doesn't directly give us the URI of the GraphQL service, so we just tag /cd/api on to the base URL of the other content service. The registration of capabilities does allow for some configuration of extra metadata, but for a vanilla set-up, just going to the well-known path should be good enough. When making multiple queries, you could certainly re-use the token and respond to invalid_grant conditions.

The GraphQL query itself is written as a PowerShell "here-string" which allows for a block of text, line breaks and all. GraphQL seems to be agnostic about readability, and if you throw away all the whitespace, it would still work. For the payload-obsessed, just remember: gzip is your friend.

Once we're in the function Query-GraphQLService you can see that we go rather rapidly through quite a repertoire of formats.

The incoming $graphQlQuery parameter is, as defined in the here-string, in graphQL format. In in order to send this to the server, it must be wrapped in a JSON message as described here. As described there, you can also send a pure GraphQL query string if you use the appropriate Content-Type, but sending JSON allows you to easily enhance the script to pass variables if you wish.

In Powershell, probably the cleanest way to create JSON is to model the data using native Powershell constructs and then pass it through ConvertTo-JSON. That's what we do here, using a hash to represent the JSON object we want:

$jsonRequestBody = @{"query"=$graphQlQuery} |ConvertTo-Json

Filling in the other fields would get you something like this:

@{"query"="#Some GraphQL";operationName="GetTheStuff";variables=@{"foo"="bar"}} |ConvertTo-JSON

All that remains is to set up the necessary headers and send the request. Invoke-RestMethod returns the data, which we then convert to JSON before returning. In a real-world script, you might well skip the JSON conversion and process the data directly, but if you just want readable output, JSON is fine. ConvertTo-JSON's Depth parameter needs to be set higher than its default value of 2, or you won't get the result you are expecting.

Clone this wiki locally
You can’t perform that action at this time.