XenMobile has a powerful REST API that exposes a lot of rich information about your XenMobile site, and also allows you to manipulate it. But what are some practical things that you can do with it?

First, if you haven’t already seen Ole Kristian Lona’s 3-part series on how to use the REST API it’s worth a read; it will guide you through the details of first authenticating, then sending requests, and also how to look at the traffic and debug any issues.

Based on that set of articles we’ll assume that you’ll know how to craft and send API requests, so we won’t cover that here.

Citrix Cloud XenMobile Service

If your XenMobile site is hosted by us in Citrix Cloud (and if it’s not, then what are you waiting for?!), then you may wonder how you authenticate to the XenMobile API. If you use the same credentials that you use to login to Citrix Cloud, you’ll notice that it doesn’t work. That’s due to the way that we enable single sign-on between Citrix Cloud and the XenMobile site.

One solution is to go to the XenMobile web console (through Citrix Cloud as normal) and then from the Manage → Users view add a new local user with the “Admin” role. That account will then be able to make REST API calls.

Even better is to follow the principle of least privilege and to create a new Role (from Settings → Role-Based Access Control) that just has the “Public API Access” permission plus whatever permission(s) you actually need. For instance let’s say you want to create a script that will just need to read device information then you might create a role that only has “Devices” and “Public API Access” permissions. Then, when you create a new local user, add them to this new role. That way, if the credentials for that API user account ever get compromised, you have limited how much damage can be done.

Practical Use-Cases

Let’s cover some use-cases and show some examples of what you can do with the XenMobile API.

Device Inventory

Create a Windows Task or Cron job that every night downloads the list of devices and archives them into a database or other data repository that you can easily search.

Request:

POST https://hostname:4443/xenmobile/api/v1/device/filter
Auth_token : token
Content-Type : application/json
{ }

Note that you’re supplying an empty filter (“{ }”) in the body of this request, which means don’t apply a filter and just given me all the results.

You’ll now not only have a historical record of all devices in your XM site, and for example be able to see when devices check-in or get removed, but you’ll also be able to easily slice and dice this information however you want. Speaking of which…

User Activity

If you want to see how active your users are — or just a particular user — you might think to go look at the user-related APIs. However that’s not available from there, and in fact what you’re really looking for is device activity from a specific user. Hence, the API request is the same as above. To see the user information look at the response.

Response:

{
“status” : 0,
… snip …
“filteredDevicesDataList” : [
{
“id” : 2,
“username” : “user4@acme.com \”user4\””,
“lastAccess” : “11/1/17 3:02pm”,
… snip …

Hence from the POST /xenmobile/api/v1/device/filter API you’ll be able to see all devices and more importantly their users and their last access. You can then filter this data in your client-side code to aggregate user info across devices (since a user might have more than 1 device) and take the most recent “lastAccess” time. That will give you a useful metric to see how active your users are.

Migrate Apps from a Test Site to your Production Site

It’s common to have a Test (or Pilot, or PoC) XenMobile site that you use to first try out new version, configuration changes, etc…, before you roll it out to your actual Production site.  That can be a bit tedious when you have a lot of apps or system properties.

Get Apps Request (from your test site):

POST https://poc-hostname:4443/xenmobile/api/v1/application/filter
Auth_token : token
Content-Type : application/json
{ }

To then add it to your Production site depends on the type of app.  We’ll cover Enterprise apps:

Upload App Request:

POST https://prod-hostname:4443/xenmobile/api/v1/application/mobile/enterprise/platform
Auth_token : token
Content-Type : application/json
… content of the app from the Get Apps request …

Migrate Server Properties from a Test Site to your Production Site

Likewise, this is how you would do it for system properties.

Get Request (from your test site):

GET https://poc-hostname:4443/xenmobile/api/v1/serverproperties
Auth_token : token
Content-Type : application/json
{ }

You will then add each server property to the Production site, one at a time:

Add (or Edit) Request (to your production site):

POST https://prod-hostname:4443/xenmobile/api/v1/serverproperties
Auth_token : token
Content-Type : application/json
… content of the server property from the GET request …

Self-Enrollment and Bulk Enrollment

I’d be remiss if I didn’t point that the Part 3 of the series I mentioned earlier covers how to create a portal that lets your end-users do self-enrollment, and also how you as a customer admin can do bulk enrollment of devices. It’s definitely worth a read!