1 2 3 78 Previous Next

SAP for Mobile

1,157 Posts

The 64-bit Agentry Toolkit is available for download, but the 32-bit version is no longer supported. Agentry Toolkit provides the components used by developers, implementers, and administrators to create Agentry applications.

 

On SAP Help Portal, older versions of the topic "Installing the Eclipse IDE and Agentry Editor Plug-In" include embedded URLs for both the 32-bit and 64-bit versions of  the Agentry Toolkit. Since the 32-bit version is no longer available, the link results in an error. Also, 32-bit information appears in the topic "Setting Up the Development Environment for Agentry Toolkit." The links will be corrected in future documentation versions.

 

See:  SAP Note 2148550 (https://css.wdf.sap.corp/sap/support/notes/2148550)

The Hybrid SDK (Kapsel) is UI5 framework agnostic. You can use any third party framework with the Hybrid SDK (Kapsel) that is compatible with Cordova. This section discusses framework integration with the Hybrid SDK (Kapsel), and provides an overview of common UI libraries for standards-based Web development.


SAPUI5

If you have not already selected a framework for your UI development, selecting SAPUI5 allows you to efficiently leverage the Hybrid SDK's integration with SAPUI5. The Login plugin uses the UI5 framework. Another strength of UI5 is that you can write an application, for desktop and mobile, using a single code base.

SAPUI5, also known as SAP UI Development Toolkit for HTML5, is the SAP client-side HTML5 rendering library with a large set of RIA-like standard and extension controls based on JavaScript (JS), and a lightweight programming model. The rendering control library is Open AJAX-compliant and based on open source jQuery and can be used together with other client-side libraries.

For more information:

 

Some of the other popular open-source frameworks include:


jQuery Mobile

jQuery Mobile is an HTML5 based user interface system for mobile devices.


For more information:


Sencha Touch

Sencha Touch  is an HTML5 mobile application framework that encourages a model, view, and controller pattern.


For more information:

This guide describes how to use HttpConversationManager and HttpConvAuthFlows libraries for implementing request, response, and challenge filters when developing native iOS OData apps with the SAP Mobile Platform SDK version 3.0 SP07 and later.

 

The iOS HttpConversationManager is an iOS networking library that enables sending and receiving of HTTP requests and responses between an iOS app and server securely, and is built on top of NSURLSession and related classes, extending the high-level abstractions built into CocoaTouch to meet SAP OData framework and corporate standards for security, traceability, and logging. The HttpConversationManager operates with native CocoaTouch constructs (for example NSURL and NSMutableURLRequest); however, it also uses some specific classes, protocols, and properties that comply with the special requirements for which it was built.

 

 

Getting Started with Conversation Manager for iOS

 

 

Requirements

 

 

 

Installing the Libraries

 

If you do not use the CocoaPod master spec file to set up the project, you must manually add the libraries to your project: after installing the SAP Mobile Platform SDK for iOS and the libraries and resources are extracted, locate and add these libraries, which is usually enough to write your first Conversation Manager based app:

  • libHTTPConversation.a
  • libHTTPConvAuthFlows.a
  • libMobilePlace.a
  • libE2ETrace2.a
  • libSupportability.a
  • libPerformanceLib.a
  • (iOS) Foundation.framework
  • (iOS) UIKit.framework
  • (iOS) CoreGraphics.framework
  • (iOS) libsqlite3.dylib (required by libSupportability)
  • (iOS) Security.framework

Note: Beginning with SAP Mobile Platform SDK version SP08, a CocoaPod master spec file will be provided which automatically sets up the project dependencies.

 

 

Architecture

 

Exposed protocols:

 

RequestFilterProtocol - defines the delegate which is called before a request is triggered; this allows modification of the request (adding request header, set POST body, and so on) prior to execution.

 

ResponseFilterProtocol - defines the delegate which is called after a request is triggered; this allows modification of the NSURLResponse and the response data before it reaches the request executor.

 

ChallengeFilterProtocol - defines the interface for the ChallengeFilter delegate, which is called whenever authentication is required for request execution.

 

ManagerConfiguratorProtocol - defines the interface for holding a view controller reference which can be used by filters to display views with additional information on top of it.Filters are basically providers that communicate with conversation manager values such as user credentials; there are various typesof filters: authentication challenge filters, configuration filters, and response filters.

 

RedirectWhitelistProtocol - defines the interface for a class that handles redirects; it is called whenever a redirect to a new URL is going to occur.

 

 

Public interfaces:

 

HttpConversationManager - request execution manager class, supports request, response, and challenge filtering.


HttpConversationObserverProtocol - defines the HttpConversationObserver interface. Observers are notified when a specific event occurs.


SupportabilityUploader - SupportabilityUploader implementation, used by E2ETrace and ClientLog uploading.

 

 

Categories:

 

NSURLResponse+HttpConversation - extension that adds batch response handling support.


NSMutableURLRequest+HttpConversation - extension that adds batch request handling support.

 

 

 

Conversation Manager API Usage for iOS

 


After adding the required dependencies to your project, add the #import “HttpConversationManager.h" statement to your source file. Instantiate the conversation manager with:

HttpConversationManager* manager = [HttpConversationManager new];

 

The Conversation Manager exposes a single block-based API to execute network requests. The API expects an NSMutableURLRequest as input, and returns response data, an URL response, and an NSError in its completion block, which is non-nil after successful execution.

 

samplecode:
-(void) executeRequest:(NSMutableURLRequest*)urlRequest completionHandler:(void
(^)(NSData* data, NSURLResponse* response, NSError* error))completionHandler;

 

NSURL* url = [NSURL URLWithString:@“<your URL goes here>"];

  

//initialize a request object

NSMutableURLRequest* request = [NSMutableURLRequest requestWithURL:url];

 

//execute conversation

[conversationManager executeRequest:req completionHandler:^(NSData *data, NSURLResponse *response,
NSError *error) {

    NSLog(@"Finished");

    if(error != nil)

     {

        NSLog(@"Error: %@", [error localizedDescription]);

                // perform meaningful error handling

     }

     else

     {

                // data received

     }

}];

 

The conversation manager instance usually cannot be used immediately to execute requests; it must first be configured to handle common authentication flows such as basic authentication.

 

 

Responding to Authentication Challenges

 

Challenge filters - assign authentication challenge filters to a manager instance to respond to authentication challenges. Use the addChallengeFilter: API to assign one or more challenge filters to a given manager instance.

Challenge Filter classes must adhere to the ChallengeFilterProtocol, which declares a delegate method that is called whenever an authentication challenge occurs during request execution.


samplecode:

-(void)handleChallenge:(NSURLAuthenticationChallenge*)challenge

conversationManager:(HttpConversationManager*)conversationManager
completionBlock:

 

(void (^)(BOOL useCredential, NSURLCredential* credential))completionBlock;

 

The delegate method should supply valid credentials in its completion block and set useCredential to YES (if set to NO or the credential is nil, it is interpreted as if no credential is provided.)

 

 

HTTPConvAuthFlows - the HttpConvAuthFlows library provides a set of authentication providers that can be used as an alternative to implementing challenge filters.

A CommonAuthenticationConfigurator instance must first be created, followed by setting the required providers and implementing specific delegates. In this example the manager instance is set up to retrieve user credentials from the implementing class.


samplecode:

// get an instance from the network standards based configurator

   CommonAuthenticationConfigurator* commonConfig = [CommonAuthenticationConfigurator new];


//add Username Password provider with our implementation

  [commonConfig addUsernamePasswordProvider:self];

 

//configure manager with standard set of plugins but with our own implementation of some providers

    [commonConfig configureManager:manager];

 


You must also implement the corresponding UsernamePasswordProviderProtocol delegate - provideUsernamePasswordForAuthChallenge:completionBlock.


samplecode:

#import “UsernamePasswordProviderProtocol.h"

@interface ViewController () <UsernamePasswordProviderProtocol,
SAML2ConfigProviderProtocol, ClientCertObserverProtocol, ClientCertProviderProtocol>

 

@end

#
pragma mark - Providers

/**

* Username Password provider. Provider hard-coded username/password for this sample only

  * Also shows how to override default UsernamePasswordProvider.

*/

-(void)
provideUsernamePasswordForAuthChallenge:(NSURLAuthenticationChallenge*)authChallenge
completionBlock:(void (^)(NSURLCredential*, NSError*))completionBlock {

    NSURLCredential* credential = [NSURLCredential credentialWithUser:@"username"
    password:@"password" persistence:NSURLCredentialPersistenceForSession];

    completionBlock(credential, nil);

}

 

 

The HttpConvAuthFlows class provides default implementations for:

  • Authentication Challenge Providers - UsernamePasswordProvider default implementation of UsernamePasswordProviderProtocol displays a secure alert view to enter username and password.
  • Configuration Providers:
    • OAuth2RequestFilter RequestFilter which handles OAuth authentication flow
    • SAML2ResponseFilter ResponseFilter which handles SAML2 authentication flow

 

 

Unit Tests and API Documentation

 

 

The HttpConversationManager and HttpConvAuthFlows libraries include an extensive set of unit tests, usage, and best practices.

Go to the <sdkinstall dir>\NativeSDK\ODataFramework\iOS\docs directory of your SAP Mobile Platform SDK installation, open the HttpConvAuthFlows-APIDoc.zip or HttpConversation-APIDoc.zip file, then open the index.html file to view API documentation for these libraries.

 

 

Additional Resources

 

See http://scn.sap.com/community/developer-center/mobility-platform/blog/2014/11/14/request-response-challenge-filters-in-httpconversationmanager on the SAP Community Network Web site for additional information about HttpConversationManager request, response, and challenge filters.

Just take a moment to imagine the following typical scenario (1) in your mind.

 

"You are walking into a super market on a Game Night and trying to find a chlorine removal shampoo. You are in a hurry to leave and cannot find that one particular product that is most important for regular swimmers. Due to game night there is less crowd in the supermarket due to which they understaff. This makes it more time consuming to seek help. Even if you find a person to help (after wandering thru the isles from end to end searching for that one knowledgeable person) they might not be sure what you are looking for, as they are not working in that department regularly. This peaks the frustration to find that product and the chances of finding it become more difficult. Ultimately after 30 minutes searching you will find it and rush to self-checkout lanes to pay for the product and check out a.s.a.p."

 

The key words in the above scenario are

Scenario 1.png

On the other hand now lets just imagine the following scenario (2).

 

"You are in a hurry to go to your next meeting on a busy day. In that short gap between the meetings, you wanted to pick up a healthy snack from the vending machine. You know it is in the same floor and its direction, due the well placed directions on every floor of your office (Thanks to building facilities team). You quickly walk up to the vending machine, choose one of the payment option (options are Coins, 1/5/10 bills, credit card, debit card, Apple Pay, Google Wallet), quickly find and pick the snack you want, enter the corresponding combination key (row and column info as clearly directed by the machine display) on the key pad, automated delivery mechanism delivers the snack into the lower bin under a minute and leave with a happy smile to catch up to the next meeting on time."

 

The key words in the above scenario are

 

Scenario 2.png

 

If you closely observe, the activities are mostly similar between the above 2 scenarios. However, they both serve different types of consumers for the similar end goal. Lets take these 2 scenarios and compare the mobile app experience for the end users.

 

In my experience I have seen mobile applications that fall under both of these scenarios. Sometimes it is unavoidable to separate the functionality even though it complicates the mobile app navigation. In order to make them user-friendlier those result in successful and highly adapted mobile applications one must adhere to vending machine style architecture pattern where it applies and vice versa.


SCENARIO 1: Super Market Pattern


The following would be useful architectural guidelines if this were a complex mobile application. It should be simple to use even with the more complex functionality.

 

  1. SEARCH Capabilities: Provide good search capabilities to find the information that the user is looking for in any corner of the mobile app.
  2. QUICK Navigation: User must be able to quickly find the content or get to the menu selection with in the mobile app that would perform a single meaningful task and complete an action (like a transaction or a decision). Navigation must be in Frequently Used transactions to Occasionally Used order. One can easily mimic the mobile app navigation in a similar to 'Popular/Seasonal Product displays' pattern at a Super Market. A section for 'Frequently Used' transactions with navigation to subsequent functionalities all can be provided in a easy to find screens. A section for a quick suggestive follow up transactions based on the user's mobile app interaction history could be helpful too. Similarly a section for 'Newly Added Functionality or Menus or Screens’ could be useful to find in one place.
  3. Target Audience: Mobile app must target a particular group of users always. A Complex mobile app must try to combine related functionality into one place. Utmost care must be taken due to its complex functionality in selecting the features of the mobile app. It also must cover end-to-end functionality of a single well-defined function. For example in a Order to Cash process scenario, all the documents that are required to be processed by Order fulfillment department starting from Sales Order to Billing must be covered to its fullest extent in one mobile app.
  4. CONSISTENCY: "Most users are used to desktop applications" - it is a safe assumption when developing a complex mobile app. Significant amount of time is spent generally to decide if the complex mobile app should provide an in-app help or not? If one spends a good amount of time on the wireframes and design for the complex mobile app then in-app help can be reduced to a simple explanation of the screen purpose. In other words, the mobile app must clearly indicate the ability to (consistently across various screens) CLICK, EDIT, CLOSE, DRAG, SAVE, CANCEL or QUIT/ABORT. Also UI must be less complex in displaying its GUI controls.
  5. FEEDBACK: Support functionality for a mobile app must be simple to use to report to the help desk if all else fails in a day-to-day use. The mobile app must provide a way to self-attach a screen and popup an email form with pre-filled support help desk email id by selecting a GUI Control (like a 'BIG RED’ help button') which makes the user to raise an incident request as easily as a click of a button. This will not only improve the confidence level of the user to use the app on a daily basis but also will help IT to eliminate those bugs that only come to life during the runtime.
  6. USER CONTROL: The one other most common issue that I have observed is the session timeout, before the user can complete a particular task in the complex mobile applications. It is very important to provide the simple session recovery and data recovery options in a secure way when the user returns to the mobile app after a phone call or any other such interruptions.
  7. Dynamic Build process: On regular intervals the mobile app must be monitored for frequently used areas of functionality. In a complex mobile app, it is very important to manage the key functionality on a regular interval. The app must provide a modularized update capability. If for example the mobile app has building blocks A, B, C and D. The most frequently used areas belong to blocks A, B and D, the mobile app must be designed in such a way that C block can be removed after reviewing the usage of block C over a period of time. This could be useful for occasions when there is a high demand for a particular portion of the app. This could be helpful in case of seasonal behavior changes in user demands. Also make sure that primary focus of the app is kept intact in all form factors while navigating thru a complex mobile app.
  8. Deployment Methods: App must be made available to all the targeted audience with less complexity to install and update. It must also make it simple and non-intrusive for frequent updates. The updates to the app must run in the background (always) and unmanaged way. In all the situations the backup and restore of the app functionality should be maintained automatically. In other words, if the app update fails it must restore to its pre-update state without any interruption and interaction with the user.


SCENARIO 2: Vending Machine Pattern


In less complex mobile applications the above rules are important as well but in slightly a different way. These types of applications come under 'Self-managed' model (with a frequent updates to the content).

 

  1. TARGET Functionality: Vending machine like mobile applications must focus on its targeted functionality to serve a broader audience. In our example we see vending machines are installed with a single purpose like a snack based or a carbonated drink based or a hot beverage based solutions. Since these types of mobile applications are single focused functionality they must be well organized with a self-contained structure.
  2. Super Simple Navigation: Mobile app must provide simple navigation as in "Vending machine pattern". Navigation must provide options at a glance and user must be able to quickly complete the task in under a certain time limit (like a Segmented Control in iOS).
  3. Self-Contained: It is very critical that this mobile app run in a self-contained fashion. It must provide a highly secure local storage, provide offline and online support and guaranteed delivery mechanism.
  4. Accurate and Efficient: Since the mobile application is a self-contained app, it must be able to update the data and keep data integrity at the highest level possible at all times. In case of failures due to any runtime errors, it must contain an internal recovery process (by way of auto-conflict resolution, auto-backup and recovery, off-line synchronization, background process updates).
  5. Robust Security: The data is stored on a local device using a local persistent store. The security to protect data must be well planned and implemented. User must be able to provide login details after a long duration of absences to access the app (this function must be configurable at enterprise level/department/app/user). This app security must have remote enabled data wipe capabilities in the event the device is lost/stolen/damaged without losing the data.
  6. Bug Free: Self-contained application must be released after a very thorough testing. It must provide 99% up time. Well-documented test cases/test scenarios must be built at an early stage to be able to deliver such bug free mobile app.
  7. Time to Deliver: The mobile app delivery must be made simple and secure. This will encourage all the intended mobile users for an early adoption and regular usage.
  8. Well Advertised: Such mobile applications need to be announced at a very early stage of the application design to invite inputs from all the key targeted department/group users.

 

Finally, the above two approaches are most common categories of mobile applications. Depending on the scenario/Complexity of the mobile app it always helps to reduce the total cost of ownership by following the above said guidelines. This not only will result in achieving the highest rate of return on investment due to its higher adoption of mobile apps by the end users (it could be employee faced internal apps or partner/customer facing external apps). With combining the above guidelines with best Mobile Application Development Platforms like SAP Mobile Application Platform will help build mobile apps with less resources and a robust framework and tools. Next time when you are at your favorite super market think about your Enterprise mobile applications.

We are pleased to announce that SAP Mobile Platform 3.0 (SP07) was released for download on SAP Service Marketplace on 18th of April 2015.

We are delivering new capabilities in the following three big areas:

  • Developer Experience
  • Expansion of Fiori capabilities
  • Enhancements around readiness for production deployment1.png

The enhancements for “Developer Experience” are around the integration Services and an enhanced Push

API. For the Integration Services the performance and functionality was enhanced. This enables, for example, developers to do deep inserts to any level on the JDBC connector. With deep inserts the developer can now insert a parent with several children with a single call into the Database.

The second enhancements are around the Push API. Customers can now send push notifications to mobile applications they have purchased of the shelf. With the integration of the HCPms Push Hub customers can now maintain their push certificates in a central place and enabling them to send push notifications through the HCPms push hub. This way customer can avoid having to recompile of the shelf mobile applications to get their push certificates into the applications and enable push notifications. For Example if a customer buys a Fiori application, which is push enabled. The HCPms Push Hub would allow the customer to run the Fiori application inside the Fiori container against the SMP and still send Push notifications to the Fiori application. And this can be done without having to add the customer specific certificate to the Fiori container with the HCPms Push Hub.


2.png

We also continue with our enhancements around development and operation of mobile Fiori apps. With

the new Service Pack 07, Administrators are enabled to control certain mobile features remotely. In Fiori and Fiori style Applications, which run in the Apache Cordova container (with the Kapsel plugins), the Administrator can control with the feature restriction Policy which features are available during runtime. This enables the

Administrator to react to security threads during runtime of the Application.


In the area readiness for production deployment we expanded the support for Relay Server, which now supports all applications developed with the SAP SMP SDK. We also further enhanced the HttpAuthentication LoginModule to full support SMP to authenticate through proxy. This enables our customers now to operate the SMP in different network zones than the Authentication Service.

You can consult the SMP PAM on Service Marketplace for details (SMP3 PAM (access to the Service Market Place is needed)).

 

 

Want more information?

 

Sami


http://scn.sap.com/servlet/JiveServlet/downloadImage/38-121272-652241/blog+signature.png

For SAP Mobile Platform SDK version 3.0 SP07 apps to use Offline OData retrieved from an ASE (Adaptive Server Enterprise) database data source, set the  DYNAMIC_PREPARE=false connection property in the JDBC URL inside <Server>\config_master\connection_data\connection.properties. For example:

 

javax.persistence.jdbc.url=jdbc:sybase:Tds:{HOST}:{PORT}/{DBNAME}?APPLICATIONNAME={DBNAME}&CACHE_COLUMN_METADATA=true&HOMOGENEOUS_BATCH=false&DEFAULT_QUERY_TIMEOUT=0& DYNAMIC_PREPARE=false


Also see https://help.hana.ondemand.com/help/frameset.htm?73e8d4c514f14a399c25711dd43f6975.html

We all know mobility is the future of computing, and this includes SAP.  We also know the future of mobility is often led by Apple, and the Apple Watch wearable is a prime example.  But what about when we talk about both in the same use case?  Does it make sense? Is the form factor too small? Does it even look good? And most of all, is it even usable?

 

I think this brings up a lot of good points.  Recently in our design shop, we had the opportunity to utilize the xCode object model and see how SAP Work Manager screens would play out on a wearable, specifically the Apple Watch.

 

What we found was very encouraging.

 

Using the container approach, we can adjust the content to the context and form factor.  We had to play around with the libraries a bit to ensure the app would neatly fit, but after some tweaking it actually looked pretty good.

 

 

http://excelliscorp.com/wp-content/uploads/2015/04/Apple_Watch_InUse_notification.jpg

 

We used the use case of a Service Technician in the field.  A good idea of the use case we were trying to hit is written up pretty cleanly by Todd Coleman here.  From a Service Technician's view point, they can see the status of a work order or service notification, they can update the status, and can also be informed on specific pieces of information related to the ticket and the product in question.

 

The apple watch makes the user be a consumer more than a contributor.  So if your design is one of maxing out information giving, and doesn’t depend too much on information taking, it works out well.

 

Here’s some of the concepts we put to use in our POC lab, using our own Gateway, ECC, and SMP systems, and our own in-house Apple Watch.  We started by building the project in the SAP WebIDE, using HCPms - this allowed us to create the stub code for a typical xCode project.  We can then use the SMP deployment model to run it on the cloud.  From a design perspective though, the key is understanding the xCode model inside and out, and then design for the form factor, don’t just relay on the standard resizing within the templates… Once you do that, it fits in very nicely.  Again - it all starts with the design, so even apps like SYCLO or stringent SAP Mobile apps can be modernized to fit wearables with the right design approach.

Hi All,

Recently I have spent some time in configuring the SMP and Mobile BI.  Thought of Sharing my experience with you all.

 

 

Pre-requisites for configure the Mobile BI client with SMP.

1. Working environment of SMP (2.2 or above)

2. Configured Mobile BI server

3. Installed Mobile BI client on iPAD

 

I have followed the latest document "BI Mobile 6.1.1 iOS Admin Guide" which is available on the SAP market place. This very detail document which talks in detail on the SMP integration.

 

There are some minor changes/correction that need to be consider when you are on SMP 2.3,

 

1. Application creation

2. Application endpoint URL

 

1. Application creation -

During application creation on SCC "BI Mobile 6.1.1 iOS Admin Guide" ask you to create and configure the application as per the following screenshot -

 

 

applicaton creation.PNG

 

But when you are running with SMP 2.3 you will find some additional fields when you navigate to the application creation page from SCC

To navigate - Goto SCC - > login with admin credentials - >select the application -> click new. Page will ask you to provide,

 

1.Client SDK type

2. Application endpoint URL & Push endpoint.

 

This fields is not cover in the "BI Mobile 6.1.1 iOS Admin Guide" document.

Client SDK type select - "Rest API"

Application endpoint URL - mention the application endpoint URL provided by BO admin.

 

Please refer the sample screenshot -

 

applicaton creation - 2.PNG

 

2. Application endpoint URL -  As per the "BI Mobile 6.1.1 iOS Admin Guide" the endpoint URL will be in following format -


http://<Mobile BI Server>/MobileBIService/MessageHandlerServlet

 

But, if we configure the URL as above we are end-up getting below error message  on iPad as well as on browser -

applicaton creation - 3.PNG

 

I have raised a OSS with SAP support. SAP expert ask me to configure the endpoint URL  as

http://<Mobile BI Server>/MobileBIService

 

After making this changes I am able to run the report on my Mobile BI client. SAP has confirm this as a typing mistake from the document writing team in the existing BI Mobile 6.1.1 iOS Admin Guide and planning to correct in next subsequent release of the document.

 

 

Kind Regards,

Amey

The SAP Mobile Secure team is pleased to announce that our support for Google’s Android for Work is now available. SAP has been partnering with Google as we share a common vision to bring Android support to enterprise users. With this program, we’re helping to ensure that our customers around the world have the freedom to choose their own devices for work and that businesses can securely support the devices employees want.

 

A few weeks ago, SAP announced that the companies are working together on the Android for Work program, which is supported by Google and brings together device makers, application developers and management solutions, to provide a secure, flexible, economical and consistent mobility platform (see Google’s AFW landing page.)

 

If you’re not familiar with Android for Work, it allows you to create a managed work profile on a device so that sensitive work data can be separated and secured from personal applications. With our support in SAP Mobile Secure, we now offer a single pane of glass for IT to manage all mobile devices. The employee’s apps, data, and settings aren’t touched by the enterprise admin at all – this is true separation of personal and corporate data.

 

SAP Mobile Secure is an integrated, cloud-based enterprise mobility management portfolio that helps you manage your company’s mobile devices, apps and content. You can try out SAP Mobile Secure and start managing Android for Work devices today at sapmobilesecure.com.


Watch this overview presentation summarizing Android for Work, and introducing features in SAP Mobile Secure 2.7.


 

SAP Mobile Secure customers running Android for Work will be able to leverage the following:

 

  • Full administration
    • Managed Profile – secure and manage the work space on the employee’s Android of choice including remote wipe and lock
    • Email, calendar, contacts and tasks - user simply opens and user work email
    • Mobile apps – full control to deploy, update and remove managed apps in the managed profile
  • Remote commands - Administrator can lock & wipe all enterprise content without affecting personal content or settings
  • Profile settings - Control over passcode quality, copy/paste, screen capture, display timeout to enforce compliance
  • Chrome settings - Manage proxy, url white/black list, cookies, bookmarks for secure browsing
  • Wi-Fi settings - WPA2/WPA enterprise and certificates to manage access to secure resources
  • Certificates - Silent installation of user and root certificates for security
  • User management – Administrator sets up Single Sign On to make user management simple, secure and easy for mobile users
  • PIM app suite – Deploy and manage email, calendar, contacts and tasks apps
  • Exchange settings – Create and assign email policies to automatically configure email for mobile users
  • Email security – Manage SSL and user certificates

 

When you are ready to get started either with your live version or with a 30-day trial, you can watch the video below, which provides detailed instructions on how to set up your Android for Work environment to manage Google Android devices within SAP Mobile Secure. Whether you are starting from a trial or a production version of SAP Mobile Secure, you’ll be able to follow these steps to set up your Google account, start an Android for Work Project and set up Android for Work Technical Settings. Watch the video.

 

Its important to note that when you’re looking at deploying mobile apps to Android devices, SAP offers much more that just a management solution – we can also help you successfully manage apps. Our leading SAP apps will be ready for installation within Android for Work and those apps can be distributed via SAP Mobile Place, a brandable, localizable and secure enterprise app store. We also support the Android operating system with the latest versions of SAP HANA Cloud Platform and its platform-as-a-service offerings including SAP HANA Cloud Platform mobile services, SAP Mobile Platform, and several hundred Android-based mobile apps.


If you're planning to be at SapphireNOW in Orlando please email me to join our Android for Work roundtable session with experts Senthil Krishnapillai and Matt Carrier.


Get started with a trial today - including the Android for Work features - at sapmobilesecure.com.

Andy Gonzalez

Agentry + Apple Watch

Posted by Andy Gonzalez Apr 8, 2015

This is a little Proof of Concept project to demonstrate how easy it is to add a WatchKit extension to an OpenUI Agentry application. It shows how events and Agentry data can be shared with the WatchKit application to be displayed in the new device. Showing that business data is not "locked" inside the Agentry application and can be shared with users in many different ways.

The full source code for the project can be found here in SAP GitHub.

This is a GIF animation of the two applications working together:

Agentry+AppleWatch.gif

For a higher resolution video, please contact me or access it in this JAM page. Enjoy!

 

Steps to create the App

Development starts with Xcode 6.2 and the OpenUI framework iOS Demo project.

The project was setup to add a WatchKit App and a WatchKit Extension following the instructions provided by Apple here.

Sharing data between the iOS App and the WatchKit App is achieved by setting up "App Groups". The instructions for doing so are described in this Apple article.

* Note: To test this, membership in an Apple Developer program is required because it will need to update the app entitlements and provisioning profiles.

Real time communication between the Watch App and the iOS App is achieved using the Darwin Notification Center and some new WatchKit APIs referenced in the documents mentioned above.

* Tip: There is an open source project available in GitHub here (MIT License) that encapsulates this paradigm rather elegantly. In this solution I manually implemented that because I wanted to see how it worked behind the scenes.


Communication from iPhone to Apple Watch

The sending happens in the MyCollectionDisplayAdapter.m file. See the updateSharedDataAndNotifyWatchKitExtension method. First, Agentry's object data is serialized into a helper object and stored in the App Group:

NSUserDefaults *sharedData = [[NSUserDefaults alloc]

    initWithSuiteName:@"group.com.syclo.agentry.SMPAgentryClientFrameworkDemo.shareddefaults"];


NSMutableArray* players = [NSMutableArray array];

for (int i = 0; i < self.model.displayedObjectCount; i++) {

 

  // Use DataAPI to get the value of the object's child properties

  id<SMPDataAPIProtocol> agentryPalyer = [self.model displayedObjectAtIndex:i];

  id<SMPDataAPIPropertyProtocol> nameProp = (id<SMPDataAPIPropertyProtocol>)[agentryPalyer descendant:0];

  // ...


  // Create the player

  Player* player = [[Player alloc] initWithName:[nameProp asString] ...;

 

  // Serialize it for saving

  [players addObject:[player serialize]];

}


[sharedData setObject:players forKey:@"players"];

[sharedData synchronize];


Then the notification is fired:

CFNotificationCenterPostNotification(CFNotificationCenterGetDarwinNotifyCenter(),

  (__bridge CFStringRef)@"playersChanged",

  NULL,

  NULL,

  YES /* Deliver right now! */);

 

The receiving happens in the InterfaceController.m file of the WatchKit extension:

- (void) watchForDataChanges {

  // Listen for notifications on Darwing

  CFNotificationCenterAddObserver(CFNotificationCenterGetDarwinNotifyCenter(),

    (__bridge const void *)(self),

    darwinNotificationCenterCallBack,

    (__bridge CFStringRef)@"playersChanged",

    NULL,

    CFNotificationSuspensionBehaviorDeliverImmediately);

 


  // Listen for our own notification to ourselves in Cocoa

[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(cocoaNotificationCallBack) name:@"playersChangedCocoa" object:nil];

}

 

void darwinNotificationCenterCallBack() {

  NSLog(@"Notification received from iPhone app!");

 

  // Go from Darwin to Cocoa land

  [[NSNotificationCenter defaultCenter] postNotificationName:@"playersChangedCocoa" object:nil];

}


 

- (void) cocoaNotificationCallBack {

  NSLog(@"Notification received from ourselves in Cocoa");

 

  [self loadTableData];

}


Note that some bridging from C to Obj-C is required to get the notification passed to the WatchKit UI code.


Also note, with this implementation, the OpenUI adapter code must be run at least once before there is any meaningful data in the Watch application to display.


 


Communication from Apple Watch back to iPhone


While the same method above works for two-way communication, there is another API the WatchKit API provides for communicating with the containing iPhone App.


For an example of this, check out this method in InterfaceController.m:


- (IBAction)doMenuAction {

  [WKInterfaceController openParentApplication:@{@"key" : @"value"}

    reply:

      ^(NSDictionary *replyInfo, NSError *error) {

        NSLog(@"Containing app returned!");

      }];

}


And in the AppDelegate provided with the iPhone Application.


- (void)application:(UIApplication *)application handleWatchKitExtensionRequest:(NSDictionary *)userInfo reply:(void (^)(NSDictionary *))reply {

 

  NSLog(@"Awoken by Apple WatchKit App!");


 

  UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Alert" message:@"Alert from   

    Watch!" delegate:nil cancelButtonTitle:@"OK" otherButtonTitles:nil];

  [alert show];


  // ...

}


 

This same Watch application could be further extended to take advantage of the Notifications and Glances paradigms provided by Apple for its new wearable device.


Enjoy and share what you find playing with Agentry!

In this blog I am explaining an easiest way of developing your mobile app on the Cloud. SAP's tools in the cloud are made developer friendly, I hope you'll like it. This example takes you through 3 major steps.

  1. Develop Fiori like application using Web IDE
  2. Deploy it to HANA Cloud Platform
  3. Deploy app to mobile device using Mobile Secure

IGWREST_35 Apr. 05 19.55.jpg

Requirements

HANA Cloud Platform trial (HCP) - The application development is using SAP Web IDE and it is on HCP. Register for free trial of HCP.

SAP Web IDE (do steps till 4.2)- It is a development environment for web and hybrid apps.

SAP Mobile Secure - It is the mobile device management solution on the cloud.

 

1. Creating app using SAP Web IDE

1. Open Web IDE

2. Click on > New > Project Template.

IGWREST_25 Apr. 04 22.44.jpg

3. Choose SAP Fiori Master Detail Application. Click Next.

IGWREST_25 Apr. 04 22.45.jpg

4. On Project Name field enter "End2End". Click Next.

IGWREST_25 Apr. 04 22.47.jpg

5. Select Gateway system "ES1" and choose Odata service ZPRODUCT_SRV[ZCL_ZPRODUCT_DPC_EXT].

    Note: To use ES1 system as your backend for your mobile app make sure you have defined a destination with SAP Gateway trial. This video could help you                 to do it.

IGWREST_25 Apr. 04 22.49.jpg

6. Click Next.

7. On the new window opened provide below details.

IGWREST_25 Apr. 04 22.53.jpg

8. Click Next, then click on Finish. Done!! You have created an app.

9. To run the app expand the project. Click on index.html, then click on Run.

IGWREST_25 Apr. 04 22.54.jpg

10. It opens the app and asks for SAP Gateway credentials. Enter the credentials to see the app running on browser.

IGWREST_25 Apr. 04 22.55.jpg

2. Deploy App to HCP

1. Right click on the project choose Deploy, then select Deploy to HANA Cloud Platform.

IGWREST_25 Apr. 04 22.56.jpg

2. Provide HCP credentials. Click on Login.

IGWREST_25 Apr. 04 22.57.jpg

3. Check Create version and enter 1.0. Check Activate, then click on Deploy.

IGWREST_26 Apr. 04 22.57.jpg

4. You should get a Successfully Deployed message. Click on Close.

IGWREST_26 Apr. 04 22.58.jpg

3. Deploy App to Mobile Device

1. Login to SAP Mobile Secure. Click on Applications tab, then click on New Application.

IGWREST_28 Apr. 04 23.29.jpg

2. On Select Application Type window. Choose Fiori Application and click Next.

IGWREST_28 Apr. 04 23.30.jpg

3. On Name field enter Products. Check Deploy to managed users only and Mark as featured app.

IGWREST_34 Apr. 05 01.08.jpg

 

4. Click on Multimedia tab and set Application Icon and Banner image.

IGWREST_35 Apr. 05 01.08.jpg

 

5. Click on Supported Platforms. Click on Get Started. A new window will appear.

6. Choose OS platform as Android and enter Base URL (application URL).

IGWREST_35 Apr. 05 01.09.jpg

Note: Find your Base URL from HANA trial account - Login to https://account.hanatrial.ondemand.com/cockpit Click on HTML5 Applications > click on end2end.

IGWREST_28 Apr. 04 23.34.jpg

IGWREST_28 Apr. 04 23.35.jpg

7. Click on App Signing tab and browse android keystore and enter the password.

    Note: To create an android keystore follow the document: Creating a signed APK in Android Studio

              Use keystore of any application.

IGWREST_28 Apr. 04 23.43.jpg

8. Click OK. It will deploy the app.

IGWREST_29 Apr. 04 23.47.jpg

9. Click OK.

10. Click on workflow icon and select Set to production.

IGWREST_31 Apr. 04 23.47.jpg

11. Click Save. We have successfully added the app to the enterprise app store (mobile place).

Untitled.png

12. The enrolled user can go to Enterprise App Store and install the app in his device.

IGWREST_36 Apr. 07 10.50.jpgIGWREST_35 Apr. 07 10.50.jpg

IGWREST_35 Apr. 05 23.14.jpg IGWREST_35 Apr. 05 23.15.jpg

Note: Watch this video to know how to enrol your device with SAP Mobile Secure.

 

What's happening during the build ?

Mobile secure is creating a Fiori Client app (Cordova) with the Fiori application URL preconfigured with it. The Fiori Client is using the same Fiori web application which was hosted on HCP.

 

Regards, Midhun

SAP Technology RIG

In this post, you'll learn how to publish Fiori base URL as an Android app in SAP Mobile Secure.  In addition, I'll show you how to run the app from SAP Mobile Place on an Android device.

 

Requirements

 

  • SAP Mobile Secure 2.7
  • Keystore tool (e.g. Java 1.7, Android Studio, Eclipse, etc.)

 

Let's get started!

 

Before adding application to SAP Mobile Secure, let's create our app signing requirement.  In order to sign the app that will be created by Fiori build service, we'll need to create a java keystore file.  I'll be using command version of Java Keytool.  Alternatively, you can generate a keystore file using an IDE.  Please note, that the file extension must be .keystore.

 

How to use Java Keytool

 

Usage:

 

keytool -genkeypair -alias <KeyStoreAliasName> -keypass <KeyStorePassword_6_Char_or_more> -keystore <KeystoreFileName.keystore> -storepass <KeystorePassword> -dname <”CN=Firstname Lastname, OU=OrgUnit O=Org, L=City, S=State, C=Country” –sigalg <> -keyalg <DSA, DES, RSA> -keysize <56, 168, 256, 1024, 2048 > -validity <YEAR>

 

Example:

 

keytool -genkeypair -alias sap123 -keypass sap123 -keystore fiori.keystore -storepass sap123 -dname "CN=Dhimant Patel, OU=RIG O=SAP, L=Chicago, S=IL, C=US" -sigalg MD5withRSA -keyalg RSA -keysize 2048 -validity 99

 

Secure the keystore file and password as we'll be using it when adding Fiori App to SAP Mobile Secure.

 

keytool_usage.jpg

 

Add Application to SAP Mobile Secure App Catalog

 

Okay, now we are ready to add Fiori type application to SAP Mobile Secure.

 

1. Login to SAP Mobile Secure

 

mobsec_login.jpg

 

2. Click Add new application

 

mobsec_add_app.jpg

 

3. Select Application Type as Fiori Application (and click Next)

 

mobsec_fiori_app.jpg

 

4. In Details section, provide Name (e.g. E2E Mobile Cloud Demo App); other fields are optional

 

mobsec_add_app2.jpg

 

5. Multimedia - optionally provide app icon and Banner image (only required if app will be featured in SAP Mobile Place)

mobsec_add_app3.jpg

 

6. Categories - select a Category (where this app be listed under); simply drag-n-drop from Available to Selected

 

mobsec_add_app4.jpg

 

7. Owner info - add additional app owners (co-owners who can manage this app's lifecycle)

 

mobsec_add_app5.jpg

 

 

8. Supported Platform - click Get Started to add platform type

 

mobsec_add_app6.jpg

 

9. Add new platform > Info

  1. OS Platform - Android
  2. Base URL - https://demo-fioritrial.dispatcher.hana.ondemand.com/sap/hana/uis/clients/ushell-app/shells/fiori/FioriLaunchpad.html
  3. Icon - optional
  4. Splash Screen - optional

 

mobsec_add_app7.jpg

 

10. Add new platform > App Signing

  1. Keystore file - Upload your keystore file
  2. Keystore password - input keystore password
  3. Keychain alias - input keychain alias

 

mobsec_add_app8.jpg

 

11. Add new platform > Multimedia (optional)

 

mobsec_add_app9.jpg

 

12. Add new platform > Documents (optional)

 

mobsec_add_app10.jpg

 

11. Add new platform > Trial Users (click OK)

 

mobsec_add_app11.jpg

 

12. Click OK (the Fiori build service is generating our .apk on the fly).

 

mobsec_add_app12.jpg

 

13. Once the app is uploaded, click action button to set the app to production so users can view and install application from SAP Mobile Place.

 

mobsec_add_app14.jpg

 

Congratulations!  You have successfully added the Fiori app in the App Catalog.

 

mobsec_add_app15.jpg

 

Install Application from SAP Mobile Place

 

Next, we'll browse the SAP Mobile Place and install our app on Android mobile device.

 

1. Login to SAP Mobile Place

 

mobplace_app0.jpg

 

2. Browse App Catalog - Upon login your app may appear as featured (with banner and link to app).  In addition, your app will be displayed in category you selected when adding app to Mobile Secure's app catalog.

 

mobplace_app1.jpg

 

3. Click the App for details and install option (click Install)

 

mobplace_app2.jpg

 

4. The application is pushed down to the device and by default it will be in the Downloads folder.  Begin to install the app.

 

mobplace_app6.jpg

 

5. Open app (you'll see the splash screen (if added)) and Fiori base url will open.

 

mobplace_app11.jpg

 

About SAP Mobile Secure

 

For more information on this topic, head over to SAP Mobile Secure Cloud.

 

You can start your free 30-day trial of SAP Mobile Secure today!

 

About me

 

Please feel free to contact me with any questions about this topic at  Dhimant Patel | LinkedIn | SCN

Disclaimer, I am the CTO and co-founder of Neptune Software.

 

The past (and sadly the present in many cases)

 

The UI was seldom high on the priority list when companies traditionally mobilized their warehouse management, field services, manufacturing or retail stores. User experience was rated by ease of use of scanners and F button shortcuts.

 

 

For SAP customers this meant and still do for loads of companies low memory CE based devices using online SAP ITS solutions such as the horrors of LMXX transactions - I don’t want to get into too much detail on how much I resent those transactions but just mentioning the debug issues with the session handling and html rendering of SAP transactions should be enough.

 

blog1.jpg

 

The offline capabilities out there were based on docking the device with file integration to IDOCS – very costly in implementation and maintenance (I spent my fair time fixing errors in BD87). Updating the software on these devices can be a nightmare and often requires the device to be docked.

 

Also these solutions demanded competences different from what the standard SAP SI can provide. Creating native Windows CE applications often meant bringing in other third party .net or c# developers plus a ton of integration work with master and transactional data.

 

The present (For some)

 

I can think of few more visual examples of the Consumerization of IT than the last couple of year’s OS evolution of ruggedized devices. Most of the vendors in this space is seeing their customers looking for the “iPhone Experience” on their rugged handhelds or tablets.


In fact the customers started to replace their devices with products from vendors traditionally in the consumer market. Apple again led the way with the Apple Stores when they removed traditional POS and slapped Linea pro barcode and card reader onto their iPods.

 

blog2.jpg

 

Others would use Android tablets or iPads with Bluetooth scanners and/or rugged cases. 

 

Of course the traditional players in the rugged computing industry such as Motorola (now Zebra), Intermec and Panasonic had to act, and all came out with Android or Windows Embedded 8 products that promises consumer grade experience and reduced prices to be able to compete.

 

In the last two years we at Neptune Software have helped mobilizing over a hundred SAP customers and the majority has had some part of the project upgrading their traditional SAP mobile scenarios such as WM, PM or in-store Retail.  Most choose to change their devices to either consumer versions or new rugged ones based on modern OS and better hardware.

 

An example of the second category that I really believe can compete is the Android based Symbol TC70 from Zebra Technologies.

 

With HTML5 and SAPUI5 we and our partners can easily generate hybrid apps that have Fiori User Experience with offline and native capabilities (critical for intent scanning, card readers or new capabilities such as NFC).

 

Custom development is now fast and the apps are easy to deploy as these often can run in the existing network infrastructure of their former legacy solutions. We now see the traditional SI of apps for rugged devices are the ones that need an upgrade of competence and a huge market opportunity for SAP consultancies. 

 

Here is a screenshot of a WM app created by our partner S5 running UI5 on a Symbol TC70 – quite an improvement from the LM00 app described above if you ask me. You can read more about the solution here

 

 

 

 

blog3.jpg

 

 

Another example of usage is this video by another of our partners, New Zealand based Soltius, showing how customize an app sending SAP Notification’s from the field using the Neptune Application Designer.

 

 

 

The future

 

Well the future is already here.

 

I stole part of this blog’s title from the company of SAP Mentor Thorsten Franz after his speech at the Inside Track in Oslo : Operatics – Operational Analytics. There are different definitions of this term but I use it to describe analytics monitoring business operations in real time. Leaders of companies use this to make better decisions based on fresher data.

 

Coming from the mobility world I am more interested in what information this can give the workers in the field. With the evolution of the rugged devices we can provide graphical analytics to their devices related to the exact process and even specific business item such as a customer, a product, a plant, an order or whatever the worker needs information on to make a better decision.

 

I would like to mention a real world example. One of our Retail customers implemented an app for their store orders. The managers in the stores uses an android scanning device with a hybrid UI5 app to replenish stocks. The neat thing about this app is that after scanning one can also view relevant analytical data using the SAP.VIZ charting concerning the specific article and store. Does stock exist in the local warehouse? Are there Store orders already containing quantities being processed centrally or already in delivery? What is the stock situation in nearby stores? These questions can be answered without running to the pc in the back office directly on the device during the replenishment operation – thus enabling the manger to make a better decision.

 

 

Unfortunately this customer does not have HANA on their ECC system yet, but this makes a good case for adding it. Imagine predictive analytics taking into account all kinds of relevant data such as weather forecast (More sun means more barbequing which will lead to more sale of certain meats) or any number of other considerations.

 

There are of course myriads of other great appliances for these new devices that is just waiting for customers and their implementation partners to invent! The tools are out there and we no longer need to tell the customers we can't do it.

 

Best Regards

Njål

This April, the Mobile Secure team will join the broader SAP Security team in San Francisco for the annual RSA conference. We're excited to come together with the security experts to share the latest advancements in our mobile, cloud and enterprise security solutions.

 

Here are a few of the topics we expect to see at this year’s conference:

 

Excitement Around Android for Work

Android for Work is expected to take the mobile world by storm. SAP will be demonstrating our EMM solution supporting the new Android for Work container. SAP's Mobile Secure support for Android for Work is now available. Read more and watch an overview video in my blog.

All of SAP’s Security Solutions on Display

There’s a lot of security see at the show! If you’re an SAP customer you won’t want to miss our showcase our security and risk related products including SAP Identity Management, SAP Single Sign-On, SAP Cloud Identity service, SAP Enterprise Threat Detection, SAP Mobile Secure, SAP Governance Risk and Compliance, and SAP NetWeaver Application Server, add-on for Code Vulnerability Analysis.


SAP Mobile Secure Integration to SAP Systems

The SAP booth is always a hotspot for our customers to gather and learn about security topics specific to SAP environments. Our focus with SAP Mobile Secure is to closely integrate with SAP systems to provide mobile experiences no other vendor can offer. We align with SAP’s Business App strategy, offering a mobile app configuration service to customize, configure and package SAP mobile apps. And we also integrate with SAP Business Suite for secure content access with SAP Mobile Documents. Talk to us to learn more!


The BYOD Discussions Continue

BYOD is not a new topic, but security challenges continue to dominate conversations as it becomes mainstream. Many companies implementing BYOD are looking to do it without mobile device management (MDM). Techniques like app wrapping and enterprise app stores will be demonstrated at the SAP booth, showing how you can secure without a "heavy hand".

 

Mobile Really is Everywhere!

It used to be that mobile was a topic called out at events, either with a separate track or area of the show floor. We have moved beyond this phase to full adoption by every company and every vendor includes mobile as a core function of their business. Just as you see at SAP's own Sapphire conference, mobile is part of every product, every session and every conversation. We expect exactly the same thing at RSA this year; mobile will be integrated into every facet of the conference.

 

We look forward to seeing you at RSA 2015 from April 20-24 in San Francisco. Stay tuned for more RSA 2015 reports!

Issue Initializing the Usage library in 3.0 SP07 (and in the upcoming SP08 release) by passing in an encryption key to the constructor fails on some Android devices because the SQLCipher fails to connect to the encrypted database, and returns an exception to the application similar to:

E/Database(18356): CREATE TABLE android_metadata failed

E/Database(18356): Failed to setLocale() when constructing, closing the database

E/Database(18356): net.sqlcipher.database.SQLiteException: file is encrypted or is not a database 

...

 

E/AndroidRuntime(18356): FATAL EXCEPTION: pool-1-thread-2

E/AndroidRuntime(18356): net.sqlcipher.database.SQLiteException: file is encrypted or is not a database

 

Workaround Until the SQLCipher is stabilized in an upcoming patch/release, use the constructor without the encryption key parameter. The database is used only for temporary data collection, and the content is removed from the local database once data is successfully uploaded.

 

Example: Initialize the Usage library without encryption:

Usage(Context context, URL url, HttpConversationManager conversationManager);

 

Instead of:

Usage(Context context, URL url, HttpConversationManager conversationManager, String dataEncryptionKey);

 

 

 

 

 

 

Actions

Filter Blog

By author:
By date:
By tag: