Testing the SDL Web 8 micro-services

A couple of days ago, at the Tridion Developer summit, I did a “lightning talk” where in fifteen minutes flat, I rattled through my recent experiences of setting up publishing and content delivery using the new Topology Manager and micro-services in SDL Web 8. It’s hard to go into much detail in fifteen minutes, so on one level it’s just a bit of fun, but I hope I also managed to help people avoid some of the pain points.

Whenever I’m setting up infrastructure, one thing I’m very keen on is being able to test the individual pieces independently. That way you can move on to the next piece confident that when you run it all together, there is a good chance of it working. So in my talk, one of the things I demonstrated was a simple PowerShell script that checks if the content service is working. After my talk, several people approached me to discuss points that I’d raised, and by far the most popular item, it seems, was this script. So here it is:

$params = @{
    client_id='cduser'
    client_secret='CDUserP@ssw0rd'
    grant_type='client_credentials'
    resources='/'
    }

$token = Invoke-RestMethod -Uri 'http://localhost:9082/token.svc' -Method POST -Body $params 
$Authorization = $token.token_type + ' ' + $token.access_token

$query = '/Publications'
$stagingUri = 'http://localhost:9081/client/v2/content.svc' + $query
$stagingContent = Invoke-RestMethod -Method Get -Uri $stagingUri -Headers @{Authorization=$Authorization}
if ($stagingContent) {
    "Staging content... there is some"

    $ns = @{
        atom="http://www.w3.org/2005/Atom"
        metadata="http://docs.oasis-open.org/odata/ns/metadata"
        data="http://docs.oasis-open.org/odata/ns/data"
        m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
        d="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
    }

    # Some weirdness here. XML fragments... 
    Select-Xml -Content $stagingContent.OuterXml -Namespace $ns -XPath "/atom:entry/atom:title" | %{$_.Node.InnerText}

    } else {
    "No data returned" 
}

The reason why people found it interesting is that these services are a bit tricky to test with a browser, because you need to send an OAuth authorisation header. There are browser plugins that can help with this, but personally, I like the idea of having a script like this in my tool box. Of course, it’s pretty rough and ready, but it serves to show how you can do a very simple test:

1. Put the required authentication details into a hash, and put this in the body of a POST request to the token service. (Here I've used the 'cduser' account with the default credentials, but of course, in production systems, you'll need to match the credentials configured in the cd_ambient_conf.xml file of the discovery service.)
2. Extract the authorisation token from the response and use it to create the Authorization header of your call to the content service.
3. What you do with the output data is really up to you. I've queried for '/Publications', and then used an xpath to fish the relevant text out of the response. You can easily modify this to do different queries and process the output differently.

The main point here is that you can verify that things are working correctly with just a few lines of code. I expect that over time I will make a more generic or fully featured version that does somewhat more. Obviously, you can use the same technique to test the other services, and it should also be possible (as suggested to me by Renze de Vries) to first query the discovery service, obtain the endpoints for the various capabilities, and then test them all in turn.

I hope you’ll find this technique helpful, and of course, I’d love to hear of any improvements you come up with, or interesting variations.