1 2 3 70 Previous Next

SAP for Mobile

1,039 Posts

SAP HANA Cloud Platform mobile services has been released today. It enables customers and developers to build, extend, and run mobile applications on SAP HANA in the cloud. This release marks a major milestone in the realization of SAP’s vision to simplify the delivery of enterprise mobility, lowering barriers to entry and dramatically reducing time-to-value.

 

HCPms.JPG

 

SAP HANA Cloud Platform mobile services inherits key features such as offline app support from SAP Mobile Platform 3.0, and makes them available as a service on the SAP HANA Cloud Platform – the in-memory Platform-as-a-Service (PaaS) offering from SAP.

 

Making developers more productive...

Developers will get more productive as they can now use the SAP Mobile Platform SDK with SAP HANA Cloud Platform mobile services to develop native and hybrid web (Apache Cordova) applications.

 

Flexibility for customers...

Customers can now choose between on-premise and cloud deployment of their mobile applications.

 

Overview.jpg


For more information...

 

Best regards,

Gerhard Henig

 

Head of Product Management - SAP Mobile Platform

This is my first blog in the SAP for Mobile area of SCN. As some of you might know, I am a product manager in SAP Gateway and currently focusing on Integration Gateway. If you don't know much about Integration Gateway and how it differs from SAP Gateway, you might want to read my blog There is a gateway for that ... that I wrote back in March. You can learn more about Integration Gateway in this blog where you will also find a webinar recording. Furthermore, if you really liked Integration Gateway and want to get your hands dirty with it, you don't want to miss my colleague Bjoern's blog on provisioning an OData service based on all supported datasources.

 

On September 11, 2014, SAP Mobile Platform 3.0 SP04 was released with many enhancements. As an integral part of SAP Mobile Platform 3.0, Integration Gateway also delivered some enhancements in support package 04. In this document, I will provide a short introduction to these enhancements.

 

Design-time (Eclipse plug-in)

  • Versioning support for SAP Mobile Platform 3.0 SP03 and SP04
  • Simplified user-experience (UX) particularly for SOAP and wizards in general
  • OData Designer enhancements, including support for cut&paste of entities between different models

 

Custom Extensions via Scripts

  • JavaScript and Groovy based scripting support
  • Both Request and Response mappings can be customized
  • All datasources (ODC, SOAP, JDBC and JPA) are supported
  • Some of the things that can be achieved via custom scripting
    • Delta Token & Tombstones
    • Mapping of multi-part WSDLs (that cannot be mapped via the user interface)
    • Various SOAP authentication mechanisms
    • Access to HTTP header variables

 

Gateway-cockpit Enhancements

  • A number of usability improvements; including better session timeout handling
  • Ability to test connections to the defined destination
  • Harmonization of the URLs between Gateway Cockpit and the provisioned OData services

 

OData Capabilities

  • Most system query operations (e.g. $orderby, $skip, $top, $select, etc.) are supported for all datasources.
  • Associations and Navigations are supported (with some restrictions).
  • More details are explained in SAP note 1931374.

 

I know that this level of detail is too little to satisfy your thirst. But rest assured, you will see more details, samples and tutorials in the coming days.

 

Best,

Mustafa.

Hello SAP Mobile Platform Community,

 

I am pleased to announce that SAP Education now has the following SAP Mobile Platform 3.0 courses available for the developer, as well as for the administrator. Learn the latest features and functions of the SAP Mobile Platform.

 

In MOB20: SAP Mobile Platform 3.0 (SP03) Development (3 day Instructor Led Training), developers will begin with an overview of the updated SAP Mobile Platform 3.0 SP03 architecture, an introduction to the server and available SDK installations, a deep dive into the new SAP Kapsel tooling, SAP Agentry and SAP mobiliser changes, data integration with SAP Integration Gateway, and then move onto the development of SAP Mobile Platform 3.0 apps on the latest support pack release. There will be extensive hands-on exercises performed during the course to help participants gain greater familiarity with the latest features of the SAP Mobile Platform.

 

In MOB10: SAP Mobile Platform 3.0 (SP03) Administration (2 days Instructor Led Training), platform administrators will learn how to plan, prepare, install (or upgrade) and administer the SAP Mobile Platform 3.0 SP03 solution. Aside from performing standard every-day administrative tasks, you will learn Wily Introscope, deployment scenarios for high availability and disaster recovery, single server to multiple server infrastructures, enhancement to security mechanisms embedded into the platform. Other topics include security configurations, authentication, securing listeners/ports with encryption, creation of physical users and groups in an underlying store (such as Active Directory), monitoring, logging and thoroughly explore the SMP concepts for Authentication and Authorization by configuring authentication and authorization. This course also covers SAP Mobiliser and how to leverage the SAP Mobiliser solution in the SAP Mobile Platform. The new features in SAP Mobile Platform 3.0 SP03 are reaffirmed via extensive hands-on exercises.

 

Please use the links below view descriptions of NEW SAP Education offerings for SAP Mobile Platform developers and administrators.

 

Developer role:

 


Follow the links below to view other courses and certifications in the SMP and SAP Agentry catalogs:


Administrator role:



Follow the link below to view other courses and certifications in the SMP Administration catalog:


Solution Architect and all other roles:


Please note that all SAP Mobility courses are immediately uploaded to the SAP Learning Hub. To subscribe to the SAP Learning Hub, please visit: Customer Edition or Partner Edition on the webshop.


Wishing you all great success in your SAP Mobility journey.


Best regards,

Vivaldo


With the release of SMP Server SP04 and SMP SDK SP05 announced a few weeks ago, it seemed like a good time to update you on the state of cross-platform mobile development at SAP. SAP Mobile Platform (SMP) developers have two options for building cross platform mobile applications: Agentry (metadata-driven applications) and hybrid web applications. Agentry applications will be covered by other posts like this blog for example highlighting what’s
New in Agentry for SMP 3.0 SP04
– in this article I’m going to cover hybrid application development using SMP.

 

Late last year we released the SMP SDK, and with it, the new hybrid SDK called Kapsel. Kapsel was a new type of hybrid SDK for SMP, implemented as a set of plugins for the open source Apache Cordova framework rather than using proprietary technology. I wrote about Kapsel here: An Introduction to SMP Kapsel and described the initial set of Kapsel plugins which were:

 

  • AppUpdate
  • AuthProxy
  • Encrypted Storage
  • Logon
  • Logger
  • Push
  • Settings

 

This initial set of plugins was only available for Android and iOS – that of course changed with the latest SDK update, more on that in a little while.

 

In June, we released the SMP Server plus an update to the SDK (SMP SDK SP04); the SDK update included some enhancements to the existing plugins plus added some new plugins. First let’s talk about the enhancements:

 

  • The AuthProxy plugin was enhanced to allow it to prompt users for their password when BasicAuth was enabled. Before this enhancement, an application could authenticate on behalf of the user, but hadno way to allow the user to enter the password directly.
  • Added support for Apache Cordova 3.5 as well as iOS 7.1.
  • Added a barcode scanner plugin to the SDK. It’s the existing PhoneGap Barcode scanner plugin, forked and enhanced just a little. This was added to support the SAP Fiori Client, I’ll explain why in a subsequent post.

 

By this time, SAP had released the SAP Fiori Client (you can read about it here: SAP Fiori Client) and customers had started requesting the ability to build a custom version of the application or to be able to deploy the application internally from an Enterprise App Store (rather than the public app stores). So, to accommodate these customers, we added the SAP Fiori Client capabilities to the Kapsel SDK as a set of new plugins customers could use to create their own version of the application. With the SMP SDK SP04 release, we added the following new plugins:

 

  • App Preferences
  • Cache Manager
  • Fiori Client
  • Online
  • Toolbar

 

It’s not really important now what these plugins do because they can only be used (today) in the SAP Fiori Client application. Our goal is to make these plugins a little more generic, so our customers can use them in other types of applications as well. I will update you once we have completed that work.

 

Just having the plugins wasn’t enough – we couldn’t expect customers to hand assemble a SAP Fiori Client from the plugins. So, included with the SDK is a Node application (the Cordova SDK relies heavily on NodeJS, so we felt comfortable using it for other things) that a developer can execute to create a custom instance of the SAP Fiori Client.

 

We knew that some customers might need to implement multiple versions of the SAP Fiori Client, separate ones for different divisions or for different business units within the company, so the script’s execution can be customized by passing in a file path pointing to a configuration file with custom settings.

 

With these tools at your disposal, you simply edit the configuration file then open a terminal window and execute the node application and a few minutes later (well, it takes more than a few minutes) you’ll have your own custom instance of the SAP Fiori Client. With this application, you can customize it to suite your needs, preconfigure the Fiori endpoint URL, add additional plugins and more. Since it’s your own application, you can easily make it more secure using SAP Mobile Secure or you can deploy it to users using MDM or MAM tools such as SAP Afaria.

 

I’ll write more about what’s happening with the SAP Fiori Client in my next post.

 

Kapsel leverages a few technologies (some from SAP and some from third parties), so for each release we have to make sure to update the SDK to support the latest versions of the following technologies:

 

  • Apache Cordova
  • SAP MAF/Logon capabilities
  • SAP UI5 (used by the Logon plugin to render its UI)
  • Google Android
  • Apple iOS

 

The Kapsel team also delivers some special support materials (described at the end of this post) beyond the standard documentation, so for each release we have to make sure that we update the Kapsel Getting Started Guide and, if needed, the Kapsel Kitchen Sink Application (this update is only needed if we add new plugins or if we change any of the Kapsel plugin APIs).

 

SMP SDK SP05

 

With SMP SDK SP05, released on September 12th we continue to enhance the Kapsel SDK. Let me show you the ways.

 

In this version, we added support for Apache Cordova 3.6; it was released late (them, not us), so this capability will come to Kapsel in a patch to SMP SDK SP04 available soon.

 

The biggest news for this release is that we’ve added Offline OData capabilities to the SMP SDK. For Kapsel developers, this capability is exposed through a Cordova OData plugin. As you have seen in some of the other posts regarding the latest release of SMP, this version implemented a server-side and client-side capabilities that allow an application to interact with an OData source while online or offline. This is a big improvement and will bring great value to our customers.

 

 

The way this works with Kapsel is a developer will add the OData plugin to a Cordova application then implement some code to let the plugin know what remote data sources to take offline. Behind the scenes, a lot of stuff happens to create the local offline store, pre-load it with data and make that data available to the application whether the device is online or offline. With that in place, the application reads and writes to the data source and synchronizes with the back-end data source as needed.

 

If an application requests some data, the plugin intercepts the request and looks to see if it has the data the application is looking for. If it does, it’s served up from the local data store (which is kept synchronized with the back-end by the application). If the data source is not available locally, the plugin redirects the application to the SMP server to get the data.  When offline, the plugin simply interacts with the data it has in the local store; any online datasources will not be available.

 

Other big news for this release is that we have added support for Microsoft Windows 8.1 to Kapsel. From the beginning, Kapsel has supported Android and iOS, but many customers have implemented Microsoft Windows tablets and Windows Phone devices and needed to be able to run their Hybrid applications on those devices. With this release, we’ve added support for the following plugins on Windows 8.1:

 

  • AuthProxy
  • Encrypted Storage
  • Logger
  • Logon
  • Push
  • Settings

 

Support for additional Kapsel plugins on Windows 8.1 will come in future releases.

 

It’s important to note that I’m only talking about Windows 8.1 here, not Windows Phone 8.1. In Windows development, Windows 8.1 applications use a different architecture than Windows Phone 8.1 applications. Because of this, when working with Apache Cordova, plugin developers have to implement different code for Windows Phone plugins. Microsoft, and correspondingly Apache Cordova, are migrating to a Universal Apps approach for Windows applications – allowing a single application (or plugin) to work for Windows 8.1 as Windows Phone 8.1. After the Cordova team has full support for Windows Universal apps, we will add support for Windows Phone 8.1 with Kapsel.

 

For your reference, Table 1 summarizes mobile operating system support for the Kapsel plugins.

 

Table 1 – Kapsel Plugin OS Support Summary

kapsel-plugin-matrix.png

 

More detailed information about our support for the Windows platform is available here.

 

There are some limitations affecting our ability to deliver a SAP Fiori Client for Microsoft Windows, I’ll cover this topic in my next post.

 

We also added some additional capabilities to the Kapsel SDK:

 

  • Logon plugin support for SAML
  • New logging API
  • End to End trace
  • Mobile Place integration

 

And of course, additional capabilities, additional plugins and more are planned for future releases.

 

At SAPPHIRE NOW, SAP announced a new web design and development tool for web applications called River RDE. River RDE is based on the open source Eclipse Orion project and allows developers to more easily design and code web applications using SAP UI5. River RDE is the tool SAP uses to create Fiori applications. It’s beautiful and pretty easy to use.

 

As River RDE is for designing web applications and hybrid applications are essentially cross-platform web applications running within a native application container, it makes sense that the two work together, right? Well, part of the team working on River RDE is the same team that created AppBuilder, and AppBuilder had some pretty cool integration with Kapsel, so we have the experience to do that. We have been working very closely with the River RDE, Fiori and UI5 teams to identify how River RDE and the Kapsel SDK can work together.

 

The first step is to give River RDE awareness of the Kapsel plugin APIs so that auto-complete and syntax checking works correctly for Kapsel applications. Next we know we want to give customers an easy way to take a web application from River RDE and deploy it through a Kapsel application. I’ll tell you more as soon as I have something I can share with you.

 

Kapsel Resources

 

There are a lot of great resources available to you to help you get up to speed on the cross-platform hybrid development capabilities of SMP. There are a lot of sessions on this topic scheduled for the 2014 TechEd&&d-code conference, you can read more about the scheduled sessions here.

 

Here are links to the SMP documentation:

 

 

The documentation is helpful when you need to understand how to accomplish specific tasks or get a detailed overview of a particular topic, but often developers need more. To accommodate this, the Kapsel development team and others within SAP have created a whole catalog of materials you can use to get up to speed.

 

The most thorough coverage of the topic is in the Kapsel Getting Started Guide which is available on SCN at http://scn.sap.com/docs/DOC-49592. Written by one of the Kapsel developers, this massive tome covers the whole Kapsel SDK start to finish. It’s not documentation for the Kapsel SDK; instead it’s a step by step guide for developers, written by a developer, for developers. The guide walks you through all of the server setup for the different features plus provides the code and instructions you need to use these capabilities in your applications.

 

For developers who want to learn more about the Kapsel APIs and see them work in a functioning application, we’ve created the Kapsel Kitchen Sink application. The Kapsel Kitchen Sink is a free web application available today from the SAP Store. When you run the application inside of a Cordova container (with the Kapsel plugins added), it shows you detailed information about each of the plugins and the plugin APIs and, when configured to connect to an SMP 3 server, provides functionality which allows you to quickly execute the different APIs and immediately see the results. Developers can use this application to test out each of the APIs to see exactly how they work before trying to use them in their own applications. I wrote the initial version of this application, so of course I think it’s pretty cool.

 

Another excellent source of information on the SAP Mobile Platform can be found in the SAP Mobile Academy: http://www.sapmobileacademy.com. The academy contains a suite of videos that introduce developers (and others) to the SAP Mobile Platform and some developer-specific topics. I expect the catalog of available videos to grow over time.

 

Lastly I hope you are all signed up for SAP TechEd && d-code, I will be there in person so would be happy to see you in my sessions. Here is a link to all the action we will have around SAP Mobility.

 

---

 

John M. Wargo is a software developer and the SAP Product Manager for the SMP Hybrid SDK (Kapsel) and the SAP Fiori Client. John has written many books on mobile development, including his most recent Apache Cordova 3 Programming and Apache Cordova API Cookbook books cover Apache Cordova development in great detail.

My colleague Scott Bonnel of Mocana recently shared a great analogy of the airport security process compared to the software security process. In recording a webinar with him this week, I’d like to share it and also invite you to watch the on-demand SAP Mobile App Protection session at your convenience.

 

Airport security used to be a painful process – especially flying out of the Toronto airport and crossing into the United States. I recall once after 9/11 it took me exactly 2 hours to get from the curb to my gate. The security line up was painfully slow, and a secondary security check was required before getting on to the plane at the gate. Today it’s much easier. I can go from curb to gate in about 10 minutes with TSA Pre and a Nexus card. My personal experience going through security has been simplified and I am a much happier traveler. 

 

The same is true when it comes to mobile security. If your users have to jump through hoops to get their app to open (or get to the gate) then they won’t be happy about it. Multiple logins, SSO, and VPN can complicate the process and make it too long when you simply want to access an app for 30 seconds. If you simplify the process and improve the experience then your users will be happy.

 

This most important similarity is that in both cases you haven’t compromised on security – you are still meeting your strict requirements – but you’re doing it in a way that keeps your stakeholders happy.

 

As I mentioned, Scott and I delivered a webinar this week on our joint solution, SAP Mobile App Protection by Mocana, part of the SAP Mobile Secure portfolio. The session provided best practices and new ideas and approaches for solving the security user experience challenge. The 45 minute session is a great summary of the product and also included discussion on three customer case studies. It highlighted some of the benefits customers are experiencing by better leveraging our mobile security solutions. 

I invite you to catch the session available on-demand. Enjoy the conversation and let me know if you have any questions.

As a proactive effort by SAP Global support to provide quick guides and assistance to our SAP Work Manager customers, I have added a quick guide or checklist in setting up the ESRI mapping tool built-in SAP Work Manager 6.1.X (in SAP Mobile Platform - SMP 3.0).

 

The goal of this quick checklist is to simplify the requirements in setting ESRI up for a WPF client and to easily find the solution via the SAP Community Network (SCN or the Online community via your favorite browser) instead of digging through multiple release notes and multiple SAP Work Manager manuals.

 

Most of these Quick Start Guides or Checklist reviewed multiple support tickets, QA tricks and request for help from the SAP Community Network (SCN discussions) to enhanced our documentation.

 

See Quick Guide: How to set ESRI Map when it is not rendering in SAP Work Manager 6.1.X WPF Client (Location tab empty) - KBA # 2071498.

 

# You may need to access your SAP account to properly view the KBA link above.

 

Users are expected to setup the SAP back-end add-on. Please set it up prior to following the Quick Guide above (please read any special mandatory patches as discussed below).

 

 

If you have any feedback, we could use it to further enhance our products or documentation. Rating each of the Quick Start Guide will help us understand if you need more of it.

 

Best Regards,

 

Mark Pe

 

SAP Senior Support Engineer (Mobility)

In my previous blog, I had talked about the onboarding process to uniquely identify a device with the SMP Server.  The next logical progression in this blog series is to write about how devices can retrieve data from the backend and also how devices can make changes to the backend data.  As part of this blog, I will try and post code for another sample application that illustrates how to retrieve data and make changes to backend using the SAP Mobile Platform SDK (hereinafter referred to as “SMP SDK” or “SDK”).

 

On a side note, I have submitted the sample application code for my previous blog to SAP Legal.  So, hopefully in the next couple of weeks the sample application code for the previous blog will be published.

 

 

CRUD operations

In order to retrieve data from the backend, an HTTP GET request is made along with the application connection id in the headers.

 

HTTP Request

URL: http://<hostname>:<port>/<appid>/<CollectionName>

Method: GET

Header: { X-SMP-APPCID : <app connection id> }



To accomplish this using the SMP SDK, the following steps need to be taken.  Creating an ODataStore instance and calling OpenAsync is only done once for a session.  From there on, it’s a matter of calling ScheduleReadEntitySet method any number of times.


GETFlow.PNG


The ODataStore library is used to interact with the SMP Server to submit HTTP requests to either GET data or perform CUD operations.  An ODataStore instance is required to interact with an OData Service.  The ODataStore hides a lot of complexities and makes interacting with OData source fairly easy for the developer.   To create an instance of the ODataStore, the developer can use either one of the 2 constructors.  The default value for the 2nd EntityFormat parameter is XML format. However, using JSON format considerably reduces the network traffic.

 

public ODataStore(string serviceUri, ODataStore.EntityFormat entityFormat = ODataStore.EntityFormat.XML);
public ODataStore(Uri serviceUri, ODataStore.EntityFormat entityFormat = ODataStore.EntityFormat.XML);
public enum EntityFormat
{
    JSON = 0,
    XML = 1,
}
// Sample code snippet for creating an ODataStore
var store = new ODataStore(uri);

 

 

Once an instance of ODataStore is created, the method OpenAsync is called.  This method retrieves the service document and the metadata document.   When making the OpenAsync call, it is also necessary to pass in the user credentials and the application connection id as header values.

 

var client = new SAP.Net.Http.HttpClient( new System.Net.Http.HttpClientHandler { Credentials = new NetworkCredential(“user", “password") }, true);
client.DefaultRequestHeaders.TryAddWithoutValidation("X-SMP-APPCID",appconnid);
await store.OpenAsync(client);

 

The ScheduleReadEntitySet method is used to schedule an HTTP GET request.  This method takes the collection name as a parameter.  The Response object is then called asynchronously to submit the request.

 

var execution = store.ScheduleReadEntitySet(collectionName);
var response = await execution.Response;

 

 

The response object is then cast as an ODataEntitySet and can be immediately bound to an UI control.  The ODataEntitySet is an IObservableCollection which allows the UI controls to automatically update themselves when the collection is changed.

 

var response = await execution.Response;
this.EntitySet = (SAP.Data.OData.Online.ODataEntitySet)((IODataResponseSingle)response).Payload;
// Bind this.EntitySet directly to UI controls

 

 

Making changes to the backend

The ScheduleCreateEntity method is used to create an entity in the backend.  This method takes an ODataEntity and the CollectionName as parameters.  An entity is created locally and passed in as parameter to the ScheduleCreateEntity method.

POSTFlow.PNG

 

var entity = new SAP.Data.OData.Online.ODataEntity(“TypeName");
entity.Properties["ID"].Value = XYZ;
entity.Properties["Name"].Value = “<XYZ>";
store.AllocateProperties(entity, SAP.Data.OData.Store.PropertyCreationMode.All);
var execution = store.ScheduleCreateEntity(entity, collectionName);
var response = await execution.Response;

 

 

Similarly, the ScheduleUpdateEntity is used to update an entity in the backend.  This method takes an ODataEntity as a parameter.  It is recommended to use the DeepCopy() method to make a real copy of an entity (not just a reference copy).  Make the necessary updates on the temporary ODataEntity. This way, even if the update operation fails (network disconnects, server error or whatever), the original entity is still intact and the app would not be in an inconsistent state.

 

var copiedEntity = entity.DeepCopy();        
copiedEntity.Properties[“Name"].Value = newName;
var execution = store.ScheduleUpdateEntity(copiedEntity);
var response = await execution.Response;

 

 

The ScheduleDeleteEntity method is used to delete an entity in the backend.


var execution = store.ScheduleDeleteEntity(entity);
var response = await execution.Response;

 

 

In conclusion, in this blog I have highlighted some of the important methods involved in performing CRUD operations against an OData Source using the SAP Mobile Platform.  This current version of SMP SDK only supports online functionality for Windows.  However, future releases of the SMP SDK will support additional functionality.  In upcoming blogs, I will talk more about the newer functionality and also provide more code samples to help build Windows applications using the new SAP Mobile Platform SDK.  Also, if you have questions building Windows applications, please feel free to reach out to me.

The SAP Mobile Secure team is pleased to share the news that the SAP Mobile Secure portfolio has been positioned by the analyst firm Ovum as a market leader in the 2014 Ovum Decision Matrix for Enterprise Mobility Management. A media alert went out on September 24th sharing the details of this report and the SAP ranking.

 

According to Ovum, “the market leader category represents the leading solutions that we believe are worthy of a place on most technology selection shortlists. The vendor has established a commanding market position with a product that is widely accepted as best-of-breed.” We are pleased that SAP Mobile Secure has been evaluated and identified as a leader. Ovum states that SAP was ranked as a leader based on “market presence, mature, well rounded solutions and its large and diverse customer base and industry-specific solutions.”

 

The Mobile Secure team has worked very hard over the last year to expand our EMM offering by innovating in the cloud; adding new mobile application management technology and advancing our mobile app security technology. Under the direction of Rick Costanzo, executive vice president and general manager of Global Mobility Solutions, we have experienced great investment in themobile secure space.


Rick was quoted in the press release as saying “SAP Mobile Secure provides our customers with the best enterprise-grade security solution for managing applications, content and mobile devices. With numerous customer deployments of more than 100,000 devices, SAP Mobile Secure elegantly scales to address the needs of organizations just getting started on their mobile journey as well as those requiring the most sophisticated and granular application and device level controls.”


If you're not already familiar with our offering, SAP Mobile Secure offers an integrated, cloud-based EMM portfolio with superior user experiences. You can learn more about our products at sap.com/mobile/EMM or read this whitepaper that hilights some of our key technologies.


Additionally, you can join us as we invite another analyst firm, Forrester Research, to speak with us in a related webinar on September 30th. This topic of this session is "Beyond MDM: It's time to reevaluate your approach to mobile security".


As always, a 30-day trial and further information on SAP Mobile Secure can be found here: www.sapmobilesecure.com

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.

 

GenericPlayer.png

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.


nupkg.png



 

Supported Environments and Devices

Windows Store Applications

  • Supported – Windows 8.1 (WinRT APIs) (eg. Surface Pro 3, any PC with Windows 8.1 etc.)
  • Supported Windows Phone 8.1 (WinRT APIs) (eg. Lumia 1520, HTC One M8 etc.)
  • Not supported – Silverlight Runtime on Windows Phone 8.1
  • Not supported – Windows Phone (from version 7.0 to 8.0)

 

Windows Desktop Applications (any machine running .NET 4.5 or higher – 4.5.1 and 4.5.2)

  • Windows 7, Windows 8, Windows 8.1, Windows Server 2008 R2 and up.



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 8.1 x64 – Pro or above version (because Hyper-V is required)
  • Microsoft Visual Studio 2013 + Update 2

 

Windows Desktop Applications (any machine running .NET 4.5 or higher)

  • Microsoft Visual Studio 2013 + Update 2

 

 

 

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.

We've all heard a lot about SAP UI5 by now. It's being touted as the UI of choice by SAP, with plans to move towards using it in every facet of SAP, originally starting with HR & Finance transactions, and now in Fiori and HR Renewal. This was, and still is, exciting news when you think about the UI that we have had to tolerate in standard SAP. Most users will tell you that navigating SAP is never an enjoyable experience. You eventually get used to it, but you never look at it and go "WOW. I'm SO glad I get to look at this everyday".

 

To be fair, a lot of the functionality in SAP is process and task driven, so you are given all your options, giving you the choice of which ones you want to perform your daily tasks. However, this means that users get too much information and too many options, which leads to confusion and frustration. Imagine their excitement when SAP announced Fiori, the new kid on the block that promises to soothe your battered senses while still letting you do your job.

 

There's no need for me to get into Fiori too much; there is a plethora of information on this as SAP prepares to love bomb us in the UI stakes. I've seen it, and it definitely looks really good, far and away the best UI I've ever seen in SAP. It's built on the SAP UI5 framework, which combines HTML5 and JavaScript to produce a UI that is finally up to the Web standards we have become so used to now.

 

Naturally there has been a lot of interest in Fiori, and therefore UI5 as the way forward in user interface of choice. Customers who have been starved for a decent user experience are now clamouring for this new kid, but are they really being informed as to what it involves? I had the opportunity late last year to implement a mobile web app based on UI5 and Gateway at a customer, which has given me some interesting insights into adopting this framework. The purpose of this blog is to explore my experience implementing this UI framework and the customer's reaction to it.

 

The requirement at the customer was to have a mobile web app that supports purchase order approval. As time wore on, the requirements evolved a little, but in the end I built an app that provided the following:

  • List of purchase orders awaiting approval at the user's release level
  • Details of purchase order when selected from list
  • Ability to approve selected purchase order
  • Ability to search for another purchase order when not in the list
  • Ability to emergency approve to all levels a purchase order not in the list when searched for

 

This may sound like a small list of requirements (I may have summarized it a little), but it was not entirely simple providing robust functionality that was similar enough to backend SAP, but also looked good. Below is a diagram of the architecture that was used from end to end:

 

MGC PO Approval App Architecture.PNG

 

The architecture was a bit more clunky that I would have liked, but it was the client's decision to use this design to facilitate their authentication and data integrity needs. In summary, the user would load the web app on their device (could be a phone, iPad or even desktop browser) and the call would be routed through the web dispatcher and the portal login screen (I modified this to handle the mobile screen) would show up. After authenticating in the portal, this provided them SSO into Gateway, which would serve up the data and communicate with the backend ECC system through SSO as well. In this scenario, the UI5 libraries and application was hosted in the Gateway system.

 

I won't go into the details of the web dispatcher setup, but here are the technical steps I had to perform to achieve the outcome:

  • Build the Gateway service and implement the logic to retrieve data from ECC
  • Build the UI5 application and host it on Gateway
  • Modify the portal login screen to handle a mobile device (a different screen is used)
  • Create a small HTML resource in portal KM that the web dispatcher URL routes to (and subsequently calls the portal login action)

 

Here are the key learnings I experienced while implementing this solution:

  • UI5 is very performance heavy, and in some cases took up to 40 seconds to load the very first time
  • Testing on a desktop browser produced different results than an actual phone browser (I used Chrome which is more tolerant) so I did a lot of testing and debugging on actual devices
  • Designs sometimes had to be simplified with only what is required on the screen due to size
  • Using ABAP tool in Eclipse to handle versioning after the UI5 application was loaded into Gateway as a BSP was quite a hassle so I did a lot of testing on my local machine before deploying
  • Supporting and implementing this solution required skills not usually found within the average ABAPer (HTML5, CSS, JavaScript, and Gateway)
  • Designing a solution from a technology perspective does not always result in the best user experience

 

The key thing that I learnt about UI5 is that is very slow to load. We tried to improve performance in numerous ways, but in the end it came down to how the framework rendered the elements, due in no small part to how it spawns .js files at runtime. Most of the user base were in metropolitan areas, and still sometimes struggled to load the screen faster than 10 seconds.

 

Given the set architecture coupled with the tight time frame and rigid requirements we had a successful outcome, but there are plenty of other ways we could have skinned this cat. I'm very glad to see customer adoption of UI5, and I'm really hoping to see SAP improve it from a performance point of view so users can have an excellent user experience without compromising on certain parts of usability. I'm also hoping that customers will be able to go into this process with their eyes open, being informed of all the factors involved before jumping in headlong.

 

Below is a short demo of the app:

Last week the NIMBL team visited SAP for a Co-Innovation workshop where we are partnering with SAP to build a Fiori application that runs on the HANA Cloud.

 

Our use case is for a Transportation company that ships millions of dollars of goods each year.  One major issue for them (and most transportation companies) is the impact that weather has on transport.  If there is severe weather that will affect a shipment the Transportation Planners are forced to scramble at the last minute to try and reroute the delivery.  This results in lost revenue by: 1) having the company pay to find another carrier/day to deliver the goods OR 2) having an unhappy customer that is forced to receive a late delivery.

 

NIMBL came up with a solution that can help the Transportation Planners determine Risk potential for shipments well in advance.  Our idea is to have a Fiori Dashboard that pulls in upcoming deliveries from SAP and calls a Weather API that gives us the forecast for the delivery addresses.  The government has come up with KPI models that predict how weather can affect ground transportation.  Using the power of HANA, we will compile the data and show it to the user in an easy to consume format.

 

Before attending the workshop we spoke with one of our customers to gather requirements for the Fiori application.  When we arrived at SAP, we were met with a Design Thinking coach.  We were told that the first two days of the workshop we would be working with the coach and our customer to dig deeper into the needs of this application.

 

Here are the activities that really helped us design the application:

 

Creating a Persona:

The objective of this task is to define WHO will be using the application.  What is their objective? What do they need to do their job?

In our case this was the Transportation Planner.  Through this exercise we determined that this person is very busy and needs to be able to access the information quickly and easily.

 

This exercise changed our entire design.  Our original idea was to have the user enter search parameters based on Transport orders. The flaw in that is now the Transportation Planner has to type in search criteria before they can access the information that they need.  Now, our plan was to have a dashboard that shows information that the user can filter if needed.

 

Mapping the Process Flow:

This involves mapping out the entire solution using a process flow.  What are the steps and endpoints involved?  How will the user’s interaction effect the design?  What logic needs to be built-in?

 

We began by drawing out exactly how our flow was going to work.  From the Transportation Planner accessing the application to calling real-time weather API’s to check newly proposed delivery dates. This task really helped us determine the tasks that were involved in development. Additionally, it revealed flaws in our design that we could not see before.

 

Wireframing:

This task is creating the entire User Interface for the application using Tools that contain UI5 controls.  It allows the business to determine if there is anything missing (fields, logic). This is also a very useful tool for the developer.  Now, I can look at what I’ve created for the wireframe and develop based on those specific controls.

 

Overall, the experience was extremely eye opening, and the power of Design Thinking was realized for us during this conference.  We plan to incorporate this methodology on custom Fiori projects going forward.

 

Here is a screenshot of our final Dashboard Design:

Dashboards.PNG

As you may already have heard, we have just launched SAP Mobile Platform 3.0 SP4.  We are providing a series of blogs describing the latest features in this service pack.  Gerhard Henig has already posted a high level overview here. You can also check out other blogs already published including SAP Mobile SDK SP05 and SAP Mobile Platform Server 3.0 SP4.  Stay tuned to this channel for more details on the latest features in SMP 3.0 SP4.


In this blog, l (with help from Karl Stevens) will be going through the latest Agentry features released as part of the SAP Mobile Platform 3.0 SP4.

 

Multiple Agentry Applications per SMP Instance

 

We have enhanced Agentry with multi-application support.  This new functionality will enable a user to deploy multiple Agentry applications to the SMP3 server starting from SMP3 SP04.

 

agentry_multipleservers.png

 

Administrative

Using the Admin UI, our Agentry administrators will be able to:

  • Deploy multiple Agentry applications to the SMP3 server
  • View all applications including multiple Agentry applications.
  • Create both Development and Production applications.
  • Configure and change settings for each application without affecting any other application deployed to the server. 
  • View logs on an application basis
    • User will be able to view logs from one application without problems from a second application.
    • User will be able to easily determine which logs belong to which application.


Changes to the Admin UI

  • Changes made to each Agentry application will be persisted to its own configuration files.
  • Server settings are moved to the “Agentry Sever Settings” page
    • This is independent of any Agentry application.
    • No server-wide settings (e.g. settings that would come from data tables of the AgentryServer.ini) will appear in the applications settings page.

 

Server

  • Each Agentry application will have a separate space for its assets including configuration files, application
    files, script files, etc.
    • There will be a separate directory for each application in the Server configuration directory (Server\configuration), named as com.sap.mobile.platform.server.agentry.application.<appid>, where <appid> is the application ID as configured in the Admin UI.
  • Each Agentry application will function independently. There will be unique URL to access every application loaded by Agentry Server, for instance:
  • The server will load all deployed Agentry applications at startup.

 

Client

From the client's perspective, nothing will be changed. Your users will have the ability to connect and run any one of the applications loaded by an SMP3 server.


Your users will only need to use the application urlPath

  • Configured in Application settings
  • By default the urlPath will be equal to the application name.

 


Support for OData Back-end

We have heard a lot of requests to support an OData Back-end, so Agentry now supports accessing an OData back-end service for consuming data from SAP. 

 

agentry_odata.png


Features include:

  • Ability to setup and connect to multiple OData data sources via the Admin UI
  • Full CRUD support
  • Dynamic URL handling
    • Filtering capabilities for fetches and read steps
    • Key property for updates and deletes
  • Support for all OData HTTP verbs
    • GET, POST, PUT/MERGE and DELETE
  • Ability for OData and HTTP back-ends to co-exist
  • Connector Studio Object Wizard Integration

 


Support for CSI Authentication

We have also added support for CSI Authentication. The CSI tool enables users to debug authentication failures and validate your security configuration with applications outside of SAP. 


With enhancements to Agentry, third parties can develop a custom module for retrieving credentials that will be provided to the SMP server from the Agentry client.  The module will then provide the Agentry Client with the credentials in the form of an X509 client certificate, which will be returned in response to an X509/SSL client certificate challenge from the server.  The use of X.509 certificates in combination with a password qualifies as 2-factor authentication, although 2FA can take many other forms (security tokens, biometrics, etc.). 

 

Agentry E2E Tracing: Client Solution Design

 

With the addition of end-to-end tracing, our users can enable tracing from an Agentry client (iOS, Android, WPF)

 

  • Transmits (including background transmits) will be traced and sent to Solution Manager via the SMP server in a business transaction xml string (BTX)
  • An Admin will be able to use Solution Manager to analyze the BTX to determine where performance issues are occurring

 

 


The client UIs for Agentry have interfaces via the About dialog model controller that allow it to set log level and whether tracing should be active in the next connection. These will in turn communicate this information to the ClientAppManager, which will use the standard implementation to actually start and stop the traces.

  • Each Trace corresponds 1:1 with a connection from the client to the server (will have a unique Context ID for all its passports in E2E parlance).
  • Each Trace Request on the Trace corresponds 1:1 with a Transmit Message or Step on the client (will have a unique Transaction ID for its passport in E2E parlance).



Each SAP Passport (or just passport) is a piece of data encoded into a string that indicates that tracing is enabled and active, at which level is tracing being
done, the trace context id, the trace request transaction id, etc ... Each passport is sent to the server inside its corresponding Agentry message. This data will later be used in Solution Manager to assemble the entire trace log.

 

The user will be able to change the enabled-ness of tracing and the trace level from the About dialog in the client. Both settings are selected from a single UI
interface that provides four states: off, low, medium, and high (the last three imply tracing is ON).

 

Changes to these settings will take effect whenever the connected status of the client changes. So:

  • If user is disconnected/logged out from server: they can turn tracing on/off and change takes effect immediately.
  • User turns tracing on: We start tracing next time we connect to the server. When connection ends, tracing is stopped, a BTX generated and
    uploaded to the server.
  • User turns tracing off: No-op.
  • User is connected to server: they can turn tracing on/off and change level, but change won’t take effect until next connection.
  • A message will be displayed indicating this situation.



SDK Enhancements
With the latest version of Agentry, we have enhanced the UI capabilities to enable our application designers to have more control.

Slide out Menu
Application designers can now specify whether a client user sees a slide out menu or traditional tabs for navigation between screens in a screen set.


  iPad Slide-out Menu

agentry_ipadslideoutmenu.png

Android Slide-out Menuagentry_androidslideoutmenu.png


Tile Display Enhancements

 

Tile Display hyperlink

A client user clicks on a clearly identified part of the screen, a “tile”, to view more details related to the contents of the tile.  This is useful to create dashboard pages that include tiles with live information.


agentry_tiledisplay.jpg

 

Multi-screen Tile Display style enhancements
Styles can be defined for tiles separately from the overall application.  This gives the designer even more control than in previous versions.

 

 

 

Support for Apple iOS 8


We have tested the current Agentry features and Agentry-based applications on iOS 8.  The features are supported and should continue to work as expected.

 

 

 

Additional UI Enhancements

 

Even with the recent availability of iOS 8, I wanted to share some of the enhancements available for clients that will remain on iOS 7 for a bit longer.  The Agentry Client iOS application has adopted some of the iOS 7 concepts and made many UI changes to align itself with the look and feel of the new OS. These changes are described below.

 

Edge-to-edge controls

Agentry has included an option to draw controls edge-to-edge to match the iOS 7 look and feel or keep the iOS 6 built-in margins.

 

 

  Built-in margins with rounded corners
agentry_ios7roundedcorners.png

  iOS 7 edge-to-edge
agentry_ios7edgetoedge.png



Application Tab Styles (The Bars)

One of the most noticeable changes introduced with iOS 7 is the change to the application's Navigation Bar. This is the new default navigation bar for  Agentry:


agentry_ios7navbar.png

Application Button Style (The Tint Color)

We added support for the “Tint Color” concept using the Application Button Style. Here are some examples of the same Agentry Detail Screen using different tint coagentry_ios7lookandfeel1.pnglors compared to the iOS 6 look and feel where bar buttons were not customizable.



  iOS 6 look and feel
agentry_ios6lookandfeel.png

iOS 7 look and feel
agentry_ios7lookandfeel1.png

 

 

 

Bar Buttons

We have made the Screen Buttons customizable. Now, just by using PNG images, your application can have the look and feel of other iOS apps out of the box.

 

 

 

 

For more information on the latest features in Agentry and Agentry-based apps, check out the following sessions at d-code:

 

 

View the TechEd DCode mobile sessions overview blog for information on all DCode session relating to the SAP Mobile Platform.

 


Follow us in any of the social media channels

 

 

Customary disclaimer
This blog references  SAP‘s strategy and possible future developments are subject to change and may be changed by SAP at any time for any reason without notice

When was the last time you opened up your iPad to do some serious work?  By serious work, I don’t mean sending and receiving email or even creating a word document.  I am talking about the kind of work that you would normally do at the office.  Like for example, I can recall many instances where my boss wants a certain file from the corporate network and check on the status of a customer ticket and see if I can reproduce the issue.  My response is always, “I will look into it as soon as I get to my laptop”.  I am sure most of you have seen the ad for a trading company on TV about a young boy asking his dad, “Why not”.  For international audiences that might not have seen the ad, it’s a young boy asking his dad, “Why not” to question why things are done a certain way that defies logic.  You can easily see where I am going with this.  The young boy in all naivety can easily ask me the same question, “Why not now”.  That’s precisely where the future of enterprise mobility lies. 


I will be writing 3 blogs as part of a blog series that got started on September 15th with the announcement of the availability of the SAP Mobile Platform 3.0 SP04 (hereinafter referred to as “SMP Server”) and SAP Mobile Platform 3.0 SP05 SDK (hereinafter referred to as “SMP SDK” or “SDK”) Link to overview announcement blog.  You will also find an overview blog for the SMP Server and the SMP SDK covering the various features available in these 2 releases.  In this blog, I will focus on the reasons behind supporting Windows in this release. In the next 2 blogs (Part 1 and Part2), I will focus on building applications on Windows 8 / Windows Phone using the new SMP SDK.  In addition to building applications on Windows 8 / Windows Phone, you can also build applications on any machine running .NET 4.5.

 

 

Enterprise applications in today’s world

In a study entitled Citrix Mobility Report : A look Ahead, Citrix found that enterprise mobile applications account for only 6% while Windows applications running on traditional desktops and laptops account for nearly 65% of the enterprise applications in 2013.

 

Citrix.png

 

In another IDC survey, the overwhelming expectation from organizations building mobile enterprise applications is to improve worker productivity (productivity being defined as having the right information in the proper context and more importantly providing the ability to act based on it).

 

idc.png

 

It would be more prudent to exploit the natural synergies between the facts that most of the enterprise applications in today’s world run on the traditional Windows laptop world and the expectation from enterprises to make their workforce more productive by building mobile enterprise applications.

 

 

Windows 8.1 and Surface Pro 3

With Windows 8.1 Update 2, Microsoft has made tremendous enhancements in making the new operating system a robust enterprise platform of the future.  Furthermore with Surface Pro 3, Microsoft has blurred the lines between the traditional laptop and a tablet.   The cost benefit of having a single device (for example, instead of having a laptop and an iPad) is phenomenal.  Companies such as BMW Group, The Coca-Cola Company and Louis Vuitton Moet Hennessy have committed to deploying Surface Pro 3 as one of the choices for their enterprises.  The demarcation between mobile space and office space has virtually disappeared with the new Surface Pro 3.  I can no longer tell my manager that I need time to get to my laptop.  My Surface Pro 3 is my new traditional (oxymoron usage intentional) laptop.

 

 

SAP and Windows

Recently, Microsoft and SAP announced a partnership program that allows SAP solutions to run on Microsoft Azure.  In addition, in the latest service pack of SAP Mobile Platform, SAP has added support for Windows mobile devices, tablets, laptops and workstations.

 

In my next few blogs (I will try to include some code samples as well), I will talk about the features that have been added in SMP SDK to support Windows. The synergy in supporting Windows using OData Services in palpable.  As we all know, OData is a data access protocol initially defined by Microsoft, but now (OData version 4.0) being standardized at OASIS. The really nice thing about SMP SDK is that it not only supports the Windows Store applications but it also supports any Windows machine running .NET 4.5 or higher.  So in essence, you could build an application using the SDK for both the new Windows 8.1 operating system and also for older legacy Windows machines running .NET 4.5 or higher.  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.  These are exciting times in the mobility arena and I am quite optimistic about the future of SMP Windows SDK.

 

 

In conclusion – why not now?

Enterprise mobility is not just creating a few dedicated mobile applications.  Enterprise mobility is extending a mobile device with all the functionality currently available on a traditional laptop.  Enterprise mobility must blur the lines between things you can accomplish at the office with a traditional laptop and things you can accomplish remotely with a mobile device and extend it to improve user productivity.

 

Enterprise mobility must answer the question, “Why not now”.  I believe we are now closer than ever before to make it happen.

With the rapid advancement of security technologies over the past two years, I’ve been thinking a lot about how often companies should reevaluate their past decisions on how to manage their mobile deployments. Without the proper security measures in place to lock down your corporate data, companies risk data leakage, malware infections, and data loss. Successful mobility deployments require a firm – and ongoing – understanding of the security risks they are facing and the solutions that are available to combat them.


Historically, mobile device management (MDM) has offered the best solution. It’s still a great solution for many use cases, but in this fast changing mobile world with broad mobile adoption and new ownership models, new technologies are emerging and MDM may not always be enough. Leading IT departments are now armed with valuable tools to apply more granular policies that secure apps and the content residing on managed and unmanaged mobile devices. This ultimately enables organizations to provide superior – and secure – mobile experiences to employees, business partners, and customers.

I’m excited to be moderating a webinar on exactly this topic and I'm planning on this being a lively discussion with Forrester’s senior mobile security analyst Tyler Shields, SAP’s head of mobile security Senthil Krishnapillai and our customer Sun Products’ IT operations manager John Major.

I’ve worked closely with these experts to tackle a few very important topics. We’ll look specifically at what has changed in the past two years and why now is the time to reconsider your current strategy. We’ll discuss some of the emerging technologies and discuss how to make the best decision for a secure future.

I hope you can join me on Tuesday September 30, 2014 at 2:00pm ET/ 11:00am PT. You can 
REGISTER! Here.

As my colleague Gerhard has mentioned we have released the new Service Pack 4 for our SAP Mobile Platform 3.

The new capabilities can split in three categories Design, Develop and Run.

For the Design Phase we have enhanced and simplified the Admin UI of the SMP. Now our customers have easy access to usage reporting to help them to plan and design the next version of their mobile solutions. Administrators can now easily access reports about the deployed mobile solutions.

thumbnail.png

For the Development Side we have added a hand full of features which are described in the blog "SAP Mobile SDK SP 5- Whats new?" of my colleague Kiran in detail. The key feature here is clearly the OData Offline Service, which enables our customers to build heavy Offline Apps, based on the new harmonized OData API. the Sap Mobile SDKs are now also supporting Windows 8.1 and Windows Phone 8.1 additionally to the Android and IOs platforms.

thumbnail-2.png

Furthermore we have added the support for additional authentication methods to our SDKs to enable customers to develop mobile solutions with the desired security level.

On the Run side we have enhanced the enablement to deploy and run applications fast and reliable through SAP Solution Manager integration. This brings CTS+, end2end tracing, workload analysis to the hands of the Administrator. Additionally we enable with the SAP SMP 3 SP4 release our customers now, to scale to millions of users and run mobile solutions in highly available scenarios.
 Moreover we have added the integration to mobile place which enables our customers to get their users faster up and running.

thumbnail-3.png

You can touch those new features and get the insides from the experts at TechEd for more details check here. More details on the features inside the server will follow over the next weeks so stay tuned in.

For more information on how to get started on developing on SAP SMP3 check the Developer Center.

Sami

Actions

Filter Blog

By author:
By date:
By tag: