SAP HANA Cloud Platform Mobile Services 1603 Release
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.
you can now put additional attributes into the user registration context of your user’s device.
We added the following values:
|users preferred language|
|users time zone|
||users email address|
So if you create a user registration using the REST API (see Documentation) you can easily add these attributes:
Content-Type : application/json
Authorization : Basic XYZ
<d:UserName m:null=”true” />
<d:UserLocale m:null=”true” />
<d:TimeZone m:null=”true” />
<d:LastKnownLocation m:null=”true” />
<d:PushGroup m:null=”true” />
<d:Email m:null=”true” />
While the application runs, you can now update the properties to update the values whenever you want.
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.
It seems that developers now have a choice to register a device using oAuth or the conventional way based on APPCID. What would be the way forward if you're developing an app greenfied?
we do have a new way of registration, mainly used by the HCP iOS SDK where we separate the authentication from the registration. So basically you can use SAML/OAuth to authenticate and afterwards already use the push service - no need for an APPCID. This parallel approach (the usual registration is completely valid) is good for use cases where you want to use the services provided services individually, e.g. without HCPms as a proxy but still using proxy.
Personally, I think I'd stay with the "traditional" registration - you get extra reporting features and more.
Kini jangan takut segera pastikan sakit Anda pada web herbal bliherbal, dan alami sendiri perbaikan positif bagi tubuh, serta terlepas dari malapetaka sakit-penyakit degeneratif. obat herbal kanker darah leukimia