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.