Developing Mobile Apps with Sybase Unwired Platform 2.1 and SAP NetWeaver Gateway 2.0
Disclaimer: Views expressed here are strictly personal and present only one approach for mobile app development using Sybase Unwired Platform (SUP) and SAP NetWeaver Gateway (GW). Please consult with the SAP Integration and Certification Center (ICC) to learn more about other available integration scenarios.
This blog describes the integration scenario when developing mobile apps using GW 2.0 and SUP 2.1.
Sybase Unwired Platform is at the heart of SAP’s mobile strategy. It has seen tremendous growth and just recently, the company announced an impressive milestone as it hit the €500M mark in mobile pipeline with more than 350 new customers and 17.5 million total seats in 2011.
With the recent release of SUP 2.1, SAP and Sybase are promoting seamless integration and closer alignment of their technology stacks with the introduction of SAP NetWeaver Gateway integration. This new architecture of combining SUP and GW promises not only to ease but accelerate the development cycle of mobile apps and facilitate integration to the SAP back-end by exposing processes as easily consumable OData services. For mobile app developers who have experienced first-hand the challenges of interfacing with SAP back-end processes, this comes as a welcomed addition to an already impressive platform.
With such promises and encouraging claims, many are eager to jump onboard and be part of the burgeoning ecosystem which by SAP’s estimate, should contribute upwards of 80% to future SAP-related mobile app development. As often the case with anything new, there’s some confusion on this new approach and many are wondering how it works and more precisely what this architecture translates to in terms of development effort when compared to the current main approach for integrating backend SAP processes with Mobile Business Objects (MBOs). Certainly, there’s a lot of information on the respective websites of SUP and Gateway yet there is little information generally available on the integration of these two components (at the time of writing in January 2012). This state of affairs combined with the launch of the Mobile App Certification for partners and ISVs by ICC has compelled me to shed some light on this new approach and share my experience.
In this blog, I will introduce mobile app development using SUP 2.1 and Gateway 2.0* by providing an overview of this architecture and more importantly, how to enable the integration between these two components.
*restricted to online native apps only, hybrid apps will not be discussed here.
First, let’s start with the basics. Prior knowledge of mobile app development using SUP is clearly indispensable in understanding the topics discussed here and how this new approach differs from current standards. Before I proceed, I invite you to review some basic concepts of mobile app development with SUP (including MBO) and SAP NetWeaver Gateway (including OData) if you are not familiar with them. Here are a few links to help you get started on the right track.
If you’re new to developing on SUP altogether, there is a nice starter page on SDN compiled by Stan Stadelman, Product Manager for SUP:
To that, I would add the following compilation of resources:
- Sybase Unwired Platform – An Introduction (Part 1) on SDN
- SUP Product page on Sybase
- SUP Installation
- SUP Online Documentation on Sybase
- Developing Mobile Applications with Sybase Unwired Platform MBO
- MBO Best Practices
- Which Mobile Architecture Should I Use?
- SUP Apps on Code Exchange
- Getting started with SAP NetWeaver Gateway
- Introducing OData
- OData SDK Developer Guide
- Gateway Installation
- Gateway How-to guides
- Gateway Online Demo System
In a nutshell, SUP is an integrated platform that enables mobile devices to access back-end enterprise data. Prior to version 2.1 of SUP, the primary development approach for creating native mobile apps with SUP to connect to SAP systems was through MBOs. MBOs encapsulate back-end business logic which is made accessible on mobile devices. When integrating to an SAP back-end, MBOs are usually derived from a BAPI (via WS or JCO). Consequently, the integration scenario that I present here will be compared to what I refer to as the “MBO approach” since it’s the most common one and it provides a good point of reference. As for SAP NetWeaver Gateway, it is essentially a component that exposes SAP Business Suite processes as OData services (OData & Generic channels will not be discussed here). This is perhaps an oversimplified summary so please take a look at the resources mentioned above for more information.
UNDERSTANDING THE NEW ARCHITECTURE
Let’s now discuss this new architecture in comparison to the previous model of MBOs and highlight some key differences. First off, when developing a mobile app using SUP you have the choice to adopt (or not) SAP NetWeaver Gateway, in case this was not clear. MBOs have always been at the core of SUP and they still have their merits. They remain an interesting option, even a better choice for some scenarios. With SUP 2.1, SAP is proposing a complementary approach to ease the development effort but furthermore, SUP and GW tackles the challenges posed by a specific class of application defined as “online apps” (as opposed to offline apps). This approach is specific to this class of application (in this release anyhow).
“Online apps” are defined as lightweight apps with rather simple business use cases or processes that are almost always connected and store little or no data on the device. Technically speaking, this category of applications usually relies on synchronous messaging based on the request-response pattern. If your application fits this model than the general consensus is to use SUP in conjunction with SAP NetWeaver Gateway as a scalable and viable mobile strategy. If you want to know more about which mobile architecture to use, take a look at this blog from Sybase.
The SUP and Gateway integration is enabled by the Online Data Proxy. The primary focus of this blog is highlighted in blue.
Surprising claims aside, the integration of SAP NetWeaver Gateway does provide some very interesting benefits. First of all, it should be stated that the vast majority of mobile development projects at SAP rest on Gateway. The slew of SAP-delivered mobile apps out there (or upcoming) is based on this architecture so there is most certainly merits to this manner. Simply, I would say that the best reason for adopting this approach is OData and how it can easily allow information from SAP systems to be easily consumed on a variety of devices. This protocol is extremely appealing as it is based on open standards, it’s easy to consume and simple to use (think in terms of http). Since OData is meant for all types of clients (not specifically mobile apps), nothing prevents your gateway services to be reused and consumed by a variety of other devices or applications if engineered properly.
Another good reason to favor this approach is the fact that all the data modeling is encapsulated at one level, the backend (contrary to the MBO approach where business logic also resides on the middleware). Needless to say, if your company is already a SAP Services Partner then you are better off investing in the in-house ABAP skills and perform all the programming in the back-end vs. having to program custom Java code (such is the case with SUP’s result set filters).
Finally, one common issue that developers encounter most when modeling MBOs to interface with the SAP back-end is that MBOs are generated based on existing BAPIs and this can pose quite a challenge. The inherent problem with this method is that existing BAPIs are not necessarily best suited for the purpose at hand as they have been designed for desktop-grade applications with different requirements in mind (think heavy and complex processes). This makes the modeling task far more complex than the trivial exercise it is supposed to be. Indeed, in this particular case the modeling task is neither straightforward nor confined to using the MBO generation tool. Linking MBOs and mapping attributes is now a tricky exercise. And so more often than not, developers decide to implement custom ABAP code to meet the specific needs of their mobile application. I think this is one of the most compelling reasons for adopting GW. If there is a clear requirement to develop your own BAPI then it’s easy to see why it makes a lot of sense to implement them in the back-end within the context of Gateway services and benefit from reusability, extensibility and scalability.
Now that you understand the benefits of using SUP and GW, let’s take a look at how to enable the integration between both.
HOW TO GET SAP NETWEAVER GATEWAY
A complete pre-packaged SAP NetWeaver Gateway Trial version is available in the Downloads section of SDN (note that Linux or Windows Server 2008 is required). Or, you can proceed with the easy route and opt for the SAP NetWeaver Gateway Demo system. This is more than enough if your goal is to understand the basics.
HOW TO GET SYBASE UNWIRED PLATFORM 2.1
At the time of writing, a trial version of SUP 2.1 is only offered to Sybase partners or customers. SAP partners should consult the SAP Service Marketplace or their partner manager.
The first thing you will notice if you are familiar with SUP 2.0 is that the software installation package for SUP 2.1 has been split into two 2 distinct components: SUP Platform Runtime and Mobile SDK. This is a good thing since it is purposely addressing the needs of deployment vs. development. You will need to install both packages.
INSTALLING THE SOFTWARE
The focus of this blog is really about the technical aspects of the integration scenario. Personally, I did not encounter any major issues by following the installation guides and so I will not cover the installation process. There’s already some good sources of information on this topic, check them out:
– SAP Developer Network: Installing Gateway
– Sybase Online Documentation: Installing SUP 2.1
A typical development flow can be initiated using a top-down or bottom-up approach (in the same way as MBO design). This is still true when developing online apps using GW and SUP. Actually, the development flow does not differ much from the standard way but you have to keep in mind that all the modeling and adaptation tasks that were required for SUP have now been moved to GW. Essentially, you will develop your client code, expose Gateway services and configure your SUP server to allow your device to consume OData services. Since, we do not have any MBOs with this approach, there’s no modeling, mapping of attributes or generation of device-specific client code to interface with the MBOs.
EXPOSING ODATA SERVICES
SAP NetWeaver Gateway is an OData provider meaning it exposes existing SAP Business Suite processes as OData services. Simply put, it takes RFC data from SAP back-end and “adapts” it into OData. For developers familiar with MBOs, this implies that your business logic will reside solely on the back-end and not on the SUP server. For the purpose of this blog and to showcase an end-to-end scenario, I invite you to use the SAP NetWeaver Gateway demo system. Most development projects will probably require creating your own Gateway services and in this case, the how-to guides on SDN cover a wide range of possibilities on how this can be achieved.
DEVELOPING THE CLIENT APPLICATION
On the client side, you must develop your client code using the OData SDK in order to enable your mobile device to consume OData services (OData SDK is shipped with SUP 2.1). The OData SDK currently supports iOS, Android and Blackberry platforms. The installation steps are described on the Sybase documentation websitehttp://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc01708.0210/doc/html/title.html (see the OData SDK Developer Guide).
It is also worth noting that as of SUP 2.1, the OData SDK only supports native mobile application development. This is certainly a deal breaker if you are building apps using the mobile workflow package (hybrid apps running on the hybrid web container).
Once OData services are exposed and provide access to back-end SAP processes, the remaining step is to enable the client application to access them by configuring SUP via the Sybase Control Center (SCC). When used in conjunction with Gateway, the SUP server is no longer a container for business logic but acts as a dispatcher of requests from mobile devices located outside the corporate firewall to Gateway and provides more infrastructure-centric functionalities, such as user handling, security and so forth. To give you a clear idea of how this is done, here is a step-by-step guide:
Open SCC (https://localhost:8283/scc/)
Sybase Control Center Welcome Page:
Select Applications à Select Application Connections tab à Press button Register…
Fill in information specific to your app to register a new application connection (*pre-requisite: your application has already been created/defined in the “Applications” tab of SCC)
New Application Connection Registration:
Select the newly created item and press button Properties à Select Proxy à Enter value for field “Application endpoint” to direct to your OData service (for GW demo system, simply fill in the URL of the sample consumption model here).
Application Connection Properties:
Click OK and we are done configuring the connection to the Gateway OData provider in SCC.
As you can see, once the client code has been implemented using the OData SDK and the OData service has been made available from Gateway, integrating GW and SUP is simply configuration work. This is quite different from the MBO approach as there’s little development effort required on SUP. With this approach, there’s essentially no more business logic residing on this component (tasks such as managing devices/users and security remain).
With the release of SUP 2.1, SAP is offering a compelling integration scenario to easily access complex SAP processes and help mobilize the workforce. Developing mobile solutions using SAP NetWeaver Gateway and SUP offers many benefits such as the ability to leverage existing ABAP skills and confine the complexity of business logic in the back-end layer. More importantly, the main advantage of this approach and key differentiator is the ability to expose information using the OData protocol.
A few years ago, SAP established a bold strategic goal of reaching a billion people by 2015 and this release is a step in that direction. It provides scalability in distributing critical business information stored in SAP systems across multiple devices and platforms. Furthermore, the recent launch of the SAP Store for Mobile Apps illustrates the ambitions of the company in promoting a rich and vibrant ecosystem for enterprise mobile apps. And ICC is certainly aligned with this effort as it rolls out the Mobile App certification for partners and ISVs.
The New Year is off to a great start and should be a thrilling one for mobile app developers as news of new developer resources have already been announced. Decidedly, it’s a great time to build enterprise mobile apps. Get started now by getting in touch with ICC and learn how simple it is to get your mobile app certified and on the SAP Store!
Allow me to reiterate that the approach discussed here is only one of many integration scenarios available to partners and ISVs. If you are interested in learning more about the Mobile App certification, please contact SAP ICC at firstname.lastname@example.org to discuss your interest more in-depth.
Trust me, the 1st post is the hardest one by far. Hope to see much more from you in future 😉
However, I wonder if there might be a third, viable option - to build a custom RESTful service using the SAP ICF framework, bypassing MBOs and Gateway all together (some excellent blogs have previously discussed how to do this http://goo.gl/9j9om). If the number of applications in the enterprise is small and requirements are relative straightforward, this seems and attractive option. OData is a sophisticated protocol, but it requires some effort to build an OData service, and perhaps a full fledged OData/Gateway service is overkill for a few, simple applications. What I don't know is if SUP would be able to communicate with such a RESTful service?
Thanks for the feedback! I would also keep in mind what kind of apps I want to build when considering my options. Right now, SUP+GW is best suited for online apps. As for your third option, it's certainly interesting(thx for the link). Technically, SUP supports the creation of a connection profile from a REST WS so it might work (using MBOs). However, I should point out that it's not supported as an integration scenario from ICC if that's a concern.
Just seeking clarification here. By saying ' it's not supported as an integration scenario' does that mean that if partners code apps with custom REST APIs from ICF rather than using GW, they won't be certified?
@David; Great work in this blog.
Apps with a custom REST solution won't be certified. It is however possible to use custom REST as a datasource in SUP.
Certification is a prerequisite for adding your app to the SAP appstore.
@David; Great work in this blog.
Apps with a custom REST solution won't be certified. It is however possible to use custom REST as a datasource in SUP.
Certification is a prerequisite for adding your app to the SAP appstore.
Thank you for the positive comments!
Well, regarding my "not supported" comment, I saw this coming and I actually wanted to edit it the moment it was added (I should have said "might not" be supported). In any case, I apologize for the misunderstanding. Allow me to rectify: as a general rule for the mobile app certification, if what you are developing is supported by SUP (i.e. REST web services) then it should be fine for the certification. But because every mobile app is different, I invite you to get in touch with us so we can discuss your needs in detail (email@example.com). It is never too early to involve us if you wish to get your app certified and have it on the SAP Store.
@Wim: thank you for pointing that out!
Great first blog post.
Can you please give us the reasons why such a mechanism would not be supported? That would help this discussion for sure.
the role of an MBO will remain one of a DTO (data transfer obj) between frontend and backend. I associated REST WS with MBOs because your MBO can be created/binded using the MBO generation tool with this type of data source... In any case, it's an interesting setup!
Great post Dave, I was looking for some info on SUP and GW and how they work together... this gave me a pretty good idea. I'll come see you if I have more questions!
Two additional resources:
Holy cow David, that is one great article. I can visualize a big decision matrix in my brain. Online-only versus Offline-enabled, MBO versus Gateway, native versus HWC.
Thanks a lot David. It's very helpfull info for me as a bignner.
and its help me alot to understand path of mobile Development using SUP and SAP gateway.
Thanks a lot for a great article David. Dear colleauges, kindly clarify the need for Sybase Unwired Platform. If we have selected a non-SAP Mobile product as our Enterprise Mobility Management suite (for example, Zenprise), why would we need Sybase Unwired Platform to access our SAP Business Suite? Thank you all in advance.
That is entirely your choice. However, from my experience the majority of 3rd party platforms will serve you only as mobile development platforms. That means, you are developing your apps from scratch, with some assistance (code generation or other) from the particular platform you choose. Only the SAP Mobile Platform additionally provides you with a suite of apps that you can purchase from SAP to run with end-to-end integration working out of the box with SAP Business Suite. So when comparing SUP with other platforms, this is one factor to take into consideration ... http://store.sap.com/mobile
You might be able to custom code a couple of apps using your 3rd party platform, but can you code the 100+ apps provided by SAP and supported ongoing by SAP? Don't underestimate the cost to support your own custom apps. With every new mobile operating system release (eg. iOS6.1) you might need to revisit your apps - and at the moment the these are being released at a rapid pace.
I'm not saying you shouldn't use another platform, just go in with eyes wide open about what that might mean from a pros and cons perspective.
I just looked up Zenprise and that appears to be a mobile device management solution.
That is very different to a mobile application development platform like SUP. I'm afraid you're comparing apples and oranges.
As at today, yes the majority of those apps require SUP in order to be supported by SAP. You will need to look at the pre-requisites for each app. For most of the productivity on-line apps, SUP acts moreso as a secure authentication provider and as a reverse proxy, whereby the OData communications is from NW Gateway to the app, via SUP.
I have recently noticed a few apps that can be supported for use directly with NW Gateway within the intranet. Look at the installation guides for apps like SAP Performance Monitor, or SAP End User Experience Monitoring. Although these particular apps seem to be ones which connect with NW Gateway in Solution Manager, so they are only useful for your technical support people, not your real end users.
The other consideration you might need to be aware of is the new Agentry platform (from Syclo) which SAP acquired last year. This is planned to be merged with SUP. I have heard through the grapevine (and confirmed with an SAP contact) that SAP have moved the CRM Sales app to Agentry. This is an app that has offline syc capability. You should be aware of this because that means also that not all apps are on SUP. Also with the acquisition Syclo had pre-existing apps that integrated with SAP running on Agentry. This included some apps for field services and works management, among others.
Thanks a lot John. Much appreaciated.
For SAP partners, the guidelines outlined in the SAP Mobile Apps Partner Program https://www.sapmobileappspartnercenter.com/ may be useful:
"The SAP mobile platform to build mobile apps consists of: (1) Sybase Unwired Platform, (2) SAP Afaria, and (3) SAP NetWeaver Gateway."
As a result we have partner apps live on the SAP Store that use Sybase Unwired Platform or SAP NetWeaver Gateway.
Exclusive Post David. Much appreciated.
Very nicely documented, covering end-to-end in completeness.