Follow these best practices and tips outlined by Ameya Pimpalgaonkar if you are planning to execute an SAPUI5 project. See how an SAPUI5 project differs from a traditional project and why the design process is essential if you want to avoid technical errors.

Key Concept

It is essential that all SAPUI5 projects begin with a user-centered design of application wireframes. Wireframes should always be the starting point that roughly captures an application’s structure. Based on approvals, a high fidelity prototype must be developed capturing color schemes, design, and look and feel, including the navigation structure. I recently had a chance to talk to a few people who have worked on SAPUI5 implementation projects. When asked about execution of their projects and whether they were any different from traditional SAP projects, they all said their projects were run and executed exactly the same as a traditional SAP project. However, in my opinion, traditional project execution does not apply to SAPUI5. Not developing an SAPUI5 project strategy for execution can cause problems in the build and delivery phases. The bottom line is that SAPUI5 projects must not be planned and executed on the same line as that of other SAP projects. Therefore, I decided to write this article to provide clear guidelines for organizations that are planning an SAPUI5 implementation project. The primary reason why SAPUI5 projects are still executed like traditional SAP projects is that the team involved in the project planning and architecture development has little exposure to technology barriers, challenges, user experience (UX), and most important, an understanding of how SAPUI5 is different from other SAP user interface (UI) technologies. In this article, I introduce a better approach to SAPUI5 project execution, covering all technical dependencies, UX strategies, building SAPUI5 applications, best practices, device agnostic applications, and finally, how to deliver a deployable application for any mobile platform. These details must be planned separately so that technical resourcing and planning do not affect the delivery of the project.

Beginning with an SAPUI5 Project

Any project typically goes through different phases such as blueprint, development and build, user and business testing, and delivery. SAPUI5 isn’t an exception to this process. However, planning and execution differ significantly compared to traditional SAP projects. For the sake of simplicity, I will keep the discussion focused around the technical planning and execution phases. How are SAPUI5 projects different? The answer to this question is simple—the underlying technology and the UX expectations. SAPUI5 promises to deliver a commercial grade UX and that is why design methodology becomes more important. Design is also one of the aspects that the majority of organizations have been neglecting so far. I have been developing SAP UIs for the past nine years and I have experienced how ignorant organizations are when it comes to incorporating a UX strategy and thinking of usability as the starting point of the project. Most times, team leads convey what screens are to be developed and people start UI building without even thinking about users and the challenges that these UIs are meant to solve. In addition, the WebDynpro framework restricted developers in a way by providing limited layout and scripting capabilities. Consider the following points when you start planning for an SAPUI5 project:

• Develop a UX strategy or re-use an SAP UX strategy for the project
• Onboard a design team that is responsible for wireframes and visual design
• Spend time on building prototypes and get them approved before the development phase
• Follow design principles and best practices for SAPUI5
• SAP developers may not have Cascading Style Sheets (CSS) and scripting capabilities, so ensure you have the required skill set on the team
• Think about mobile or desktop options before the development phase is started
• Allocate sufficient time for unplanned and unknown challenges in the build, deploy, and deliver phase
• Think about the responsiveness of the applications
• Think about deployment and delivery
• Most important – understand the limitations of an SAPUI5 framework. It isn’t a panacea.

What UI5 Is Not

Before I get into UX and design strategy, it is important to understand what SAPUI5 is not. Put simply, SAPUI5 is a JavaScript framework that enables you to develop web applications for SAP systems. SAPUI5, being a JavaScript framework, differs significantly from other SAP development tools such as SAP NetWeaver Developer Studio (NWDS). SAPUI5 should be looked at from the aspect of web applications and not just as an SAP development tool. SAPUI5 bridges the gap between web applications and SAP systems. Therefore, practices that apply to web application design are also applied to SAPUI5. SAPUI5 is not a development environment; rather, it is a framework that can be extended and enhanced to develop SAP-focused web applications. SAPUI5 enables you to develop commercial-grade SAP applications with tools such as the SAP Web Integrated Development Environment (SAP Web IDE). In addition, SAP Web IDE also enables you to customize SAP Fiori applications. However, to enable these applications to provide a commercial grade user experience, you must carefully work on design aspects such as CSS, custom layouts, responsive design, and delivery of applications in a native installable format. Without a UX and design strategy, you will get nowhere despite using SAPUI5 for every UI requirement in the project.

Develop a UX and Design Strategy

This is one of the most distinctive steps exclusive to SAPUI5 projects. If you try to save time by avoiding this step, you will spend more time in the build and acceptance phases of the project. Note: If you do not have enough time or the skill set to develop your own UX strategy, simply adopt the SAP UX strategy to accelerate development. However, in addition you must cover the following points: device-specific delivery, a device-agnostic approach, design and prototypes, and wireframes. A number of tools are available that can be used to build UI strategy—for example, SAP Splash. It is a collaborative design tool that enables non-technical users to develop interactive prototypes. You can find more information on Splash here: https://standard.experiencesplash.com. In addition, SAP Fiori stencils can help to kick start your UX strategy by following pre-designed and configured stencils. Use the SAP Fiori icon set that comes with stencils so that your design and prototypes follow unified designs. With this, you indirectly align with SAP UX strategy as you do not have to design UIs and icons or even the framework from scratch. Note that SAP Fiori stencils require a license to Axure, but it is free for 15 days. You can try out features and work with stencils. However, to use them in a productive environment you need a licensed copy of Axure. These resources can help organizations build a UX strategy that is aligned with SAP standards and hence make it easier for organizations to build demos and prototypes quickly. These tools also support the SAPUI5 framework so that there is no disconnect between a prototype or a UX strategy and the actual application UI. For more information on SAP Fiori stencils go to https://experience.sap.com/fiori-design/resources/downloads/. For more information on SAP Fiori design guidelines go to https://experience.sap.com/news/new-sap-fiori-design-guidelines-launched/. These are not ready-to-use strategies and guidelines if you are looking to cater to a highly specific UI scenario. However, you can use these guidelines as a starting point and build a custom strategy from here.

Importance of Wireframes and Prototypes in SAPUI5 Projects

It goes without saying that wireframes play an important role in any application development. They help streamline important aspects and sections of the applications by bringing the most important features of the applications up front. In any web design or web application design project, the starting point is always wireframe design and prototyping. Unfortunately, organizations are still not looking at SAPUI5 in relation to web apps. Therefore, wireframes are rarely designed, resulting in a poor UI and user experience.

SAPUI5 is a Web App First

This is exactly what I tell any new SAPUI5 developer: SAPUI5 is inherently a web app that is designed specially to communicate with SAP systems. You can look at the SAPUI5 app as a web application wrapped in a new extension. If this is the case, why not start considering web application design principles for SAPUI5 applications too? This is the fundamental change required today.

Wireframes Can Help You Get an Early Stage of User Experience

Wireframes help you understand what feature needs to be where and how to define the user interaction point. Wireframes can help you identify potential usability glitches and problems that can easily be eliminated before development. Many SAPUI5 developers lack this view today.

Wireframes Can Help You Identify Framework Limitations Early

SAPUI5 also has certain limitations that need to be considered before development begins so that developers know what UI control to use and what not to use. For example, the SAPUI5 SplitContainer API was in beta earlier in 2015, so using this API in a productive environment would have been a major concern. However, SplitContainer is no longer in beta, but it is important for architects to know such details early on in the project.

Wireframes Can Help You Select the Appropriate Layout for Application

If an application is supposed to be responsive, it is important to draw separate wireframes for both landscape and portrait designs. SAPUI5 provides a responsive layout that can be selected and fixed even before development begins. In addition, often you have to consider some additional responsive design principles such as grid design, view port tags, or media queries. These points must be considered in project effort estimates. This step primarily helps in getting organizations and developers on a same level of understanding about how a UI should look and how should it behave on different devices. With approved wireframes and prototypes, developers are aware of display requirements from the beginning and hence extra caution can be taken at the time of UI design. This certainly eliminates gaps between the expectations and the delivery of the application. A prototype, on the other hand, helps everyone understand what goes where. It also briefly explains the navigation structure of the application and briefly showcases the overall architecture of the application. Wireframes act as an input to prototyping. Therefore, the prototype must be developed only after wireframes are approved and frozen. The point to take away here is that it is important to consider design aspects of the SAPUI5 application along with application usability, user experience, and UI control selection. This helps save time during the development phase that is otherwise wasted in fixing issues.

SAPUI5 Application Design Decisions

The reason this section is placed right after the UX and design strategy section is simple. UX and design strategies help you make some of the most important decisions about SAPUI5 application design, delivery, and of course, security.

Design Decision – Desktop or Mobile?

When application development begins, developers need to choose APIs and methods appropriately so that the application design meets the goal. For example, if a user intends to design an error console for IDoc processing for managers on the move, the application should be designed for smartphones or tablets. An application developed for a desktop affects UX significantly. In fact, the user may not be able to use those applications at all. SAPUI5 delivers every UI control in two flavors – desktop and mobile:

• Desktop – Methods beginning with sap.ui.commons.xxx are meant for desktop applications. When you know for sure that application will not be used on a mobile device, it makes sense to develop an application dedicated to desktops.
• Mobile – Methods beginning with sap.m.xxx are meant for a mobile device. One of the major advantages of using this method is that applications designed for mobile devices can be consumed on a desktop.

Design Decision – UI Control Selection

Wider penetration of commercial mobile applications on the Android and iOS makes it extremely important to choose the right UI element for the right actions. Users will expect a similar user experience and functionality from your SAPUI5 application, and a wrong UI choice will adversely affect the user experience. SAPUI5 offers additional and newer UI elements than that of WebDynpro Java and ABAP. This is also one of the reasons you need to understand the functionality of your application much before development starts. This is where a wireframe will help you select the right UI for the right functionality. In my previous project, we developed a mobile app based on SAPUI5 that displayed the IDoc status and allowed users to respond in case of any pending action. Because there were no finalized wireframes and UI strategy, we struggled a lot with development. We ended up experimenting with a number of different UI elements and wasted a lot of time. In the following section, I take you through some of the incorrect UI selections. Often, I have seen many of the following UIs being used incorrectly. SplitApp and SplitContainer: I have seen developers using SplitApp and SplitContainer interchangeably. This is an incorrect interpretation of both these UI elements. The first point to note is that SplitApp is a parent class of SplitContainer. In short, SplitContainer is a borrowed class of SplitApp. However, as a developer, you are free to use either but only when you understand when to use SplitApp and when to use SplitContainer. SplitApp has only one event called orientationChange and it is fired when the orientation of the device is changed from portrait to landscape and vice versa. On the other hand, SplitContainer has a slew of different events that are fired at different conditions— for example, afterMasterClose and afterMasterOpen. In a nutshell, SplitContainer provides a much more detailed level of control over the application in various different conditions. Read more about these events here: https://openui5.hana.ondemand.com/docs/api/symbols/sap.m.SplitContainer.html. Drop down: One of the applications I reviewed earlier this year had a user registration form in which it was mandatory to indicate whether the user is a male or female. The developer used a drop down for this feature and therefore incurred an extra click to select the required data. You should use a drop-down UI element only when there are three or more options to be selected. Although this point is not specifically meant for SAPUI5, all web applications should follow this approach. Text field: For long-range values, often drop-down UI elements are used incorrectly—for example, birth year. I have seen this on almost all the applications I have reviewed so far. Instead, it is much easier to provide a text field and a specific format as the value holder so that the user understands the format to be used to enter the day. Pull to refresh: Pull to refresh is overused and can make applications over intuitive. Pull to refresh makes sense only when there is a new line item or a new update in the ordered list such as an email inbox or even a Facebook timeline update. However, if you are not using an ordered list, then using this feature just to refresh the data is wrong. The reason I am covering this point is that I came across this in my previous SAPUI5 project. In this scenario, we wanted to display IDocs with different error states. We had categorized IDocs in Error, Warning, and Success statuses. Therefore, using pull to refresh was not making sense as it would incorrectly tell the user that there is a new item at the top of the list. However, the new item could be in any category. We simply removed this feature, used the refresh button instead, and changed the color of the IDocs based on time. This correctly resolved the issue and the UX improved immensely.

Design Decision – Frameworks

First, understand that SAPUI5 itself is a framework. However, given some of the limitations of SAPUI5, you need to understand what other UI frameworks can fill in the gaps left open by SAPUI5. For example, the right detail navigation menu isn’t available in SAPUI5. You can build this UI with jQuery Mobile. Blending different frameworks with UI5 is not a recommended practice. Firstly, it would have a different look and feel, which depreciates the user experience. And secondly, third-party frameworks are not supported by SAP. The proper way would be to modify SAP’s controls or to build a new control from scratch. jQuery Mobile: Being an HTML5-based development framework, jQuery fits seamlessly into SAPUI5. You can build custom UI controls and libraries with jQuery Mobile. Note that jQuery Mobile is known to be resource heavy. So understand the limitations of jQuery Mobile before thinking of using it in an SAPUI5 application. Sencha: Sencha Touch is yet another UI development framework that is especially used for HTML5-based mobile applications. Sencha Touch also uses Model View Controller (MVC)-based development methodology and therefore it blends seamlessly with SAPUI5. Cordova/PhoneGap: This is more of a mobile middleware that helps wrap and convert any web application into an installable and native hybrid mobile application. SAPUI5 applications can easily be wrapped and converted into Android applications with Cordova. For iPhone, you have to use Apple tools. It is important to note that unless it is really required that you deliver SAPUI5 applications in a native format, you can use the SAP Fiori client for mobile platforms such as Android, iOS, and Windows. SAP Fiori Client is a mobile run-time client for SAP Fiori and it enables a native user experience for SAP Fiori applications. For more information about SAP Fiori Client go to https://scn.sap.com/blogs/johnwargo/2014/01/25/sap-fiori-client. Some other frameworks are Ext.JS, EmberJS, AngularJS, and Kendo UI. Before you jump and use these frameworks, study the limitations of each framework in detail. Covering these frameworks in detail is not in the scope of this article.

Design Decision – CSS Rules

The UX in SAPUI5 is not only based on layouts and APIs, but is also heavily dependent on CSS rules. This does not mean that in built layouts, APIs are not sufficient to build applications with a superior UX. However, to provide a unified UX across different platforms, CSS helps immensely to streamline rendering and screen adoption irrespective of the size. SAP UI Theme Designer: SAP UI Theme Designer is a tool that enables you to modify or create new themes for your SAPUI5 applications. This tool is a WYSIWYG browser-based editor that can be used to modify an existing theme or create a new theme from templates that are provided. New or modified themes can also be applied to SAPUI5 desktop applications, saving significant time that is otherwise spent on writing a custom CSS or editing the standard one. However, note there are limitations to using these themes. First, only standard SAPUI5 libraries can be themed. If you have a custom library, you must write a custom CSS to style the UI element accordingly. Also, for mobile applications, you may have to develop a custom CSS. Go here to learn more about the SAP UI Theme Designer. Media queries: Media queries are CSS rules that enable your applications to render a different style for different devices and screen resolutions. Media queries help in developing applications that adopt screen changes and yet provide a unified UX. Transition properties: Transition properties enable an application to change value over a period of time instead of immediately. Transition properties are browser specific and hence it is important to use a browser prefix to provide unified UX across all browsers. Internet Explorer (IE) fixes: IE does not support certain CSS3 properties such as border radius. Therefore, to ensure the UX is not hampered if someone runs an application in IE, it is important to understand how to fix these issues. For example, you can use PIE.CSS in IE to enable a border radius.

Design Decision – Layouts

SAPUI5 provides a number of different layouts that need to be used carefully for specific use cases only. For example, do not use a master-master-detail layout when the application navigation hierarchy is only two levels deep. The layouts are all available in the SAP Web IDE to use as predefined templates. When you use a predefined template from the SAP Web IDE the code is auto-generated. Following are use cases for different layouts: Master-Detail: This pattern is supported by SplitApp control of SAPUI5 and it is just a master list displaying a list of content that allows lead selection and its detailed view. This is mostly a starting point in application building. Master-Master-Detail: Think of a shopping cart or trip booking application. You don’t want your trip to be booked right on the first page or payment to be made when you visit a shopping cart. You want to see a confirmation page that shows what you are buying or which flight you are booking. It also should displays details of the transaction in the detail section. Full Screen: This is best suited for displaying charts, bar graphs, and pictorial data. Multi-Flow: SAP recommends using this pattern when the application flow is too complex and you need to use all patterns together to build the working app.

Technical Mistakes to Be Avoided

Following are some aspects that must be taken into consideration before you start planning an application landscape and architecture. For example, if you have cross-domain communication as part of your enterprise landscape, and if your SAPUI5 applications are supposed to consume third-party Open Data Protocol (OData) services, then you must plan how to manage cross-domain communication issues. Similarly, it is a common web security practice not to use HTTP calls to authenticate users if your SAPUI5 application involves user authentication. Cross-Domain Communication Often, OData services that originate in one domain and are consumed in another give errors with a standard OData model. An OData model linked to such a third-party service always returns no data to be displayed in the table despite having no error in service execution. This happens because browser security blocks the cross-origin calls to be performed and that is why one of the following approaches are used. CORS stands for cross-origin resource sharing. There are two ways to use CORS in your SAPUI5 application. Either use CORS filters to enable cross-origin resource sharing, or use a CORS Heroku App. The later approach is done by making proxy request via a Heroku app server. For more information on CORS filters go to https://enable-cors.org/. For more information on CORS Anywhere go to https://www.npmjs.com/package/cors-anywhere. Mistakes to Be Avoided CORS Anywhere is not a recommended approach for one simple reason. If one uses the following URL pattern to bypass the origin issue, then you are basically getting data through the Heroku app. There is no control over data security in case the data being fetched is related to banking or any other sensitive data. No matter how quick and easy it may seem, never use this approach for applications in a productive environment. The URL pattern is https://cors-anywhere.herokuapp.com/<URL to OData>. XCSRF: To prevent cross-site request forgeries, SAPUI5 has provided an XCSRF token that must be used every time either authentication is performed or a database modification request is sent to the server. For example, if your SAPUI5 application is using HTTP requests such as GET and PUT, you need to use this token for every PUT request. Mistake to Be Avoided Do not use an XCSRF token for a GET request as there is no data modification being performed. An XCSRF token does not support requests that do not require authentication. If you still use an XCSRF token, you may get an HTTP 500 internal server error. Also, if SAPUI5 applications use user authentication, it is important to use an XCSRF token with every authentication request. It is also important to understand the lifetime of this token. If a user is inactive, the token should expire as well. These scenarios if not handled correctly could compromise access and security.

Alternative to Cross-Origin Requests

This isn’t a mistake to be avoided, but a better practice that can be used to handle cross-origin requests if OData or a web service supports JavaScript Object Notation (JSON) with Padding (JSONP). JSONP works on a principle that <script> tags can send and receive requests across different domains without any restrictions. In short, <script> tags are independent of domains. However, this method is useful only if the OData service or a web service supports the JSONP format of data exchange. For more information on JSONP go to https://json-p.org/. Covering this in detail is not in scope of this article. However, there is a blog published on SCN that precisely covers this concept in detail for SAPUI5. Following is the URL to the blog: https://scn.sap.com/community/developer-center/front-end/blog/2013/06/14/useful-jquery-functions-for-sapui5-development.

Some Additional Points to Consider

When you begin an SAPUI5 application development, it is important to understand some of the points that may have an impact on maintenance and scalability. View type: SAPUI5 primarily provides three types of views – JavaScript, XML, and HTML. XML and HTML are more of a declarative view. All these views have advantages as well as disadvantages.

• JavaScript views are difficult to maintain and scale up for a large enterprise scenario. As this view relies heavily on programming, it is necessary to have the required skills when you are planning to build enterprise applications.
• XML views are declarative, and hence they are best for applications that need to be scaled up and meet an enterprise level of detailing. Application maintenance is relatively easy and quick. That could also be one of the main reasons why SAP Fiori applications are developed with XML views. SAP recommends XML views for all new SAPUI5 applications, especially SAP Fiori applications. In fact while using SAP Web IDE templates you are limited to only using XML views.
• HTML views allow HTML to be blended in seamlessly. However, it is important to know tags and their behavior clearly.

Models: SAPUI5 supports four types of models – OData, JSON, XML, and Resource:

• OData models are server-side models and are best suited when a data set is huge and is entirely available on server.
• JSON models are client-side models and are not recommended for enterprise-level applications. Avoid these models in situations in which data is large as they have a severe impact on the performance of SAPUI5 applications.
• XML models are also client-side models and are suitable for small data sets. If a data set is embedded in the application itself, it is a best practice to use either JSON or XML models.
• Resource models are not used for data exchange. These models are used only for resource bundling and language support.

Proxy for web service calls: When web services from different domains are consumed in SAPUI5 applications, it becomes imperative to build cross-domain communication carefully. You can either use CORS or Same Origin Policy (SOP) suppress snippets, or even disable SOP in browsers. However, you cannot ask a non-technical user to disable SOP in his or her browser. Therefore, an easier way that is often used is to call the web service via an organizational proxy. This may run the application for now, but using this method to make web service calls for productive usage applications is highly discouraged. Never even use a proxy to call a web service or an OData service if you know that application will be deployed to a production server. Using a proxy on a production server could be a security breach or even a violation of security policy.

SAPUI5 Application Deployment Scenario

An SAPUI5 application can be deployed in one of the following ways:

1. As a Business Server Page (BSP) application on an ABAP server (the user can access it via a URL or it can be deployed on Enterprise Portal)
2. Independent application on Enterprise Portal
3. Hybrid application (deployable on devices)

In view of the scope of this article, I cover only the hybrid application deployment steps in brief so that organizations planning to develop Android- or iOS-based SAPUI5 applications can get an early idea of the process involved and plan for the effort and time.

Hybrid Application with SAPUI5

To create a hybrid application with SAPUI5, you have a few different options. You can select any of the following to wrap an SAPUI5 application into a hybrid application and develop an installable Android or iOS application.

• PhoneGap/Cordova
• Ionic
• Sencha Touch
• Kendo
• Intel XDK

Basically these frameworks/tools provide you with a platform to wrap an SAPUI5 application into a web container that more or less functions like a native application. At this point, I want to mention some of the disadvantages of developing or using a hybrid application with any of the above mentioned tools.

1. Though the hybrid application may be deployable on devices, it is still a web application rendered inside a web container running in a browser
2. It is very difficult to provide a user experience similar to that of a native application
3. There are API-level limitations that a hybrid application cannot overcome
4. A hybrid application may not perform as efficiently as a native application
5. Developing cross-platform applications such as IOS/Android/Blackberry/Windows requires additional effort and toolsets. The tools or frameworks mentioned above do not enable you to develop cross-platform applications out of the box.

I have worked with Cordova for developing a hybrid application, and, in my opinion, it is the easiest of all other options. I cover Cordova-based hybrid application development steps briefly.

1. Create an SAPUI5 application in Eclipse
2. Create a Cordova application package
3. Include a “webcontent” folder from the SAP UI5 application in the Cordova application under a WWW folder
4. Build and run the app locally
5. For Android, you need to register in the Google Store and create a released version of that application from a local system
6. For iOS, you need to get the application key for a hybrid application and then host it on the Apple application store

There is detailed blog already published on SCN covering how to use PhoneGap for wrapping SAPUI5 applications into a hybrid application. You can follow these blogs to understand entire process: https://scn.sap.com/community/mobile/blog/2014/06/14/sapui5-mobile-app-for-cross-platformsiosandroid-using-phonegap-part1 https://scn.sap.com/community/mobile/blog/2014/06/14/sapui5-mobile-app-for-cross-platformsiosandroid-using-phonegap-part2 Following are additional reading resources: SAP and mobile powers combined through SAPUI5 and PhoneGap: https://scn.sap.com/community/developer-center/front-end/blog/2013/04/06/sap-and-mobile-powers-combined-through-sapui5-and-phonegap. Building awesome mobile apps with SAPUI5 and PhoneGap: https://scn.sap.com/community/technology-innovation/blog/2012/05/11/sapui5--building-mobile-apps-together-with-phonegap.