1 2 3 67 Previous Next

SAP for Mobile

997 Posts

The mobile security team has been investing significant time and engineering effort into enhancing the SAP Mobile Secure enterprise mobility management portfolio, making it the ideal solution to manage and secure mobile apps, content and devices. As a leader in enterprise applications, SAP has now further expanded this portfolio with the addition of a mobile application management (MAM) offering to expand our app-centric focus. This technology, referred to as Mobile Place is a brandable, localizable and secure enterprise app store that makes it easy for companies to simply and proactively push their mobile apps into the hands of employees, business partners and consumers.

This new app management capability was included in the latest release of SAP Mobile Secure and was announced at Sapphire. It has been available since late June and is already gaining applause from our customers. Our top priority with this new enhancement is simplicity - making the mobile app experience as easy as possible for all mobile users. The technology delivers apps, services and content in a simple way to both managed and unmanaged mobile devices. For managed users, it identifies when their device is out of compliance and directs them to download the appropriate mobile device management (MDM) solution before they can download any apps (note that MDM solutions include SAP Mobile Secure's own cloud based MDM offering, our on-premise SAP Afaria product or other MDM vendor products).

The best news is that Mobile Place is included at no additional cost with the purchase of SAP Mobile Secure in the cloud. And that's only 1 euro per device per month.

For IT admins, Mobile Place it is the single destination to publish, manage and analyze apps, content and profiles -- including any MDM, enterprise mobile management (EMM) and mobile content management (MCM) offering. For end users, it is the place to easily discover and download relevant apps and set up related services such as network access, email, identity and more.

The press release quoted Senthil Krishnapillai as saying "With the expansion of the SAP Mobile Secure portfolio on both managed and unmanaged devices, we are delivering the best mobile experience for our customers for consuming enterprise apps. For example, a large beverage company will use mobile place to make their mobile apps easily accessible to distributors, and a healthcare provider can provide a single mobile app to authorized patients. The discovery features of mobile place help ensure any corporate developed or licensed apps can be easily configured."

Mobile place provides a secure, multi-channel central hub that offers self-service capabilities to best serve employees, business partners and consumers while reducing IT support costs. This solution brings the management of content, apps and devices together in a seamless workflow for IT admins, application developers and end users.

So far the response has been fantastic - you can see for yourself by watching the short video. Check out the free trial of SAP Mobile Secure. It is available today at www.sapmobilesecure.com.

The UX Explorer is a tool that answers questions relating to user experience and user interfaces at SAP. It provides information that allows you to clearly understand the availability and capabilities of UX innovations, UI technologies, and services. The UX Explorer is committed to providing you with the most up to date UX information and the addition of the SAP Fiori launchpad section is proof of this commitment.

 

The launchpad section can be accessed directly from this link or you can access the UX explorer homepage and navigate to Explore Items -> UI Clients -> SAP Fiori launchpad, alternatively you can use the search on the homepage. On the launchpad page you will find a summary, list of features, screen shots and much more. I encourage all of you to check out this tool and benefit from the power it provides.

 

LP_UXExplorer.PNG

 

For those of you interested in learning more about the UX Explorer tool please visit this page in SCN and watch the video recorded by Juergen Jakowski.

In a previous post, I've already discussed the fact that SAP Fiori is not a mobile platform, but a user experience platform with a mobile-first framework.  Understanding this is even more important once you move past the strategy and architecture steps, and into a deployment exercise.

Choosing proper use cases for SAP Fiori is critical.  Fortunately AND unfortunately, Fiori provides standardized, out of the box feature sets delivered as standalone applications.  At first blush this seems great, because you can deploy a new experience to users, already integrated with the backend, within days or weeks.  The ability to achieve rapid success is realistic.  However, doing so with the wrong use cases can lead to frustration, which breeds rejection.

You absolutely must select appropriate use cases for the standard apps, plan to extend the Fiori toolset when needed, and ensure the user communities you engage for early projects are up for the challenge.

 

It is realistic to deliver Fiori solutions quickly with the right approach to delivery.
It is realistic to deliver Fiori solutions quickly with the right approach to delivery.

 

Use Cases for Standard Fiori Apps

In my earlier post on SAP Fiori strategy, I pointed out Fiori's core strengths:

  • You can derive value quickly with standard apps
  • No native development skill sets are needed in-house to support it
  • Responsive/Multi-device is a cornerstone
  • No need to deal with app submission
  • Built to support extending the platform with minimal effort

 

When choosing which of the numerous standard apps (190 in all for waves 1 & 2) to deploy, it makes sense to adhere to the lightest, simplest use cases possible.  So what does that mean?  It means that to succeed with standard Fiori apps, you need to play to the solution's strengths.  Consider this checklist when looking at use cases.  Compare the projects you're considering to this criteria:

  • First, can you boil the use case down to a task, rather than a comprehensive "set of functionality"?
  • Are you addressing a task that should be simple and straightforward? (regardless of how SAP does it now)
  • Does the task require minimal data moving back and forth? (field data, contextual data are okay)
  • Is the user base always connected when they want to perform this task?

 

In order to succeed with a standard Fiori app, the project use case needs to be a "Yes" for every criterion I just listed.  In addition - and this is the most important part - the standard features have to match up with the requirements for the use case.  And if they don't - you will need to amend the use case or consider extending Fiori.

Extending SAP Fiori

Great news - SAP Fiori, as a user experience platform, was designed to be extended and enhanced.  It's so much simpler to enhance than SAP Portal or any of the other past UI technologies that SAP or competitors have released.  Most of our clients select at least a small amount of enhancement, if only to simplify a few fields or implement branding.

The most important thing to ask yourself when you begin a use case is: "Will the out-of-box functionality drive the users to do what they want to do?"  The phrasing of this question is deliberate - because functionality is key, but Fiori is all about the User Experience.  You want to equip the user, but also aid and encourage the user to use the new app.  So, if the standard app doesn't completely pass muster because it's one screen too many or the fields aren't in the right order, you can make those changes without breaking the bank.

There are many ways to extend SAP Fiori, and we do them all.  I'll talk more about customizing SAP Fiori and what it takes in the final post of this series.

User Groups

I'll define "User Groups" as the community of users that you will focus on for the deployment of any Fiori apps.  Because Fiori is task-based, not a comprehensive "module", you have the opportunity to deploy multiple specific apps based on the user's identity context.  This means a simpler, more relevant experience for each user, rather than muddying up their day with a bunch of confusing extra features that don't matter to their role.

That said, considering user groups is nearly as important as the use case itself.  That's because SAP Fiori is so different than the traditional SAP applications some old school SAP users may be used to using, yet for other user groups, it's much more in-line with the marketplace (including Salesforce.com, and other tools).

At a very minimum, your target groups need to have a very well-defined role.  This is imperative, as the solution is focused on tasks, so you have to be able to break down what you're delivering to one or a group of tasks rather than the traditional functionality mix.

Secondary to that, it will help if you decide if you want to deliver first to user communities with familiarity with SAP systems or new non-users.  Accommodating the non-users allows you to bring in groups that may be "rogue" on other systems, but you may determine that with the early projects you want to serve the experienced staff who've been waiting for improvements.

It's also beneficial to look for user champions to help with the solution deployment, because though it should be simple to use, any project benefits from evangelism.

Finally, you need to be sure you educate users on the fact that the Fiori experience is one that can easily be enhanced over time.  Unlike traditional SAP projects, this doesn't have to take months or years - enhancing or creating custom apps can be completed in just weeks.  I'll cover that in my final post in this series, or you can contact us directly to talk it over.

Looking for the entire SAP Fiori overview?  Watch our video on SAP Fiori by SAP Mentor Pete Lagana here.

There seems to be a lot of confusion on what Fiori is, and what the benefits are.  Since the recent Sapphire announcment that Fiori is free, we have gotten a lot of questions from our customers.   This blog will attempt to clear up any confusion on Fiori, and provide a high level overview on benefits, negatives and why SAP customers should care.

 

So what is Fiori?


Fiori is a collection of applications, pre-delivered by SAP, that cover the most common business scenarios across multiple modules of SAP.  Some examples of these applications are:

 

HR: Time Approval, Leave Request

MM: PO Approval, Order from Requisition

CRM: My Accounts, My Contacts

 

You get the idea.

 

Fiori is commonly misconceived as a Mobile Solution.  Yes, Fiori can run on Tablet and Mobile Devices, but the applications also run on Desktops.

 

The Good:

  • Finally, a solution that bridges the gap between Desktop and Mobile.  Prior to Fiori, SAP mobile users were forced to use a different User Interface on their Mobile devices and Desktop
  • Fiori design is clean, simple and easy to use.  For anyone who has ever been forced to use SAP GUI you will know what I mean.  When building Fiori, SAP took a simplistic approach, and only included the relevant fields and functionality needed to complete the task.
  • Customers now have a modern user experience.  There have been a mishmash of UI products released by SAP in the last decade: Web Dynpro, Web UI, Personas; but none of them solved the issue of not having a consistent user experience across devices and creating a UI that does not make users want to pull their hair out.
  • The best part of Fiori is the ability to customize it and create applications from scratch that fit business needs.  Customers now have options:

          1) Extend and Enhance the pre-delivered SAP applications to fit business needs

          2) For scenarios not covered by pre-delivered applications we can create fully customized Fiori applications.  These look and  feel the exact same as the SAP delivered ones.

 

The Bad:

  • The initial installation and configuration can be a bit tricky.  SAP documentation seems to reside in multiple places, making it somewhat frustrating to get it up and running.
  • The enhancement framework for pre-delivered SAP applications is somewhat limited.  If the customer wants to do anything more than add or remove fields or shift some of the controls around I recommend building a custom Fiori application
  • You must complete configuration steps for each individual application.  These do not take too long(depending on the application), but in short; deploying all Fiori applications in a week isn’t going to happen

 

Wave 2 of Fiori applications is just scratching the surface of the potential.  SAP has made heavy investments in SAPUI5 technology and integrating it with common SAP use cases.  See the Amazon-like shopping cart for SRM and HR Renewal apps and the Fiori River RDE which connects UI5/Fiori to the Hana Cloud Portal.

 

The bottom line is that Fiori is well worth the time investment to get it installed and running in your landscape.  The capabilities, and functionality will only continue to grow and users are demanding a way to complete business tasks on the go.  SAP has finally caught up to the rest of the world in providing a next generation User Experience with no additional license cost, the verdict: Your users will thank you.

Your first reaction here is likely one of stupefaction, which is completely understandable - SAP does have mobile solutions for IBM Maximo because of the Syclo acquisition in June of 2012. Syclo got its start working with Maximo backend systems from its first customer, Rush Memorial Hospital, in Chicago. SAP continues to develop mobile apps for Maximo systems including Work Manager, Inventory Manager and Auditor.

 

The now SAP mobile apps for EAM (enterprise asset management) have helped hundreds of customers to see these kinds of improvements in respect to their assets*:

  • Downtime and production reduced delays by 20–30%
  • Maintenance backlog decreased by up to 60%
  • Preventable failures minimized by up to 90%

 

Want to learn more about the SAP Mobile Solutions for IBM Maximo? Join us at a Maximo User Group (MUG) meeting:

 

      • Aug 3 – 5, 2014: Mountain West Maximo User Group 2014 Summer Meeting
        The MWMUG hosts annual summer and winter meetings.
        Each meeting consists of user presentations, an open forum/roundtable, and networking opportunities.Meet with us at our booth during “Vendor Night” on Monday, August 4th at 6:00 p.m. to learn the benefits of mobilizing Maximo, hear about the latest Maximo customer product roadmap, and see live product demonstrations. Register to attend now.

 

 

      • Sep 29 – Oct 2, 2014: Maximo Utility Working Group Fall 2014 Workshop
        The MUWG Spring and Fall workshops are the premier events for Maximo users in utilities. The Fall workshop themes this year are “Sharing Maximo Experience” and “Extending Maximo with Mobile and Other Applications”. The host for the Fall workshop is SAP customer Salt River Project (SRP). The event has presentation sessions for new and experienced Maximo users as well as Maximo certification opportunities. Meet with us at our booth during Vendor Night on Tuesday, September 30th at 5:30 p.m. to learn the benefits of mobilizing Maximo, hear about the latest Maximo customer product roadmap, and see live product demonstrations. View the full agenda
        here. Register to attend now.

 

*Source: SAP Customer Reference Statistics

Hello SAP Mobile Platform Community,

 

 

I am very pleased to announce that SAP Education has just released a new global instructor-led course that is designed to focus on the new administration features of the SAP Mobile Platform 3.0 and latest support pack - MOB10: SAP Mobile Platform 3.0 (SP03) Administration.  The course is a 2-day class is targeted at system and platform administrators, developers with an administration knowledge requirement, and useful to solution architects. However, it is also valuable to anyone with SMP 3.0 system administration responsibilities. Please note that the same instructor-led content will also be available as an eLearning (MOB10e) in a couple of weeks. The eLearning contains SAP WPB exercise simulations, videos of talented SMEs discussing each topic, assessments, and demonstrations of each exercise and much more. You can now register for MOB10 as an instructor-led class near you by visiting the SAP webshop or purchase the eLearning version of the course when it is available (search for MOB10e on the SAP Education webshop).

 

 

What is covered in the MOB10/MOB10e course?

 

For starters, you will learn how to plan, prepare, install and administer SAP Mobile Platform 3.0 SP03. You will explore the platform's administration architecture, how learn how to design and implement a configuration that best meets your organization's needs, as well as learn ow to perform standard every-day administrative tasks such as deployment and configuration of mobile apps developed on Agentry, Native device platforms, Mobiliser, Hybrid and Kapsel-based apps. You will continue to learn post deployment configurations, registration of application users, and so on. Use of the new SMP 3.0 SP03 Management Cockpit will be a major part of this course.

 

As an example of some of the new features covered in MOB10, let’s look at the packaging and deployment approach between pre-SMP 3.0 and SAP Mobile Platform 3.0:

adm1.jpg

 

 

Firstly, note that SAP Mobiliser applications were packaged as customization solutions using the SAP mobiliser frameworks. SAP Agentry (a.k.a. metadata-driven) apps, in turn, had their own packaging and deployment approach in pre-SMP 3.0. With SAP Mobile Platform 3.0, SMP and Agentry packaging and deployment are consolidated into a single approach:

 

adm2.jpg

 

In SMP 3.0, all services will be packaged and deployed via the provisioning system - Equinox P2 Provisioning.  Using the SMP P2 feature, administrators can make provisioning for the packaging process more formal, repeatable and therefore re-usable. A section on migrating Agentry Apps created prior to SAP Mobile Platform 3.0 is also included in MOB10 to help you take full advantage of the new packaging and deployment features of SMP 3.0.

 

Another important topic for system and platform administrators is High-Availability (HA) and Disaster Recovery (DR) of your mobility landscape. The course devotes quite a significant amount of time discussing HA and DR in great detail. You will learn the most effective high availability and disaster recovery scenarios to ensure that all your applications running on SAP Mobile Platform 3.0 continue to run with the utmost minimum downtime. The course discusses stand-by scenarios as well, to improve stand-by & redundancy and therefore reduce or even eliminate the chances of any downtime or data loss at all.

 

These are just a few topics that each administrator will learn in the MOB10: SAP Mobile Platform 3.0 (SP03) Administration course. Be sure to check out the description and look for a public schedule near you. If you cannot find a schedule, be sure to use the Contact Us feature on the webshop and make a request to add this class to the schedule. For those of you who are already subscribers to SAP Learning Hub, know that the course material will be available in SAP Learning Hub for your peruse, and in about two weeks so will the eLearning version. But you have to be a full subscriber of the SAP Learning Hub to access the content.

 

 

SAP Mobile Platform Education in the SAP Learning Hub:

 

SAP Education offers multiple delivery formats and learning solutions. If you find that attending a live classroom poses a time and financial challenge, SAP Education introduces the all new SAP Learning Hub, the on demand learning platform from SAP. All SAP course content is also available in the SAP Learning Hub, including all new SAP Mobile Platform courses. If you are not sure that SAP Learning Hub is the right solution for you, SAP Education offers a FREE access to select courses via SAP Learning Hub, discovery edition. In the free edition, you can explore and assess the free content available to you. Get started– register for free access to SAP Learning Hub, discovery edition, and begin to experience the benefits for yourself. Click here to register

 

 

Other Related Blogs and Resources:

 

  • For anyone interested in SMP 3.0 developer training, see this blog.
  • For solution architect training, click here.
  • For SAP Fiori and SAPUI5 training, see this blog.

 


Thank you and wishing you all success with SAP Mobile Platform 3.0.

 

Best regards,

Vivaldo

Considering where SAP Fiori fits depends on how you define it within your technology footprint.  In an earlier post on the SAP Fiori strategy I explained that while Fiori is certainly a solution to many mobile challenges, it's not a mobile platform at its core.  It's a user experience platform with a mobile-first framework. 

It's still a great solution for mobile, but it can be so much more.  However, I'll save the use case discussion for another post on choosing SAP Fiori use cases.  How you are planning to use it doesn't change how you'll need to work SAP Fiori into your technology footprint.  Here I'll explore Fiori as part of your architecture footprint, and part of your mobile software footprint.

SAP Fiori as Part of an Architecture Footprint

If you have a traditional SAP landscape, you're dealing with multiple environments.  Your first decision is to what degree you want to deploy Fiori.  In our experience, we generally lead with either a standard install (full environment) or a "light" install - for just one environment.  This is because deploying Fiori throughout your entire landscape is not the best option if you're just running a feasibility pilot, as an example.

The great news is that because there are minimal pre-requisites to installing Fiori, Gateway being one, we can usually stand it up in a matter of days for a test environment.  Throwing in your Dev and Prod environments extends that a bit, but it's still not a huge time consumer.  Getting Fiori up and available is something we can realistically achieve in days or weeks, even for a more complex environment.

At a minimum, you need to be sure you either have installed or are ready to install ABAP, Gateway, and UI5, and of course, ERP Business Suite, other backends that you want to leverage like CRM, SRM, or PLM.

 

Excellis Approach to SAP Fiori Install
Excellis Approach to SAP Fiori Install

 

From a backend standpoint, be sure that you know which backends will be required for the apps you are choosing for your initial use cases (see my thoughts on use cases), especially if you're choosing a custom or enhanced app.

The good news is that Fiori offers out of the box connectivity to SAP backends, so choosing to connect to future backends will be something we can achieve quickly when the time is right.  The even better news is that there are truly no limits to what you can connect to Fiori.

if you want to connect it to SalesForce or some other application, that is possible.  Did I really just say that?

Sure did, but it's not likely something SAP will encourage, of course.

SAP Fiori as Part of a Mobile Footprint

I'll put my feelings on Fiori as a user experience solution aside, because the pressing question for most is how it is going to fit into a mobile strategy.  We have a great matrix slide that compares Fiori on a number of different levels to other mobile technologies, but I'll keep it a bit briefer than that here.

There are three different approaches to integrating Fiori into your mobile strategy.

Fiori First

Leading with Fiori is most suitable for anyone who hasn't already purchased SAP Mobile Platform (SMP) or legacy mobile licenses - that is obvious.  It's a way to test out the "free" product to see if you'll need to spend money.  However, this scenario is the most likely to fail early if the wrong use cases are chosen.

Use case is absolutely imperative here.  Read my next post on choosing the right use case for more details, but at a minimum, the use cases have to meet the following criteria:

  • Users are always connected
  • Roles are clearly defined
  • Limited data processing is needed
  • Use case is simple

 

I'm not suggesting that Fiori can't meet more complex use cases.  In fact, I'll talk about that more in the final post in this series.  However, if you're looking to deploy Fiori as a pilot for enterprise-wide mobility, you have to get a few wins under your belt, and the simpler, better defined scenarios will render the best results.

Hybrid Footprint

In reality, a hybrid approach to mobile delivery is going to be the solution that best fits most companies.  Why?  Because of the limitations I laid out previously.  The limitations of Fiori are beautifully supported in the SAP Mobile Platform, as one option.

For example, consider the connectivity limitation.  Odds are, if you have some users that are infrequently connected (like field service), you also have some users that are only disconnected in very rare situations (executives, office employees).  In that situation, you have an opportunity to deploy Fiori for the connected users (as long as they meet the other criteria) while only licensing SMP for the disconnected users.  This saves money in licensing, and allows you to really utilize the strengths of each solution.

However, there are some major challenges to this approach.  For one, you'll be supporting multiple applications and experiences, which certainly costs.  Also, you will have to deal with the shared use case obstacle - when there is a use case shared across both connected and disconnected users, how will you deploy that use case?  Just on Fiori?  Or twice, once in each product?  This is something you'll have to deal with early.

Hybrid Solution

A hybrid solution approach does not differ in licensing or technology from hybrid footprint, but it differs in delivery.  Consider this an advanced approach that may address some unique situations.

Hybrid solutions are ones that allow us to leverage a native or SMP application with Fiori-delivered content.  What that means is that we can utilize containers within native or SMP apps to deliver other Fiori apps or features.  The two real challenges this solves are the "build once" challenge, in which you have features that you want to deploy and manage within Fiori, but you have users that need to utilize the SMP capabilities, and the "UI" challenge, in which you want to resolve some major usability issues by leveraging the Fiori themes.

This is an advanced approach, and requires a strong strategy and support system.  However, it's a method you can use if you're targeting the hybrid footprint for your enterprise.

As with any technology strategy, though, the use case(s) will be pivotal to success.  I hope you'll read more about selecting use cases in my next post, or get in touch with us to talk it through.

Want even more technical information?  Watch the SAP Fiori video by SAP Mentor Pete Lagana now.

John Wargo

New Apache Cordova Book

Posted by John Wargo Jul 18, 2014

Note: Shameless Self-Promotion Follows

 

Last week, my publisher released my latest book: Apache Cordova API Cookbook (www.cordovacookbook.com). The book is available in print form from Amazon.com, InformIT.com and several other online retailers. For those who like electronic books, you can buy an e-book version from those vendors as well as Apple iBooks, Google Play Store, Kobo and more. You can learn more about the book and access links to the book in the different online stores at www.cordovacookbook.com.

 

acac-cover-320.png

 

In 2012 I published PhoneGap Essentials (www.phonegapessentials.com). The book covered PhoneGap 2.0 and delivered complete coverage of everything a developer needed to know to get started with PhoneGap development. At about 300 pages, it covered the topic pretty thoroughly. If you look at PhoneGap Essentials, the first half was all about the tooling available for PhoneGap development, and the second half was a complete study of the PhoneGap APIs.

 

As the book was going to press, Nitobi was acquired by Adobe and PhoneGap eventually became known as Apache Cordova.

 

In December 2014 I published an update to PhoneGap Essentials called Apache Cordova 3 Programming. This book covers Apache Cordova 3.0, PhoneGap 3.0 and was essentially a rewrite of the tools part (the first half) of PhoneGap Essentials plus a 50-page chapter on the Cordova APIs. Things had changed so much between PhoneGap 2 and Cordova 3 that an almost complete rewrite was needed. Unfortunately, this book is only available in e-book format; you can find more information about the book at www.cordovaprogramming.com.

 

Apache Cordova API Cookbook is essentially a rewrite of the second part of PhoneGap Essentials. The book takes the 150 pages of API coverage from PhoneGap Essentials and expands it into an entire 300-page book on the topic. There is a short introduction to Cordova (Chapter 1), then the entire rest of the book is dedicated to the Cordova APIs. Where I covered all of the APIs in PhoneGap Essentials, in the Apache Cordova API cookbook I expanded the coverage to include more sample applications and added more capabilities to the sample applications. The book includes complete source code for more than 30 Cordova applications.

 

When you bundle Apache Cordova 3 Programming together with Apache Cordova API Cookbook, you get almost 600 pages of coverage for the topic. No other books provide the same level of detail on the topic.

 

If you’re doing any Cordova or PhoneGap development and need help getting started (or just want access to everything I know about the topic) please pick up copies of Apache Cordova 3 Programming and/or Apache Cordova API Cookbook. I’m planning on presenting at d-code in Las Vegas and Berlin, and I’m hoping to have a few copies to give away at my sessions.

Over the last few weeks, the world remained riveted to the various games of the World Cup 2014.  Some were early disappointments such as Spain; however, many were surprised just how far their own country made it into the final tournament.  Social media and mobile engagement were also big winners in the 2014 World Cup.  These channels are immensely popular today and will continue to grow in influence as they are now part of most people’s daily lives.  Both Facebook and Twitter had set usage records during the World Cup final.  In fact, the Wall Street Journal article noted that Twitter beat its own record of 580,166 Tweets per minute during Germany’s defeat of Brazil in the semi-final by reaching 618,725 tweets per minute during the Argentina – Germany final.


SMS messaging was also quite prevalent throughout the World Cup, but more so around the games.  For the 2014 World Cup, we took a look at each game in terms of SMS traffic interest.  For each hour of the day, each minute, there are, what we call “normal” SMS traffic patterns.  For example in the 18:00 hour, a particular country may normally send x number of messages; likewise, that can be broken down in the SMS per minutes.  While SAP Mobile Services doesn’t see all of a country’s SMS traffic, we certainly see enough to ascertain statistically relevant movements of SMS traffic.  Given that billions of SMS messages move around countries and between countries daily, this clearly shows that SMS as a person-to-person communications medium is still completely relevant and that it will be for the foreseeable future (I am not so deluded as to not admit that SMS has taken a large hit in many markets due to OTT cannibalization; however, for many people, somehow SMS texting still seems more reliable).

 

By reviewing our messaging statistics before, during, and after the games, we were able to determine the percent above normal spikes in SMS traffic as a result of the World Cup games.  This gave rise to our Textiest Moments of World Cup 2014 infographic:

Textiest Moments Infographic - v2.png

 

Click on the image to expand it.


Interestingly, but not surprising, messaging traffic only spiked in countries whose teams were playing. For example, even though Germany vs. Argentina generated world-wide interest, the message spikes were only pronounced for those two countries.  If we start with an estimate of 63 billion SMS messages sent from Germany in 2014 (extrapolating from a Portio Research report) and then do some rough calculations, Germans sent around 1.2 million SMS messages in the minute following their World Cup win (with a normal minute generating approximately 120K messages).


Like Twitter and others, SMS very much tracked the game’s progress.  In the graphic below, for the game between Germany and Argentina, we can see the extreme reactions to the scores and the end of the game. Following the game is a wind-down as people discuss the results with friends and family.

Germany vs. Argentina - DE 1-min traffic.png

Click on the image to expand it.


In another example, we overlaid times when yellow cards were issues and the teams’ substitutions along with the goals. In this next example between Argentina vs. Switzerland, the SMS pattern clearly showed increases in traffic immediately before, during the half, and before extra time.  Events such as yellow card issuances and substitutions did not heavily influence the traffic – likely because people were paying attention to the action on the field and not texting.  In fact, if you look back up at the Germany vs. Argentina SMS game graphic, you can clearly see the increase of traffic during the half and at the break before the extra time.

mobilesms.png

Click on the image to expand it.

 

A few observations come to mind.  First off, people only text about the game when there is a definitive break in the action.  Unlike social media, where tweets are sent or Facebook postings made to provide an ongoing narrative or commentary (e.g. one -to-many) about an event, SMS texts are sent to discuss the topic with another individual.  The engagement model is different.  Additionally, in our SMS statistics, we don’t filter out the “background noise” -- meaning that there are always unrelated texting going on.  That typically accounts for the “normal” traffic levels and that’s why by looking at the deltas from normal – especially huge ones, you can ascertain the level of reaction.  I will note that some countries had very little SMS increases at all. France was one – the games seemed to not influence traffic patterns away from their hourly norms.  Their SMS traffic actually dropped around the games in some cases.  I’ve not yet come up with why that was.  The US SMS traffic around the games was minor – averaging around 9-10%.  But that is because many in the US simply did not pay attention to the World Cup, but still – that is nice to see and significant.  Four years ago, there would not have been that much of a rise (and there
was much less in terms of competing media).  But this does tell us that SMS-based texting is still extremely relevant and still well used.

 

Please follow me on Twitter: @wdudley2009

I recently came across this issue at one of our customers - thought of sharing this in SCN,

 

FIORI launchpad runs perfectly in Language = EN, when I change the language to DE,ES,RU.. it dumps on the launchpad with a lot of errors directing to PAGE_BUILDER_PERS, RFC Error, Error inserting Duplicate record in table, etc.

 

For such issues perform the following quick checks to see if the Chip texts are available in the required language

 

1) SE11- > /UI2/CHIP_CHDRT

2) See if there are entries existing in the table for the desired language

3) If there are no entries,

4) Logout and Login in the language you have an issue (ie login in Russian, German)

5) Run the report program /UI2/CHIP_SYNCHRONIZE_CACHE

6) Go back to the table /UI2/CHIP_CHDRT - see if the entries are generated for the desired language

7) Retest the App

 

Perform this for all required languages.

 

Cheers,

Best Regards

Babu Ganesh V

 

Customer Experience Group

SAP Labs India,

Bangalore

Everyone is talking about the fact that Fiori is now included for maintenance customers.  Many are wondering about the impact this has on SAP Mobile Platform and other native products.  Others are talking about the recent video SAP Mentor Pete Lagana did overviewing SAP Fiori.

I want to point out something that a lot of people aren't discussing.  While SAP Fiori is certainly a solution to many mobile challenges, it's not a mobile platform at its core.  It's a user experience platform with a mobile-first framework.  Most people are looking at it as a mobile platform, and while it solves many mobile challenges, considering it just a mobile platform is short-sighted.  It doesn’t do justice to the product or your mobile strategy.

 

Here's an example of an Excellis custom Fiori app that works across platforms - that's the responsiveness at work.
Here's an example of an Excellis custom Fiori app that works across platforms - that's the responsiveness at work.

 

Fiori is a user experience toolkit, and thinking about it that way will help you better understand where it fits.  As a product, it was designed with the following tenets in mind:

  • Role-based (provide simple entry-point for user/multiple tasks)
  • Responsive (available on any device with minimal intervention)
  • Simple (lots of context based on user, quick to complete tasks)
  • Coherent (consistent & brandable)
  • Instant Value (make it quick to deliver on user needs)


Now, that certainly sounds like it could be the answer to a lot of things.  Yep, could be.  It could also fall short in some ways, and it certainly doesn’t fix all problems.  Let's take a look at how Fiori stacks up to other technologies, because before you even think about adding Fiori to your technology footprint, you need to decide if you're going to use it as a part of the big or little picture.

SAP Fiori as a User Experience Tool

Today when you talk about applications, you’re generally talking about what it does - what the functions are.  SAP screens become very complex very quickly because the functionality is so dense.  Most SAP products are extremely functional, built to mark the checkboxes for clients and on RFPs and so they become very complex from a user experience standpoint.


So how is this relevant?  It matters because Fiori is a strong option to battle the widespread adoption problem, and although SAP knows this, the message has gotten confused.Fiori is based on delivering tasks to specific roles.  Each application is of a module and more like a specific workflow to achieve any given task.  Rather than delivering an "expenses module" with many features, there are numerous task-based applications exposed based on their relevance to a user's role and security.  Fiori also gives you one entry point, even if traditionally a user's responsibilities spanned multiple modules or programs.


A product like Fiori provides a toolkit that you can use to bring on user groups that were resistant to SAP products before.  As an example, consider the most resistant staff you may have - CRM users.  They may be resistant to CRM for many reasons, not least of which that it's hard to learn.  This is a key group that could benefit from Fiori-delivered CRM features because the users are often diverse with many different roles, and well-defined responsibilities.  Often times, these users will also benefit from the mobile-first approach that Fiori brings with it.To be successful with leveraging Fiori to drive adoption, you'll need to be very focused on the use case.  Think about tasks, not modules.  Align each Fiori app you deploy with a specific problem you are solving for the user.  Be sure you know if the standard/out-of-box app is going to work seamlessly, or if you will need to enhance it.

SAP Fiori as a Mobile Tool

Though Fiori may be an excellent solution for enterprise-wide user experience, that's not likely the reality for most.  Most companies want to know how Fiori fits as a mobile solution.In the mobile marketplace, we know that Fiori is best suitable for certain scenarios.  Consider Fiori's core strengths:

  • You can derive value quickly with standard apps
  • No native development skill sets are needed in-house to support it
  • Responsive/Multi-device is a cornerstone
  • No need to deal with app submission
  • Built to support extending the platform with minimal effort


Overall, Fiori as a mobile solution checks out pretty well.  It allows you to develop once for all devices, and extending the product doesn't require the specialized consultants that other SAP products do.  When we compare it against things like the SAP Mobile Platform, it offers superior UI capabilities because of its responsiveness, and equal out-of-box connectivity.However, we also know that Fiori has some important shortcomings.

  • There is no offline support; users must be connected
  • Because of connectivity, there are heavy device data processing limitations
  • Designed for task-oriented use cases, not as a comprehensive module

 

If these limitations are important to your mobile strategy, products like SMP and even native applications can fill the gaps.  Using a hybrid footprint for your mobile solutions is a very viable strategy and allows you to play to each product's strengths.  However, it also creates some challenges that you'll need to consider, and I'll discuss that in my next post on how SAP Fiori fits into your technology footprint.

Overview:

SAP CRM Service Manager is designed to automate workflow and improve service. It connects technicians with the data stored in the SAP CRM system so they can better manager customer service requests. With SAP CRM Service Manager mobile app, you can maximize efficiency and effectiveness of your field technicians by providing them access to relevant and real-time information and tools. The app connects to the SAP Customer Relationship Management (SAP CRM) applications and enables status updates, last minute changes, and accurate data capturing to help achieve higher first-time fix rates.

 

This release includes new functionality and features like:

• Manage service orders and create confirmations in real time

• Record status, materials, problems, actions, expenses, and customer signatures

• Generate account factsheets and create service confirmation for serialized products and add surveys

• Get 360 degrees customer view using Account factsheet

• Display customer and contact information in regional formats

• Support all note types created on SAP CRM Service backend

• Upload and Download Attachments for Service Orders and Confirmations

• Display equipment or install base listings. · Display entitlements and contract or service history

• Display Assignments on Calendar

• Create / Edit non-order ibase for Service confirmation

• View Serial number for iObject / Equipment

• Backend integration with MRS

• Support on SMP 3.0 Platform

• Additional Languages Support (German, Italian, Japanese, Korean, Russian, Simplified Chinese, Spanish , Portuguese, French, Hebrew, Hungarian)

 

 

Vehicle Stock Component

The Vehicle Stock add-on component for SAP CRM Service Manager is an optional component that allows technicians to view current stock for their vehicle as well as external stock. They can transfer stock to and from their vehicle in preparation for field services. The Stock component integrates into ECC.

  • It enables the Service Technician to view stock within their Vehicle as well as stock with other users.
  • Technicians can control his own vehicle/trunk stock like look-up/search products for current inventory,
  • Technicians can transfer from his vehicle stock into another technician
  • Transfer stock from external trunk/technician.
  • Search and receives STO's.

 

Deployment scenarios:

  1. SAP CRM Service Manager 4.1
  2. SAP CRM Service Manager 4.1  with Vehicle Stock component

 

Service Manager 4.1 release notes

 

2028339 - Software Release Note - SAP CRM Service Manager 4.1

1985589 - Release Restrictions Note - SAP CRM Service Manager 4.1

 

 

Prerequisites

For SAP CRM Service Manager 4.1

SAP CRM 7.0 Ehp 0 SP11 (SAP_ABA 701 SP11+,  SAP_BASIS 701 SP11, BBPCRM 700 SP11+, WFM core 2.0 SP16+, MRS 9.0 SP01)

For optional Vehicle stock component

SAP ECC 6.0 Ehp 0 SP15 (SAP_ABA 700 SP18+, SAP_BASIS 700 SP18+,SAP_APPL 600 SP15+)

 

Mobile Add-On for CRM 6.10 contains the following ABAP Add-On software components:

Support Package Stacks can be found in the Service Marketplace at: http://service.sap.com/swdc -> Support Packages and Patches -> Browse our Download Catalog -> SAP Mobile Solutions -> Mobile Add-On for SAP -> MOBILE ADD-ON FOR CRM -> MOBILE ADD-ON FOR CRM 6.1.

SMFND 610_700 - Mobile Integration Framework Foundation

SMCRM 610_700 - Application Add-On for SAP CRM 7

 

Upgrade from existing Service Manager 3.X or 4.0 SAP ABAP Add-On

SMFND 610_700 Installation Package

SMCRM 610_700 Upgrade Package

 

Service Manager Documentation

For the latest version of the installation guide and documentation, see the SAP Service Marketplace athttp://service.sap.com/instguides -> SAP Components -> SAP Service Manager.


Device Support

  • Windows 7 and above
  • Windows 8 Pro tablets
  • Windows Mobile 6.0, 6.1, and 6.5
  • Apple iOS versions 5.1 and above
  • Android Tablet minimum version is 4.0 and above
  • Android Phone minimum version is 4.0 and above

 

Reference Notes:


2014454 - MRS Integration with CRM Service Manager 4.1

1935387 - For SAP CRM Service Manager ABAP AddOn Installation

1962949 - Release Information Note - Mobile Add-On for CRM 6.10 Support Packages

1936049- How to upgrade ABAP AddOn SYCLO 3XX_700 to SMCRM 610_700

1828657 - To get more information about planning the installation and upgrades of the ABAP add-ons SMFND, SMERP, SMISU, and SMCRM.

You do not want your users to see the Catalog button or use its feature on the FIORI launchpad ?

 

There is no out of the box way to do this as of today, in the meantime I will suggest a workaround to achieve this. this may not be the best solution but this will work, please comment if there is a better approach.

 

Prerequisites -

Find out using Chrome's Inspect Element Feature to identify technical details of what you want to hide.

  • Launch the FIORI launchpad in Chrome
  • Press F12 key on your keyboard to open Chrome Developer tools
  • Click on the first Icon on the developer tools window

               Inspect_Element.PNG

  • Move your mouse on the Launchpad and Click an object on the launchpad that you want to hide (Catalog Button / Search field / anything else)

               Choose.PNG

  • Once you click on the object you will notice that in the developer tool window, the html tag of the selected object is displayed

               html.PNG

  • Not always will it be the actual line you are looking for - but Chrome will help you to get closer to what you are looking for
  • You see that the <span> tag does not contain any css emements - so this tag will not be helpful
  • Click on its neighbors(html tags) and see where they are pointing to.
  • After initial set of trials you will see that <a tabindex=0 ....... this line has a CSS element "class = sapUiUfdShellHeadItm" and this may be helpful,
  • You can test within chrome to see if this css element will be helpful to hide your button/element
  • Click on the tag <a tabindex=0 ....>
  • On the right side of the Developer tools in Chrome, you will find the actual CSS styles of the Class sapUiUfdShellHeadItm,
  • You can do a "what if analysis" by changing the CSS elements of this style
  • Click on an empty spot near the definition of sapUiUfdShellHeadItm,
  • This will allow you to add another attribute to the CSS Style sapUiUfdShellHeadItm -
  • Type in 'display: none;' (if display property is already defined you can as well modify its property rather than adding one)
  • Once you have added this you will notice that the button/element you wanted to hide is no more visible on the screen
  • You now know the CSS definition you should be modifying.

 

Now you know what needs to be hidden, lets us see how to achieve this without modifying the standard SAP Code.


1) Create a theme as a copy of Blue Crystal (as an example) - you can refer to any of the existing blogs on how to create a custom theme - SAP Fiori UX - UI Theme Designer by Masayuki Sekihara

  

2) In the Theme Designer, you can use Expert mode to edit/override the CSS definition.

3) Under Expert mode, In addition to the actual definition of CSS Class sapUiUfdShellHeadItm, add the property "display:none;" to it

     css.PNG

4) Publish your Theme

 

5) Launch your FIORI launchpad with the new theme specified in the url parameter, (http://myserver:port:.....FioriLaunpad/index.html?sap-theme=<yournewtheme>@.........) refer to the blog written by Masayuki Sekihara if you do not know the parameters used to call custom theme - How to set a theme parameter to SAP Fiori launchpad

 

 

 

You no longer see what you do not want to see -

 

 

Babu Ganesh V

Customer Experience Group

SAP Labs India Pvt Ltd

Bangalore

SAP recently published an update to the SAP Fiori Client. The update implements several bug fixes plus adds some additional features customer have asked for. You can find the updated version of the Android version of the application at https://play.google.com/store/apps/details?id=com.sap.fiori.client&hl=en and for iOS the application can be accessed at https://itunes.apple.com/us/app/sap-fiori-client/id824997258?ls=1&mt=8.

 

New Features

From a new feature standpoint, this updated version of the SAP Fiori Client includes the following new features.

 

Custom User Agent

Several of our customers have asked for the ability to easily identify the client running SAP Fiori. These customers want to either redirect traffic based on client type (SAP Fiori Client vs. mobile browser for example) or to block access to the server depending on the client. In one case, the customer wanted to be able to only allow the SAP Fiori Client to be used to access SAP Fiori.

 

To accommodate this, we’ve added a custom User Agent string to all requests submitted by the SAP Fiori Client. Requests to the server will include the string “Fiori Client” in the User Agent header.

 

Added Version Number

In this version of the application, we’ve added an about screen that lists the version number for the application. We added this to make it easier to determine which version of the application is running on devices during troubleshooting.

 

Help Link

Added a menu item with a link to the online user guide for the SAP Fiori Client. The user guide can be found at http://help.sap.com/fiori-client.

 

Support for Additional Link Types

Added support for tel & mailto links within a Fiori application. This allows SAP Fiori Client users to more easily initiate a phone call or send an email message from within a Fiori application – just like they can from within a browser.

 

Upcoming Updates

We know that security and certificate management are important topics for our customers; a future update to the SAP Fiori Client will address those topics.

The existing SAP Fiori Client is a custom Cordova application. SMP SDK SP04 was just released, so the next version of the SAP Fiori Client we publish to the app stores will be built using the Kapsel plugins. I will provide more information about this version once it’s published.

Take a scenario where you need to create a service where we need to fetch data from multiple backend system.


We will just see the high level design for fulfilling this requirement :


Prerequisite :


  1. Gateway System is connected to all the back end system from which the data is to be fetched.
  2. System alias for all the back end system is maintained
  3. Parallelization node is maintained for better performance : Open the SAP Reference IMG in transaction SPRO and navigate to  SAP NetWeaver  Gateway  OData Channel  Administration  General Settings  Define Parallelization for Multiple Origin Composition  .


Say :

     GWS : Gateway System

     SAP_ERP1 : Backend system alias 1

     SAP_ERP 2 : Backend system alias 2

 

  • To define a service with multiorigin, we use ;mo with the service name . For eg : sap/opu/odata/sap/ZSERVICE;mo/$metadata
  • With the addition of ;mo, a new key property "SAP__Origin" is added in the response
  • SAP_Origin will specify the system alias to be used to get the data from different ERP systems.

 

11.png

 

Creation of Service :

 

  1. First we need to create a Gateway service using RFC or Structure.
  2. For using RFC we make sure that same RFC is present in all the ERP systems, with Import and Export parameters and the same Structure should be available in all the ERP systems, with the ABAP fields being the same.
  3. Create a GW project on all the backend system with same name : say ZSERVICE
  4. Once the service is created, add one of the service using one of the system alias say SAP_ERP1
  5. You dont need to add all the service as the names are same. Only one should do.
  6. Now you need to add all the system alias in /IWFND/MAINT_SERVICE for the ZSERVICE
  7. SAP_ERP1, SAP_ERP2, SAP_ERP3....etc

 

Execution from Gateway Client alternatively : Gateway client (/iwfnd/gw_client) :

 

You can execute GET, PUT, POST operations to read, update , create data.

 

Get_Entity can be used as :

  • /sap/opu/odata/sap/ZTEST_SRV;mo/GetBankDetailsSet(SAP_Origin=’ECC1’,Bankcountry=’’,Bankkey=’0001’)

 

Get_EntitySet can be used as :

  • /sap/opu/odata/sap/ZTEST_SRV;mo/GetBankDetailsSet?$filter=SAP_Origin eq ‘SAP_ERP1’ and Bankkey eq ‘0001’ and Bankcountry eq ‘Country’
  • /sap/opu/odata/sap/ZTEST_SRV;mo/GetBankDetailsSet?$filter=SAP_Origin eq ‘SAP_ERP2’ and Bankkey eq ‘0004’ and Bankcountry eq ‘Country’

 

POST :

 

/sap/opu/odata/sap/ZTEST_SRV;mo/CreateBankNo


XML :


<?xml version="1.0" encoding="utf-8"?>
<entry xml:base=
"http://mytestdomain.com/sap/opu/odata/sap/ZSERVICE_SRV/" xmlns="http://www.w3.org/2005/Atom" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices">
<category term=
"ZSERVICE_SRV/CreateBankNo" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>
<content type=
"application/xml">
<m:properties>
<d:SAP__Origin>SAP_ERP1</d:SAP__Origin>
<d:BankData>Test</d:BankData>
<d:BankArea>TestArea</d:BankArea>
<d:BankCode>00001</d:BankCode>
</m:properties>
</content>
</entry>

 

Let me know if this article is useful for custom Fiori like application and to get the details from different systems. :

 

Thanks. Appreciate your responses

 

Cheers!!

Tejas

Actions

Filter Blog

By author:
By date:
By tag: