In the past several years, there has been a huge shift in the SAP development landscape. While most of the SAP development community has been focused on SAP HANA technology, several other key products and technologies have silently emerged as key enablers for delivering next generation applications. Some of the more prominent products and technologies in this space include:

• SAP HANA Cloud Platform (HCP)
• SAP Mobile Platform (SMP)
• SAP NetWeaver Gateway
• SAPUI5 and SAP Fiori
• SAP River

When combined with the innovations introduced with SAP HANA, developers now have a set of tools for developing applications in the cloud, mobile applications, and much, much more. I’ll try to make sense of all this by providing a glimpse at how these new technologies may factor into the way that next generation applications are developed within the SAP landscape.

To guide you through this discussion, I look at a handful of typical development scenarios and consider how the presence of these new technologies might influence the development approach. I emphasize the term might here since there are typically a number of factors that might cause a project to head in a different direction (e.g., not having the prescribed technology in the landscape, a lack of available resources, or fear of change). In any case, my goal is not to establish a new set of architectural best practices, but rather to demonstrate how these new technologies can be real game changers in the SAP development space.

Scenario 1: Developing UI Applications

The first scenario is a fairly common one: The development of user interface (UI) applications. Such applications might offer an input mask for entering data in a set of Z tables or provide a wizard to guide users through a complex business process. These days, one of the major challenges in developing UI applications is figuring out which UI technology to use. For quick-and-dirty applications, you might be able to get away with using classic Dynpro technology, but as soon as a user wants to be able to access the application through the Web (e.g. via a portal), you may have a dilemma on your hands since an Internet Transaction Server (ITS)-based view of a Dynpro transaction often doesn’t cut it.

Up until recently, the solution for handling such Web-based requirements was to develop the application using either Business Server Pages (BSP) or Web Dynpro ABAP (WDA) technologies. These technologies continue to represent viable alternatives for many scenarios, but what if the UI application is expected to be viewed on a variety of device types (e.g., tablets or smart phones)? Though it’s possible the BSP or WDA applications may render on these devices, the experience will surely fall short of what users have grown accustomed to.

To address these types of concerns, SAP introduced another UI technology into the mix based on the World Wide Web Consortium’s (W3C’s) HTML5 standard: SAPUI5. Due to the widespread support for HTML5, UI applications based on SAPUI5 technology are generally accessible from any current device type: desktop browsers, smart phones, and tablets. This makes SAPUI5 a safe choice for maximizing portability.

SAP UI5 and SAP Fiori

Even though SAPUI5 is a relatively new technology, it’s gotten a lot of press recently with the introduction of SAP Fiori. SAP Fiori apps are basically just SAPUI5 apps that happen to have been developed according to a set of design principles geared towards improving the user experience. Now that users have had an opportunity to test drive SAP Fiori apps, the demand for custom apps based on SAP UI5 technology is sure to increase.

Though the adoption of SAPUI5 may seem like a no-brainer from a long-term strategy perspective, it does represent a fairly sizeable shift in development approach. Some points to consider:

• Unlike BSP or WDA applications which are based on ABAP technology, SAPUI5 applications are based purely on HTML5 technology. This means that SAPUI5 applications primarily consist of HTML pages, JavaScript or JQuery script files, and Cascading Style Sheets (CSS).
• SAPUI5 enforces a more strict separation between the view and model layers. This means that model data consumed in the view layer is sourced by external HTTP-based services as opposed to inline SQL queries and the like. This forces developers to spend more time up front modeling their applications (which is, of course, a good thing because you end up with more flexible designs that are easier to maintain).
• Application controller logic is generally developed using JavaScript instead of ABAP.

To put these architectural differences into perspective, consider the block diagram contained in Figure 1. As you can see, there’s a significant departure from the classic three-tier application model used in classic Dynpro applications. This new hybrid model thins out the application layer and pushes more of the processing out to the view and model layers. This generally makes applications more responsive since there are fewer server roundtrips required to refresh screens or respond to user selections. Plus, by cutting out the application tier middle man, some of the latency associated with propagating data back from the model tier is eliminated.

Figure 1

Deployment options for SAPU15 applications

Looking closely at Figure 1, you see that SAPUI5 applications are generally much more distributed than classic Dynpro or WDA applications. Here, you have several options for deploying SAPUI5 applications:

• Since the view layer of an SAPUI5 application doesn’t contain any proprietary technologies, the SAPUI5 application bundle itself can, in theory, be deployed on any Web server. In practice though, SAPUI5 applications are generally deployed on one of three platforms:
  • AS ABAP systems (where they’re accessed via BSP technology)
  • Data-centric applications can be deployed on an SAP HANA XS system. SAP HANA XS is essentially an extension of SAP HANA (the XS stands for extended services), providing a lightweight application server for deploying data-centric applications on top of SAP HANA.
  • SAPUI5 applications can also be deployed on the SAP HANA HCP. I’ll discuss HCP in further detail a little bit later.

The data consumed by an SAPUI5 application is generally delivered through a series of OData services. OData is an open protocol for developing lightweight REST-based Web services. Though it’s possible to create these REST-based services on top of any HTTP library, SAP provides a couple of platforms that make this job a lot easier:

SAP NetWeaver Gateway

SAP NetWeaver Gateway is an ABAP-based middleware platform focused on developing OData services. This product provides many productivity tools that allow developers to create OData services from Remote Function Calls (RFCs) or BAPIs, Business Object Repository (BOR) objects, or custom ABAP classes.

As a standalone product, SAP NetWeaver Gateway makes it possible to place fine-grained control over access to sensitive back-end application data. It also allows you to more easily move UI applications outside the firewall without having to open up access to SAP Business Suite systems. This capability can come in handy whenever you want to expose UI applications to customers or partners, for instance.

SAP HANA XS

The SAP HANA XS system provides a couple of mechanisms for developing OData services to consume data from SAP HANA. Here, developers can develop services from scratch using server-side JavaScript or automatically generating services on top of SAP HANA repository artifacts such as tables or views.

Though many companies may be slow to adopt SAPUI5 as their de facto standard for UI development, it’s nevertheless important for developers to recognize the changes it portends. Going forward, regardless of the UI technology being used, it’s critical that more attention be paid to developing application models that are UI-agnostic. This has long been an industry best practice outside of the SAP space, and now it’s going to have to be embraced within the SAP space as well.

Scenario 2: Developing Interactive Reports

Another fairly typical development requirement on SAP projects calls for the creation of various ABAP-based reports used to operate on live data in SAP Business Suite systems. Here, a user might ask for a report to generate a worklist or display a snapshot view of key performance data using SAP List Viewer (ALV). These requirements are usually easy enough to implement, but you can run into challenges when you have to churn through large volumes of data.

For particularly large volume reports, various techniques were used in the past to pre-process the data so that the report would run in a reasonable amount of time. Of course, there were some technical limits to what could be achieved, which is one of the many reasons that SAP introduced SAP HANA technology.

Sometimes, just the mere substitution of an SAP HANA database can produce the performance improvements you’re looking for. However, depending on the complexity of the data, you may have to dig a little deeper. Here, you might end up needing to push more of the data processing functionality down to the database level by making use of stored procedures or other SAP HANA-proprietary artifacts (e.g., calculation views). The upshot of this from a development perspective is that you end up refactoring the selection logic to call down to the database as illustrated in Figure 2. Then, on the SAP HANA side, you can write the data crunching logic using, for example, SAP’s proprietary SQLScript language.

Figure 2

Refactoring ABAP-based reports

Once again, you can note a stronger separation of concerns between the application or model layers and the view layer. This is a recurring theme in the new SAP development landscape. Think of it this way: More separation of concerns = more flexibility = agile IT.

Scenario 3: Creating Customer- and Supplier-Facing Applications

Sometimes, you may encounter a requirement to expose selected applications to external customers or suppliers. In the past, such requirements usually called for significant and complex changes to the SAP technical landscape (e.g., portal federation or proxy servers). As a result, the time it took to deploy external applications was almost double or triple the time required to deploy normal applications.

These days, this task can be greatly simplified with the introduction of the SAP HCP. SAP HCP is:

• A platform-as-a-service (PAAS) offering from SAP
• Built on top of SAP HANA technology
• A complete development platform that makes it possible to develop cloud-based applications using SAPUI5, Enterprise Java, and native SAP HANA and HANA XS technologies

As a cloud-based offering, SAP HCP provides the core infrastructure needed to build external applications in a secure and reliable manner. The upshot of this is that it ends up taking days instead of weeks to set up the infrastructure. Then, once the infrastructure’s in place, developers can build their applications as usual without having to worry so much about low-level security and connectivity issues.

Connectivity-wise, SAP HCP makes it easy to tap into data from backend SAP Business Suite systems via the SAP HANA Cloud Connector. This simple component provides a secure tunnel for extracting sensitive data without having to introduce significant changes to network infrastructure or firewalls. Normally, the data is exposed via the aforementioned SAP NetWeaver Gateway tool. For more advanced scenarios, there’s also SAP HANA Cloud Integration, which is similar in functionality to SAP NetWeaver Process Integration (PI).

Overall, SAP HCP provides a quick and robust solution for rapidly developing external-facing applications. Plus, it gives you room to expand your development footprint over time and integrate with other cloud-based technologies such as the SAP HANA Cloud Portal and SAP Mobile Platform Cloud. Instead of creating a one-off solution for providing external access, companies can establish a foundation for developing and maintaining multiple applications that share these qualities.

Scenario 4: Developing Data-Centric Applications

Earlier, I touched on the notion of using SAP HANA technology to boost the performance of ABAP report programs and the like. This approach, though powerful, does have one drawback in that it requires you to funnel the data through the ABAP layer. When it comes to the development of pure, data-centric kinds of applications, this overhead can end up causing a drag in performance.

Before, developers had no choice but to live with this latency since ABAP was basically the only game in town. Now, with the advent of SAP HANA XS, such restrictions no longer apply since you’re able to develop application logic right on top of the data. Performance-wise, this is huge since the application code now has fast in-memory access to the data it’s processing.

In an SAP HANA XS scenario, the application UI would be based on SAPUI5 and the application model would be developed using server-side JavaScript and HANA-related artifacts, such as stored procedures and views. All these artifacts are installed directly on the SAP HANA XS server and there’s no need to hit the backend ABAP system – though you could if we absolutely had to.

Another potential benefit of developing applications directly on SAP HANA is that it gives you the opportunity to tap into another new and powerful feature: SAP River. SAP River is a development language or platform that makes it possible to develop complex applications using largely declarative techniques. Here, depending on the requirements, it may be possible to develop a complete application in a matter of hours as opposed to days. Expect to hear much more about SAP River in the months ahead.

Scenario 5: Enabling Access on the Go

As the workforce continues to become more and more distributed, a major challenge for many IT departments is figuring out how to support so many user access scenarios. Some common requirements here include:

• Providing at-a-glance visibility to key metrics for executive types who are constantly traveling and rarely able to log on to the system directly
• Delivering work items to casual or non-SAP user types
• Making it possible for users in the field to record information remotely and sync it up after the fact

In the past, such requirements might have been implemented using portal technology, Adobe Interactive and Offline Forms, email, or selected mobile application offerings provided by SAP. While these technologies generally provided a workable solution, the cost of maintenance of these applications was difficult to manage since the solution architecture was so fragmented. Now, you have another alternative which offers a more streamlined approach: The SAP Mobile Platform (SMP).

SMP makes it possible to develop mobile applications that satisfy all these use cases and more. Using the tools and features of the platform, developers can create mobile applications that are easily deployed to smart phones, tablets, and so on – regardless of platform (i.e., Apple iOS, and Android). Mix in SAPUI5 and its support for HTML5, and you have a technology stack that’s capable of supporting multi-channel access on an unprecedented scale.

On the administrative side, SMP offers tighter controls around security, centralized monitoring, and controlled deployment. This eliminates the aforementioned fragmentation and makes it easier to support and enhance these scenarios in the long run.

So what conclusions can you draw from all this? Well, as developers, the main thing to note is that you have more options when trying to solve complex problems. Sometimes the use of these new products and technologies makes sense, other times it may be best to stick to the status quo. You just have to evaluate the situation and select the best tool to solve the problem at hand.

Realistically, the changes brought about by these new products may force many developers outside of their comfort zones. Indeed, in this article alone I’ve touched on a number of new technologies – many of which call for radically different skill sets than what the average ABAP developer might possess. Though this can seem scary at first, rest assured that there’s time to come up to speed. Suffice it to say that ABAP is not going away any time soon. However, ignore these new technologies too long and you run the risk of getting left behind.

James Wood

James Wood is the founder and principal consultant of Bowdark Consulting, Inc., an SAP NetWeaver consulting and training organization. With more than 10 years of experience as a software engineer, James specializes in custom development in the areas of ABAP Objects, Java/J2EE, SAP NetWeaver Process Integration, and SAP NetWeaver Portal. Before starting Bowdark Consulting, Inc. in 2006, James was an SAP NetWeaver consultant for SAP America, Inc., and IBM Corporation, where he was involved in multiple SAP implementations. He holds a master’s degree in software engineering from Texas Tech University. He is also the author of Object-Oriented Programming with ABAP Objects (SAP PRESS, 2009), ABAP Cookbook (SAP PRESS, 2010), and SAP NetWeaver Process Integration: A Developer’s Guide (Bowdark Press, 2011). James is also a contributor to Advancing Your ABAP Skills, an anthology that holds a collection of articles recently published in SAP Professional Journal and BI Expert.

You may contact the author at jwood@bowdark.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.