iOS 9.3.2 testing has completed. This iOS version is now supported for both SAP Afaria and Mobile Secure. Documentation will be updated accordingly.
iOS 9.3.2 testing has completed. This iOS version is now supported for both SAP Afaria and Mobile Secure. Documentation will be updated accordingly.
To All SAP Agentry/SMP 3.0 users,
SAP Global Services and Support (GSS - One Service) tries to be proactive in giving the solution to the customers to make the knowledge available. We value your time in using our products and we always try to give the best solution out to the customer. Our mission is to give the best support anytime, anywhere and using any device.
Based on some internal and external installation of SAP Mobile Platform SDK 3.0 (Agentry) in SP08 to SP12, the SAP team believed that there may be a new security features available in Windows 8.1 OS that is preventing the full successful launch of the SMP 3.0 SDK Agentry WPF/ATE clients successfully. These features may be different in older Windows OS 7 environment.
This causes the SAP Agentry WPF/ATE client software (SMP 3.0 SDK) to show the following issues:
To resolve this issue, please do the following:
Thanks to all our valued SAP community of users, designers, engineers, partners and others who constantly share their knowledge to help one another to make SAP's support and user community - Best in Class.
SAP Platinum Support Engineer
This letter provides a notification that beginning with the July 2016 release, the Afaria Windows client will no longer contain support for computers running Microsoft Windows XP and Windows Server 2003.
After this release, the Afaria Windows client will support devices running the following Windows operating system versions: Windows 10, Windows 8.0 and 8.1, Windows 7, Windows Server 2008, Windows Vista
This change does not affect Afaria Windows CE, Windows Mobile, Windows Phone and Windows MDM clients. Please refer to the latest product documentation for Afaria (http://help.sap.com/afaria) for more information.
We regret any inconvenience that this may cause your organization. Our support staff is available to assist you in any way possible.
We are really excited to announce the availability of some of work that Microsoft and SAP have been engineering together to ensure that custom SAP Fiori apps can be enabled with the management and security capabilities that come in the Microsoft Enterprise Mobility Suite (EMS ).
SAP has an incredible portfolio of apps. One could argue that Microsoft is the gold-standard for the productivity tools that the world uses, and SAP is the gold-standard for the business apps. Thus, it makes sense that customers would want both of these sets of apps to securely share data and empower users to achieve more! And that is exactly what we hear from customers around the globe!
Engineering this integration to be both empowering and secure took some thought and innovation. There were a couple key customer requirements we had to think through together:
Together, Microsoft and SAP are delivering a solution that meets all of these customer requirements – and we are unique in delivering this. You may remember that SAP blogged about this collaboration back in November, and today we’re announcing that the technology enabling these integrated scenarios is in public preview @ SAPPHIRE NOW and will GA in early Q3 2016. Intune is the first EMM solution integrated into the SAP HANA Cloud Platform Fiori Mobile integration framework.
Here’s how it works:
At that point the apps can be pushed, the users’ mobile devices or the users can install the apps from the Intune Company Portal. Because the Intune MAM capabilities are integrated into custom SAP Fiori apps, they have the same level of in-depth management as other apps like the Office mobile apps, Box and Adobe Acrobat. Intune adds value to the capabilities that ship in iOS and Android to enable the top two customer requirements above. And, because the Office and Fiori apps are participating in the same MAM solution they can securely share data on any device. Very cool!
From the customer’s standpoint, with a few simple configuration steps, any current or net-new, SAP Fiori application can be consumed as a robust, highly customized, responsive mobile app. With Intune Integration, deployment and management and data loss prevention becomes a breeze as well. There are a variety of SAP Fiori standard apps available already (it is an impressive list) go to this link!
Here is a view of building a custom SAP Fiori app with the Intune MAM capabilities auto-integrated into the apps.
We are really excited about this partnership. And even more excited about the empowering environment that this delivers for end-users, while also delivering what IT needs in protecting the company data. This is just the first step in the SAP and Microsoft partnership. We look forward to continuing to expand the partnership.
Senthil Krishnapillai Brad Anderson
Global Vice President - SAP Corporate Vice President – Microsoft
SAP Afaria 7 SP14 has been released and is available for download in the SAP Support Portal.
If you would like to stay tuned on the latest news around Afaria, you may want to watch this wiki page to receive update notifications.
Hint: You need to be logged on in order to have the "watch this page" option available.
SAP Fiori is SAP’s new web-based User Experience approach going forward. Being designed for omnichannel consumption of information, it is a natural fit with SAP’s Mobile offering. Nevertheless Mobile Computing is a broad field that comes with its own specific requirements and challenges. This paper discusses some advanced topics centred around architecture and life cycle management that apply to Hybrid applications in general, and to SAP Fiori in particular. First a description of various consumption models is given. Then the strengths and weaknesses of these approaches are presented. Finally reference architectures for Life Cycle Management are given for each of the approaches.
Fiori applications are typically consumed via standard browsers on desktop computers. In this scenario the Fiori Frontend Server (FES) acts as a web server, providing both the web applications and the underlying web services on a single host. Since Fiori apps are thick clients, the server does not need to provide any complex services beyond what is encapsulated by the OData services serving the corresponding application.
Figure 1 depicts this situation using the example of the Fiori Launchpad itself. It should be noted that it is not treated specially by the FES, making it a regular Fiori application. In this case we assume a simplified scenario, where the Launchpad is loaded as a whole, and does nothing but querying its associated OData services for the current user’s Fiori application catalog and configured home screen tiles. In reality Fiori applications are typically loaded in modules, meaning that requests retrieving code and data are interleaving each other. This applies to the Fiori Launchpad in particular, since it first retrieves the minimal amount of information required to display one’s applications. Only when an application tile is clicked, the remaining code for this particular application is being lazily loaded.
Figure 1: Standard Fiori client-server architecture and interaction
While this architecture implies that the application itself needs to be transferred to the client before it can be executed, it makes managing updates rather easy. Proper browser-based caching will ensure that round trips are reduced once the code has been transferred to the device, while still allowing code updates once the application deployed on the FES is changed centrally.
As can be seen in Figure 2, the Fiori Client runtime looks very similar to regular browser-based Fiori consumption. Most notably no changes on the server side are involved. The difference is that this consumption form applies exclusively to mobile devices, such as iOS and Android phones. Rather than opening a browser window to the Launchpad, the users are installing a proper application that emulates browser behavior. Technically speaking, the Fiori Client is a simple single-screen application, which contains a single WebView. Those views are used to embed HTML content from external and local sources into native applications, and in this case it is used to display the whole user interface in terms of the Fiori Launchpad. While this brings Fiori closer to a native experience in terms of a proper application icon on one’s phone home screen, it is important to note that from the server-side both consumption forms are equivalent.
Figure 2: Fiori Client client-server architecture and interaction
What is the added value of using the Fiori Client then? A look under the hood reveals that the Fiori Client is in fact implemented using Cordova, a hybrid application framework that exposes native device capabilities to web-based applications. While the HTML standard is generally catching up with the features available on the average computer (i.e., including phones) nowadays, there are still huge gaps. For instance, Cordova provides access to sophisticated capabilities such as the user’s personal address book, and even platform-specific features such as the iOS fingerprint protection. This generally enables developers to write true cross-platform omnichannel applications, while still allowing access to platform-specific features depending on the runtime environment.
Figure 3: Cordova Architecture. Based on the official documentation.
While the above setup generally works extraordinarily well under office conditions, it is important to note that we are in fact looking at a distributed system, and with that come the challenges particular to distributed computing, the most important one being the network itself. Despite the perceived stability of networks, they are very fragile especially in large scale. Not only are there many potential points of failure on longer routes, the data transfer rate typically also declines, leaving more time for failures to actually become apparent.
There is a multitude of possible causes of network failures, e.g. faulty hardware, peaks in data centers, or just the user moving between access points. Therefore in this section we are emphasizing the symptoms rather than the causes during two different points in time of the application life cycle: One while arbitrary code is being loaded, and one while data is being transferred.
Figure 4: Network failure during initialization
Figure 4 depicts the former scenario, in which a network outage occurs while code is being loaded. In this case the effects are difficult to anticipate, since it depends on which component exactly failed to load. Continuing the example of the Launchpad, here are some examples:
These scenarios have in common that it is generally very difficult to catch and handle the related failures, the problem being simply that an application that is not fully loaded is unable to handle errors of any kind. In addition browsers do not expose an API to detect script load errors from within the WebView, making recovery even more difficult. Regardless if the Fiori Client or a browser is being used, there is no reliable and consistent way to deal with these failures short of having the user reload the application until it works. Caching does help a lot to mitigate these issues, albeit only once the application has been loaded successfully and until the caches are invalidated.
Figure 5: Network failure after initialization
In comparison, failures while loading data, as shown in Figure 5, can be handled easily by the application itself. Since it should generally be assumed that any network request may fail easily, most applications should deal with this failure scenario out of the box, e.g. by automatically retrying a number of times or notifying the user that due to network issues the requested information could not be displayed. What is crucial in these scenarios is the distinction between code and data: Even though the same causes for failure may apply, error recovery in the latter scenario is much easier, simply because the code required to handle it is already on the device.
Packaging is a means of ensuring that failures such as depicted in Figure 4 can never happen by making sure the code is already on the device. This is actually the “intended” way of working with Cordova: When a template project is created from the Cordova Command Line Interface (CLI), a web app folder is actually created within the generated native application. The web app sources reside within this folder, rather than being loaded from the server. In that regard the Fiori Client is a special case, somewhere in between standard Cordova applications and the more traditional use of WebViews: While it enables the consumption of device-native features, it does not require you to have the application sources on the mobile device. This also makes it rather easy to derive the meaning of “Packaging” in the context of the SAP Mobile offering: It means moving the Fiori application code, including a Launchpad, from the server to the mobile devices, so that both native and web application code are installed alongside on the device.
Figure 6: Packaged application client-server architecture and interaction
Figure 6 outlines the difference to the other consumption models. Most notably it is irrelevant to the mobile application what is being deploy server-side in terms of web applications. The only thing that matters is that the required web services are up and running. This does not imply that there must not be application code deployed to the FES. On the contrary, both packaged and traditional applications may be used alongside each other.
As was discussed in the Section “Failure Scenarios”, the most obvious benefit of packaging applications is that network-related crashes are impossible, assuming that the packaged applications themselves are properly suited to deal with such situations. However, there is another benefit related to eliminating the network factor during initialization: Startup time. Especially the first start of a Fiori application may take longer than usual because the application code actually needs to be downloaded before it can be run. This means an occasional additional round trip, which may or may not be very noticeable depending on the network quality. Worst case the previously outlined failures may occur. On average the startup time is increased significantly due to the low transfer rates on mobile data networks. Once the applications are fully cached, best-case performance can be reached by saving these addition server round trips. Packaged applications, however, always guarantee the best-case application performance.
On the other hand, packaging is a typical time-space-tradeoff: Processing and network time is reduced by increasing the size of the built application. This is an issue with the average UI5 application since packaging also involves all dependencies of the packaged applications, and a full packaged UI5 distribution may lead to application packages well beyond eighty megabytes in size. However, considering that UI5 may be minimized in terms of the number of packaged modules, in practice the increased application package size may be neglected. Packaged applications and the Fiori Client alike are typically around thirty megabytes in size, most of that being plugins. For instance, the popular Crosswalk (XWalk) drop-in WebView replacement alone consumes around twenty megabytes in size on Android.
There also is an innumerable amount of differences in implementation details between a packaged Fiori application and the Fiori Client. While both are Cordova applications inside, the standard Fiori Client comes prebuilt with a huge number of plugins. This is the reason that the standard Fiori Client has a “double tap to open menu” feature, while standard packaged applications do not have it. Since both the Fiori Client and packaged applications may be customized to the heart’s content, this is more a matter of degrees than a sharp line between both consumption models. Generally a packaged application can be taken arbitrarily close to the Fiori Client in terms of behavior and features, and the other way around also works. It would, for instance, be possible to copy an arbitrary amount of Fiori applications and a Launchpad into a Custom Fiori Client project, and have the Custom Fiori Client display the local Launchpad rather than the FES Launchpad. Whatever is implemented in the Launchpad can easily be moved to packaged applications. The only real challenges are server-side components that are not part of the actual Launchpad, such as Gateway Logon classes. When the SAP Mobile Platform (SMP) is not used, it may be necessary to add a login view to the local Launchpad that sends the user logon data to the Gateway logon class.
However, the biggest open question is: How do the applications actually get from the FES onto the device, when they are not being loaded directly during runtime?
In order to comprehend the full implications of packaging, especially when it comes to Life Cycle Management (LCM), we first need to establish a reference architecture for the development environment prior to packaging. For that purpose, we revisit the simplified architecture from Figure 1. Figure 7 shows the same situation in a bigger context. Most notably, it can be seen that the simplified model introduced in Figure 1 is actually replicated across a number of mostly identical system landscapes: One for development, one for tests, and one for production. This is in fact more an example than a fixed rule; there may also be less or more stages on the way from development to production. The important thing is that applications are deployed once to the first stage (development), where they are tested. Once the quality check passes, a transport is requested from the first to the second stage, effectively updating the application on the second stage to the version on the first stage. This is repeated from stage to stage until the application is finally being deployed in production. This does not only apply to the FES, but also to backend systems. The FES separates the upstream landscape simply by means of named connection mappings. The application itself does not know to which backend system it is talking, but requests a generic endpoint that the FES would resolve appropriately according to the system configuration.
Figure 7: Mobile Fiori Life Cycle Management architecture
The journey of the code does not begin in the first deployment stage, however. The application is code in the WebIDE and shared between team members via Git, a source code management (SCM) system. Once a unit of work, e.g. a feature, is completed, the change is pushed into the upstream Git repository, from where the current project status is retrieved by a Continuous Integration (CI) server. The CI server then continues to build the project and execute the project test suite. Only when these steps are successful, the built application is deployed to the first test stage.
It is easy to see how manual tests would be carried out from the browser: Each of the deployment stages comes with a full Fiori stack, so that each of the FES has its own Launchpad. On the mobile device this is somewhat trickier: A Standard Fiori Client is configured against a single FES, and one application (identified by its bundle ID, e.g. com.sap.fioriclient) may only be installed once per mobile device. Therefore it is either necessary to use different mobile devices for each of the stages, or to build three Custom Fiori Clients with different bundle IDs that may be deployed to the same device (e.g. com.sap.fioriclient.dev, com.sap.fioriclient.test, com.sap.fioriclient.prod).
Going forward we are going to assume the latter approach is taken. Since now development, build and distribution of the Custom Fiori Client itself become a concern, Figure 8 shows the corresponding LCM view on the mobile development landscape.
Figure 8: Typical Mobile Life Cycle Management architecture
It can be seen that apart from using a different set of tools for development, the build and test infrastructure still is the same with Git and the CI server in its center. The first large difference is that a Mobile Device Management (MDM) solution such as SAP Afaria is the target of the CI server deployment rather than a FES. Secondly, it can be seen that it is not typical to replicate MDM systems for each testing stage. Instead, different application configurations are created in the MDM system, one for each Custom Fiori Client. Thirdly, the CI server builds one version per stage per update, resulting in three built Custom Fiori Clients per update in the current example, which are then pushed to the client devices. As outlined before, the mobile applications only differ in their configuration, and the subjects under test (SUTs) are the Fiori applications rather than the Custom Fiori Client. Therefore the separation between FES is sufficient, and switching to a different Custom Fiori Client stage is equivalent to switching to another FES Launchpad stage. The beauty here is in the clean separation between web application and native code, as was hinted in Figure 3. The Custom Fiori Client merely provides a shell in which the Fiori applications may run, and it only contains the rather rarely changing native components of a hybrid application. The more frequent application updates follow the quality assurance path shown in Figure 7, whereas Custom Fiori Client updates are shipped occasionally via the MDM solution.
Now that a reference LCM architecture has been established prior to the implementation of packaging, we can now take a glimpse at the changes packaging would introduce. Figure 9 provides a unified view on LCM for (packaged) mobile and web-based Fiori applications.
Figure 9: Basic packaged application Life Cycle Management architecture
The first conclusion is that both approaches may actually coexist, which makes it easy to experiment with packaged applications while the existing system landscape remains largely untouched. In fact the packager included in the SAP Mobile SDK leverages FES as the source of truth, downloading apps and their dependencies from there. Secondly the CI server now not only builds and deploys to the FES once per Fiori application update, but it will also need to rebuild and redistribute the packaged applications to the mobile devices. This potentially introduces significant additional load on the MDM, depending on the frequency with which Fiori application updates are checked in. For this reason SAP provides the App Update plugin, which enables packaged applications to connect to the SMP and update themselves if a newer version of the web applications is available.
Figure 10 shows an updated architecture incorporating the (so far optional) SMP. In this setup the MDM service is only used for the first-time installation and updates when changes are made to the native application components.
Figure 10: Packaged application Life Cycle Management using SAP Mobile Platform
Just as before, when a Fiori application is updated in Git, the packager is triggered to assemble the required web assets for the packaged application Cordova build. This intermediate build result can now be used to create a web application package using the Mobile SDK Kapsel CLI and upload it to the SMP. Then it can be rolled out either automatically or manually to a number of test devices, or to all registered devices. The most important bit here is that the SMP calculates a delta based on previously uploaded web application packages, and only sends the differing files to the devices. This way frequent updates of thirty megabytes and above can easily be cut down to single-digit numbers and below.
On the previous pages we considered how packaging Fiori applications affects the LCM and client-server interaction. However, it is also important to understand that there are challenges in Mobile Computing that cannot be addressed by packaging, the most notable being processing power. Mobile devices generally have less computing power, main memory and storage capacity than the average desktop computer. While it is true that packaging may improve overall performance by eliminating server round trips due to code loading, it does not affect the performance of the applications themselves, i.e. their consumption in terms of processing power and main memory. To the WebView, it does not matter if the same piece of code was loaded from the local file system or from a remote server. The remaining network performance is not affected either, i.e. slow data requests in the Fiori Client will not complete faster in packaged applications.
With the packaging in place, network-related failures to load the application are mitigated. While this greatly improves stability, it does not address performance issues, since uncached data requests still require full server round trips, and especially time-intensive data requests are vulnerable to connection interruptions. Therefore it makes sense to think about going the extra mile and also implementing the SMP Offline OData support. Figure 11 shows an updated runtime architecture diagram, continuing the Fiori Launchpad example we used previously.
Figure 11: Packaged offline-enabled application client-server architecture and interaction
Rather than having the applications access the remote OData service directly, the SMP provides the client with a local database that is used to feed a local OData producer. Requests on the client are then rewritten to the local OData provider, allowing near-instant access to the data. Not only does this enable scenarios that are otherwise impractical due to network unavailability, but it also helps you provide a very fluent user experience. The local offline data can be synchronized with the backend in the background whenever network connectivity is available.
In this paper the technical concept of packaging, i.e. moving web application code from the Fiori Frontend Server onto a mobile device, was discussed. It was shown that both traditional Fiori consumption models (browser, Fiori Client) may coexist with packaged deployments without interfering with each other. The biggest difference between the approaches is in the life cycle management, which may or may not lead to additional load on the Mobile Device Management solution. It could be shown, however, how this issue can be addressed by leveraging the web app delta update capabilities of the SAP Mobile Platform.
 Throughout this paper the term SAP Mobile Platform may be exchanged equivalently with HANA Cloud Platform mobile service.
 Throughout this paper the term SAP Afaria may be exchanged equivalently with SAP Mobile Secure.
We just whitnessed what appears to be a gamechanging partnership between two giants in the IT World. SAP and Apple are going to collaborate, to seriously break ground in the Enterprise mobility world. My LinkedIn, Facebook and Twitter feed exploded with likes and shares of the same article. A couple of hours later, the first analyst blog posts started appearing. I particularly liked Gareth Ryan and John Moy 's posts.
I figured both of these posts touch on very important topics. When I noticed colleagues, friends, acquaintances and people I don't know go out in a frenzy on different social media channels, I suddenly felt the urge to answer with some skeptical sounds of my own.
I've seen people shouting (from a keyboard that is) "Finally!! We'll get decent mobile apps!", "Hurray, all our problems are solved now!", "I knew it! Apple will save us."
Okay, I'm slightly exaggerating the reactions, but it's in the same spirit.
Here's a little wake-up call for you all:
The issue with Enterprise mobility has never been the front-end
I've built my fair share of mobile apps on top of SAP software already and I can tell you one thing for certain: The User interface is not an issue. You can build iOS apps today, with a great user interface. You can build sexy looking Android apps on top of SAP ERP functionality. You can make magnificently square apps on Windows phones. No issue whatsoever!
The biggest hurdle in enterprise mobility is, and always has been, the synchronization layer. SAP ERP is built around record based transactions and client initiated actions. In other words, the client opens up a record, locks it, changes some fields, saves and releases the lock. Now you might think that only those fields are updated in the source record, but in reality, the entire record is updated with the information coming back from the client.
If something concurrently had changed in that record (which shouldn't happen, as it was locked, but we all know that locks are sometimes forgotten in custom code), it woul dnow be overwritten again.
Let's be honest here: Apple is not going to solve that issue. They'll only touch the UI.
You see, things used to be easy in the SAP ERP world. You had one big database and one fat client. If one user opened an object, it would be locked for anyone else. So an update could only come from one user at a time. So SAP never felt the urge to build in a broadcasting mechanism, to update the client(s) with changes that were done from a different client. As a result, business users got used to the idea of "always consolidated". The data in the system always corresponded to a user's actions.
With mobility, things are very different. First of all, you have much more users working on possible the same object at the same time.
Secondly, some of these users may be working in an offline mode, and perhaps only synchronize the data at a later time.
So that means you end up in a situation of "eventually consolidated". Which is a difficult thing to explain to a lot of business users.
Another thing, as John and Gareth had already mentioned, is the trend of BYOD. With the SAP-Apple partnership, people can be easily mislead into thinking that SAP is going to focus on Apple devices and might neglect the other devices. People may also be lead to believe that the HTML5 and hybrid web trend was a mistake. Obviously none of these are the case, but in an overly hyped world, perception is everything.
So in my opinion, all the hoopla around the SAP Apple partnership, is nothing but marketing.
I can understand that it is a necessary hype, seeing as IBM recently made a similar partnership: Business - Mobile Enterprise Apps - Apple
So obviously, SAP couldn't lag behind. Customers are much too easily dragged along on a hype. But let's not forget that SAP already had partenrships with Google and Microsoft as well, so it really isn't anything new.
This new partnership is only scratching the surface, but most business users only see the surface, and not the un-sexy, oily and dirty underlying layer.
So my hope is that while everyone is looking at the Apple partnership, that meanwhile SAP is seriously working on solving the sync principles in the backend.
Just because I can, I also published a theoretical model for eventually consolidated webservices: http://scn.sap.com/docs/DOC-72717
That should give you an idea of where the real complexity is with modern landscapes. Hint, it's not about the color of the submit button
If you are the first time to use the work manager application, especially for 6.3 version, this quick start guide about Work Manager 6.3.x deployment will be good for you to start.
Note: All the contents of this article are the minimum requirement on this topic.
SAP Mobile Platform 3.0 SP10
Work Manager 6.3.x
WPF Agentry Client v70.11.0
Step by Step guide:
Download the Work Manager 6.3 from SAP ONE Support Launchpad following the link below.
Each available software to be downloaded are standalone. For example: Deployment, Crew Management or Meter Management. Users has to choose which one they want and work on it from there.
Unzip the installation file and run the workmanager.server-6.3.0.exe
Enter the Work Manager Backend Server address, Client number, Sys Number and User information, and then select directory to generate the application.
During the installation, the workmanager.server-6.3.0.exe will produce the SAP Work Manager 6.3.x application definition, libraries and other configuration files in a zip file “SAPWorkMgr630Deployment-20151103.0552.zip” that will be used in the SAP Mobile Platform Management Cockpit.
Ini files – Configuration files used in Work Manager 6.3, for example: JavaBE.ini file will include the backend connection information that we just input in the previous step; Java folder will include many *.jar files – Java class files used to interface with SAP backend;
Open the SMP Management Cockpit and create a new application with type “Agentry” and set the Authentication providers with ‘No Authentication Challenge” option.
Save the application and the Agentry application node will be created under the SMP configuration folder, generic ini configuration files area would be generated.
Restart the SMP server, check the startup.log and you can see the message about there is no application and backend loaded yet for this new application. Once Restarted, open the application in the management cockpit and navigate to “APP SPECIFIC SETTINGS”, press the Browse button to import the application zip file “SAPWorkMgr630Deployment-20151103.0552.zip” under Publish tab.
After loading the application zip file, the backend will be shown in the configuration screen and include the contents in the Agentry.ini file before.
Note: sapsso.jar is only for sso setup and is not part of the out of box deployment files.
Save the application and restart SMP server. Check startup.log and event.log, make sure the work manager 6.3 application has been loaded successfully in the SMP/Agentry Server.
Check from IE if you can connect the application in the SMP and see “I am here” by typing https://SMPServerAddress:8081/ApplicationName, open the SMP cockpit and navigate to the configuration screen of this Agentry application, then you can get the application name from the ‘urlPath’ field under APP SPECIFIC SETTINGS.
During the SMP 3.0 installation, the smp_crt.cer file would be generated under the Server/configuration folder. In order to get the approval for accessing SMP server from Agentry Client, we need to install the certificate file in the mobile device.
In this scenario, copy the smp_crt.cer file to the root folder of WPF Agentry Client and install it under the Trust Root Certification Authorities.
Open the WPF Client, input the Agentry Backend user name and password, enter the URL “https://SMPServerAddress:8081/ApplicationName” that can access the work manager 6.3 deployed in the SMP server and you will see the transmit has started in the popup screen.
At last, if you open the SMP Management Cockpit and navigate to “USERS” option under the APPLICATIONS tab, you would find that the connect information for this user on this Agentry application.
Worldwide, SMS-based mobile messaging continues to evolve and innovate. Nowhere is this more apparent than in A2P or enterprise messaging. Numerous analysts have forecast that enterprise messaging (or A2P messaging as it is sometimes called) will continue growth and prominence through at least the rest of this decade. Why is this? SMS is still the most ubiquitous, far-reaching messaging channel in the world and will remain so for quite some time. While there are a growing number of non-SMS messaging/social media options (WhatsApp, Snapchat, Facebook Messenger, WeChat and many more) virtually all of them require both the sender and receiver to be using the same solution, thus leading to significant fragmentation – notwithstanding that many of these non-SMS chat apps are and will become significant “A2P channels,” going forward. Otherwise, SMS continues to show strength in that regard.
So why is it important that SMS messages are routed correctly? The global SMS ecosystem consists of separate, logical Application-to-Person (or A2P) connectivity network – one where mobile network operators (MNOs) have approved, and in many cases, monetized, this type of mostly commercial and non-human generated traffic. Traditionally, the A2P network uses separate connectivity from the general conversational or Person-to-Person (or P2P) connections. The reasons for this are numerous; however a significant reason is that it helps to control spam and grey route traffic over the P2P networks.
Wait? What do I mean by “grey route traffic?” Grey route traffic is typically A2P SMS traffic that attempts delivery outside of approved A2P connections or routes into the MNOs. Grey route traffic tries to leverage the P2P network and ubiquitous connectivity to avoid MNO fees or approval processes. Much of it attempts to take advantage of MNOs, aggregators, and even senders. As the ability to reach consumers through SMS is immensely valuable, there are numerous messaging aggregators and service providers that use a variety of tactics to attempt to circumvent MNO-supported routing standards.
Unapproved routing puts businesses and consumers at risk
When unscrupulous messaging aggregators try to circumvent operator-approved and monetized routes, they put
the business who is paying for the messages at substantial risk, due to non-delivery of these messages. The mobile ecosystem is becoming increasingly vigilant against so-called “grey route” traffic and is deploying SMS firewalls as well as more aggressive spam control measures.
This practice also increases the risks to consumer by exposing them to potential spam and/or fraudulent messages (phishing attacks, etc.). There are a growing number of unscrupulous, do-it-yourself SMS websites that promise low prices per message and bulk messaging. These services can typically cater to anonymous senders and the sites use a variety of methods to hide the messages among legitimate P2P messages and connections.
The sites may also leverage SIM farms – an organization that leverages thousands of SIMs (or Subscriber Identity Modules), connected to computer servers instead of mobile devices – to send large amounts of messages. They may also be used by unscrupulous senders to send unsolicited messages to large numbers of consumers with the further goal of obfuscating just who the sender is. The messages appear as if they are legitimate P2P messages – the originator is a phone number of a mobile operator (from which the SIM cards are from). SIM farms are also attractive to some businesses because they are very cheap and messages from them may be bounced from service provider to service provider in order to avoid legitimate operator connections – hence is why the routes they use into MNOs are known as grey routes.
MNOs don’t like SIM farms and do take measures to shut them down. Additionally, when they are uncovered as sources of mobile spam, they can be shut down by authorities. In the UK, the Information Commissioner’s Office (ICO) is an independent body set up to uphold information rights takes enforcement action against SIM farms and nuisance calls and spam texts.
What is behind grey route trends?
Most of the world’s MNOs apply termination fees to SMS traffic entering their network from another network through standardized agreements. Termination fees were put into place in early days of SMS as a measure to help control spam. While that goal was accomplished to a point, as SMS traffic continued to grow, the underlying SS7 networks were left relatively open as there are various types of signaling beyond SMS that must flow between MNOs. In the P2P messaging world, traffic between two MNOs is typically balanced – meaning conversational – termination fees effectively cancel each other out.
Grey routes will many times take advantage of national P2P traffic, by setting up shop within a targeted country. Many times, originators will be outside of the country leveraging thousands of “local” or national phone numbers of SIMs in the SIM-farm allowing the message to appear as a P2P message bound for subscribers with a local origination number. This practice breaks the balanced nature between the operators, but since each number may be used only a small part of the time, it gets through various types of filters that the destination operator has in place. This is but one example of how legitimate A2P or enterprise messaging traffic can suffer as it is travels several hops into the destination operator. Enterprise customers may pay lower price, but the traffic has a relatively low chance of delivery and due to multiple hops, there is no way to validate the message even made it to the destination. Consequently, many enterprises are getting heavily fleeced by these bad actors as they are billed for messages sent – not ultimately delivered. Because of the lower prices that many “bulk messaging aggregators” are able to support via SIM-farms and other vulnerabilities, this practice most definitely attracts spammers that will send unsolicited messages to subscribers without their consent, violating laws and regulations in most countries.
Mobile Operator benefits of trusted message routing
Trusted messaging aggregators, like SAP Mobile Services contract directly with MNOs and other trusted aggregators to provide approved routes to mobile operators. These service providers offer the highest quality routes to mobile operators – many, if not most – with such features as handset or network delivery receipts. Additionally, when working with each MNO, trusted aggregators may be able to negotiate termination rates that enable the aggregator to then pass along favorable pricing to enterprise customers.
The physical connection to the operator may be through the global SS7 network, or now, more than likely, through direct, secure IP connections, and more increasingly, IPX connectivity. Whether connected through IP or SS7, the sender and the aggregator are recognized by the MNO and as such, traffic from this source will be prioritized and delivered.
Trusted aggregators will also work to insure that traffic delivered to the MNO is from trusted sources and can filter any traffic that is not. If an MNO requests that all of their incoming traffic – especially international traffic – flow through the aggregator, they can stem the bleeding of revenue due to uncontrolled inbound messaging through unmanaged SS7 channels. With the addition of an SMS Firewall into an MNO’s ecosystem, the MNO now has a valuable set of tools available to manage their network and traffic, while protecting subscribers from unsolicited messages.
This point is further emphasized as in many countries, MNOs are increasingly being held accountable for non-solicited or spam traffic reaching their subscribers. For example, in India, the regulator TRAI amended regulations calling for a Rs. 5000 for every SMS spam complaint.
Enterprises and Brands benefit the most from trusted routing
Shutting down grey-route and untrusted, multi-hop SMS routing certainly benefits the MNOs, but it is the end-customers – the enterprises, brands, and other organizations who are sending the messages – that stand to benefit the most. These are the organizations that pay the money to send messages and they expect and deserve a high conversion rate. When messages are sent through low-cost providers, these organizations are lulled into thinking that their messages will all reach their intended destinations. Furthermore, many organizations rely on high conversion rates to reach their target ROI on the messaging investment. Low cost or “too low to be true” is just that – too good to be true. Enterprises will never reach target conversion rates.
The concept of consent – that is, the end-users consenting to receive certain commercial SMS messages is at the center of most legal issues around SMS messaging. If an organization’s messages are received by an MNO’s network and there is not a readily identifiable sender address, then many of these messages are very likely subject to being blocked as spam since they cannot be readily identified, regardless of whether the end-subscriber consented to receive these messages.
Enterprises that use SMS for marketing must comply with a growing array of regulations such as TCPA in the United States, Canada’s Anti-SPAM Law (known as CASL), TRAI regulations in India, and the ICO regulations in the UK, to name but a few. All of these have provisions around identity and consent; however, by simply trying to avoid lawful MNO termination fees, they are already on the wrong foot and at worse, can be subject to legal troubles.
Finally, one of the most important reasons for using trusted routes to mobile operators is for delivering two-factor authentication (2FA) tokens to subscribers. Those suppliers and messaging providers that use “cheap routes,” and those that may take advantage of grey routes, do a major disservice to the overall concept of 2FA over SMS. One of the biggest complaints about 2FA over SMS is that many times the delivery rates are low. This can be heavily mitigated if the 2FA providers would simply use approved routes into mobile operators. In our own experience, we see successful delivery rates of many millions of 2FA tokens into operators around the world at success rates greater than 97%! But, we use approved operator routes. It is not our policy to use grey routes, but instead, we rely on our own direct, approved routes into our mobile operator partners.
The bottom line is: Yes, it very much does matters what route a message takes to reach a mobile operator and the consumer. There are legal ramifications as well as quality – whether simple notifications or high value 2FA PIN codes.
 Conversion rate: A measure of successful SMS respondents vs. the number of messages sent. In other words, how many end subscribers responded or acted on the message the received.
If you are the first time to use the Agentry Backend System and want to add a notification with attachment and transmit the data from Backend System to Agentry Client successfully, this quick start guide will be good for you.
Note: All the contents of this article are the minimum requirement on this topic.
For the Agentry Backend part, you can follow the link below for the reference if have any query.
SAP Mobile Platform 3.0 SP10
Work Manager 6.3
WPF Agentry Client v70.11.0
Step by Step guide:
Log on the Agentry Backend ERP system and run the Transaction code /SYCLO/CONFIGPANEL and open the web page.
Select “Mobile Application Configuration” and choose the work manager 6.3 application. Press “Client Globals” tab and change the ‘Attachment.Synchronous’ setting’s value to ‘Y’ if the content was “N” before, also the active flag should be clicked.
Input name in the notification title field, scroll down the list to the bottom of Notification tab, navigate to Responsibilities’ field and enter the Plant number, Work center and the Personnel id who has been associated with this work center.
Close the attachment screen, press “put in process” button to publish the notification and save the notification.
Run the Transaction code IW23 to display the notification modified before and click “System” in the header and select Service for Objects -> Attachment list. Make sure the object has been attached successfully.
Select notification tab on the client and we will see the new notification has been uploaded to client from backend system. Press the attachments option in this notification and the attachment should be there with “Not Downloaded”.
After press the download button, the downloading process bar would popup on screen. After finishing the transmission, we should find that the attachment status has been changed to “On Device”.
Check out our new CIO Guide : Enterprise Mobility
Mobile devices are everywhere, making supercomputing accessible anytime – often as cloud services and applications – and making high levels of security a standard in this mobile environment.
Enterprises are looking for more and more ways to capitalize on these facts. While this mobile trend offers tremendous opportunities, it also increases the pressure on IT departments to define a coherent mobile strategy.
This Guide discusses the need for an organization-wide mobile infrastructure to provide enterprise-grade solutions. It is aimed at CIOs, IT managers, Architects, Experts and Project Leads who are considering new or substantial growth in their enterprise mobility initiatives and are not yet caught up in the day-to-day details of their company’s ongoing mobile activities.
SAP provides a complete portfolio of solutions for mobile app development, mobile app management, and mobile device management.
These capabilities can be deployed either on premise using SAP Mobile Platform (SMP) or in the cloud using SAP HANA Cloud Platform.
I hope our Guide will give you direction and guidance on your way into the Digital and Mobile Enterprise.
SAP Afaria 7.0 SP13 has been released and is available for download in the SAP Support Portal.
If you would like to stay tuned on the latest news around Afaria, you may want to watch this wiki page to receive update notifications.
Hint: You need to be logged on in order to have the "watch this page" option available.
At the 2016 Facebook’s F8 Developer’s conference, a new no-password login solution was announced called Account Kit. Account Kit is designed to be an alternative login facility for people who either don’t want to use a social login such as Facebook or a non-password login. Users are given a choice between either email or their mobile phone number as their “identity.” After providing one or the other, a one-time code is sent via email or SMS to their mobile device. Access to the account is then granted.
I initially thought this was Facebook’s way of usurping the GSMA solution called Mobile Connect – an alternative to the one-button Facebook login. But upon further reflection, it is not. As the GSMA site notes: “Mobile Connect is a secure universal log-in solution. Simply by matching the user to their mobile phone, Mobile Connect allows them to log-in to websites and applications quickly without the need to remember passwords and usernames.” So, that sounds a lot like Facebook Account Kit on the surface.
Let's dig a little deeper. First off and foremost, Mobile Connect does not share any information with enterprises / sites (AKA “service providers”) without explicit permissions. No such assurances are in Account Kit. In fact, the service provider (e.g. site or app using Account Kit) has complete access to the Email Address or Phone Number the end-user provided as well as the Facebook-generated account ID (which would not overlap with a Facebook social account ID). Bottom line, it is certainly not an anonymous login. While users don’t have to have a Facebook social account (like is required for the one-button Facebook login button that is common), it is unclear how Facebook will use the acquisition of all of these phone numbers and email accounts that don’t have an associated Facebook account.
Now it should be noted that Account Kit is free for up to 100K confirmation SMS per month; however, most sites/apps will quickly exceed that if they achieve any prominence, whatsoever. Also, users must continually re-provide their phone number/email and receive the code each time they log in. This is not a one-button login for subsequent logins, after the initial registration (unlike the Facebook login, Mobile Connect, and other one-button logins). Some of the initial press was comparing Account Kit to Twitter’s Digits – a similar solution; however, Digits also provides some higher-security options such as a 2nd-step verification code among others.
Facebook Account Kit can be characterized as the 2nd-part of two-factor authentication without the first factor – something you know and only you know – a password. This is not a secure login. I’m a little concerned that people are swapping convenience for security. Imagine a non-passcode locked phone with numerous apps with accounts set up using Account Kit. Information in those accounts or associated with those accounts would be wide open, should that un-secured mobile device be stolen. If app/website providers are going to offer this, they are also vulnerable. Account Kit, is at best, one-factor authentication – leveraging something you have – the mobile device. In today’s environment of privacy and security, I’m surprised this solution is as vulnerable as it is less secure than a user-id and password. Just because both of these password-free login solutions send a one-time code via SMS (a very valid side-channel for true 2FA solutions), doesn't make them a full two-factor authenticated and secure login solution.
That said, the vulnerabilities are not limited Account Kit. As noted, Twitter Digits is quite similar; however, it too has the same issues should an app/website not implement additional security measures. These days, if any site or app requires account creation where something is for sale, that means that account should be locked down tight – protecting the account which might contain financial instruments to enable purchasing as well as private information about the users. These password-free, single-factor login solutions are convenient, but they lack significant security and can end up harming the user and the business that implemented it.
After install the Agentry SAP ERP backend following the guide below:
Guide Part 1： https://scn.sap.com/docs/DOC-71310
Guide Part 2： https://scn.sap.com/docs/DOC-71321
Guide Part 3： https://scn.sap.com/docs/DOC-71246
Guide Part 4： https://scn.sap.com/docs/DOC-71247
You may want to start your journey to play with the Agentry client.
However when you try to transmit for the first time, you may have the error as below:
"com.syclo.agentry.BusinessLogicException: No personnel id found for user XXX"
There is a way to bypass the personnel ID, you can refer to the SAP KBA https://launchpad.support.sap.com/#/notes/2287101 for more details.
But if you do not configure the personnel ID in your backend system for your mobile user, then you can never get the work order you created in the backend system to your device.
I draw a picture to show the relationship about the personnel ID.
In the picture, you can see the most important thing to get the work order on device is that we have to map the personnel ID and the user ID to let the device know the work order is sent to him not others.
I will give you a simple example to show the difference between the personnel ID and the user ID.
The User ID is like your name in the company, it will be printed to the card for you to access the door of the company. Like in the Agentry backend, the user ID is used to log into the system and also configure the system.
But in your daily work, you may have an identify number, the number is the real one that represents you in your work. In Agenty, it is not enough only getting the user ID, you also need a personnel ID which is generated by hiring operation. The ID is used for everything related to the work. You have to map your user ID to your personnel ID, so that the device will know they represent for the same person.
In the picture, you can see the number from ① to ⑤. That is the order to configure the system. I will give more detail information during the configuration of each part.
Part ①: Hire an employee using TCode PA40.
Here are the two SCN thread that related to this part:
Choose a number and click on “Hiring”. After input the needed information, you can get your personnel ID which is “17”.
(There is a range of the number and you can set. Please refer to the SCN link for more details.)
Part ②: Assign the employee you hired to existing user using TCode HRUSER.
(Your mobile user or backend user)
Choose the one in the red box.
Just click execute button and you can choose the user you want to assign.
Now you can transmit with your client and you will not see the error again.
But if you want to get the work order, please go ahead.
Part ③: Create a work center using TCode CR01.
Please remember to choose the personnel ID in the HRMS part.
This means your user has been added to the work center now.
Part ④: Create a work order using TCode IW31.
Please remember to choose the personnel ID of your user and the work center that your user is in.
Then click on release.
Part ⑤: Maintain the parameters in the user profile using TCode SU3.
Now you can transmit on your device or WPF client to check whether you can get the work order or not.
Please note, it is tested in my environment and it is almost the minimum requirement of the configuration. Please check more if you need more function.
The March/April Mobile Secure/Afaria client has been released to the Google Play store and is now available. The client build is 9986
PLEASE NOTE: The Afaria app has been renamed to "Mobile Secure". MS enrollment processes will direct users automatically to the correct client on Google Play. More details will be made available in the What's New for the release section on Google Play.
Latest Android client updates for SAP Afaria are listed in the following KBA: 2297852