Blither, Blather, Web Content Management.
Blog » Alexa on Azure: Part 9–Azure Function Proxies

Alexa on Azure: Part 9–Azure Function Proxies

So I’ve been sinking a bit of my spare time into the Ask Teenage Daughter & Ask Teenage son skills over the last couple months. I’ve been maintaining them as separate skills, but really they are almost exactly the same. So I feel like I’ve been duplicating my efforts where I could be simplifying them.

I wanted to have two, gender specific, skills on Amazon. Although I probably could have pointed both skills in Amazon to the same service, I don’t believe Amazon passes anything in the call that tells you which skill it came from and it won’t pass in any query string parameters when it’s in production. Maybe it’s there somewhere, but it isn’t obvious and, full disclosure, I didn’t look that hard. Back to the point though, these skills are almost identical now, but I have plans to expand the responses to be more gender specific in the future.

Then I saw this episode of Tuesdays with Core: Azure Functions Proxies extravaganza with Donna Malayeri. You can think of Azure Function’s Proxies as a redirect, or a pipe. You stand up an outward facing URL and point it at another URL. The second URL doesn’t even have to be an Azure Function, but in my case it is. My idea was to create two separate URLs for Alexa to see, and behind the scenes point them to the same Azure Function URL, but with a gender specific query string parameter attached to each one.

Step 1. Refactor. I copied all of the Teenage Daughter version over to AlexaAskTeenager and then spent some time making the code gender neutral and getting it to all compile again. I split the SpeechAssets into 3 folders, Common, Daughter, & Son. I added the _09 extension to the old versions and updated all the readme files – that was more time consuming than I’d like to admit.


Step 2, create the Proxies. Since proxies is still a preview feature, it needs to be turned on inside the settings tab. Yeah, there’s a settings tab now, and hey this whole screen is different.

Enable Proxies

Then you’ll be able to click the + to add a proxy.

Add Proxy

It’s a very simple setup and if you were going to do it through the UI, it would look like this. Notice I put an additional query parameter in there (and also I made my new function use function security instead of anonymous).

New Proxy Screen

However, don’t do it this way. Instead, its dead simple to just define the proxy in your project and deploy it with your function code. At the root of your project (a sibling to your host.json), add a proxies .json file.

add proxies.json

And the contents of that file are as simple as you’d hope.


You can find more info on Proxies, including the documentation on the proxies.json file here.

Step 3. Update the skill information in the Amazon developer portal.

Now I’ve got Alexa working with my proxies great, but I’m not yet doing anything in my code to respond differently to a call from Teenage Daughter than a call from Teenage Son.

Step 4. Use the query string parameter in the code. I decided that I at least wanted to have the card that gets passed back to Alexa display the title of the skill that was called. So I’ll just do that for now.

In a previous article I mentioned that the function code just passes execution into the speechlet and the speechlet is responsible for parsing the request and creating the response. This was an issue I already dealt with when I wanted to pass in the Tracewriter and Azure Queue for the speechlet to utilize within my method overloads. The same technique works here too.

Add a new property and update the speechlet constructor to set it:

Update Constructor

And update all of the calls to BuildSpeechletResponse to use the new property.

Reference Property

Then update my function code to read in the query string parameter and pass it to the constructor.

Update Function Code

Step 5. Update my timer function to point at the right URL.

Posted: 4/28/2017 6:00:00 AM by Ryan Miller | with 0 comments