Building Service Management API requests for Windows Azure Mobile Services in Fluent Management

Over the last few days I’ve been having some fun with mobile services specifically trying to reverse the CLI tools by
tracking their HTTP requests-responses. Somebody recently asked me if we (as a company) had the capability to add a Mobile Service deployment to our orchestration for Fluent Management and since I’ve been working with mobile services for the last few months I figured I might as well give it a go and decided to try and work out the Service Management requests I need. Everything I write here is specific to the mobile services addition to Azure Fluent Management. To get started with Fluent Management have a play with the latest version on nuget or check out the code on Github. For a quickstart guide you can look at the wiki here.

In order to facilitate an experience akin to the new CLI tools I wanted to copy the parts which would make a good stateful experience and allow for a full deployment of a mobile service. Give the client in Azure Management a test run but weary of deploying and using in a production system just yet until the v1 of the API is published by Microsoft. Until then the CLI is a great resource and pretty much does everything you need for a full scale deployment of Mobile Services.

Currrently there are two things I’ve left out in my implementation:

  • Apns (Apple Push Notification Service)
  • Scheduled Jobs

The former I’ll add in the next few weeks as I have a need for it going forward. The latter I’ll have to take a closer look at and maybe see if I can get a heads up from the mobile services and/or the CLI team. Remember, this is all reverse-engineered and there is no published spec for this API. Given what I’ve seen of it I’m sure it will change considerably before being released as well. For my part I’ll keep Fluent Management up-to-date and hopefully there will be some backward compatibility with operations. There’s also some feedback I’ll give to Microsoft since I’ve come across some issues in attempting to do this.

It’s important to say that I haven’t yet implemented this as transactional component of Fluent Management but it is a stateful client called MobileServicesClient which is fairly feature rich. In the next month I will as I have to ensure that Cloud Services, Storage and Db’s are created transactionally with the Mobile Service so watch this space. For the time being the client is pretty much fully functional apart from the above so should suit most scenarios where the CLI is not applicable.

The current client contains the following features:

  • Create a new mobile service with a new linked Db
  • Get the context of an existing mobile service
  • Return all mobile service settings including identity and push notifications
  • Return all mobile service tables with associated permissions
  • Add new tables
  • Add new scripts and update table permissions
  • Update all properties (including dynamic schema)
  • Regenerate application and master keys
  • Restart the mobile service
  • Return the top 200 logs and show incremental state filtered by date

The following shows what you can do with an existing mobile service. Since Fluent Management has had a rehaul I’ve built new mock tests with @andybareweb but have foregone all of the functional tests. For now I’ve decided to build a fully functional console application as a test harness which will leverage fluent management. It’s not that I’m trying to write another set of powershell CmdLets or CLI tools with this because Fluent Management was simply released to provide a fluent interface to deployments and to build orchestration patterns atomically for deployment of all dependent Azure ┬áservices. It is, however, a good way to test the fluent interface where we cannot test through mocks.

And you can also just build a new mobile service like so:

As you can see building a new mobile service is automatically stateful so you can just keep the MobileServicesClient context and do any available operations on it.

Hope you enjoy this. For me it was a couple of days of intense effort but I’m very happy with the results.

Tagged with: , , , , , , , , ,
Posted in Azure REST APIs, Service Management API, Windows Azure Mobile Services
3 comments on “Building Service Management API requests for Windows Azure Mobile Services in Fluent Management
  1. Paul Batum says:

    Great post! It is pretty cool to see that someone can grab your package off NuGet and start creating mobile services from C#.

    I’m a member of the Mobile Services team and I work on the management API (among other things). I appreciate the careful qualifications you gave about using the API given that we have not published it just yet! Feel free to contact me at if you have questions or feedback about the API.

    One last thing: I imagine you may run into difficulty with scheduled jobs because our CLI doesn’t support those yet – we are working to address this.

  2. Ali Zaidi says:


    First of all i like your fluent api great work.

    In my scenario i want to create mobile service with existing database its not supported then i go for getting data of existing mobile service but it failed too i got 404 response saying mobile service not exists.

    I switch to create new mobile service it created successfully but i got message 410 Gone.

    any help..?

    thanks in advance

    • azurecoder says:


      Hi, sorry for the late response. Just got back from a vacation. I haven’t added support for using an existing database but I can do this it’s not a big job I just haven’t had a need yet. Can you raise an issue on Github and write the specific scenario and put the fluent management code you’re using and I’ll try and replicate and take a look at it.

      You can add it here:

      Thanks again!


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>