- SAP Managed Tags:
Update: The code for the sample application and the How To Guide is now published.
Many years ago, when I had to drive to a different city my first order of business was to print out a map from MapQuest. Armed with the map, I could for the most part navigate myself in the new city with not much trouble. Then came the GPS and the rest is history. In a similar fashion, last year I wrote a simple application to consume an OData Service using WCF Data Services client library. The process was not tough. By adding a service reference to the OData Service, Visual Studio automatically generated client data service classes which are then used to consume the OData Service as objects. So when I heard SAP was going to create our own Windows SAP Mobile Platform SDK (hereinafter referred to as “SMP SDK” or “SDK”) to consume OData Service, I was naturally curious…
Characteristics of an enterprise application
Let me digress here a little bit. What makes the GPS a far superior alternative to printed maps? It’s the fact that you don’t have to spend much time reading the map. The GPS with its voice navigation offers more features – features that make you focus on driving.
As a developer, your main objective is to write applications that meet business requirements. However, in addition to business requirements, there are also a number of enterprise requirements that are common to all the applications (for example: authentication, data security, administration, offline access and synchronization, push notification etc.). And that is precisely how the SMP SDK helps the developer. It makes writing applications to meet business requirements a lot easier and at the same time devolves the responsibilities of meeting enterprise requirement to a higher power.
Supported environments
SMP SDK ships with 2 separate set of libraries. One set of libraries target Windows Store applications – specifically Windows 8.1 and Windows Phone 8.1. The other set of libraries target Windows Desktop applications – any Windows machine running .NET 4.5 or higher. It is important to understand that the APIs we provide on the 3 platforms (Windows desktop, Windows tablets, Windows Phone 8.1) are all identical. The platform differences are handled inside the libraries, so the developer can call LogonCore or ODataOnline (or any other library) APIs exactly the same way regardless of the targeted Windows platform. Also, using the Universal Windows app project templates, it is now possible to build applications using a single code base that runs on Windows Phone and Windows.
Another cool feature about the SDK is the dynamic nature of consuming the OData Services. Instead of having to add a service reference to the OData Service during design time to build the proxy classes as in the case of WCF applications, the developer can build applications that can dynamically consume any OData Service at runtime using the SMP SDK. Here is a screenshot of a sample application (about 200 lines of code including UI and error handling), that can dynamically consumes any OData Service using the SDK. In the next couple of weeks, I will try and post the code for the sample application in SCN. I have actually started the process of publishing the sample application on SCN. Unfortunately, it takes 3 ~ 4 weeks before it actually gets published. Notice that even complex properties are handled in the sample application during runtime.
Update: The code for the sample application and the How To Guide is now published. This sample application is not integrated with the SAP Mobile Platform Runtime SP04 and therefore can be run as a stand-alone application. Please download the code and let me know if you run into any issues.
Surprisingly, the footprint of the SDK is less than 250 Kb. The library itself is packaged as NuGet packages. The .nupkg files contain libraries for both Windows Store and Windows Desktop applications.
| Supported Environments and Devices |
|---|
Windows Store Applications
Windows Desktop Applications (any machine running .NET 4.5 or higher – 4.5.1 and 4.5.2)
|
The API set available for Windows Store applications was always Windows Runtime. The API set available for Windows Phone from version 7.0 to 8.0 was a modified Silverlight Runtime. Microsoft unified their tablet and phone platforms, thereby ensuring that Windows Phone 8.1 now supports the Windows Runtime and the modified Silverlight Runtime (for backwards compatibility) API set.
Microsoft Visual Studio 2013 + Update 2 is required for building universal applications that can target both the Windows and Windows Phone devices with a single code base – business logic can be shared between the devices. Note: We have also tried Microsoft Visual Studio + Update 3 to build applications and have found no issues.
| Development Environment |
|---|
Windows Store Applications
Windows Desktop Applications (any machine running .NET 4.5 or higher)
|
Onboarding a device
As part of the administration capabilities offered by the SAP Mobile Platform, a new device needs to be registered with the SAP Mobile Platform before it can perform any of the CRUD operations against the backend. This process (hereinafter referred to as “onboarding”) is quite helpful for administration purposes. There is now a log of the device history and this is quite helpful in troubleshooting purposes. Also, when it comes to server initiated push notifications, we can target the specific device for any notification.
The process of onboarding a device is fairly straightforward with the new SMP SDK. Microsoft has simplified the process of making asynchronous calls using the keywords await / async. The compiler does all the heavy lifting and the end result is code that closely resembles synchronous code. Upon successful onboarding, an application connection id is created and sent down to the device along with the server response. This application connection id uniquely identifies the device and must be passed in the header during all further communication with the SMP Server.
To onboard a device, the developer needs to call the following 3 asynchronous methods…
private async void button1_Click(object sender, EventArgs e)
{
// initialize the LogonCore
var logonCore = await SAP.Logon.Core.LogonCore.InitWithApplicationIdAsync("<appid>");
var logonContext = new SAP.Logon.Core.LogonContext
{
RegistrationContext = new SAP.Logon.Core.RegistrationContext
{
ApplicationId = "<appid>",
ServerHost = "<hostname>",
IsHttps = false,
ServerPort = 8080,
BackendUserName = "<username>",
BackendPassword = "<password>",
}
};
// registers the device
await logonCore.RegisterWithContextAsync(logonContext);
// persist locally
await logonCore.PersistRegistrationAsync(passcode, logonContext);
}
The first method initializes the logonCore variable. This method takes the “appid” (name of the application in SMP Server) as the parameter.
The second method submits an HTTP POST request from the device to the SMP Server (logonContext variable provides all the necessary information to connect to the SMP Server) with a payload identifying the device and requesting the SMP Server to register the device. Upon successful registration, the SMP Server sends an HTTP response with important registration values that are saved in the logonContext variable.
The third method saves the logonContext variable in the data vault securely using a passcode. The SMP Server administrator has the option of defining client policies that require passcodes on the device. This is optional, but highly recommended.
Once onboarding is complete, the next step is to perform any of the CRUD operations against the backend. In my next blog, I will talk about how to retrieve data from the backend and also how to make changes to the backend data.
2 Comments
| User | Count |
|---|---|
| 24 | |
| 13 | |
| 11 | |
| 11 | |
| 10 | |
| 10 | |
| 9 | |
| 9 | |
| 8 | |
| 6 |
