Skip to Content

In today’s connected world, enterprise mobility allows organizations to earn business value by engaging closely with colleagues, suppliers, partners, and customers. With always-on online connectivity, employees wish to get more tasks completed in less time, from wherever they are.

This increasing demand for handheld access to enterprise applications and business data, is driving the need for more adaptive, dependable and cost-efficient IT solutions. By integrating mobile applications with back office data management platforms, companies can access and analyze data about customers, employees and operations much faster. This anytime, anywhere access to information helps business managers across the enterprise to make real-time, strategic decisions that deliver business value.

The need of enterprise mobility is undeniable – faster business processes, closer customer connections, and faster decisions. However developing the enterprise mobile applications which will meet the user requirements is a very difficult job  for IT. Moreover, there is always a high pressure from business to mobilize applications quickly versus high effort and limited budget to mobilize processes.

SAP is growing exponentially in Mobility Space and we have multiple ways in which SAP provides rich enterprise mobile applications.

As per the Gartner’s Report published in August 2013, SAP is on top in leaders Quadrant. According to this report:

  • Customers report high levels of satisfaction with SAP mobile solutions, and that SAP’s MADP offerings are stable and secure
  • SAP’s banking and messaging solutions have demonstrated the ability to scale to support demanding consumer scenarios
  • SAP offers some of the broadest device support among all the multichannel vendors

SAP provides a industry-leading mobile application development platform named as SMP – SAP Mobile Platform, that solves mobility challenges, supports mobile apps that fit your business-to-enterprise (B2E) or business-to-consumer (B2C) use case, and helps balance device user requirements with enterprise requirements.

In first quarter of 2013, SAP has come up with SAP Fiori which is a collection of applications with a simple and easy to use experience for broadly and frequently used SAP functions that work seamlessly across devices – desktop, tablet, or smartphone. Wave 2 of Fiori apps is also out in the market with more 198+ apps.

This Document highlights the solutions provided by SAP for enterprise mobile apps. The paper also makes an attempt to provide detailed view of these solutions and crisp comparison between these solutions. I trust my attempt will help you find best-fit mobile solution to your business scenario.

SAP Mobile Platform (SMP) :

Sybase Unwired Platform and the Syclo Agentry development platform have been integrated, and the product rebranded to SAP Mobile Platform. SAP Mobile Platform provides the middleware platform where users connect to and interact with various enterprise information systems and applications that exist in any large or medium size corporate IT infrastructure that supports customers, employees, sales, partners, suppliers, and executives. SMP acts as the hub that connects enterprise information systems and data sources to mobile devices.

Find more details on SMP here …

SAP Fiori :

SAP Fiori is a collection of apps with a simple and easy to use experience for broadly and frequently used SAP functions that work seamlessly across devices – desktop, tablet, or smartphone. Fiori is developed by SAP working closely with over 250 customers to understand the most commonly used business functions and ways in which the user experience for those functions could be improved and simplified.

Wave 2 of Fiori app with 198+ apps, is now in market for our use, The apps are designed for the most common business functions, such as workflow approvals, information lookups and self-service tasks, analytical apps.

Find more details on Fiori here …

Now as we have seen that SAP has provided above two approaches majorly, for mobilizing your business, let us now compare these solutions and see which one best fits to your scenario.

I

SAP Mobile Platform SAP FIORI
SAP’s Roadmap and Goal

A stable platform that will allow for mobile innovation through the use of a common architecture, enhanced security and better control. Goal is to qquickly build and deploy mobile apps that keep your workforce and customers connected and engaged – with the SAP Mobile Platform.

Collection of ready to use applications for broadly and frequently used SAP software functions . Goal is to provide immediate impact by renewing the user experience of the most broadly and frequently used SAP software functions that can be accessed from mobile and desktop devices

Usage

The SMP is an on-premise or cloud-based mobile application development platform that accelerates the development and delivery of secure, highly scalable business-to-enterprise (B2E) and business-to-consumer (B2C) mobile applications on any device.

SMP is a mobile enterprise application platform that securely mobilizes information on a variety of mobile devices. 

Thus using SMP, developer has to build a complete custom application that meets business requirements.

Fiori is a collection of  apps with a simple and easy to use experience for broadly and frequently used SAP software functions that work seamlessly across devices – desktop, tablet, or smartphone.This is not a platform, rather these are ready to use applications and hence with little installation and configuration, become available for customers to use.

Major Highlights

Provides an enterprise-class mobility platform delivered, maintained, and further developed by SAP,    as your unified mobile enterprise application platform (MEAP)

Includes fully integrated mobile device, user, apps, and security capabilities.

Includes non-SAP, thin integration layers, so that well selected instant value pre-packaged solutions can be added out of the box.

Supports multiple mobile devices and operating systems

These apps are extensible and customizable to meet customer’s requirements and can be adapted and aligned to corporate branding.

They are designed for increased productivity.

Fiori Apps can be assigned by specific roles so users get
only what they need.

Users can personalize the order of the applications.

Responsive design allows the same application to be available for different form-factors.

Architectural Overview

The Architecture is little complex as compared to Fiori:

  • SAP backend systems
  • NetWeaver Gateway for providing oData interfaces to business logic.(this will not be used for MBO approach).
  • SAP Mobile Platform (SMP) to store and pass data between NetWeaver Gateway and mobile devices.
  • SMP SDK is a development tool set which will be used to build mobile applications, which will meet mobility needs.

Afaria Server offers integrated device management and security for the broadest range of platforms from a single, web based console.

Fiori Architecture is simple and relies on three components.

  • SAP backend systems
  • SAP NetWeaver Gateway
  • SAP UI5 for NetWeaver

No mobile platform is required.

Backend Integration

There are two approaches :

MBO Approach: 

  • An MBO is a middleware object that describes mobile data and operations on that data.
  • Operations on an MBO are typically record related, but can also be operations that are directly invoked against the back end.
  • Changes made to MBO data on the device are reflected in the back end.
  • Back-end changes are communicated to the user when the middleware notifies the device application of an update and the application subsequently synchronizes the MBO data on the device.

oData Approach:

  • SAP Mobile Platform also supports the “Open Data Protocol” (OData) as a back-end resource.
  • When an OData source is used as the back end, the application developer does not need to create any model elements (MBOs) in SAP Mobile Workspace, but rather inherits a service model from the service document published from the back end, for example SAP NetWeaver Gateway.
  • These OData service documents contain all the information the device developer needs to parse and interact with these data streams.

Backend integration is simple aand uses oData Approach.  SAP Netweaver Gateway exposes existing SAP Business Suite processes as OData services. 

In simple terms, it takes RFC data from SAP back-end and
“adapts” it into OData. This implies that your business logic will reside solely on the back-end and not on the SMP server.

The SAP Fiori apps can be deployed in multiple ways;

  • As a collection of apps with a single launchpad,
  • As multiple Web apps, and they can be consumed from SAP or third-party portals.

SAP Fiori can also be configured to give access to a sub-set of apps based on user roles. Also as Fiori apps use Netweaver Gateway as middleware connector, Netweaver Gateway has two deployment options:

  • Central Hub deployment of SAP Netweaver Gateway
  • Embedded Deployment of SAP Netweaver Gateway
Development Approach

SAP Mobile Platform supports two mobile business object-based application types:

Native Applications :

  • The native application model enables the developer to generate platform specific code.
  • Here, the application is based on compiled code that is specific to a particular mobile operating system.
  • Provides the most flexibility in terms of leveraging the device services, but each application must be provisioned individually after being compiled, even for minor changes or updates.
  • Supports both, offline and online development.
  • You can also choose native-MBO or Native-oData approach

Hybrid Web Container-based Hybrid App

  • The Hybrid Web Container offers a fast and simple way to build applications that support business processes, such as approvals and requests.
  • With this, the server-side of the application is metadata-driven and the client-side of the application is a fully generated Web application package.
  • This package of platform-independent HTML, JavaScript and CSS resources can be deployed automatically to the Hybrid Web Container, a native application on the device, without writing any code.
  • Hybrid applications only support online model.

SAP Fiori are (online web based) lightweight apps fectching data directly from the backend system.

  • For SAP Fiori to work SAP has developed additional standard SAP Netweaver Gateway Models based with oData interfacing.
  • Fiori uses SAPUI framework based HTML5 on top of that. SAPUI5 framework is developed by SAP for a common UI development tool for all SAP products
  • FIORI apps are hybrid which are based on the web technologies (HTML5, CSS, JavaScript) so it will work in all major mobile platforms and in desktops.
  • If an organization has already adopted another UI Framework for deploying self-services, it should be relatively easy to build their own UI’s on top of SAP Fiori Gateway Models.
  • SAP has adopted a clean MVC framework with Fiori that allows easy adoption of other UI frameworks.
Application Security 

SMP provides Basic Protection to mobile devices like PIN to activate  device. SAP Afaria®, can add another layer of security to the mobile devices.

Developers can add security to SMP server client applications by configuring a prompt for authentication, requiring a username and password upon launch.

SMP supports Local Database File Encryption to prevent unauthorized users from accessing data

A Relay Server can be used as it provides secure network connectivity between devices connecting from the Internet and the SMP servers on an intranet that have access to corporate data systems and applications

For more details on security please check SAP documents

Secure system access for SAP Fiori applications involves password, user, and password policies, as well as special considerations for mobile devices

You can enable an additional PIN code to enable users to lock their devices and prevent unauthorized users from accessing data.

You can also Enable remote management software allowing you to remotely lock mobile
devices or wipe the data from them.

All communication channels should be encrypted in order to ensure confidentiality and integrity of data.

HTTP connections can be protected through Transport Layer Security (TLS) and RFC connections can be protected through Secure Network Communications (SNC).

Internet access to your SAP ERP backend system from an SAP Fiori application can be secured by means of an application-level gateway in the corporate network Demilitarized Zone (DMZ).

For mobile device the SAP Mobile Platform (SMP) can also be a viable access path if you wrap the Fiori apps into small hybrid apps. In that case SMP can add an additional layer of security with its device registration features, but all of that is purely optional.

For more details on security please check Fiori Security Guide.

Total Cost of ownership  and Total Cost Deployment

As with SMP, a complete custom application has to be developed, overall cost of building the application will be high thus increasing TCD and TCO.

More number of skilled resources will be required and development time would increase with complexity of application, in turn Total cost of ownership and deployment will go high.

Reduced development efforts: Implementation efforts and time for Fiori apps is less than developing custom application. This provides faster and easier deployment of applications, thus you can get started with SAP Fiori immediately and bring instant value to all employees. SAP Fiori enables companies to leverage their existing SAP investments by delivering powerful business results. Early users of SAP Fiori have reported tremendous business benefits,

  • Improved user satisfaction through intuitive easy-
    to-use interfaces.
  • Increased efficiency and productivity of employees with a lower TCO.
  • Reduced work completion time thus promoting better business decisions by enabling quicker approvals.
  • Increased adoption of business processes.
Web responsive design
With SMP, you won’t be able to create a unified web responsive design application. With Hybrid web container, you can create a single application that can open across multiple OS on mobile devices, however you cannot use them on desktop/laptops.

As Fiori uses HTML5 as frontend technology, thus allowing
organizations to deploy and manage a single code deployment that can serve any device on any platform running any screen resolution.

These apps are designed to adjust to the device form-factor, and thus can be accessed from mobile and desktop devices through a consistent user experience.

Thus to conclude, with Fiori, SAP is delivering (online web based) realtime apps directly from the backend system. There is no more need for a separate mobile platform. These apps can also be made available through the new SAP Mobile platform, enterprise edition, Cloud version. Main reason would be to provide a single platform to combine, and control, both SAP backend Apps and e.g. own build SAP Hana Cloud apps.

Since there are plans to also provide offline capabilities in the new oData releases, less existing application will require SAP Mobile Platform. SAP has planned “offline” integration with SMP. It will work on current MBO concept that gets their data from the OData connection. SAP has also released the SAP Mobile Platform on HANA cloud. With this now ithere is no need to install and maintain a platform server on premise. This will definately simplify our life.

In reality, SMP and Fiori are the solutions that SAP has intended for different purpose. There usage and Roadmap is different. However if you read various articles published in SAP Mobility space, SAP clearly say’s that a company has long way to go in both these areas.

References :  SAP documents on SMP and Fiori

To report this post you need to login first.

108 Comments

You must be Logged on to comment or reply to a post.

  1. Jitendra Kansal

    Nice comparison between SMP and SAP Fiori based app. You could also put some points of new release SMP 3.0 since there will not be any MBO approach, hybrid web container anymore.

    (0) 
  2. varada santosh

    Hi Sheetal

      Thanks for the nice overview  on both approaches. Could you please answer below Queries.

    1. SAP Fiori, can we compare it with RDS as it is readily availble for use with little config changes. Also can we customize this according it the business requirement.

    2. As Fiori applications are built using SAP UI5. I believe they can be accessed via any Mobile platform as well as desktop . Please correct me if I am wrong.

    Thanks

    Santosh Varada

    (0) 
    1. Sheetal Deshmukh Post author

      Thanks Santosh !

      1. SAP Fiori, can we compare it with RDS as it is readily availble for use with little config changes. Also can we customize this according it the business requirement.

      Yes Fiori applications can be deployed in minimal time. we can customize these apps as per our business requirement . We can add/ delete/ change functionalities provided.

      2. As Fiori applications are built using SAP UI5. I believe they can be accessed via any Mobile platform as well as desktop . Please correct me if I am wrong.

      Yes Fiori apps can be accessed from any device. They are device ( OS) independent.

      Regards,

      Sheetal

      (0) 
  3. Tejas Chouhan

    yah SMP3.0 where offline capabilities are possible with Fiori will be a very good combo, you can add this..moreover very good content here Sheetal..will clear many doubts..

    n yes there are dependency on browser versions though for Fiori access.. IE 9 or above, Chrome, Safari and Mozilla..:)

    regards,

    Tejas

    (0) 
  4. Yokesvaran kumarasamy

    Great!!!! I’m clearly a SMP guy and I thought Fiori is also a mobile platform, i was wondering that why SAP have released another mobile platform while having SUP. Now i understand Fiori is not a platform and it provides set of ready to use apps.

    Thanks Sheetal Deshmukh

    Regards

    Yokesvaran Kumarasamy

    (0) 
  5. Andy Silvey

    For the connected/online scenario, which these days most people are anyway, through a combination of 3g/4g and wifi almost everywhere, I am waiting for SAP to bite the bullet and start with a targeted approach of writing mobile website versions of the ABAP WebDynPro Business Suite applications.

    Andy.

    (0) 
      1. Andy Silvey

        <For the Connected Online Scenario>

        I am not sure they will take that approach, I think they should take that approach and I think the younger people behind me (I am 40) who will be the next line of Users and Managers will be confused why existing popular SAP Web based functionality has not been prepared to also have ABAP WebDynPro generated dynamic html screens which work with the Smart Phone and Tablet, in the same way as Ebay, Amazon and others have done as I blogged here.

        We cannot change history, but everyday is a new day and an opportunity to improve on past performance and I simply think SAP should bite the bullet and start writing ABAP WebDynPro generated dynamic html versions of the most popular Website based SAP Business Suite applications as mobile versions suited to the Smart Phone and Tablet.

        Our generation of SAP people, kind of accept the current situation, but during the next few years, try explaining to the next generation of CIO’s, Business Leads etc, that if they want their favourite Intranet based SAP Applications to work on a Mobile then we need to buy this, this, this, implement that, that, that, and for BI it will be this infrastructure, for CRM it will be this.

        Their answer will be, if Amazon and Ebay et al can make mobile versions of the websites, why haven’t SAP simply made Smart Phone and Tablet friendly mobile website versions of the most popular valuable common SAP Business Suite Intranet based applications ?

        The question is coming, it’s just a matter of time.

        In the blog, I proposed SAP a strategy to achieve the goal.

        To be honest, it is an opportunity waiting for somebody, it’s easy, put together a team of:

             Business Expert

             Functional Expert

             ABAP WebDynPro Developer

        Do some thorough analysis and cherry pick a collection of existing SAP ABAP WebDynPro website based Business Suite applications, and write the mobile website versions.

        Start with a small collection and simply grow the portfolio.

        Imagine the smile on the Customer’s faces when the salesman can say to them, if they want this, it is just an ABAP Add-on or better still it’s included in the next EHP upgrade, runs in ABAP WebDynPro, and doesn’t require any new hardware, software, infrastructure, expertise, monitoring, lifecycle and reuses existing assets investment.

        Either SAP will do it or somebody else will do it.

        I am surprised OpenText or somebody like that haven’t done it.

        </For The Connected Online Scenario>

        Andy.

        (0) 
        1. Joao Sousa

          if Amazon and Ebay et al can make mobile versions of the websites, why haven’t SAP simply made Smart Phone and Tablet friendly mobile website versions of the most popular valuable common SAP Business Suite Intranet based applications ?

          In my opinion there are various reasons for this. The most important one is that Amazon and Ebay are consumer centric companies.

          A slow, cumbersome site, with no multi-channel approach will kill you, the customer will just move elsewhere to another site. That’s not true in a corporate environment for professional applications. Employees can’t choose to use another application, and they have specific training.

          Must SAP make mobile versions or the core transactions in order to keep itself relevant? I don’t believe so, and for some of the most used transactions it doesn’t make sense, since they are transactions targeted at people who work sitting down all day in front of a desktop. Would it be nice to have a mobile version? Perhaps, but it’s far from critical.

          SAP Fiori targets the processes that make sense to mobilize. Document approval, time management, those make sense, and SAP has already addressed them. Making a mobile version of a VA01, VL02N, MIGO, MIRO, FB60, FBCJ would be a waste of time. I personally have made JQueryMobile apps for some processes, but I never considered mobilizing the core SAP transactions.

          (0) 
          1. Andy Silvey

            Hi Joao,

            this is a good question and fair point and gives the opportunity for clarification.

            The goal is not to mobile website version enable every transaction in SAP.

            The goal and the expectation, is that, beginning methodically, business case by business case, SAP would look at the existing portfolio of web enabled ABAP WebDynPro functionality and cherry pick the most applicable candidates to be extended with mobile website versions for Tablets and SmartPhones.

            These days, SAP’s portfolio targets not only people sat at their desks, but people on the move, Managers on the move from meeting to meeting, who have workflows to approve, as one example.

            Once SAP begin down this path, the response will be unanimous and contageous and the demand will be for more and more which can be rolled out with EHP upgrades.

            Best regards,

            Andy.

            (0) 
            1. Joao Sousa

              The goal and the expectation, is that, beginning methodically, business case by business case, SAP would look at the existing portfolio of web enabled ABAP WebDynPro functionality and cherry pick the most applicable candidates to be extended with mobile website versions for Tablets and SmartPhones.

              But aren’t they doing it already with SAP Fiori?

              (0) 
              1. Andy Silvey

                yes and no

                yes in terms of the apps

                and no in terms of accessibility

                The coming generation of Users don’t and won’t distinguish between User Agent, and they will expect functionality as a rule of thumb, to function across User Agents out of the box.

                SAP web enabled ABAP WebDynPro applications are delivered as part of the Enhancement Pack Versions of the underlying Business Suite systems, and so, if the Customer has for example SRM 7.01 SP09 running on NetWeaver 7.02 then the Customer can expect that out of the box they will have certain applications running through the web browser as ABAP WebDynPro generated dynamic html.

                The coming generation of Users and Managers will expect that at least some of those functionalities will out of the box support the suite of User Agents and not distinguish between them.

                Fiori is not out of the box.

                If you want Fiori, is it out of the box, I don’t think so, you need the GateWay Add-On, the UI-Add-Ons etc.

                This is the problem.

                Mobile should not be the exception, it should become the rule.

                There is a lot of catching up to do in this area.

                Look at the large enterprises, the Users have the corporate iPhones with VPN access and email access, and the same on iPads, consequently, the demand is bubbling away for the SAP apps to be enabled for these User Agents, and this enablement should be out of the box and not require more infrastructure and deployment projects and maintenance paths, it should use the existing robust technologies and software application lifecycles.

                And if Amazon and the others can do this with robust proven technologies and not requiring apps etc, then why can’t SAP ?

                Andy.

                (0) 
                1. Joao Sousa

                  If you want Fiori, is it out of the box, I don’t think so, you need the GateWay Add-On, the UI-Add-Ons etc.

                  Not since Netweaver 7.4, now everything is integrated in the SAP default installation.

                  And if Amazon and the others can do this with robust proven technologies and not requiring apps etc, then why can’t SAP ?

                  Like I said before, I believe you are asking the wrong question. Why do Amazon and others do it? Because they must, while on the other hand SAP doesn’t need to.

                  (0) 
                    1. Joao Sousa

                      But what are we disagreeing on?

                      • I’ve shown you how the components required for Fiori are included in standard installation;
                      • SAP is making these Fiori apps available precisely for your use case, mobility;
                      • SAP will had more Fiori apps in the future.

                      If your argument is that there should be a 1-to-1 mobile version of every web page, then yes we will have to disagree. A mobile app has to have less functionality and therefore I believe it’s impossible to do a 1-to-1 translation.

                      Consumer oriented sites are much more simple since they have to be simples. They cater to people with no training. Putting a SAP web page on mobile, on a 1-to-1 basis, it is in my view impossible.

                      I also disagree that ABAP Webdynpro is an appropriate framework, it’s too heavy.

                      (0) 
                      1. Andy Silvey

                        Hi Joao,

                        I think we can safely say, for the record, nowhere have I said my argument is that there should be a 1 to 1 relationship between a PC Web Page SAP version and a Mobile Web Page SAP version – from the beginning.

                        Must SAP make mobile versions or the core transactions in order to keep itself relevant? I don’t believe so, and for some of the most used transactions it doesn’t make sense, since they are transactions targeted at people who work sitting down all day in front of a desktop.

                        This is precisely my point, we have to think towards the future and to re-use an existing phrase, outside the box.

                        Why have we had to sit at desks for the last few hundred years ? Because the tools to do our jobs only worked from desks, this goes back in history to the scribe and right upto about ten years ago because wifi started becoming prevalent. Until wifi, pc’s were anchored to desks as I have explained here.

                        These days, with Wifi and Tablets which can  be held in one hand and operated with one finger, we are in the period of a changing work environment and working style. Our generation will move away from the psychology of going to one’s desk to work on the pc, and the next generation are already there.

                        Offices will change, desks and workstation designs will change, offices will become more fluid spaces and less rigid than they are now.

                        Applications will be accessed through the tablets. People will work on the move from there tablets. This morning in this area of the building where this team sit, this afternoon in this area of the building where this team sit, moving from team hub to team hub as their work demands and armed only with the tablet.

                        I totally agree WebSites need to become lighter, much lighter and mobile websites are already proof of this.

                        Only 15 years ago, big commercial websites had goals to keep a page under 100kb, these days if you go on a newpaper website, eg http://www.dailymail.co.uk you can end up with a 6mb page. Even on fast networks and modern pc’s these pages are not opening fast enough and there needs to be a certain amount of calming and reduction in the size of webpages.

                        Andy.

                        (0) 
                        1. Joao Sousa

                          Why have we had to sit at desks for the last few hundred years ? Because the tools to do our jobs only worked from desks, this goes back in history to the scribe and right upto about ten years ago because wifi started becoming prevalent.

                          Not every job requires mobility. An accounting department is more produtive if people are sitting down working with large screens. This has nothing to do with technology, there are simply some jobs that have no/little mobility requirement.

                          SAP is mobilizing processes that make sense, many of them I’ve made custom developements in the past (purchase order approval, for example).

                          (0) 
                          1. Andy Silvey

                            yes, SAP are mobilizing, but not fast enough and now need to catch up.

                            mobile enabled content should not be the exception to the rule, should not be a special case

                            if Customers are forced to write custom code to meet demands from the business then SAP is failing to provide their customers the solutions they need and missing opportunites to sell software and expand their portfolio and scope and presence

                            customers shouldn’t be forced to write their own code to meet mobile business demands, those days were 15 years ago

                            further more, custom costs $$$ compared to SAP standard, and is more complicated than SAP standard to maintain and support over the application life cycle

                            Andy.

                            (0) 
                            1. Joao Sousa

                              if Customers are forced to write custom code to meet demands from the business then SAP is failing to provide their customers the solutions they need and missing opportunites to sell software and expand their portfolio and scope and presence

                              I guess we’ll just have to agree to disagree. We are talking in a thread about SAP Fiori, and I don’t understand what is so critical (and standard) to mobilize that SAP hasn’t already addressed with these solutions.

                              And customers will always be forced to write custom code. That’s not something specific to mobility, there is no way SAP can provide solutions that address the business requirements of all clients.

                              (0) 
                  1. Alon Raskin

                    Hi Joao,

                    Quick question on this point about Gateway being part of the ‘standard install’. Does that mean it is no longer a separate license cost or does Gateway still need to be licensed separately?

                    (0) 
          2. Andy Silvey

            Coming back to this question of who needs access, and who is tied to their desks,

            here is a very interesting document, it is the SAP Road Map for User Experience

            it really shows where SAP sees the product suite going and who the Users are going to be.

            Notice how much attention is put onto Casual Users as an evolving User Group, and the changing expectations of the Users.

            The document is from Q1 2013, so it will be interesting to see the next versions.

            Andy.

            (0) 
        2. Alon Raskin

          Hi Andy,

          If you look at 3i Mobile, that is exactly what we have done. With our approach, you can use traditional ABAP development (similar to WebDynpro) to build offline HTML5 web apps which run in the browser or packaged up into SMP HWC (or any other deployment platform). The apps run on desktop and mobile. No need for mobile developers, just an ABAPer and a functional expert.

          I read your comments and couldn’t believe that you had the same thought as our original founders…

          (0) 
          1. Andy Silvey

            Hi Alon,

            I read it, the 3i site, and if it really does what it says on the box then this is precisely what I am talking about.

            I would have thought there’s an aquisition candidate here somewhere.

            Andy.

            (0) 
            1. Alon Raskin

              I am sure the owners of the company will entertain any offers you may have 😆

              One thing I did want to note is that there are many online only solutions out there. I find this very odd in a mobile space. I appreciate that 3G/4G is everywhere but it doesn’t mean I want to be downloading pages over these connections everytime I need to enter my time sheet or approve a req. These apps (like my email, calendar, etc) need to be available to me regardless of whether I have connectivity or the quality of that connection. I can grab any device and send an email (and it will synch later). I expect the same from my enterprise apps. Thats why Fiori leaves my head scratching a bit.

              As I have always said “If you are tethered to the network, you arent really mobile”.

              (0) 
  6. Sajesh T

    Comparison of SMP to Netweaver Gateway may have been fairer… not Fiori.

    In any case, with SMP 3.0 already launched, most of what is written about SMP is no more true! MBO is no more an option. One major drawback with Fiori being a mobile web app is that it cannot have native push notifications. All those approval applications are not cool without this.

    (0) 
    1. Midhun VP

      New additions will be added to Fiori during the time. SAP Fiori and SMP 3 integration will give you native device capabilities, offline access, push notifications and additional security.

      – Midhun VP

      (0) 
      1. Joao Sousa

        The main benefit of Fiori is having a light infrastructure. I seriously question the relevancy of SMP in a always connected environment, the future is either mobile web apps (SAPUI5/JQueryMobile), or native apps connected through Netweaver Gateway.

        I can see the relevance of Afaria to control these deployments and secure the devices, but why do I need SMP? Does it provide enough value to warrant an additional, expensive license, when Gateway comes “free” with a SAP named license.

        (0) 
        1. Midhun VP

          You are right Fiori has a light infrastructure and its easy to implement. But there are limitations with it (no push nofications, no native features or no additional securities) because its a web application. Of course we can suggest Fiori to a customer but later if the customer is coming with a requirement of push notifications and it is a limitation means we need to go with SMP.

          There are many options to develop enterprise app without SMP, also its not mandatory to use SMP, but to get additional features to the app and make the development process easy (using SDKs provided with SMP) without any complexities in implementation of SSO, LDAP integration, push notifications, easy user on boarding, troubleshooting etc we need a platform and it is SMP. So based on the requirement from customer we can suggest a platform, otherwise develop the app using SAPUI5 or with NW gateway alone.

          – Midhun VP

          (0) 
          1. Sajesh T

            The only value I see in SMP is the integration gateway that would allow you to adapt SAP and non-SAP data sources and gives the mobile client developer a single server view. And may be the push notifications to some extend. Most of the above mentioned additional features  can be easily included in a hybrid app or native app directly without SMP’s help. Paranoid enterprises can use the mobile app wrapping like mocana for the extra security.

            (0) 
            1. Midhun VP

              Everything is possible with and without a platform, but a platform simplifies the way you are doing the things. It removes the complexity in implementation of features because the platform has the inbuilt features to do it in few steps, for example SSO/LDAP can be implemented without device developer intervention, but think without a platform, it will be an experimentation. Its all about understanding the difference between with and without a platform.

              – Midhun VP

              (0) 
              1. Sajesh T

                Agree with your point on the need/choice of a platform Midhun. But what I am saying is that there’s nothing much I see that SMP provides that ‘justifies the investment’ especially after the offline capability is gone with the MBOs… or I should be educated 🙁 .

                (0) 
                1. Midhun VP

                  I think you are more concerned about the money customer need to spend for license, a customer facing experience may made you to think that way 😉 . But don’t have any comments on whether I agree or disagree on it. I am expecting more features on SMP3, hope for the best.

                  – Midhun VP

                  (0) 
                  1. Joao Sousa

                    I think you are more concerned about the money customer need to spend for license

                    And every consultant who invests time (and money) on a platform needs to be concerned about that. It’s the difference between getting a return on your investment, and investing in a technology that no one cares about because it’s too expensive.

                    I’m product oriented because in the end, I get paid (and satisfaction) for fulfilling a client’s need. It’s fun to play with a platform, but that doesn’t put food on the table.

                    (0) 
              2. Joao Sousa

                Everything is possible with and without a platform, but a platform simplifies the way you are doing the things.

                At an extremely high cost. The last time I checked SMP was extremely expensive, only very large corporations will consider it. In my country I doubt there is a single corporation that would pay for SMP.

                If it had a killer feature … maybe, but in my view it’s just a nice to have. For that, it’s way too expensive.

                (0) 
          2. Joao Sousa

            but to get additional features to the app and make the development process easy (using SDKs provided with SMP) without any complexities in implementation of SSO, LDAP integration, push notifications, easy user on boarding, troubleshooting etc we need a platform and it is SMP

            The problem is that the SDK has actually lost functionality since the deprecation of MBOs. What was once a development process centered on these object, it now very similar to dealing directly with oData/Gateway (if there is actually any difference). It’s true that it deals with things like SSO, but is it worth it?

            Push notifications can be handled without SMP, since webapps can be wrapped in an iOS/Android app with little trouble. I’ve done it in the past: a JQueryMobile BSP wrapped in an iOS app with push notifications.

            (0) 
            1. Midhun VP

              I haven’t said that this particular one is not possible or possible, a platform helps to minimize complexities in a development and maintenance.

              Btw, Odata SDKs are also provided with SMP too. That helps in parsing, connectivity, limited caching (persistence), datavault, afaria integration etc. In future complete offline Odata support would be possible using SMP3.

              – Midhun VP

              (0) 
              1. Joao Sousa

                I haven’t said that this particular one is not possible or possible, a platform helps to minimize complexities in a development and maintenance.

                But it also requires specific training, and specific skill set. The infrastructure is also a maintenance cost and barrier for entry. Gateway comes “free” with Netweaver, and is required for SMP anyway.

                I’m not saying that SMP doesn’t have value, what I’m saying (and this is a opinion shared with a lot of consultants and prospective clients) is that the value doesn’t compensate the (high) costs. Maybe SAP is targetting SMP specifically at the huge corporations who can easily afford this.

                As for the oData offline roadmap, SAP has changed the roadmap so many times in the past, that I don’t consider that as fact. That’s the main problem with SAP’s mobile strategy, the technology is expensive, and changes every other semester.

                (0) 
                1. Andy Silvey

                  That’s the main problem with SAP’s mobile strategy, the technology is expensive, and changes every other semester.

                  and that is why I am advocating, keep it simple, stick to a standard, and develop the Mobile Website versions using good old ABAP WebDynPro generating dynamic html.

                  It will work everywhere on every device, it will be fast enough, security will be straightforward, maintenance and development and software lifecycle will be straightforward and new versions of the applications will be delivered with the SP Stacks and EHP’s.

                  Andy.

                  (0) 
                  1. Joao Sousa

                    It will work everywhere on every device, it will be fast enough, security will be straightforward, maintenance and development and software lifecycle will be straightforward and new versions of the applications will be delivered with the SP Stacks and EHP’s.

                    I agree on that regard. It’s much to simpler to have on application server instead of multiple components that change drastically every semester. One or two skillsets (ABAP + Javascript) instead of 5 (ABAP, Gateway, SMP, Javascript, Infrastructure).

                    Where we disagree is on the dynamic html. For me, mobile apps have different requirements and have to be designed from scratch with mobile in mind. Dynamic HTML doesn’t cut it.

                    (0) 
                  2. Midhun VP

                    Not all requirements satisfy here. Different clients has different requirement. HTML5 based app never fulfill all the requirements (even interest is growing), because of its performance limitations. There are business scenarios where end user downloads 1000’s of records to mobile and work offline, online and occasionally connected environment, they need good UI with best available performance in the field, that is satisfied with a native app. So do you think that it is possible with ABAP webDynPro?

                    I always suggest a HTML5 app only if the app is light weight because the end user should not stop using the mobile app and go back to desktop. SAP is giving multiple options to develop an application based on requirement, that doesn’t mean that SMP is must. There are customers who implemented mobile strategy with and without SMP.


                    – Midhun VP

                    (0) 
                    1. Andy Silvey

                      Yes in the main you are correct, I am not disputing that, the offline scenario is a different kettle of fish and requires technologies to deal with the challenges the offline scenario brings.

                      My main argument is this in the connected scenario..

                      Andy.

                      (0) 
                    2. Alon Raskin

                      I am going to respectfully disagree Midhun. Our 3i Mobile solution created HTML5 offline capable solution which can process 1000s of records in an offline manner. We have deployed it with various customers in the oil, pharma and other industries.

                      If the customer wishes to have push notifications or some other scenario then we take our HTML5 and can deploy on SMP and/or PhoneGap depending on the customer requirements/infrastructure.

                      So HTML5 affords an amazing offline capable user experience without all the complexity of SDKs, MEAP, etc.

                      (0) 
                      1. Midhun VP

                        I likes your solution then, not sure how much effort your team put to make the app to support offline and manage 1000s of records. But when I am developing a simple mobile web app with HTML5 with 100+ records in a listview, while scrolling up and down gives poor response, its giving me a mobile browser experience instead of a mobile app. Help me understand how you managed 1000s of records with HTML5.

                        The point is that web apps have limitations when compared to native apps. So a big business scenario can only satisfy with native apps.

                        Have a look at the story of Linkedin Mobile app (even its B2C); In 2011 they came with HTML5 based app, How LinkedIn used Node.js and HTML5 to build a better, faster app and in 2013 they dumped HTML5 and went native, Why LinkedIn dumped HTML5 &amp;amp; went native for its mobile apps

                        – Midhun VP

                        (0) 
                        1. Alon Raskin

                          Hi Midhun,

                          Thanks for your response. There are several features that are built into our framework that solve the issue you have mentioned. You need to remember the first release of our product came out in 2008. So it is very mature and we have had the time and skill to solve all these complex issues.

                          I agree that scrolling through 100s of records CAN give poor performance (especially on some earlier releases of BlackBerry (6,7) and Android (2.1) etc. However there are ways to mitigate these by designing your UI and caching strategy a certain way. Of course these are things that are difficult to achieve if you have to build it yourself from scratch. This is where solutions like SAPUI5/Fiori fall down and more mature frameworks pay themselves off. These younger frameoworks are great for building simple apps like Hello World or displaying a list of Shopping carts. etc. But this is where they fall down. When it actually comes to building a fully capable CRUD (Create, Read, Update and Delete) transaction which is offline capable it is impossible or difficult to do.

                          Our solution is built upon the following premise:

                          1. Leverage existing ABAP developers to build mobile apps. Our customers use SE80  and SE11 to build offline capable apps without hiring a single mobile developer

                          2. Support all platforms (Desktop – Mac and PC) and Mobile (BlackBerry, iOS, Android and Windows Phone)

                          3. Be MEAP agnostic. If a customer wishes to use SMP that is fine. If they wish to use a different MEAP, that is fine. If they wish to just deploy in a browser that is fine too.

                          4. Under ALL scenarios, apps must run offline unless the customer explicitly marks the solution as online Only (this is a flag which the user checks using SM30).

                          I’ll give you a good example, One of our customers is a medical device manufacturer which is headquartered in Germany. They built a  solution which was deployed in two parts. The first is an Administrator console which just runs on a desktop browser.

                          The other part of the solution was a HTML5 app which we wrote and deployed using SMP 2.2 in the Hybrid Web Container. When the customer moves to SMP 3.0 we will probably redeploy using Kapsell. As you can see this approach gives the customer simplicity of building web apps and the built-in security and AD integration of SMP. Best of all they didnt have to compromise everything works offline which was important to them since app will be used in hospitals and surgery rooms where wifi may not be available or prohibited.

                          I don’t want these postings to become an ad for 3i but you should keep an eye out for some of the webinars that we do periodically where we do a live demo build of an app from scratch. It’s a great way to understand out approach.

                          (0) 
                          1. Andy Silvey

                            Hi Alon,

                            nice answer but you didn’t really answer how you do it 🙂

                            If we will keep this technical and not as an advertisement then we should to a certain extent discuss the challenges (which is the offline scenario) and potential solutions using SAP’s technology.

                            Andy.

                            (0) 
                            1. Alon Raskin

                              I understand what you are saying. However, our solution is based on SAP technology. It is an ABAP add-on which is certified by SAP. True, it is not sold by SAP however it is very much ‘SAP based’.

                              Anyway, regarding the offline capability I could probably write a few pages on it. I will try to summarize below.

                              1. ABAP developers can create a database on the device by defining the database structure in SE11 (Data dictionary). Once the tables are defined in SE11 our framework automatically creates the tables on the device (desktop, mobile etc)

                              2. A developer then writes a very basic XML file which when accessed can simply insert, update or delete records in that database. The developer doesn’t have to worry about how to write client side DB updates (very complex area since there are various competing standards), rather we take care of the complexity in our framework

                              3. Once the data is available on the device it can be displayed, updated just like we use the ABAP Dialog screen tool today. You just defined the screens and the corresponding fields and our solution renders them using HTML5

                              4. All the MIME files are stored offline on the device too. So the HTML5 page can be loaded even if there is zero connectivity (ie. airplane mode etc). I cant underscore how important this feature is to the user experience. Since all the MIMEs arent loaded everytime, the ‘web page’ is super responsive and loads almost immediately. Users love that and its the main reason why I cant understand ‘other’ solutions which are online only.

                              (0) 
                        2. Joao Sousa

                          The point is that web apps have limitations when compared to native apps. So a big business scenario can only satisfy with native apps.

                          But you don’t need SMP for native apps. The Android and iOS frameworks are very flexible, and iOS even has Core Data to handle the persistency layer.

                          I worked in the past with SUP, had formal training in SUP, and still developed a pure iOS + Webservices app much faster then the equivalent in SUP. In fact, the pure iOS app gave much more flexibility like the possibility of a dynamic data model (consultants can create pricing tables and my app just handled the changes to the data model dynamically).

                          (0) 
                          1. Midhun VP

                            I given this reply to Alon when there was a need to compare HTML5 with native apps. Of course its possible to develop enterprise native apps without SMP. In 2011 I developed Android apps that consumes Odata from Nw gateway without SUP, since android was not supported by SUP that time. I am not here to support any platform or framework, the selection of a technology is purely based on the requirement, availability of resource and infrastructure. SAP is providing different options to choose from.

                            – Midhun VP

                            (0) 
                          2. Paul Horan

                            Of course – an “Enterprise Platform” like SMP is total overkill when your goal is to build a single app, for a single platform, without any enterprise features like application registration, user on boarding, FIPS-level encryption, app usage statistics, end-to-end tracing and diagnostics, LDAP/AD integration, …  I could go on.  Note: none of those have anything to do with the crafting of the actual user interface.  Because we decided not to engage in the battle – use whatever toolset you’re using today.  When you want to make it enterprise-ready, you’ll quickly realize what SMP brings to the table.

                            By focusing on the front-end development tools alone, you’re missing the 80% of the iceberg that’s under the visible waterline…

                            (0) 
                            1. Joao Sousa

                              Note: none of those have anything to do with the crafting of the actual user interface.  Because we decided not to engage in the battle – use whatever toolset you’re using today.  When you want to make it enterprise-ready, you’ll quickly realize what SMP brings to the table.

                              Like I already said in response to another post, I said almost nothing about the UI. Don’t know where that idea came from…. even in SUP the UI was basically left outside of the platform.

                              The rest … well, there are lot of “enterprises” that use SAP that have different priorities and requirements. I’ll leave it at that….

                              (0) 
                        3. Alon Raskin

                          One more thing regarding your LinkedIn example. In the interview he mentions that the biggest reason they went to Native is because the dev tools were not good enough. I am not sure I entirely agree that this applies to Enterprise apps but I suppose that is somewhat true.

                          That is not really an issue for the 3i Mobile platform because it is mostly ABAP based. Developers use SE80 and the various debugging tools that they know in order to debug an app.

                          (0) 
                          1. Midhun VP

                            I really appreciate your detailed explanation. How you are supporting the backends other than SAP or a heterogeneous bakcend ?

                            – Midhun VP

                            (0) 
                            1. Alon Raskin

                              We just use REST services which is clearly where the industry is moving towards. We can integrate data in from any oData/REST capable system like SalesForce, Oracle Apps, etc. We can even leverage a customers existing XI system and pull data in via those existing interfaces.

                              The reality is that SMP (or any other MEAP) is not the first solution that can integrate data from other system. SAP Netweaver was doing this for a very long time (example:  SAP – SAP Composite Application Framework: A Robust Environment for the Design of Composite Applications ).

                              I am not saying that we are using the Object Access Layer from the Composite framework. I am just saying that SAP systems have been integrating with other systems for a long time before SAP bought Sybase.

                              Ultimately I think that was Andy’s point. Why didnt they just extend WebDynpro to be HTML5 friendly? I am not sure there was any real technical reasons why they couldnt.

                              (0) 
                              1. Joao Sousa

                                Ultimately I think that was Andy’s point. Why didnt they just extend WebDynpro to be HTML5 friendly? I am not sure there was any real technical reasons why they couldnt.

                                Webdynpro ABAP is mainly server side, while a responsive HTML5 app has a lot of AJAX and client side code. Right now, you can mix pure client side operations with server side operations in a single webdynrpo method.

                                Even if a framework could translate ABAP into Javascript, it would be impossible to separate the client side operations from the rest, therefore the automatic translation of Webdynpro ABAP framework wouldn’t take advantage of all the benefits of light weight html5 applications.

                                (0) 
                                1. Alon Raskin

                                  Even if a framework could translate ABAP into Javascript, it would be impossible to separate the client side operations from the rest…

                                  Respectfully Joao, that is precisely what our framework does. Our approach allows an ABAP developer to build all the screens and define the fields and other UI widgets that they see on the screen. Then the developer defines which client side tables (which are defined in SE11) those fields are linked to. Then the 3i Mobile framework takes care of displaying, updating, saving, deleting etc without requiring the developer to ever write a single line of client side webSQL (or indexDB).

                                  (0) 
                                  1. Joao Sousa

                                    Respectfully Joao, that is precisely what our framework does.

                                    I was responding to your statement “just extend WebDynpro to be HTML5 friendly“. It’s not as simples as “just extend”, it would require a huge change to the way Webdynpro development is done and to it’s framework (to the point where it wouldn’t be Webdynpro anymore but something else).

                                    Your framework is not Webdynpro ABAP. If development is made with your framework in mind, I’m sure it is possible. But not with Webdynpro as it is designed.

                                    (0) 
    2. Paul Horan

      Two corrections:

      –  MBO support will continue in SMP 3.x as an optional “sidecar” installation.  Essentially, it’s the 2.3 server runtime for supporting MBO-based applications.

      –  And we are working on releasing the Fiori Mobile Client.  This will be a Cordova-based implementation of Fiori that offers better on-device cache management for Fiori apps over the standard mobile browser implementation.

      -Paul Horan-

      SAP Global Mobility Enablement

      (0) 
      1. Midhun VP

        Paul, In that case of a sidecar for MBO apps, whether customer need to pay separate license for it ? I mean since there are two servers running is it two separate licenses ?

        (0) 
            1. Jan-Gerrit Groeneveld

              Hi Midhun,

              the MBO Runtime, as it is properly called, is shipped with SMP 3.0. Paul already as described at high level what it is: Essentially, it’s the 2.3 server runtime for supporting MBO-based applications.

              Given that it is part of SMP 3, MBO apps are supported with this release.

              Having said that, SMP 3 embraces new technologies and standards, in particular OData. To take advantage of achievements, you’ll have to work with apps that are ‘made for SMP 3’. See this doc for what we support with SMP 3.0: SMP 3.0 for Developers.

              SMP 3.0 is still in Ramp-Up, and additional information will be made available by Product Management closer to General Availability.

              (0) 
              1. Midhun VP

                If I am right, SMP 2.3 runtime is carried with SMP 3 to support existing MBO apps. So that option is given to give some time to the customer to get ready to develop apps with SMP3. But the option may not be for lifetime, ie after a particular time period SAP may remove that option or stop supporting it (can’t reach SAP to solve an issue). So my question is what is that time period given or is it a lifetime support option ?

                – midhun VP

                (0) 
                1. Tobias Hofmann

                  The question to ask is: will MBO in SMP3 be tagged as “in maintenance mode” or not. If so, it is clear that it’s there for legacy reasons and new applications should not use it. They may, but this doesn’t mean that SAP will help you a lot when you run into problems (aka: told you so).

                  If MBO in SMP 3 is announced as a part of the platform with no restrictions, you can use them for your apps as you like.

                  A smart move would be to tag MBO in SMP 3 as a runtime environment for 2.x apps only i.e. if you write a custom app in SMP3 SDK you cannot select MBOs.

                  (0) 
                  1. Jan-Gerrit Groeneveld

                    Hi,

                    I am not sure if MBO functionality carries the flag ‘in maintenance mode’.

                    The MBO runtime will be supported until the end of maintenance of SMP 3.0, at minimum.

                    We do encourage to embrace the new technologies and possibilities that we release with SMP 3 (after all, that’s why we developed them), and recommend to consider these when creating new apps.

                    The speed of innovation in the mobile space is huge, in all aspects, and I’d be somewhat disappointed if the question of MBOs will still be relevant by the time SMP 3 reaches end of maintenance 😉

                    (0) 
                    1. Tobias Hofmann

                      Never underestimate corporations when it comes to keep a certain technology alive. If someone did a mobile app based on MBO (btw, MBOs are not bad, they just do not fit nicely into OData concept) and sold it to an client, this can easily be a 3 to 5 year contract. Go live end of 2014 … and in 2019 you’ll still have a SAP client running an MBO app.

                      Yep, enterprise software. #creepy

                      (0) 
                    2. Angelo Antonello Borges

                      Simple, open standards are more resistant to being discontinued. Products or concepts owners (MBOs and others) tend to be developed, invested, sold (as the solution of all problems), tested and enhanced for a certain period. If it were otherwise, we would be still developing in WDJ and SAP NW Mobile.

                      (0) 
                      1. Joao Sousa

                        Simple, open standards are more resistant to being discontinued.

                        And yet SAP spent billions aquiring Sybase, and little is left of what they bought. SUP was MBOs.

                        WDJ was more “open” then plain ABAP that uses a proprietary language. SAP invested in Java and HTML5 because of the promise of millions of developers, yet most development is still done in ABAP.

                        And I’m still puzzled as to why SAP discontinued MBOs without having offline support with oData…. Who needs offline right? …..

                        (0) 
                        1. Midhun VP

                          SUP is one of the product in a list of products from Sybase. So you can’t say that SAP spend billions to get SUP. You are right from the standpoint that most part of SUP going to be replaced/removed.

                          Offline can be implemented even now with Odata, but the developers has to write a lot of code for it. The MBO part was good since there was no headache for developers in managing the data going back and forth. Hope for a better library for Odata to make the developers life easy.

                          – Midhun VP

                          (0) 
                          1. Joao Sousa

                            SUP is one of the product in a list of products from Sybase.

                            The Sybase purchase was mainly about mobility, and that’s SUP and Afaria. Little is left of the former. You don’t buy a company because of a list of products, the driver for the purchase was mobility.

                            Offline can be implemented even now with Odata, but the developers has to write a lot of code for it.

                            If the developers needs to code everything, then it’s not part of the framework (a very expensive framework by the way). What I said stands, SAP killed offline support with MBO without replacing it.

                            Hope for a better library for Odata to make the developers life easy.

                            Remind me again why I’m paying SAP, if the functionaly comes from a open standard?

                            If all SMP does is use “open protocols” why should I pay for the privilige to use them? I won’t, I’ll use oData without SMP.

                            (0) 
                            1. Midhun VP

                              You are right, SAP removed the proprietary solution provided by SUP and came with open protocols. SMP can be used if the customer want to ease the development to implement push notifications, user on boarding, SSO, security etc but the customer can decide whether its worth buying SMP 3 for these features since the SMP3 has the below limitations for now:

                              • Relay server not supported,only reverse proxy supported for now.
                              • Clustering not available
                              • End to End tracing is not supported.
                              • Data vault encryption for mutual SSL with X.509 not supported
                              • Integration Gateway design time tool not available etc.

                              SAP customers can go with SMP if they believe that SAP will be adding missed/additional features to the platform to make it a real mobile platform in the future. Or the customers can wait and decide. Its my opinion.

                              – Midhun VP

                              (0) 
                              1. Joao Sousa

                                Or the customers can wait and decide. Its my opinion.

                                Or the customer can implement another solution, or the extra features by themselves. SMP is very expensive, and implementing push notifications from scratch is trivial with iOS/Android.

                                The main feature of a Mobile Platform is the efficiency/coherence of the data and the development environment, not those extra features. Right now, that data component is supported by an open standard that I can implement by myself without paying SAP a dime, and the IDE well, it doesn’t exist.

                                And “Clustering not available” shows that SMP is an overpriced mess.

                                With all these lacking features, SMP should be free for SAP Customers. It’s based on open standards anyway.

                                (0) 
                                1. Paul Horan

                                  Clustering support is coming in the next SP to SMP 3.0.  But since there’s no state being maintained in the middle tier, as there was with the MBO model, a single 3.0 node will already scale to much greater levels than the 2.x architecture did.

                                  >>The main feature of a Mobile Platform is the efficiency/coherence of the data and the development environment<<

                                  I couldn’t disagree with that statement more. The benefit of a platform is in providing consistency across all the tiers in my applications – not just its ability to put buttons on a screen and build a pretty UI…  Focusing only on the UI is incredibly short-sighted.

                                  Take diagnostics and logging, for example.  I want all the log files on server and client to be written in the same format (timestamp, error code, app_id, error message, whatever), with a consistent error code system and file naming convention, with multi-language and time zone support.  Now imaging trying to coordinate that requirement across 10 development teams in 3 countries, building 30 mobile apps.  I don’t care how flexible your development environment or how robust your client-side code framework is, you’d have chaos – just on that feature alone!   With SMP, it’s one API call, and it’s already written for you. 

                                  (0) 
                                  1. Joao Sousa

                                    I couldn’t disagree with that statement more. The benefit of a platform is in providing consistency across all the tiers in my applications – not just its ability to put buttons on a screen and build a pretty UI…  Focusing only on the UI is incredibly short-sighted.

                                    Where did I say anything about the UI? Before saying I’m short-sighted you better read three times what I wrote. The phrase you quoted says “efficiency/coherence of the data” which has ZERO to do with UI, and the development environment of SUP (that they discontinued) also had nothing to do with the UI, was all about data modelling.

                                    If you’re going to call someone short-sighted you should be dammed sure of what you’re saying.

                                    (0) 
              2. Sajesh T

                Having said that, SMP 3 embraces new technologies and standards, in particular OData. To take advantage of achievements, you’ll have to work with apps that are ‘made for SMP 3’. See this doc for what we support with SMP 3.0: SMP 3.0 for Developers.

                SMP 3 embraces new technologies and we are left with no way to create solid offline applications!  Or is there something that I missed apart from offline OData? Or is it recommended to create MBO apps with SMP2.3 dev tools and use them in SMP3?

                (0) 
                1. Midhun VP

                  A complete Odata offline is planned for the future by extending the persistence library. Offline sync with high volume is not available now.

                  – Midhun VP

                  (0) 
    3. Arun Santhanam

      i feel when we compare 1 on 1 it should be SMP to another mobile platform. When we compare Fiori it could be compared to some apps like (Rex or Sales manager) it would make more sense. Saying so i’m not declining these information provided above i means say that i could be of more value add in that case. Bcos in future if you want offline then it bcos mandated to have SMP so there cannot be another thought.

      (0) 
  7. Suseelan Hari

    Hi Sheetal Deshmukh,

    Thank you for sharing about SMP Vs SAP Fiori, I am doing cross training in SUP and I will try to update the information from this blog. Thank you so much for sharing nice blog. Keep it up!

    Regards,
    Hari Suseelan

    (0) 
  8. Uday Kumar Kanike

    Very helpful article.

    But my doubt is, if customers want to develop custom apps with low TCO & TCD, they would still have to invest lot of money in SMP. Because, Fiori app may not fulfill their requirement for their business scenario and they would have to build custom app using SMP SDK which can turn out to be expensive.

    It there a way to reduce or avoid this cost?

    Regards

    Uday

    (0) 
    1. Midhun VP

      SMP is providing you with best features to your application enterprise ready, so definitely cost involves. If you don’t want to use any middleware you are free to do that, you can directly consume Odata services to mobile apps from NW gateway. When you are not using SMP you need to invest time and resource to do an R&D to add enterprise features like SSO, data encryption, user management, push notifications to your application. SAP is providing you different solutions with and without(have a look at SAPUI5 framework with phonegap) SMP. Its your choice to select a technology based on your requirement.

      Midhun VP

      (0) 
  9. Alejandro Yabrudy

    Hi Sheetal,

    Thanks for an excellent article. I think that the included table have all the elements to clarify the differences between both mobile solutions. It’s a good starting point for understanding SAP mobile initiatives.

    (0) 
  10. Phileas Fogg

    Hi everybody,

    We are currently doing some proof of concept with SAP FIORI apps and I would be very grateful if you could give me your thoughts regarding some questions have come up.

    We are currently using SMP as our mobile platform where we deploy our mobile applications. In case of new applications for consuming SAP backend data where no SAP FIORI standard app exists, which will be the best approach to follow? Using SMP or implement FIORI based applications? Which are the pros and cons of each approach?

    I really appreciate your input.

    Kind regards.

    (0) 

Leave a Reply