There are a host of UI technologies available, and the list is growing. I am finding that SAP customers are confused about what UI technology to use when, particularly as there is a moving target. There doesn’t seem to be any great assistance from SAP to help customers through all the options to determine what solution best matches their requirement.
I certainly don’t pretend to know the answers myself, but when I’ve seen other blogs on the subject, either the details are out of date, or the content is incomplete. So these are my thoughts on a simple framework for thinking about what approach might be the best fit for different scenarios.
On premise, on device, on demand.
SAP’s technologies cover 3 architecture scenarios:
• On premise. Traditional SAP server-based installation at the customer.
• On device. Mobile solutions for tablets and smartphones
• On demand. Cloud-based/hosted services
A customer may have a mix of product architectures across their solution landscape. Business requirements, available solutions and services, and the sales model of the software will drive the decision for the architecture.
First I’d like to consider what we mean by an ‘app’. Apps can run on desktops, on mobile devices, or in the cloud. They add rich client-side functionality and can be designed for complex or multiple tasks.
SAPGUI is of course that traditional client/server application where some functionality is handled locally such as personalization settings. Netweaver Business Client (NWBC) can be used as an alternative to SAPGUI. This has a more web-like interface, but the SAPGUI transactions are exactly the same. Traditionally, developers build custom transaction screens, and Floorplan Manager (FPM) provides a fast framework for building SAP applications. The typical use-case is for expert or professional users who process complex business transactions.
Mobile apps can be custom-built or off-the shelf applications, designed to do a small number of functions very well. They can be designed to store data locally, and synchronized to SAP back-end using Sybase Unwired Platform. Alternatively they can be designed to use SAP Gateway for real-time integration to SAP database.
With cloud apps, the application is hosted externally and the customer purchases software as a service, running through a web browser, so no software is required on premise or on device. Customers would not typically design these themselves. For SAP customers and partners who want to build cloud apps, then the SAP NetWeaver Cloud Portal can be used for easy application creation, and sales through the SAP store.
For custom SAP functionality, you would consider whether such functionality is already available as off-the-shelf application, such as a SAP add-on, a mobile app, or cloud-based offering. If you decide to build your own application, then you should decide whether the application should be accessed through SAPGUI, or whether a mobile application is required. Then benefit of a mobile application is when data is stored locally on the device as part of the application; if the mobile application can only be used when on-line, then this is little more than a web portal, so the management effort of the apps (using Afaria for example) may outweigh the benefits of the app.
Web (portal) screens
I’d prefer to avoid the term web dynpro, since there are multiple technologies available for building custom web-based screens: Business Server Pages, ABAP Web dynpro, Java web dynpro and SAPUI5.
Despite how new the software is, it is difficult to imagine not using SAPUI5 for designing new web-based functionality. It’s certainly the direction we’ve chosen for FLM, having previously used both Java web dynpro and BSP. With SAPUI5 you can design once and support many different browsers, such that this provides a desktop and a mobile solution.
With SAPUI5 you can build rich controls with easy integration to SAP. You can host the SAPUI5 solutions on any web server, so you can host on the SAP ABAP stack, for example. With this approach you are ‘front-ending’ SAP BAPIs and transactions – either pre-delivered or custom-built –with a web-based interface to deliver simpler or more usable screens for your users.
In those scenarios where customers are front-ending a SAP Workflow with a web screen, using the screen to collect data and push on to the next user, without the need for deep SAP integration while the data is being collected, then they are probably using the wrong technology, and should consider an e-form instead.
I’ve written a lot about E-forms (SAP Interactive Forms by Adobe and Forms Lifecycle Manager) in other blog updates, so I’ll try not to re-tread old ground. E-forms provide another user interface solution, and here we consider both on-line and off-line scenarios.
For on-line forms, the form is accessed using a web-browser. For HTML / HTML5 forms, then that is all you need. For PDF forms, then the embedded Adobe Reader is required, which does not support e-forms on mobile devices. In the past, a lot of development effort has been required to embed the on-line form inside a custom web dynpro. But now this is not required, and the form can be delivered through web dynpro, BSP or SAPUI5* without any custom development using FLM.
For off-line forms, the form is accessed using Adobe Reader, and typically downloaded manually or sent via e-mail. Off-line forms are PDF rather than HTML, since the PDF can store the form data locally; each form is like a mini application.
Although I have seen many complex e-forms, I advocate that they are most useful when kept simple. We should expect forms to change, and so they should not be used to front-end an entire SAP transaction or BAPI – they should be used to collect, verify and route data from and around the organization, triggering updates to SAP when appropriate.
E-forms typically have 2 integration points with SAP: Pre-population (pre-render) and Validation / Update (post-submit). This means that drop-down list options are fetched before the form is rendered, and there is a ‘single shot’ update of the form data back to SAP, rather than lots of data transmission on a field-by-field or section-by-section basis. That’s how we keep them simple, easy to maintain and fast in performance.
Companies should not invest deeply to build a single e-form, as they should be fast and cheap to develop. When organizations spend months building a complex on-line form to front-end an SAP transaction (such as ‘create customer’) then probably they are using the wrong technology, and they should consider a SAPUI5 approach instead.
Companies should have hundreds of simple e-forms that are easy to change, look great and are easy to use for the occasional user.
Choosing the right approach
In most organizations, there are a small number of users who require complex transactions, and a large number of employees with a decreasing need to transact with the core SAP system. Where portal solutions such as ESS reach more employees, e-forms can reach new communities of users; including those without an SAP user-master record or beyond the corporate firewall.
So in simple terms, e-forms tend to work best when they are simple, and apps work best when they are more complex.
Traditionally we saw lots of custom SAPGUI screens, and more recently lots of custom web dynpros. But one technology does not fit all: It is not appropriate to select one technology and to build all custom development using that technology.
Ask yourself the following questions about your particular requirement to help determine the best approach for your particular requirement.
Although there are overlaps in the functionality provided by the various approaches, using a simple framework like this should point most organizations in the right direction for their choices of UI technology.
* SAPUI5 form portal will be launched in 2013