Hi,

This time we have put the following features into the release:

• OAuth Authentication for Back-end Connections
• Flagging of Account Types
• Enhanced User Registration Data
• Application List Enhancements
• Canonical ID support for Google Push Notifications
• Mobile Services Preview

OAuth Authentication for Back-end Connections

By allowing OAuth authentication for back-end connections we allow for more secure connectivity towards other cloud services like SAP Jam or SAP Cloud4Customers.

Now it is no longer necessary to use HTTP Basic authentication as a fallback to create integrated mobile applications. Here is how the OAuth configuration for back-end connections looks like:

Flagging of Account Types

With this release we introduced the option to qualify your account as a being used for production or other purposes. This has two effects. First, when you work with multiple accounts, you now have a better visibility for what the current account is being used to. In addition, HCP mobile services DevOps team can better allocate necessary resources to your account if marked “production”.

Please be aware that flagging an account as “production” is a non-reversible action.

In the settings section, you can now find a new tile labeled “Account Type”. Here you can specify a tag to identify the purpose of your account.

You can specify either “production” or “non-production” and provide a description. Possible options where e.g. “HR development” or “q-landscape”. Basically, the description is free text that should make sense to you.

Once you have saved your changes, you can see the account information whenever you click on your user profile icon in the upper right corner of the Administration Cockpit:

Enhanced User Registration Data

With this HCP mobile services 1603 we introduced a new version of our registration API.

Under

https://{host}/odata/applications/v4/{APPID}/Connections

you can now put additional attributes into the user registration context of your user’s device.

We added the following values:

So if you create a user registration using the REST API (see Documentation)  you can easily add these attributes:

POST https://{HOST}/odata/applications/v4/{APPID}/Connections

Content-Type : application/json

Authorization : Basic XYZ

{

“DeviceType”:”Windows”

}

…

<content type=”application/xml”>

      <m:properties>

     ….

<d:ApplicationConnectionId>172038f3-ccc7-4b75-830f-5ef399ee7afd</d:ApplicationConnectionId>

         <d:UserName m:null=”true” />

         <d:UserLocale m:null=”true” />

         <d:TimeZone m:null=”true” />

         <d:LastKnownLocation m:null=”true” />

         <d:CreatedAt m:type=”Edm.DateTime”>2016-03-18T07:42:13.166</d:CreatedAt>

         <d:PushGroup m:null=”true” />

         <d:Email m:null=”true” />

      </m:properties>

   </content>

…

While the application runs, you can now update the properties to update the values whenever you want.

POST https://{HOST}/odata/applications/v4/{APPID}/Connections(‘{APPCID}’)

X-HTTP-METHOD:MERGE

Content-Type:application/js

{

“UserLocale”:”de_DE”,

“PushGroup”:”News”,

“LastKnownLocation”:”49.2936957,8.6394329″,

“Email”:”noone@email.com”

}

Canonical IDs

If a bug in the client app triggers multiple registrations for the same device, it can be hard to reconcile state and the client app might end up with duplicate messages.

Implementing canonical IDs can help you more easily recover from these situations. A canonical registration ID is the registration token of the last registration requested by the client app . This is the ID that the server should use when sending messages to the device.

If you try to send a message using an old registration token, GCM will process the request as usual, but it will include the canonical ID in the registration_id field of the response. Make sure to replace the registration token stored in your server with this canonical ID, as eventually the old registration token will stop working.

Mobile Services Preview

Silently we have released the option for customers (and not for trial) to subscribe a preview landscape in the HCP Cockpit (upon request).

This subscription behaves exactly like the productive version of HCP mobile services, but it runs one version ahead. The idea is, that customers can create automated regression test against this landscape and in addition developers can check how a new feature behaves. This landscape or better: additional subscription is much less resources than a productive landscape assigned and therefore it is not meant to be used for any other purposes.

This is an illustration about how the Preview works from a timing perspective:

Hope you will enjoy the new features. Let us know what you think about the new stuff.

Have Fun,

Martin