Azure Logic Apps Text-to-speech with TalkToMe API

Many years ago i made a text-to-speech WCF binding that i used in demos and proof-of-concepts with BizTalk Server. Its time to bring that up to 2015!

This time i will use the Azure App Service stack with a custom Azure API App that can be used from a Azure Logic App. The API App will let you connect a browser session to it that will act as the “loudspeaker”.

TalkToMe GitHub repo – instructions and code

The API app has two parts, both hosted together. First the API that hosts a SignalR hub and the second one is the UI that connects one (or more) browser as the API App “Loudspeaker”. As an Azure API App is just a ‘normal’ Web App it can host both parts and no other deployment is needed. Sweet!

  • WebAPI
    • SignalR Hub
  • Client UI (Hosted inside the API App!)

SignalR is the brilliant communication framework that will allow us to trigger functionality in the client (browser) yet abstracting away the actual connection details (web-sockets, long-polling etc.).

To test the API App i used a Logic App that gets weather data from that TalkToMe API then will read out. Note that by design the API will return 202/Accepted even if no browser (ie. SignalR client) is connected and no queuing or similar is performed.

How to use in Azure Logic Apps

  1. Deploy Azure API App
  2. Create and deploy a Logic App where TalkToMe is used as an ‘action’ Logic App
  3. Connect one or more browsers to the API by browsing the root URL of the deployed API. If you are unsure of the URL you can find the link in the ‘essentials’ section of the API App in the portal.image image
  4. Run the Logic App

When the logic app runs and the TalkToMe action fires the portal should show something like image

And you should hear the artificial voice read the weather 🙂 image

Test API using HTTP

If you just want to try the API App, outside of an Logic App, you can use a simple REST call.

REST param Value
URL http://{your-apiapp-url}/api/TalkToMe
Content-Type application/json
Body { “TextToRead” : “Nice weather today” }




ASP.NET Web API support for ODATA $select

Since VS 2012.2 update ASP.NET Web API can take advantage of the ODATA Query parameters. Having the API consumer dictate part of the query can be powerful yet something that naturally needs some performance and security consideration before implementation.

Enabling the support is as simple as decorating the controller class or selected methods with the ActionFilterAttribute Queryable.


Now the API automatically supports things like $top, $orderby, $filter directly on the URL. 🙂

So a HTTP GET to http://server/service/api/wines?$top=2&filter=WineType eq ‘Red’ would get me this response


You can control what queries to allow using properties on the ActionFilter Queryable.

One thing missing in the Web API ODATA implementation compared to the full-blown ODATA implementation in WCF Data Services is the $select keyword. The $select lets the API consumer pick what fields to return. With large objects this can save both bandwidth and serialization/deserialization performance.

The fact that ASP.NET Web API is open source in combination with the nightly-builds available on MyGet makes testing upcoming features super easy. Since a week or two back both $select and the $expand are available in the nightly-builds. (

To install run this command:

install-package Microsoft.AspNet.WebApi.OData -pre -source


After installation i can now make a HTTP GET like this
http://server/service/api/wines?&$top=2&$filter=WineType eq ‘Red’&$select=Id,Name and get only the ‘Id’ and ‘Name’ fields in the response.



The nightly-build i tried (5.0.0-beta1-130511) only had $select support when using JSON. With XML it causes a serialization exception. I guess supporting this with the DataContractSerializer would require alot more work compared to what they had to do with JSON.

Anyway – i think its a nice feature so thanks to the team working at getting this feature into the framework in a future release and the opportunity for me to beta-test it already today 🙂