9

Application Development

In this chapter, we are starting a whole new part of our book in which we will cover how SAP BTP facilitates application development. With the cloud transformation of business applications, especially with Software-as-a-Service (SaaS) solutions, businesses are encouraged to standardize their processes and leverage out-of-the-box functionality with the fit-to-standard mentality. However, the fast pace of change in IT and the impetus for innovation necessitate the development of extension applications to complement the core business solutions.

In the last decade, new application development paradigms emerged or gained traction. The open source movement has enabled large-scale collaboration, and together with connectivity and integration standards, it also improved the efficiency in interoperability between applications from different vendors. As a result, companies started using open source software in their commercial products, actively supporting their expansion and adoption. For example, SAP is a platinum member of Cloud Foundry, the Platform-as-a-Service (PaaS) foundation that underpins the SAP BTP multi-environment.

The application development capabilities of SAP BTP are primarily provided from the perspective of extending SAP’s business solutions. Therefore, the relevant services are sometimes referred to as the Extension Suite. The naming here may be justified from certain aspects; however, using the application development services, you can also create independent and self-contained cloud applications on SAP BTP.

SAP BTP supports application development as a highly robust and flexible platform and includes best-of-breed development tools.

In this chapter, we will cover the following main topics:

• Implementing extensions
• Development platform types
• SAP BTP runtime environments
• Frontend applications
• Backend applications
• Mobile applications
• Application development tools
• Launchpad applications
• Non-functional design
• Other related services
• Deployment considerations

We will also apply what we learn to an example scenario for which we will produce an architecture design.

Technical requirements

The simplest way to try out the examples in this chapter is to get a trial SAP BTP account or an account in which the free tier can be enabled, as described in the Technical requirements section of Chapter 3. For SAP AppGyver, you can sign up for free at https://www.appgyver.com/ and check out how you can build applications with it. SAP may change this as they integrate SAP AppGyver into the SAP BTP ecosystem.

Note

Remember, this book is not meant to contain step-by-step instructions; instead, we provide higher-level design examples for architects, which should also work as pointers for those who want to dig deeper and learn the lower-level details.

Implementing extensions

Do you need to implement an extension? We have started by asking this question on purpose. For business applications, there is a strong trend toward SaaS applications. With SaaS solutions, businesses expect to reduce the total cost of ownership by primarily staying away from the complexities of running the operations below the application layer. In such cases, companies are happy to give up on the flexibility of on-premise deployment models. As a result, we see the fit-to-standard approach is within the principles of most SAP S/4HANA transformation programs, where businesses intend to standardize their processes and align with the models put forward by the SaaS solutions. Some companies are much keener on standardization after the bad experience they’ve encountered due to the high level of modifications and customizations they’ve applied to their systems in the past.

On the other hand, as we learned in this chapter’s introduction, creating extension applications is almost inevitable due to the fast-paced change in IT and the drive for innovation. These are motivations in addition to the traditional modification requirements where businesses change how an application runs processes so that they adapt them to their custom business needs. This, in a way, contradicts the trend that comes with SaaS solutions.

So, complete standardization is still too ambitious for many companies, and extensive customization is somewhat discouraged as it will bring many maintenance headaches. Acknowledging the reality of the dilemma between the two ends, SAP provides extensibility options at different levels, which helps its customers to adjust according to their requirements. While making these options available, SAP encourages keeping the core clean by using formalized extensibility methods.

SAP puts a massive effort into providing optimized business processes and delivers localization where needed. This is one of the primary strengths of SAP solutions. The main track for standard usage of these solutions is determined by the out-of-the-box models and processes provided in the solutions and the best practices suggested by SAP.

So, we agree that there will be custom-built extension applications. Before these applications get out of control, it would be wise to create a framework for extension governance and methodology. You may remember SAP Integration Solution Advisory Methodology (ISA-M) from Chapter 6, Defining Integration Strategy. Although not as established as ISA-M, there is a similar work for extensions called SAP Application Extension Methodology. You can check it out as a template for your extension governance framework. Another tool you can look at is the SAP Extensibility Explorer. Although the name is generic, its content is built specifically for SAP S/4HANA Cloud at the time of writing this book.

Extensibility options

Before discussing the extensibility options, let’s remind ourselves that we are looking at scenarios for implementing an extension in the cloud. Now, let’s list the three layers where extensions can be relevant:

• Data: This is about extending the standard data model with extra data fields or even complete data entities peculiar to your processes. An extension at this layer generally cascades extensions in other layers.
• Application: In the application layer, an extension corresponds to a change in the business process flow or data processing. For example, you may change the business logic that determines a process milestone, amend the formula that calculates an aggregation, or manipulate data as per your custom requirements. For sophisticated extension requirements, this can even be an isolated application integrated into the standard business process and may have its own storage and user interface.
• Presentation: You may want to tailor the user interface according to your needs. This may be a user experience improvement, for example, by hiding unused fields or changing the layout. Another example would be adding new user interface components, such as showing static or dynamic text or displaying custom data with which you extended the standard data model.

Now, let’s talk about extension options. Here, we will cover S/4HANA Cloud extensibility options. Be aware that we aim to provide a helicopter view so that you can observe how SAP BTP is positioned for implementing extensions.

If you come from a technical SAP background, you must know the concepts of enhancements and modifications in the on-premise ABAP-based SAP solutions. With modifications, you have the full power to change almost anything, whereas enhancements, such as customer exits and business add-ins (BAdIs), provide a formalized and more controlled approach. Again, if you are a seasoned technical SAP professional, you must already know why to stay away from modifications and even complex enhancements unless they are really necessary since they complicate upgrades and transformations.

As you can expect, there is no modification option in SaaS applications since the vendor shares certain responsibilities and manages the underlying platform and the software, where modifications cannot be allowed. So, instead, formalized extension approaches are provided, which also guarantee stability as they are upgrade-proof. Let’s look at them.

In-app extensibility

Also called key user extensibility, this option includes low-code and no-code tools that enable users to implement extensions in a restricted scope. In addition, the tools are highly streamlined so that even key users, who do not necessarily have deep technical knowledge, can implement the extensions. Here, the extension points and the extensible objects are defined by SAP, which limits flexibility. Nevertheless, in-app extensibility caters to many business requirements.

For instance, with in-app extension tools in SAP S/4HANA Cloud, you can add a custom field at the data layer. Then, necessary extensions can be applied across all layers (for example, CDS views, business objects, and Open Data (OData) services to use the added field in business logic and the user interface.

Developer extensibility

With this option, you have more flexibility to fulfill more complicated extension requirements. You can create fully custom development objects that interact with the core application components via released objects to maintain a stability contract between these and your custom development. For SAP S/4HANA Cloud, this means you can develop custom ABAP objects on the same stack of the SAP S/4HANA Cloud application. The interaction between these is based on lower-level ABAP components such as BAdIs, classes, interfaces, CDS views, behavior definitions, and authorization objects that are released for extension use cases.

Side-by-side extensibility

With this extensibility option, you can detach your custom development fully from the main applications running the business process you would like to extend. This means you define the scope of extension and how much it relates to the standard business processes. Therefore, the extension relies on integration between the custom-developed objects and the standard applications, which happens mainly through APIs (OData or SOAP) and events. For SAP S/4HANA Cloud, you can also add BAPIs and IDocs to the list.

For side-by-side extensibility, the recommended environment is SAP BTP, which provides capabilities and facilities that work well with the SAP solutions. With SAP BTP, you can use ABAP or non-ABAP programming to create extension applications. We will discuss these shortly in a later section.

Figure 9.1 – Extensibility options for S/4HANA Cloud

The preceding diagram illustrates all extension options for SAP S/4HANA Cloud. As you can see, SAP BTP is mainly relevant for side-by-side extensibility, where you can create decoupled custom applications that integrate with SAP S/4HANA Cloud.

As mentioned previously, we deliberately started our discussion regarding application development by focusing on extensibility. This is because you should have an informed idea of what you aim to do with the application you are creating. While acknowledging the valid reasons for extension use cases, we want to highlight the importance of keeping the core clean and using the standard as much as possible.

That said, application development on SAP BTP cannot be confined to standard application scenarios only. As we mentioned previously, an extension can have a very loose relationship with standard applications and can be scoped as an extension to a business process in a broader aspect. Meanwhile, you can also create fully independent applications on SAP BTP. This includes, for example, creating SaaS applications that you can commercially offer to your customers, partnering with SAP to implement Industry Cloud solutions, or building cutting-edge innovative solutions to support your intelligent enterprise transformation.

Development platform types

Over the last two decades, the way we develop software has changed dramatically. This is a result of several technological advancements, such as cloud, mobile, IoT, AI/ML, and more. In addition, agility in developing software gained importance due to increasing competition, and the IT industry came up with numerous programming languages, paradigms, frameworks, and patterns. With all these, the tools used by developers needed to support much more than coding. We will talk about tools in the Application development tools section later; here, we want to discuss the rise of a new development platform type, along with all these changes.

Low-code/no-code development

One part of the story is about the tools and which convenience features they provide for developers. This includes hiding some of the complexity behind patterns, boilerplate codes, and reusability. For many scenarios, applications share similar components, and for the parts that differ from scenario to scenario, the development platform can let the developers provide them as configuration elements. If that is the case, why not bring a graphical editor to visualize the data model, application components, the flow, and the user interface structure while letting developers input specifics as configuration? This was the trend when rapid application development (RAD) approaches got traction in the IT world. RAD introduced elements that complemented traditional application development with tooling that made developers’ lives easier.

Following the train of thought here, vendors took this to the next step, where all the aforementioned elements were abstracted at a separate layer hiding the generated code. So, the platform can take away control over the actual code running the application. What remains for the developer is almost a lean application description that can be converted into the lower-level design time and runtime elements as needed. Because these platforms require low code and even maybe no code at all for application development, they are called low-code/no-code (LCNC) development platforms.

If your requirements are straightforward to develop in this fashion, this sounds great, doesn’t it? And there is one plus side to this as well. This convenience also means the entry barrier for learning to build such applications has become much lower. This is not only because of the capabilities provided by the LCNC platforms but also because the IT literacy of non-IT people has increased as a result of IT becoming an essential part of the business world and even our personal lives. Today, we call such people citizen developers as they are not necessarily dedicated developers; however, they have the skills to develop certain types of applications that would make their personal or work lives easier. Here, we can make a further distinction between no-code and low-code. However, the names are already quite intuitive, giving away what they mean.

The LCNC practices can be the main ethos of the platform if it is specifically for LCNC development. Besides, LCNC elements can also be embedded features of a development platform. You have already seen examples of this in previous chapters. For example, SAP Integration Suite and SAP Data Intelligence contain graphical editors that can be considered low-code components.

Pro-code development

Are you a developer concerned that LCNC may threaten your job security? Feel no fear at all. The business world is very IT-orientated; we can almost say every sizable company is also a technology company, and lots of sophisticated IT work requires advanced programming techniques and flexibility. As this is the default mode for application development, it doesn’t need a specific name; however, in contexts where development platforms are discussed, it is called pro-code development. As you can guess, this chapter is mostly about pro-code development. So, we will cut it short here and move on to the next section, where we will provide a comparison of the various development options.

Comparison

There are use cases where LCNC development or pro-development is more appropriate, and this is mainly driven by the complexity of the application. The highly formalized development approach put forward by the LCNC platforms may become insufficient to implement sophisticated features, and the level of extensibility and performance optimization may be limited. On the other hand, the LCNC approach can save significant time and money for many use cases. LCNC platforms also allow citizen developers to develop creative solutions that help them do their job more efficiently, whereas getting the same functionality developed through pro-development delivery channels would be too bureaucratic, hence off-putting.

There is a gray area between the two ends where decision-making between the two approaches may be tricky. At the end of the day, these two approaches can co-exist. The fundamental requirement here is establishing an application development governance framework that identifies when to use which approach. It’s best to keep LCNC platforms accessible to citizen developers as this will empower them while reducing the work funneled to the development teams, reducing their workload. For more complex cases that will be built by dedicated LCNC development teams, necessary controls and safeguards should be incorporated into the delivery mechanism of such applications. After these have been established, LCNC can provide remarkable opportunities for citizen developers and for developing certain application types.

SAP AppGyver

So, as part of your IT estate, you should keep your options open and wish to invest in LCNC platforms. In terms of LCNC platform solutions, you have several options in the market. Concerning your SAP estate, you can use SAP’s own offering, SAP AppGyver. If you plan to use another vendor’s product, such as Mendix or Microsoft Power Platform, make sure you understand its capabilities around specific support for SAP solutions, such as native connectors or plugins.

Important Note

When deciding which LCNC product to use, consider the licensing impact of Digital Access (indirect use) as accessing SAP systems from third-party applications may require additional license entitlements. Check with your SAP Account Executive to see whether your use case is relevant to Digital Access licensing.

SAP AppGyver is mainly positioned as a no-code platform and, typical with LCNC platforms, it needs you to primarily define the following elements to build an application:

• Data model: You define the data model that will be used by the application. SAP AppGyver lets you use on-device storage, REST API integration, OData integration, and Google Firestore as data sources.
• Pages: You define several pages as required by your application. For each page, you set the layout, include page components, and apply data binding for the components that will be linked to the data sources. In pages, you can add logic so that your page can react to events. Here, SAP AppGyver allows you to add basic JavaScript code.
• Navigation: You can define the navigation flow between the application pages and configure the navigation menu and style navigation elements.

The following screenshot shows SAP AppGyver’s page-building editor:

Figure 9.2 – Building a page for an SAP AppGyver application

On the left are screen components that you can drag and drop to the page. You can bind data to these elements and set other component properties using the right-hand pane. At the bottom, you can see the page-level logic elements where some flows are defined to respond to page events.

You can subscribe to SAP AppGyver through SAP BTP. When you start the subscribed application, it will launch the Application Development Lobby, a landing page for administrating your LCNC projects. Here, you can create and manage the following:

• Projects for developing no-code applications with SAP AppGyver
• Business applications that are implemented using the low-code features of SAP Business Application Studio, which we will discuss shortly in the Application development tools section of this chapter

Typically, LCNC platforms provide the convenience of building frontend applications. However, there are examples where similar LCNC approaches are applied to backend development as well. At the time of writing, SAP announced the upcoming release of Visual Cloud Functions, a cloud-powered backend development tool for SAP AppGyver. With Visual Cloud Functions, you will be able to create backend capabilities such as security, business logic, scheduling, and persistency with a no-code approach.

SAP BTP runtime environments

There are several ways to build complex applications in SAP BTP. If, for example, you come from an ABAP development background, this may seem overwhelming. With ABAP, application development is quite formalized and many aspects such as authentication are taken care of by the underlying NetWeaver platform before the execution of the application becomes relevant. Before discussing the different types of applications that you can build on SAP BTP, let’s have another look at SAP BTP runtime environments.

You may recall our discussion on SAP BTP environments from Chapter 3, Establishing the Foundation for SAP Business Technology Platform. SAP initially offered their proprietary Neo environment in the cloud, mainly supporting HTML5, Java, and HANA development. As you already know, although still supported for existing customers, the Neo environment is no longer strategic, and SAP is encouraging customers to transition to the strategic multi-environment. Under multi-environment, SAP offers three runtimes: Cloud Foundry, Kyma, and ABAP.

Cloud Foundry runtime environment

Cloud Foundry (CF) is an open source application PaaS. Besides its foundational elements, it allows reusable services to be provisioned on the platform, which applications can leverage. It virtually supports any runtime using buildpacks, which provide framework and runtime support for applications. CF, as a platform, provides all the necessary tools for developing and deploying applications, as well as managing their lifecycles .

In Chapter 3, Establishing the Foundation for SAP Business Technology Platform, we discussed how services are structured and how SAP BTP encapsulates CF. So, if you need to refresh your memory, this is a good time to scroll back and have a quick read. Regardless of how they are built, most of the strategic SAP BTP services are provisioned through the service structure of the CF foundation underpinning an SAP BTP subaccount.

For application development, SAP BTP primarily supports Java, Node.js, and Python buildpacks; however, it’s possible to bring your own language using community buildpacks, such as PHP, Ruby, and Go. Although the underlying CF platform is open to access, SAP is formalizing specific approaches to leverage the platform for deploying and running your applications. In principle, CF supports application development guided by The Twelve-Factor App methodology, which sets forth certain qualities that make applications cloud-native. You can visit https://12factor.net to learn more about this methodology.

Kyma runtime environment

Virtualization and containers are the enablers of modern cloud technologies. Together with the microservice architecture, container technologies such as Docker and Kubernetes have recently become the norm for building cloud-native applications. In line with this trend, SAP started building Kyma on top of Kubernetes to enhance the way its functions are used and ease some of the hardships of working with Kubernetes. Later, SAP donated Kyma to the open source community.

With the Kyma environment, SAP BTP provides a fully managed Kubernetes cluster on which you can deploy high complexity cloud-native applications to leverage cloud qualities powered by Kubernetes, such as high scalability. Acknowledging that this is an interesting topic, we have a dedicated chapter, Chapter 11, Containers and Kubernetes, where you can find more information on the Kyma environment and how SAP uses Kubernetes.

ABAP runtime environment

Good old ABAP has found its way to the cloud and is available as a runtime that is provisioned through the CF environment. As you would expect, teleported to the cloud, ABAP in SAP BTP is quite different from the traditional ABAP. Many of the traditional ABAP features that are linked to the underlying NetWeaver platform and user interface capabilities, such as Dynpros, are not supported in the cloud release of ABAP. Here, ABAP is positioned mainly for backend business logic. We’ll leave it here for ABAP and cover it in a bit more detail later in the Backend applications section of this chapter.

Choosing the right runtime environment

Again, with multiple options comes the question of which one to choose. Let’s start from the easiest angle.

The ABAP environment can be your preferred option if the application you are building is an extension of an ABAP-based product, such as SAP S/4HANA. Another factor in favor of the ABAP environment would be your development workforce. You can consider the ABAP environment, especially if you have highly skilled ABAP developers who can develop an application more efficiently compared to other alternatives.

Then, it’s between the CF and Kyma environments, where the boundary may be a bit blurry. So, here, we can say the following:

• If you want to implement a sophisticated application that you believe will evolve rapidly and extensively to respond to changing requirements, you can consider the Kyma environment.
• Otherwise, you do not need to deal with the complexities of the Kyma environment and can create Twelve-Factor cloud applications in the CF environment as it is streamlined for this.
• Some application runtimes are supported by the CF environment by default, whereas you still have the option of Bring-Your-Own-Language (BYOL) for other languages. However, doing so may amplify the complexity of deploying the application. If you are willing to deal with such complexity anyway, you can consider the Kyma environment instead of CF.

Finally, you need to take into account the cost of the runtimes as they are chargeable elements. Remember that the ABAP and Kyma environments may cost significant amounts as soon as you create them since they need reserved infrastructure elements. This, in a way, is linked to the complexity of the application, and you need to justify the cost if you want to use these environments. The ABAP environment comes with its SAP HANA database attached to it; this is one of the main reasons for its high price tag. On the other hand, typical with CAP applications, you will need a database, and if you use SAP HANA Cloud, that option may become costly altogether, comparable to the ABAP runtime option. You can see the pricing metrics in the following table:

Runtime Environment	Pricing Metric	Description
Cloud Foundry	Memory (GB)	Memory consumed by the deployed applications
Kyma	Capacity units are calculated based on the infrastructure elements.	VM size, number of additional nodes, storage capacity, and throughput
ABAP	Hours of persistent and runtime memory	Number of hours x memory (GB)

Table 9.1 – Pricing metrics for runtime environments

Important Note

Kyma is the most recent addition to the environments and is a sign that SAP embraces the Kubernetes technology with a special focus. This may tempt you to pick Kyma as the environment of choice as you may think it’s the newest, cutting-edge, and much shinier. However, a good piece of advice here would be to assess your options properly and first consider the CF environment, especially for low and medium-complexity applications.

This chapter will mainly cover application development in the CF environment. This is mostly the case throughout this book unless we discuss other options explicitly.

Now, let’s look at different types of applications and what SAP BTP offers for building them. With this, we will start designing an architecture in small steps and enhance it as we progress to further sections. Let’s begin.

Frontend applications

These are the applications presented to a solution’s end users. The users interact with these applications to operate the overall functionality provided. Frontend applications can be specifically built for desktop, web, or mobile. Desktop applications are not relevant to our scope as web applications already provide more convenient ways for consuming cloud services within web browsers. In this section, we will cover web applications; we will touch upon mobile applications later.

Typically, a web application is supposed to present information and let the user interaction via the user interface elements (also called controls). A web application comprises three pillars that correspond to different web technologies:

• Page content, structure, and basic formatting → HTML
• Advanced formatting and theming → CSS
• The behavior of page elements and interaction → JavaScript and WebAssembly

As web applications became more widespread, the developer communities came up with efficiency solutions and introduced libraries and frameworks to streamline the development of web applications. Today, there are several frameworks, mostly open source, which make developing complex web applications much easier. Typically, these frameworks follow design patterns, such as Model-View-Controller (MVC), which let developers provide what differentiates the application while concealing the complexity and repetitions. For example, Angular, React, and Vue are the most well-known JavaScript frameworks.

As web browsers are also used in mobile devices, web technologies support building responsive applications that can adjust the presentment of page content depending on the form factor of the device.

The OData protocol

Before getting into the application development technologies, we need to talk about the OData protocol, which is a protocol that adds a layer on top of REST APIs to define best practices and streamline their use. For example, the OData specification includes resource identification documents such as the service document and the metadata document, making REST APIs more interoperable. OData services are specified with an entity data model using Common Schema Definition Language (CSDL). Therefore, the metadata file is sometimes referred to with the generic term CSDL document. In addition, the OData protocol includes query options for complex filtering, pagination, expanding the data retrieval to related entities, free-text search, and so on.

The current version of the protocol is OData v4; however, at the time of writing this book, it was relatively new, and SAP was in the process of adopting this version, whereas OData v2 had strong support. In the SAP ecosystem, the backend technologies are architected to serve OData APIs, and frontend technologies are designed to work mainly with OData.

Taking this to the integration domain, OData is the preferred protocol for synchronous integration – for example, replacing the BAPI technology in SAP S/4HANA. Although the SOAP protocol is still mostly preferred (for instance, over IDocs in SAP S/4HANA) for asynchronous integration, there is ongoing work to make OData an option for such integration scenarios as well. Here, we will mainly talk about SAP S/4HANA; however, remember that SAP Netweaver has been supporting OData for a while, which means SAP Business Suite applications can expose OData services as well.

SAPUI5/OpenUI5

The user experience qualities of a web application are essential for its adoption. With web browsers becoming the main canvas for applications, the competition was fast-paced and introduced lots of features that improved user experience. As more people had access to the web and mobile, the user experience became one of the top factors differentiating an application from its competitors.

Traditionally, SAP applications were shipped with proprietary user interface technologies such as SAP GUI (Dynpros), SAP Business Server Pages (BSP), SAP WebDynpro, and SAP WebUI. SAP still supports these technologies and even provides the SAP Screen Personas technology, which can be used to personalize and give an elegant touch to SAP GUI and WebDynpro applications.

As mentioned previously, with JavaScript frameworks becoming the industry standard for web frontend applications, SAP invested in developing a framework to be aligned with this trend. As a result, SAP introduced the SAPUI5 technology, a JavaScript framework that includes several enterprise features. Leaving out some of the very specialized libraries, the framework is also available as open source with the name OpenUI5. SAP uses UI5 when generically referring to these frameworks and relevant technologies and tools.

Important Note

For more information on UI5, you can visit https://ui5.sap.com.

As a web application framework, UI5 can be used to develop any web application. However, since it is the primary technology for SAP frontend applications, the most typical use case is where the application manages data from an SAP backend, such as SAP S/4HANA and Business Suite, or a backend application running on SAP BTP, where in both cases the OData protocol is used. This way, SAP efficiently formalizes how data is maintained through Create, Read, Update, Delete, Query (CRUDQ) data operations. For scenarios where OData APIs are not available, UI5 also natively supports REST APIs, and it is always possible to access any web resource and parse the response if needed.

As a best practice, UI5 applications follow the MVC pattern:

• Model: The data structure used by the application.
• View: How the model is presented in the user interface through screen controls – for example, input boxes, tables, date pickers, text areas, and more. The view also includes other elements such as the layout, margins, paddings, responsiveness, and so on.
• Controller: The engine that controls the interaction between the model and the view.

Besides the MVC components, UI5 allows developers to define data bindings, where a screen element is bound to a property or a more complex data structure in the data model. With data binding, any update in the model is immediately reflected in the view. If it’s a two-way binding, a change in a screen control immediately changes the data model’s content as well.

Since we need to keep things high-level, let’s cover some UI5 features to give you an idea of what’s available:

• As it’s quite typical to have multiple views (for simplicity, let’s consider them as pages), the UI5 framework also facilitates routing and navigation between them.
• UI5 applications run on smartphones, tablets, and desktops; they automatically adapt to the device and the operating system and can use functions specific to them, such as device APIs.
• UI5 supports extensibility, where it is possible to add, hide, and rearrange fields, as well as change their labels. The best part is that because UI5 uses a consistent layering structure, the changes made at the end user layer stay upgrade-safe and modification-free.
• Although UI5 applications support standard themes delivered by SAP, it is possible to customize and manage the custom themes, for example, for branding.
• UI5 supports multiple locales and lets developers define multi-locale properties, such as localized texts, in the application.
• As it’s designed for enterprise applications, UI5 supports several accessibility features such as screen reader support based on ARIA and HTML standards, high contrast themes, and keyboard shortcuts.

Now that we’ve talked about SAPUI5, let’s start designing our example architecture.

Example architecture design

First, let’s note that our example design is mainly for demonstration purposes. Here, we won’t necessarily consider other aspects that may influence decisions, such as cost impacts, already existing solutions, and so on.

At this stage, we have an SAPUI5 application that connects to an on-premise SAP S/4HANA system to retrieve data for a specific group of customers and displays this information. The design would be similar if it were an SAP Business Suite system:

Figure 9.3 – Example architecture design – an SAPUI5 application and on-premise connectivity

Here, we have our SAPUI5 frontend application in the design, and it elegantly presents the customer information. Here, we will use what we learned from Chapter 4, Security and Connectivity: the application securely connects to the on-premise system via the SAP BTP Connectivity service and SAP Cloud Connector. The connection information is stored and retrieved via the SAP BTP Destination service. As we mentioned previously, we are at the very early stages of our design, and as you will see, this will evolve throughout this chapter. Here, we purposefully described the application as an elegant application. Let’s see what we mean by that in the next section.

SAP Fiori

SAPUI5 offers functionality across the complete set of frontend layers, including page structure, formatting, and behavior. It includes a broad set of prebuilt and configurable screen controls. For designing these controls and UX principles, SAP also introduced a common user experience for the frontend applications: SAP Fiori. SAP Fiori provides a modern, elegant, coherent, and cloud-ready design system that provides a consistent user experience across multiple platforms and device types.

Important Note

You can visit https://www.sap.com/products/fiori.html to learn more about SAP Fiori.

Today, SAP S/4HANA Cloud frontend applications are built with SAPUI5 and automatically use SAP Fiori as the user experience. This is valid for other SAP products that are based on ABAP in the cloud, such as SAP Marketing Cloud. SAP S/4HANA on-premise, on the other hand, includes SAP Fiori applications as well as older UI technologies, such as SAP GUI.

Because many of the other cloud products in SAP’s portfolio are acquisitions, such as SAP Commerce Cloud, SAP Ariba, and so on, they use different UI technologies. However, SAP invests in unifying the user experience across these different solutions. As an extension to this investment, SAP released UI5 Web Components as a Fiori-compliant reusable UI elements library for web development frameworks other than UI5, such as React, Angular, and Vue, so that the Fiori experience can be extended to these frameworks.

Applications that use SAP Fiori design are called SAP Fiori apps and there are more than 2,000 of them. SAP designates some of the Fiori apps as SAP Fiori Lighthouse apps. These apps bring immediate business value mainly because they support tasks and processes that are not supported in SAP Business Suite or provide extensive simplification and efficiency compared to the traditional way of handling the same task in SAP Business Suite.

SAP Fiori elements

The power of SAP’s programming languages and frameworks mainly comes from their focus on developing enterprise-grade business applications. Looking closely, you can observe the prevalence of five typical floorplans used in business applications. By incorporating these floorplans into templates and creating patterns for the behavior models, SAP created SAP Fiori elements, a framework for accelerating the creation of SAPUI5 applications that use one of these floorplans.

Using SAP Fiori elements, developers can create an SAPUI5 application that uses OData and is underpinned by predefined views and controllers based on the selected floorplan. With this framework, the application automatically includes features for message handling, global edit flow, draft handling, keyboard shortcuts, and navigation. On top of this base, developers can add annotations to complete the application development. Annotations allow developers to tailor the application as per the requirements without needing to write JavaScript code. However, if needed, developers can still add JavaScript code for additional requirements. As you can see, SAP Fiori elements offer more than just layout templates.

With SAP Fiori elements, you can use one of the following floorplans:

• List report: Listing several items in a tabular format with a section at the top for defining and applying filters.
• Worklist: Listing several items in tabular form where no complex filtering is required.
• Object page: This page contains a header section for the highlighted properties of an object and then sections that contain other information about the object. This page can function as a form to create a new object or edit the properties of an existing object.
• Overview page: A page with several elements that contain high-level information for many areas in a well-organized way via cards. These cards can be list cards, table cards, stacks, or analytic cards, allowing the user to navigate to the specific application to drill down the details.
• Analytical list page: A page enriched with analytical elements that are generated from some transactional content. These elements may include filters and charts that interactively change the page’s content.

The following screenshot shows a sample application built with SAP Fiori elements and the list report floorplan:

Figure 9.4 – An application built with SAP Fiori elements and a list report floorplan

Given that the backend services are in place, creating this frontend application takes much less time than creating it with freestyle SAPUI5 development. Next, let’s take look at backend applications.

Backend applications

Looking from a different point of view, there are some limitations to frontend applications:

• They are used via clients (for example, browsers), which run on end user devices; therefore, they have restricted resources to run applications.
• When they run within a browser, the data they use is exposed and easily accessible.
• They run specifically for the end user.

So, how can you leverage a database application that holds common business data managed by several users? Or, how about a resource-hungry application that needs to run complex business logic concurrently accessed by several users? How can you securely check whether the user is authorized to make the change they attempted?

To handle requirements such as these, we need applications that run at the backend - that is, a (virtual) machine that runs possibly somewhere else and can deal with these requirements. In a traditional SAP Business Suite world, backend applications are mainly the ABAP applications that run on servers where the SAP NetWeaver platform is installed. In the new world of the cloud, as we discussed previously, the cloud release of ABAP is still an option for backend application development. However, with SAP BTP, virtually, there is no restriction on which programming language and runtime you can use to implement your business logic as a backend application.

The flexibility of choosing any language makes SAP BTP a powerful application platform; however, SAP needs to consider efficiency; therefore, streamlines the way backend applications can be implemented by officially supporting a subset of possible runtimes. As discussed previously, these include Node.js, Java, and Python runtimes.

Cloud Application Programming (CAP) model

Besides the supported runtimes, SAP also provides the Cloud Application Programming (CAP) model, a streamlined framework of languages, libraries, and tools offering an approach to building enterprise applications following best practices and efficient coding styles.

Without CAP, the developers are in a wild jungle with several ways of developing an application on SAP BTP. This level of flexibility is mostly unnecessary, and since SAP BTP is supposed to provide a platform for several complex business applications, non-standardization may hinder its adoption. At this point, CAP makes developers’ lives much easier and tremendously accelerates application development by providing a formalized approach. CAP is mainly for backend application development in Node.js or Java runtimes, which are officially supported. In addition, CAP also supports serving SAP Fiori elements applications with little effort.

CAP provides an abstraction layer on top of application components. For example, at the heart of a CAP application is a data model specified with a descriptive language, Core Data Services (CDS), which is an abstraction layer on top of the actual database elements. When deployed, the CDS data model description creates, updates, or deletes the underlying database artifacts accordingly. With the data model in place, it is possible to call queries using the CDS Query Language (CQL). This is almost like in ABAP, where developers write the same Open SQL query to access the database, regardless of the specific database underlying the application platform. Another similarity is that the CAP framework takes care of all the hard work to manage the database connection.

From the data model description, it is quite straightforward to define services that manage data via CRUDQ operations, again using the CDS language. The services are, by default, exposed as OData services, and the CAP framework lets developers influence the standard operations by adding logic before or after their execution. Alternatively, it is possible to completely overwrite the logic for a data operation. Besides providing the CRUDQ data operations, services can also include actions and events to define other behaviors of data entities.

Important Note

You can visit https://cap.cloud.sap to learn more about CAP.

The CAP framework includes the usual application components, such as the following:

• Access control and authorizations: The CDS language provides annotations that can be used to control data entity exposure, which CRUDQ operations are allowed for the entity, and who can access the entity (even at a granular operation level) through role-based access controls. For this, the CAP framework leverages the Authorization and Trust Management service (XSUAA). This means the user context can be made available to the application. Besides annotations, the user context can be used programmatically to check authorizations.
• Messaging: The CDS language allows you to define events for data entities, and CAP provides intrinsic support for emitting and receiving events. Although CAP’s implementation for handling events is generic, it provides out-of-the-box support for SAP Event Mesh and the CloudEvents specification.
• Databases: With the data model specification, CAP handles the lifecycle of database artifacts as well as the runtime management of database access. The specifications can stay at a generic level, meaning the code can be deployed for any supported database, such as SQLite or SAP HANA. However, for complex use cases, it may be required to use database-specific elements to exploit native database features. SQLite is used for non-production purposes as it’s a lite database. This means that at the time of writing, only SAP HANA is officially supported for productive use.
• Localization: Like UI5, the CAP framework supports localization and multiple locales. For example, application texts can be specified in multiple languages through text bundles.
• Temporal data: CAP provides intrinsic support for time-bound data entities, containing validity start and end dates. With this, it is possible to execute time-travel queries as well.
• Media and binary data: CAP supports serving media and any binary data. This means the data entities can contain media data that can be managed via the exposed services.
• Data privacy: The CDS language provides annotations to designate entities or entity fields for their relevance to data privacy. After defining a service interface, an application can be linked to SAP Personal Data Manager (a subscription in SAP BTP) so that personal data can be retrieved and changed for data privacy purposes. Furthermore, audit logging annotations can be added to log data operations to sensitive entities.

Next, we’ll see an example architecture design.

Example architecture design

Now that we know more about backend applications, let’s extend our design so that it responds to a requirement where we need to implement business logic to enrich the customer data we receive from the backend system:

Figure 9.5 – Example architecture design – CAP application added

Here, we extended our design by adding the CAP application, which uses the same setup to connect to the on-premise backend system as an external service to consume its OData services.

ABAP RESTful Application Programming (RAP) model

Besides embracing several open source technologies, SAP continues to position its proprietary programming language, ABAP, as a strategic element for cloud application development. ABAP supports modern application development paradigms with the new ABAP RESTful Application Programming (RAP) model. SAP came to this point through the evolution of different models for the interaction of frontend and backend applications in SAP S/4HANA. Like CAP, RAP also streamlines how the backend applications are developed and how they expose services for efficient consumption. Surely, RAP does this exclusively for the ABAP platform. And, when we say the ABAP platform, we mean both ABAP in SAP S/4HANA (on-premise and the cloud) and the SAP BTP ABAP runtime.

RAP has a similar approach to CAP, and the story begins with a data model specification. At the foundation, the database objects for persistency are controlled by the ABAP Dictionary. However, the RAP model includes other layers between this persistency layer and exposing services. On top of database tables, there are layers of views that mainly provide two benefits:

• They create a separate data model layer that is decoupled from the actual database tables. This provides flexibility as the database tables can be changed without impacting the applications relying on them.
• With a separate data modeling layer, application developers can restructure the underlying data, giving them the flexibility to tailor the data model that best fits the requirements.

For implementing these views, we have ABAP Core Data Services (ABAP CDS). Sounds familiar? Although they serve similar purposes, are built with similar principles, and have similar syntax, ABAP CDS and CAP CDS are different. And to make this even more confusing, there is another CDS flavor, HANA CDS, which again differs from the other two despite similarities in purpose and syntax:

Figure 9.6 – ABAP RAP model elements

The preceding diagram illustrates the elements of the ABAP RAP model. Firstly, on top of database tables, you define a new data model for a business object (BO) using ABAP CDS. A business object corresponds to a real-world object we use in business processes, such as a purchase order or a product. The business object data model comprises a root (parent) node, such as a purchase order header, and optionally its child nodes, such as purchase order items. These are specified as CDS views that eventually use database tables as data sources. The parent and child entities are in a composition relationship, meaning the existence of the child entities depends on the existence of their parent entity. Depending on your requirements, you can implement an additional layer of CDS views before the BO CDS views to loosen the relationship between the BO data model and the ABAP Dictionary persistency model.

Important Note

A CDS view is a type of CDS entity, such as a CDS table function, CDS custom entity, and others. Therefore, sometimes, CDS views are referred to by using this generic term. To learn more about the ABAP CDS language, check out the ABAP CDS Development Guide in the SAP Help Portal.

After the data model for a business object has been specified, the next step is defining the business object behavior, including the following items:

• Draft enablement
• Numbering
• Feature control
• Authorizations
• Standard operations (create, update, delete, and lock)
• Actions (non-standard operations that modify the business object)
• Functions (non-standard read-only operations)
• Determinations
• Validations
• Prechecks (so that a request doesn’t even reach and impact the transactional buffer)
• Augmentation (such as enriching incoming request content)

Behavior pools (ABAP classes) are created to implement the behavior elements, which is how the business object interacts. Here, behaviors can be defined mainly in two ways:

• Managed: With this option, the framework takes care of essential parts of the required implementation, such as the standard operations and the handling of the transaction buffer. This is generally recommended for new implementations as it gives a ready-to-run business object in a very short time, and you can focus on the business logic that differentiates the business object from others.
• Unmanaged: As you can guess, with this option, you need to implement all aspects of the business object. This is only recommended for use cases where it is reasonable to leverage existing business logic.

Implementing a business object is a tedious task; hence, it is preferable to have a generic one that implements a general data model and a wide variety of operations. On top of this foundational business object layer, another CDS view-based layer is implemented, which reuses the elements of the business object and defines a more specialized version of it. These views are called projection views. With a projection view, it is possible to refine the context specifically for the intended service and implement certain elements that help this specialization, such as UI annotations, default values, calculated virtual elements, and value helps. This can be considered a bottom-up approach where you first define a generic object and then define its version, which is meant to be used for the specific service you want to expose.

We are almost there. The business object is ready, and there is a projection that has been fine-tuned for the service we want to expose. At this point, a service definition is created to specify which CDS entities are in the scope of the provisioned service. A service definition mainly specifies this much and is not associated with a specific protocol (such as OData v2 or OData v4) or consumption type (that is, whether it is to be consumed by an SAP Fiori UI application or as a web API). To add this information and conclude the RAP model structure, a service binding is created. This is the last step to exposing the service for consumption.

After this point, the provisioned service needs to be attached to an access control structure so that it can be consumed:

• For business users, when accessing SAP Fiori UI applications, the service needs to be added to an IAM app, which needs to be included in a business catalog. Business users need to be assigned a business role that consists of the business catalog.
• For system-to-system communication users, the service needs to be added to a communication scenario, which is then included in a communication arrangement that contains the communication user.

RAP is primarily about exposing the business objects as OData services. However, in the ABAP platform, service bindings can also be created for direct SQL read access using the Open Database Connectivity (ODBC) driver. This way, tools that can leverage ODBC, such as Microsoft Excel, can use SQL queries directly to business objects. Similarly, a service binding can also use the SAP Information Access (InA) protocol for analytical queries, making it usable by SAP Analytics Cloud.

Now, let’s consider some ABAP code that needs to access the business object within the same system. Should it use the services exposed by the RAP service provisioning layer? That would be overkill. Instead, the ABAP platform provides the Entity Manipulation Language (EML), which is contained in the ABAP language and allows business objects to be accessed internally.

You now have two options for developing a backend application on SAP BTP: CAP and RAP. Again, which one should you choose? The decision is not really about the programming models simply because they offer similar benefits for distinct runtimes. So, the competition is actually around the runtimes, which we briefly discussed in the Choosing the right runtime environment section.

HANA applications

SAP HANA is more than a database; it’s a platform that includes several other components tied to the core database element. SAP HANA can be used as a database in on-premise scenarios. In the past, SAP HANA was offered on SAP BTP via different services. The newest offering is SAP HANA Cloud, which includes an SAP HANA database and data lake in the cloud architecture. SAP encourages customers to migrate from the old offerings to SAP HANA Cloud.

We have a dedicated chapter, Chapter 12, SAP HANA Cloud, which covers SAP HANA Cloud in great detail, including an extensive Development with SAP HANA section.

You can create database artifacts and use SAP HANA as a database through its connectivity features, including ODBC, JDBC, Smart Data Integration (SDI), Smart Data Access (SDA), and so on. However, embedding HANA development in the CAP project structure is the most efficient option for most application development scenarios where CAP can be used. The data modeling part of CAP includes creating and managing the life cycle of some types of SAP HANA artifacts. You can also incorporate other HANA artifacts in your project and manage their lifecycles. This includes procedures written in SQLScript. SAP HANA procedures can also be managed through ABAP Managed Database Procedures (AMDP), which allows native consumption of these procedures and handling of their lifecycles.

Example architecture design

For the sake of completeness of our example scenario, let’s consider an additional requirement. So far, our CAP applications didn’t have their own storage. Instead, we relied on them to run some sort of business logic for data enrichment, and they connected to the on-premise backend SAP S/4HANA system for the main data. Now, we have a new requirement to calculate ratings and other classification data for customers and store this information in the cloud.

For the calculations, we need data that can be replicated from the SAP S/4HANA system using existing CDS views that are replication enabled. We also need data from a second source, which is a non-SAP database that supports real-time change data capture. The calculation logic is quite data-intensive and should happen automatically whenever related data changes. Alternatively, it can be triggered manually so that you can see the calculation logs.

The rating and classification data should be available through OData APIs so that the existing SAPUI5 application can retrieve and display the information. This data should also be available to SAP Analytics Cloud to be used in dashboards efficiently. Finally, this data needs to be collated as a file and uploaded to an AWS S3 bucket for detached integration and data retention purposes:

Figure 9.7 – Example architecture design – SAP HANA Cloud added

Let’s update our architecture design with the necessary components, as shown in the preceding diagram. We now have an SAP HANA Cloud, HANA Database service instance that stores data for the solution. This includes the custom data model that is used for customer ratings and classification. The same instance also includes tables that contain data replicated from the SAP S/4HANA on-premise system CDS views via SAP Data Intelligence, as well as data replicated from the on-premise non-SAP database via Smart Data Integration (SDI). The Data Provisioning (DP) agent at the source database side is part of SDI that allows you to transfer data to SAP HANA Cloud. Both data integration arrangements replicate delta changes in near-real time.

The CAP application contains services that manage data in SAP HANA Cloud and expose the data as OData services that are then consumed by the SAPUI5 application. The CAP application project also contains HANA Deployment Infrastructure (HDI) artifacts that are deployed in the database. This includes SQLScript procedures that do the calculations. Because these need data-intensive operations, we push down code to the database layer. The procedures can be executed by database triggers and can also be called on an ad hoc basis via CAP services.

SAP Data Intelligence is also used to run scheduled pipelines that read data from SAP HANA Cloud and write it as a file to an AWS S3 bucket. Finally, a live connection is established between SAP HANA Cloud and SAP Analytics Cloud so that the classification data can be used in analytics stories with near-real-time updates.

SAP Cloud SDK

SAP Cloud SDK is a set of tools and libraries that aim to accelerate the development of cloud-native applications with mainly three elements:

• Providing an abstraction layer for SAP Business Technology Platform features such as connectivity, authentication, destinations, multi-tenancy, logging, and more.
• Facilitating easy integration with SAP cloud solutions such as SAP S/4HANA Cloud, SAP SuccessFactors, and others through type-safe client libraries, some of which are pre-generated and maintained by SAP. Others can be generated using the SDK tools.
• Providing other peripheral tools to make developing cloud-native applications easier.

The preceding definition may sound familiar to what we discussed regarding the SAP Cloud Application Programming (CAP) model. There is a bit of an overlap, and in fact, CAP leverages the SAP Cloud SDK under the hood. Let’s continue our discussion by comparing the two as it may help you understand the SAP Cloud SDK.

CAP is an opinionated framework that encompasses all aspects of your development project and provides formalization for end-to-end application development. With CAP, some decisions are already made for you, including the principle of convention over configuration. This way, CAP guides your application development in a best-practices frame.

On the other hand, SAP Cloud SDK is more like an injectable tool for an arbitrary Java/JavaScript project. Yes, its tooling provides features such as generating an application; however, the SAP Cloud SDK doesn’t enforce a structure for the entire application. Instead, it’s more about making application development easier through abstractions and integrations.

CAP is more about implementing applications by building APIs; therefore, it defines what the application will be provisioning, whereas the SAP Cloud SDK focuses on consuming APIs.

Figure 9.8 – A code snippet using SAP Cloud SDK

Let’s look at the code in the preceding screenshot to solidify what we discussed earlier. This part of the code consumes the business partner service exposed by an SAP S/4HANA system:

• Line 1 imports a library, which is a pre-generated OData client for the SAP S/4HANA business partner service.
• You can see the OData query elements, such as restricting the number of returned records, selecting a subset of properties, filtering based on a condition, and expanding the query to a related entity.
• The property selection uses type-safe constants, as predefined by the library.
• Though not directly visible in this code snippet, the SAP Cloud SDK will handle authentication by interacting with the XSUAA service.
• The execute statement accepts a destination parameter and the SAP Cloud SDK knows how to use the SAP BTP Destination service before establishing connectivity.

As you can see, by having the SAP Cloud SDK, the developer can concentrate on what is required for the business logic and let the SAP Cloud SDK handle some of the lower-level details. Next, let’s look at mobile applications.

Mobile applications

For most of us, until we are awakened by a historical drama, we forget the fact that in the past, people used to live without mobile devices. They are such an integral part of our lives today; we learn, buy, pay, navigate, and entertain ourselves using these mobile devices. And indeed, we use them for business, too.

People, such as field engineers, depend on their mobile devices heavily to do their work. On the other hand, in the fast pace of business life, other roles also enjoy the flexibility that comes with mobility enabled by mobile applications. While rushing from one meeting to another, an executive can make use of mobile applications for most of the access they need to the business systems, such as approvals, worklists, analytics, and so on.

SAP BTP’s mobile offerings are mainly grouped under SAP Mobile Services, which includes mobile development tools, and comprise management elements such as the application lifecycle, discovery service, push notifications, usage analytics, monitoring, identity, offline access, connectivity, and so on. Now, let’s briefly discuss mobile development tools.

SAP Mobile Development Kit

The SAP Mobile Development Kit (MDK) is an application development platform. The story of mobile application development with the SAP MDK starts with creating an application record in SAP Mobile Services Cockpit. Here, metadata information and desired mobile features are specified. After this step, a project can be generated, and in a supported editor, you can edit the pages, styling, and the application’s behavior, mainly using a low-code development approach.

With the SAP MDK, you can build multi-channel applications, which means the same application can be deployed for mobile clients and also as web applications. For mobile devices, the mobile client translates the metadata, configuration, and scripts provided for the application into native code at runtime. This provides a native mobile experience to the user. For the web application, the web runtime takes care of the application running on the Cloud Foundry runtime.

Figure 9.9 – SAP Mobile Services Cockpit showing the admin page of an MDK application

After an application has been deployed to SAP Mobile Services, you can use the client application, which you can install on your device, to launch the application either using its QR code (which you can obtain from SAP Mobile Services Cockpit) or via a URL with an application URI scheme For installing the client application, search SAP Mobile Services Client in the app store.

An example of the mobile features we alluded to previously is that you can configure push notifications in Cockpit using SAP Mobile Services. After slightly adjusting the application behavior in the editor, you can send push notifications to mobile devices. Another example of what SAP Mobile Services provides is that every time you deploy changes, SAP Mobile Services makes sure the mobile client is aware of the updates and asks the user to download the new version of the application. You can see a screenshot of SAP Mobile Services Cockpit in Figure 9.9, which also shows mobile features that are assigned to the application.

SAP Mobile Cards

SAP Mobile Cards provides a low-code environment to design and publish stylish mobile cards that compactly contain business information. These cards allow user interaction, which means they can be used as entry points to business transactions or workflows.

Mobile cards can work as enriched notifications, quick worklist items, tickets, teasers, and wallet-style cards for various information-sharing purposes:

Figure 9.10 – The SAP Mobile Cards app

Figure 9.10 shows screenshots of some demo cards. With SAP Mobile Cards, you can auto-refresh cards so that they are always up to date, use integrated support for native apps (such as Mail, Maps, Messages, Phone, and SMS), and leverage offline support. If you want to have a peek, you can install the app on your mobile device to see the demo content.

Mobile backend tools

Mobile applications can be deemed as frontend applications and typically need a backend for the heavy lifting, as discussed in the Backend applications section. Mobile back-end tools provide a toolset for modeling and generating OData services. After defining the core entity model, mobile-specific entities can be added to the OData CSDL document. The OData services can then be implemented using the generator tool, which creates a Java EE application. This application can be enhanced to have required elements such as routing and authentication so that it can be deployed on the SAP BTP Cloud Foundry runtime.

Customarily, mobile applications use existing OData services like those built using the previously discussed frameworks such as CAP and RAP, or the traditional services implemented in SAP Gateway. However, if your project is orientated around a mobile app, mobile back-end tools can be an option for implementing OData services conveniently. Generated OData services can be used by any application and are extensible through the hooks provided, which means you can tailor the business logic according to your requirements.

Mobile Transaction Bridge

With Mobile Transaction Bridge, SAP Mobile Services takes a step into the ABAP world. You can create OData services from recorded SAP GUI for HTML transactions. First, you define the ABAP system to be connected, and Mobile Transaction Bridge gives you the tool to do the recording while running a transaction. The recording lets you specify elements that will be used for the OData specification. This includes annotations that are used to generate the mobile application UI. Using the recording, an OData metadata CSDL document is generated that puts forward actions and properties. This document is then published as an OData service, which can be natively attached to an SAP Mobile Services application or can be consumed directly by an external application.

From a recording, a mobile application can be designed using graphical tools that eventually generate the Mobile Transaction Bridge application project. Then, the project can be tailored and deployed like an SAP MDK application.

The target ABAP system needs to be provided as a destination for the runtime. You can use a destination defined in the SAP BTP Destination service or specify the destination explicitly. And, as you would expect, the ABAP system can be accessed via the SAP Cloud Connector if it’s an on-premise system behind a firewall.

SAP BTP SDK for iOS and SAP BTP SDK for Android

When it comes to building powerful native apps using the complete feature set of the native mobile application platforms, the story can start in a native application project on iOS or Android. This is where SAP provides the SAP BTP SDK for iOS and the SAP BTP SDK for Android to empower mobile application designers and developers with tools to accelerate the implementation process. This way, the applications can use platform features such as the fingerprint scanner, notifications, location services, and so on while nicely integrating with SAP BTP and providing a consistent enterprise-grade SAP Fiori user experience.

Although they are crafted for their specific platforms – that is, iOS and Android – the SDKs are built with the same mentality and work similarly. The SAP BTP SDK for iOS contains an SDK Assistant and the SAP BTP SDK for Android includes an SDK Wizard. These are used to generate mobile application projects into which the SDK libraries are incorporated. With this, the native applications are provided with a link to leverage SAP Mobile Services, and SAP Fiori controls are added.

Typically, app development happens as follows:

1. Install the SDK Assistant/Wizard.
2. Configure SAP Mobile Services in the SDK Assistant/Wizard.
3. Create an app record in SAP Mobile Services Cockpit and select the features you want your app to have, such as offline access, push notification, analytics, user feedback, and log upload. This is also where you configure SSO settings.
4. Generate the app development project in the SDK Assistant/Wizard by referring to the app record created in SAP Mobile Services.
5. Now, you can go wild and craft your native application with all the rich features that come with the mobile platform.

As mentioned previously, the SDKs also ensure the applications leverage the SAP Fiori design created specifically for the iOS and Android platforms. An essential part of the SAP BTP SDK for iOS is the SAP Fiori for iOS Mentor, which generates customized UI code snippets for SAP Fiori controls. Similarly, the SAP BTP SDK for Android includes the SAP Fiori for Android Mentor.

Example architecture design

Let’s enhance our example architecture design so that it includes a mobile application. This can be an SAP Mobile Cards application that sends important customer information as a card to subscribers or a native application that shows detailed customer information on mobile devices:

Figure 9.11 – Example architecture design – mobile app added

The preceding diagram shows the added mobile application elements. We have added mobile apps as a separate client that users can leverage to access mobile applications deployed in SAP Mobile Services. We have changed the label for the existing client type to reflect that it can be any browser, including browser apps running on mobile devices. So, the preceding diagram explicitly and expressly represents the mobile applications apart from browser access. SAP Mobile Services includes tools that can generate OData services that can be deployed in the CF runtime; however, for the sake of simplicity, we presume our mobile app consumes the services of the CAP backend application. Again, the Application box has connectors to the Destination and Connectivity services. This includes SAP Mobile Services consuming these services, too.

We have covered a lot about different types of applications and briefly discussed what they do, how they are developed, and how they are different. Now, let’s take what we’ve covered so far as the core and delve into peripheral topics that complement core application development.

Application development tools

When discussing low-code/no-code platforms, we talked about how application development has changed in recent years. Since the early years, it wasn’t only the capabilities of programming languages and runtimes that advanced but also the ecosystem of application development peripherals that increased developer efficiency and made developers’ lives easier. This was inevitable as application development scaled up tremendously; agility became a must with intense market competition and there was no room for low quality. Although it’s not possible to cover everything that falls under this subject, let’s briefly discuss some of these tools and how they can help.

Integrated Development Environments (IDEs)

An Integrated Development Environment (IDE) is an application that facilitates software development by providing several capabilities for efficiency. At the core of an IDE is an editor where code is written. In addition, it can provide capabilities such as the following:

• Source code analysis, which checks for errors and quality issues
• Deployment automation for building, compiling, and deploying the code as applicable
• Debugging to find runtime issues and troubleshooting
• Organizing the development project’s structure and searching source code
• Language support for syntax highlighting and code completion

Advanced IDEs can include visual programming features, wizards, and extensibility with plugins that provide several convenience features.

When it comes to SAP application development, we have several options; so, let’s touch upon them.

ABAP Development Tools (ADT) in Eclipse IDE

For traditional ABAP development, as some of you may remember, SAP ABAP Workbench was the development environment embedded in SAP NetWeaver. In terms of SAP BTP, this is not relevant. SAP has recently been encouraging developers to use the Eclipse IDE for traditional ABAP development, and some objects can only be developed there. On the other hand, developing ABAP in the cloud is only possible with the Eclipse IDE:

Figure 9.12 – ABAP development in the Eclipse IDE

As you can see, the Eclipse IDE provides a robust environment that includes advanced features for ABAP development.

CAP and UI5 development

For developing CAP and UI5 applications, you are not limited and can develop these applications in almost any IDE you prefer. However, for the best development experience, there are two main options.

SAP Business Application Studio (BAS) is SAP’s cloud-based IDE, which it offers specifically for SAP-relevant application development. Therefore, you can expect rich features that make SAP development much easier. Furthermore, as it is cloud-based and works on browsers, you can develop anywhere, so long as you have an internet connection. We will talk about SAP BAS in more detail shortly.

Microsoft Visual Studio Code is a desktop IDE (although its foundation allows cloud-based usage) that both SAP and the developer community support by providing plugins for convenience features. Note that it’s different from Microsoft Visual Studio and can be considered a lightweight IDE mainly for web development:

Figure 9.13 – CAP and UI5 development in Visual Studio Code

Figure 9.13 is a screenshot from Microsoft Visual Studio Code where a full-stack application is being developed. Microsoft Visual Studio Code is usually preferred, especially if you need to work offline. Many developers also like it because they are quite familiar with it as they use it extensively for other types of projects.

Also, note that you can also use the Eclipse IDE to develop CAP Java applications, and SAP provides tool support for this.

HANA development

As you may recall, some SAP HANA artifacts can be created together with CAP and RAP development projects. However, if it’s about creating native SAP HANA artifacts independently, you have two options: SAP BAS and the Eclipse IDE. Here, SAP BAS may provide a better developer experience, enriched with specific tools and convenient features. In old articles, you can see references to SAP HANA Studio, which is the Eclipse IDE with SAP HANA development tools.

Here, let’s also mention SAP HANA Database Explorer, a web-based tool that comes as part of SAP HANA Cloud and allows you to work with SAP HANA artifacts. It offers IDE-like features such as managing artifacts, debugging, and executing SQL and SQLScript procedures.

Mobile development

SAP BTP-related mobile application development starts by creating an application record in SAP Mobile Services. After this step, an SAP MDK application can be developed in SAP BAS, which provides specific tools for such applications:

Figure 9.14 – SAP BAS – editing an SAP MDK application page

The preceding screenshot is of SAP Business Application Studio while a page of an SAP MDK application is being edited.

Regarding native application development, SAP provides the SAP BTP SDKs for iOS and Android and assistant/wizard tools that generate the scaffold of an application project. Then, this project can be opened in a relevant development environment, such as Xcode for iOS or Android Studio for Android, to complete the development of the application.

Other development types

Apart from the mainstream development paths mentioned previously, let’s briefly note other development types:

• As you may recall, SAP BTP CF runtime supports virtually any programming runtime; this means you can build any application in any IDE and deploy the code in SAP BTP. Although this is not the mainstream route, it’s possible so long as you can justify implementing applications this way.
• The Kyma environment lets you implement projects in any language and can be the preferred option, especially if your project has sophisticated requirements such as higher scalability. We covered the Kyma environment very briefly earlier in this chapter, and you can find more information in Chapter 11, Containers and Kubernetes.
• From our discussions in the previous chapters, you may remember that there were editors embedded in other SAP BTP services, such as the one for adding JavaScript or Groovy scripts in SAP Cloud Integration, and the pipeline operators that let you add scripts in SAP Data Intelligence.
• To highlight again, SAP AppGyver is a development platform where you can develop no-code applications. In addition, SAP BAS is also used for creating applications with a low-code approach.
• Some SAP cloud solutions have their own application development approaches, such as SAP Cloud for Customer’s Cloud Application Studio, Java application development and SAP Spartacus for SAP Commerce Cloud, and so on. However, as they are not directly relevant to SAP BTP, they are outside the scope of this book.

We have talked about SAP BAS a lot, so now is the time for a proper introduction to it.

Business Application Studio

As SAP’s IDE offering, we thought we should cover SAP BAS in more detail.

As mentioned previously, SAP BAS is a cloud-based IDE and is accessible from anywhere with a browser, so long as there is an internet connection. It is based on the open source Eclipse Theia IDE framework, which is API-compatible with Microsoft Visual Studio Code. This means SAP BAS shares many Microsoft Visual Studio Code components, including the plugins written for it. On top of this base, SAP BAS contains many powerful features crafted for SAP application development.

After subscribing to the SAP BAS service on SAP BTP, you can create dev spaces with which you get an environment such as a Linux virtual machine where several tools relevant to SAP application programming are installed. You can even open a Terminal window and execute Linux commands in this environment:

Figure 9.15 – SAP BAS – creating a dev space

As shown in the preceding screenshot, first, you specify an application type from a predefined list to create a dev space. This defines which extensions will be installed when creating the dev space. You can add other extensions when creating the dev space or later. These extensions provide additional capabilities you can use while developing an application.

In the previous sections, we mentioned you could use SAP BAS to develop CAP applications, SAP Fiori/UI5 applications, mobile applications, and SAP HANA native applications. With SAP BAS, developers get the following:

• Typical IDE editor features such as syntax highlighting and code completion
• Graphical editors for building UI screens, creating data models, and so on
• Visual editors that make maintaining important complex files easier
• Wizards with which applications and modules can be generated where necessary elements are automatically included
• Guided development to add specific features to applications
• Running applications in different run configurations, including local test runs
• Debugging applications for troubleshooting
• Git integration
• Terminal access
• Automation for deploying the SAP BTP CF runtime environment, SAP HANA, and SAP Mobile Services

Besides full-fledged application development, SAP BAS is also leveraged for application development while following a low-code approach. As you may recall from our previous discussions, when you launch the Application Development Lobby, in addition to the no-code SAP AppGyver option, you have the low-code business application development option, which loads a lite version of SAP BAS tailored for low-code development. It provides typical low-code application sections for data models, services, sample data, user interfaces, and workflows.

Another use case for SAP BAS is extending standard SAP Fiori (SAP Fiori elements and SAPUI5 freestyle) applications delivered in SAP S/4HANA. This provides additional flexibility compared to in-app extensibility. For this, you can create an adaptation project in SAP BAS and adapt UI elements, including the attached coding. Here, you only apply adaptation at places where the extensibility framework allows changes. And the project doesn’t include the complete code for the application; instead, it includes references to the standard application and contains your adaptation code. Eventually, when you deploy, it creates an app variant that can also be included in SAP Fiori Launchpad.

Other application development tools

Covering all application development tools in good detail is beyond the scope of this book. So, let’s briefly touch upon some other types of application development tools:

• Mock servers: With mock servers, it is possible to test-run frontend applications without connection to an actual backend. This way, you can detach the timelines for frontend and backend application development, which means frontend developers can start development with no dependency on backend development, at least for some time. Based on an OData metadata document, a mock server can act as a pseudo server providing OData services with given mock data. The UI5 framework includes an OData mock server.
• Test frameworks: You can automate testing using several available testing frameworks and exploit the benefits of test-driven development (TDD) for a mature application delivery approach. UI5 framework has integrated testing tools such as Qunit, Sinon, OPA, and Gherkin. Similarly, CAP (Node.js) includes testing libraries with which you can write tests that run with Mocha and Jest frameworks. And, for ABAP, you can write ABAP Unit tests.
• Command Line Interfaces (CLIs): The frameworks include tooling that can be leveraged by using operating system commands. For example, UI5 tooling includes the UI5 CLI, and CAP includes the CDS CLI to execute relevant framework features.
• UI Theme Designer: SAP invests in designing modern and elegant themes that are delivered as part of UI technologies, such as SAPUI5. In addition, you can create custom themes for your frontend applications. To create a custom theme, you start with one of the standard themes, customize it, and save it with a different name. Depending on your requirements, you can adjust the level of customization. For example, you can simply add your company logo and change the color palette for simple branding. Alternatively, you can make radical changes to the CSS and add custom CSS if you need a highly customized theme.

The content we’ve covered so far was mainly about implementing applications. However, the story doesn’t end there; so, in the following sections, let’s see what the next steps are.

Launchpad applications

So, you have one application, you know its URL that you bookmarked, and you launch it using this bookmark. That’s all good. How about when there are tens or maybe hundreds of applications that are relevant to your role at your company? Organizing them in your bookmarks wouldn’t work after a point. Here, you must think about the administration side of controlling the visibility of these applications for several users.

To overcome the problems we mentioned earlier, an effective approach would be presenting these applications on a launchpad-style page to improve the digital experience.

The SAP Launchpad service

With the SAP Launchpad service, you can establish a central point of entry for all users. You can configure how the applications are grouped and assign authorization elements to applications so that they are visible only to authorized users. As shown in the following screenshot, applications are represented by tiles that can show static and dynamic content. The size of these tiles can be configured, and you can also add links for the applications for which a smaller representation is sufficient. It’s also possible to implement custom visualization for the tiles. The Launchpad’s content can be organized with spaces (vertical tabs) and groups (horizontal panels):

Figure 9.16 – An example SAP Launchpad site

While bringing several applications together in an organized way, the launchpad also provides a shell embracing all these applications. Technically, this enables a streamlined approach for application-to-application navigation, a common technical area where all applications can access, centralized user preferences, personalization, a common theme, an app finder, favorites, and so on.

Important Note

SAP Launchpad is like a spin-off of the SAP Cloud Portal service, which also includes freestyle portal capabilities. Although SAP continues to support the SAP Cloud Portal service, it announced it would not be enhancing its freestyle capabilities. SAP recommends that new projects adopt the SAP Launchpad service for essential launchpad capabilities and SAP Work Zone for enhanced content capabilities.

If you are familiar with SAP S/4HANA, you should know about the SAP Fiori Launchpad, which exposes its applications based on the SAP Netweaver (ABAP) platform. The SAP Launchpad service works with the same approach; however, it can be leveraged generically. You can integrate business content into the SAP Launchpad service by manually adding configuration on how an application can be launched. This is available for SAPUI5, WebDynpro ABAP, SAP GUI for HTML, and WebClient UI applications. You can also simply add URLs for straightforward navigation to applications.

As a more advanced option, you can integrate business content with content integration/federation. In this approach, there are supported content providers that expose their content in a format that the SAP Launchpad service can use. This way, a tighter integration is established where the content can be managed with less hassle. At the time of writing, this option is available for SAP S/4HANA (cloud and on-premise), SAP Business Suite, SAP BTP ABAP environment, SAP Enterprise Portal, SAP IBP, and others. For example, when you establish a content federation with an SAP S/4HANA system, you can expose certain roles, which are then reflected in the SAP Launchpad service. These roles can be attached to launchpad sites and assigned to SAP BTP users to authorize them. After that, the relevant SAP S/4HANA applications become available on the launchpad site for authorized users.

Important Note

By using content integration, you can establish central launchpads that span multiple solutions.

When you subscribe to the SAP Launchpad service, you get access to the Site Manager, which is a design-time tool for creating launchpad sites. The content of the launchpad is organized using the following elements:

• A catalog contains apps to technically classify them so that they are displayed together in the application finder.
• A group contains apps that will be displayed together on the launchpad as a group. This means that an app needs to be assigned to a group so that it can be visible on the launchpad.
• A role contains apps to define which users can access these apps. Roles are assigned to launchpad sites, and with this assignment, all the previous classification items and apps become relevant to the launchpad site.

You can extend the launchpad’s functionality and its UI by developing shell plugins. Shell plugins are HTML5 applications that are deployed in the SAP BTP Cloud Foundry environment. You can also integrate Enterprise Search (SAP S/4HANA) to search for and access business data stored in SAP S/4HANA. There is a streamlined integration option that enables adding SAP Task Center tiles to a launchpad site. Finally, supported applications, such as SAP S/4HANA (cloud and on-premise), can provide notifications that can be shown on a launchpad site.

SAP Work Zone

SAP Work Zone extends the capabilities of the SAP Launchpad service by adding premium user experience elements. Using SAP Work Zone, in addition to SAP Launchpad service capabilities, you can do the following:

• Design the page layouts with more flexibility
• Create a structure for different visibility levels using administrative areas, team workspaces, and sub-workspaces
• Add content with more variety by using widgets, such as images, slideshows, multimedia, rotating banners, polls, and so on
• Integrate external applications such as Microsoft Teams, Microsoft 365 Sharepoint Sites, SAP SuccessFactors Learning, SAP Cloud for Customer, and Google Drive
• Add chatbots
• Embed UI Integration Cards into pages
• Integrate OpenSocial gadgets
• Provide mobile experience with the SAP Work Zone mobile app

As you can see, SAP Work Zone is a platform for building digital workplace solutions that integrate content from various SAP and non-SAP solutions and function as an advanced central point of entry.

SAP Mobile Start

The SAP Launchpad service provides great benefits for controlling how users access applications while improving the user experience. Following the same approach and tailoring it for mobile usage, SAP Mobile Start provides a launchpad experience using native mobile capabilities. With this, SAP Mobile Start is positioned as the native entry point to the SAP mobile experience, including native mobile apps delivered by SAP or customer apps:

Figure 9.17 – SAP Mobile Start app

In essence, SAP Mobile Start leverages the SAP BTP Launchpad service, SAP Mobile Services, and other relevant SAP BTP services to provide a consolidated view across all mobile solutions.

In Figure 9.17, you can see screenshots from the SAP Mobile Start app, which has the following sections:

• The home area, which shows highlights and suggestions
• The application launch section, which lists available applications
• The To Do section for workflows, alerts, and notifications
• A dedicated Notification Center

Example architecture design

Now that we know more about launchpad applications, let’s incorporate them into our architecture design. Our example focuses on one application; however, let’s add some launchpad components, assuming that the company will have more applications soon:

Figure 9.18 – Example architecture design – launchpad applications added

The preceding diagram shows that our design now includes the SAP Launchpad service, SAP Work Zone, SAP Mobile Start, and Site Manager. We preferred displaying SAP Mobile Start as a client application; however, as you may recall, at the backend, it uses SAP BTP. We have omitted showing the mobile app for SAP Work Zone for the sake of simplicity. As we discussed application development tools in the previous section, we have added design-time services to the diagram.

Non-functional design

In Chapter 4, Security and Connectivity, and Chapter 5, Non-Functional Design for Operability, we extensively covered important non-functional design elements. If you need to refresh your memory, just scroll back and have a look. Here, let’s briefly point out how SAP BTP application development services cater to some non-functional requirement categories:

• Security: You can bind applications to the XSUAA service so that they can utilize the authentication and RBAC capabilities. This binding can be done by running ad hoc commands or can be specified as a deployment element. Through XSUAA, applications can be made accessible only after the user authenticates, including the identity federation and single sign-on (SSO) capabilities provided by SAP Identity Authentication Service and/or the corporate identity provider. Similarly, by adding security specifications, such as role and role template definitions, the application can check a user’s authorizations and reveal information or allow actions accordingly.
• Availability: SAP BTP CF uses the availability zones of the region on which your subaccount runs, provided that the region has availability zones. When you create multiple instances for your application, the platform automatically distributes them across different availability zones, achieving zonal redundancy. You don’t need to add another service here as the runtime arranges this setup.
• Scalability: You can use the Application Autoscaler service to scale applications by automatically adding or removing instances based on specific policies.
• Observability: You can use the Application Logging service to record logs from your application, which helps troubleshoot problems. You can use the Alert Notification service to respond to certain events that happened in the application runtime, such as application crashes, deployment, and others. In addition, your applications can produce notification events and call the Alert Notification service to publish the event as an alert.
• Accessibility: We didn’t cover this non-functional design element in the previous chapters; however, let’s briefly talk about it here. With an inclusive mindset, one of your application design goals should be to enable access for people who need extra support for using the application. This is mainly relevant for frontend applications. For example, UI5 supports several accessibility features such as screen reader support based on ARIA and HTML standards, high contrast themes, keyboard shortcuts, and so on, following standards/guidelines such as the Web Content Accessibility Guidelines (WCAG) and the Accessible Rich Internet Applications suite of web standards (WAI-ARIA) specification.

Now, let’s add some of the services we discussed in this section to our architecture design.

Example architecture design

As a detail for the security requirements, let’s assume we need to use Microsoft Azure Active Directory (AAD) as the corporate identity provider, while also providing an SSO capability. Besides, we also want the flexibility to manage third-party access to our application within the SAP team:

Figure 9.19 – Example architecture design – services added for non-functional requirements

In the preceding diagram, our example architecture design now shows the use of Authorization and Trust Management, which allows us to implement RBAC controls and provides integration with Microsoft AAD for single sign-on. We have SAP Identity Authentication Service (IAS) in between so that we have a layer where the internal SAP team can control user access, such as for emergency access of third-party support teams. Otherwise, SAP IAS is used in proxy mode, passing the authentication requests to the corporate identity provider for corporate users. With the addition of these IAM elements, the applications now have the logged-in user context. Besides, it’s now possible to leverage principal propagation to use the actual user to authenticate to the backend system when consuming its services.

At the top right, we added the Alert Notification service, the Application Logging service, and the Application Autoscaler service, to exploit the observability and scalability features of SAP BTP, as discussed earlier in this section.

Other related services

We have covered a lot so far, and as visible in the example architecture design, so many SAP BTP services can be involved in an application development scenario. But there is still room for extending our scenario with other services. The good side of all these services being available on SAP BTP is that it’s easy to integrate them, the connectivity between them is efficient, and it’s possible to manage their lifecycles together. Let’s briefly cover other services that can be leveraged in an application development scenario:

• SAP Integration Suite: The best practice programming models suggest implementing services in an API-led approach. As you may recall, with both CAP and RAP, the end product is a set of OData APIs. So, in an inbound scenario, you can create a layer to control access and protect these APIs using the API Management capability of SAP Integration Suite. We discussed a digital integration hub design example in Chapter 7, Cloud Integration, which covered this scenario. For outbound integration, the applications can consume SAP Integration Suite endpoints. This can be a Cloud Integration flow, or an API proxy created in API Management to control outbound access and abstract the outbound service consumption.
• SAP Process Automation: Your application can make use of process automation elements, such as triggering workflows, using configured business rules, and so on. We will discuss this topic in more detail in the next chapter.
• SAP Job Scheduling: As the name suggests, you can schedule jobs to run once or with a recurring schedule. You provide an action endpoint, start times, and schedule as key inputs. The scheduled application needs to define and grant authorization scopes to the Job Scheduling service so that it can authenticate via OAuth 2.0 when calling the endpoint. Jobs can be created using the service dashboard or service APIs. For convenience, SAP provides a Node.js client library based on APIs. With these APIs, you can also manage the jobs and retrieve relevant information such as job details and run logs.
• SAP Custom Domain: The endpoints provided by the services and the deployed applications use a default subdomain. Although the customer defines the subdomain name, the main domain name comes from SAP’s domain for SAP BTP – for example, ondemand.com. If you want to have a stable domain name with which you prefer to expose these endpoints, you can use the Custom Domain service to manage your custom domains, including route configurations and server certificates.
• Other storage services: Being SAP’s strategic database offering, our examples included SAP HANA Cloud for persistent storage. This is also reflected in the programming models as they have the best out-of-the-box support for SAP HANA. However, you have the option to use PostgreSQL as a relational database, Redis for cache instances, and Object Store for object storage. SAP BTP manages these services through brokers that connect to hyperscalers where the storage service runs. There is no extra layer, such as functionality abstraction, provided by SAP for leveraging these services. So, for example, for the Object Store service, depending on the hyperscaler you chose, your application will be interacting with an Amazon S3 bucket, an Azure Blob Container, or a Google Cloud Storage bucket. Your application needs to read the credentials and access details from the environment variables and then use standard libraries provided by the hyperscalers to interact with these services.
• SAP Document Management: You can use this service to store and manage business documents. The difference from the Object Store is that here, the files are recognized as documents where additional metadata is specified for the files. Additionally, content management capabilities, such as versioning, are available. SAP BTP provides an integration option that allows applications to interact with the service via APIs. There is also an application option that comes with a web application to manage documents.
• SAP Credential Store: If your applications need to handle security elements such as passwords, keys, and keyrings, you can use the SAP Credential Store service to manage and use them securely.
• SAP Forms Service by Adobe: Using this service, you can generate print or interactive Adobe forms. The service acts like the Adobe Document Services (ADS) server. You can make REST API calls to the service endpoints by providing a form template and the form data. Accordingly, you will get the PDF file content. You can manage forms, templates, and schemas stored in the Template Store using APIs or the Template Store UI. You need to use the Adobe LiveCycle Designer application to design form templates.

Let’s extend our example architecture design according to what we covered in this section.

Example architecture design

Let’s assume we want to expose the services implemented with the CAP applications so that they can be consumed by serverless functions implemented with Google Cloud Functions. In response to new requirements, we need to update customer data in SAP Marketing Cloud and also create a ServiceNow incident when certain conditions are met during the classification determination. Finally, let’s assume one of the branches of our company has recently completed a greenfield implementation of SAP S/4HANA Cloud (public) and we would like to integrate customer data from this system using events:

Figure 9.20 – Example architecture design – integration services added

The preceding diagram shows new additions to our example architecture design. The serverless function in Google Cloud can consume the APIs the CAP applications expose through API proxies created in SAP API Management. The CAP applications can trigger integration flows to call SAP Marketing Cloud OData services to update contact data for the customer. Similarly, it can trigger integration flows to create incidents in ServiceNow via the ServiceNow adapter or the ServiceNow connector in SAP Open Connectors. For all these integration scenarios, we added SAP Integration Suite in the design as the parent service to include the capabilities we mentioned previously.

There was a new SAP S/4HANA Cloud implementation and we wanted to use events to integrate customer data. For this, we can use SAP Event Mesh positioned as the event broker. As you may recall, CAP applications can consume events via the framework’s out-of-the-box messaging capabilities with SAP Event Mesh.

Deployment considerations

With the application development tools, you can develop locally and even test your application using mock data or by connecting the backing services. For commercial projects, you need to deliver your application by deploying it to a productive SAP BTP environment. The first target for deployment will be a development environment. Depending on your change delivery model, you should typically use a source code management tool, such as Git, which also helps with collaboration for developing code as a team. Your source code must be stored in a repository that supports your management tool. You have internet-facing options such as GitHub, GitLab, BitBucket, Azure Repos, and others. Alternatively, you can establish your own on-premise platform behind your firewall.

This is the starting point of your continuous integration and continuous delivery (CI/CD) approach. You can use the source code repository and establish a pipeline to automate your software delivery with necessary controls such as automated testing, code quality checks, security checks, and so on.

To establish a pipeline, you can leverage the SAP Continuous Integration and Delivery service, which comes with predefined pipelines for SAP BTP development scenarios, including CAP, Fiori/UI5 applications, Integration Suite artifacts, and container-based applications. You can connect your source code repository and establish Webhook connectivity for automation. Then, you can configure pipeline jobs using the service’s job editor. Alternatively, you can add a configuration file to your project that includes job specifications. This allows you to specify pipelines as code, and this pipeline specification can be tracked for changes, together with the project code.

As an alternative to the SAP Continuous Integration and Delivery service, you can establish your own pipelines on other platforms such as Jenkins, Azure DevOps, and others.

Continuous integration and the build pipeline

So, one part of the delivery pipeline is about continuous integration, where a state of the application code is built and deployed to the CF runtime. What does this mean?

Although there are other alternatives, the best practice deployment happens through multi-target application archives (MTARs). A multi-target application (MTA) is an application package that contains code for different modules and can be deployed to different targets, such as an SAPUI5 module and a HANA DB module. When the application code is built, the builder application creates an archive (MTAR) file. The archive file contains the application code in a specific structure and compressed format. If you are familiar with JAVA development, this is similar to web application archive (WAR) files.

When the application is deployed, the application runtime makes sure the application is accessible via an endpoint and runs the application. In addition, other foundational tasks need to link multiple elements together for an application to run as expected:

• As you may recall from Chapter 3, Establishing the Foundation for SAP Business Technology Platform, applications use SAP BTP services via bindings. Although you can create service instances and bindings manually, the most convenient way is to automate their creation or make updates happen at the time of deployment.
• The CF runtime needs to know some properties to run the application, such as the amount of memory to be reserved for the application, the required input for the XSUAA service instance, and so on.
• Configurations are needed to build and deploy the application modules, such as what tool to use to build modules or their sequence.

To specify the configuration elements for these aspects, an MTA descriptor file (mta.yaml) is added to the project folder. Your MTA descriptor can include the specification for service instances and how the application will be bound to them.

For frontend applications, the static content is stored in the HTML5 Application Repository service, which provides features such as versioning, availability, caching, and so on. However, to access the static content, a dynamic runtime element is required mainly to serve the content via an endpoint, handle routing, and manage access features such as authentication and authorization. This can be accomplished by using an application router (app router). You can include an app router in your project by adding a standard package managed by SAP and a file for its configuration (xs-app.json).

As an economical option, SAP allows applications to use the app router of the SAP Launchpad service (or SAP Work Zone) if you are subscribed to it. In this case, you should specify a managed application router when creating your application.

Continuous delivery and the release pipeline

After deploying an application to a development environment for continuous integration, you will need to take it up to the production environment to deliver it to the end users. This is where you can create a release pipeline that serves as a transport route for the deployment artifacts (for example, MTAR files). This pipeline typically deploys the application code to one or many test environments, optionally a pre-production environment, and finally to the production environment. You can set an approval process between the deployments so that they happen under control, for example, after the testing is signed off.

The SAP Continuous Integration and Delivery service can deploy the artifacts directly to the CF runtime. Alternatively, it can deliver them to the SAP Cloud Transport Management service, which allows you to manage the transportation of the content across different environments.

For content other than application code, such as the configuration of an SAP Launchpad service site, currently, the easiest option is to use the export/import capabilities. For a similar case for some of the SAP Integration Suite artifacts, the SAP Content Agent service could be used to assemble content as an MTAR file that the SAP Cloud Transport Management service can use:

Figure 9.21 – CI and delivery setup with SAP BTP services

The preceding diagram illustrates a CI/CD setup using SAP BTP services. The route depicted with dashed lines is for the manual export/import mechanism for content such as launchpad site configuration. The route represented by solid lines is where SAP BTP services are used to deliver the change. The CI pipeline deals with deploying the committed code to the development environment and the delivery pipeline deals with deploying this code to subsequent environments until it is delivered to production. Here, approval mechanisms can be established so that the change delivery can happen in a controlled manner.

Example scenario

Throughout this chapter, we talked about an example scenario with several requirements that revolved around use cases for application development. We enhanced the design as we covered new topics:

Figure 9.22 – Example architecture design including several application development-related services

In the preceding diagram, you can see the final version of our example architecture design with some adjustments to make it generic to show almost everything we covered in this chapter. Let’s make it easier to spot the recent changes: We added ABAP as a backend application development option and the CI/CD relevant services.

Summary

Well, this was a chapter with so much content, so you will need time for everything to sink in. With this chapter, we wanted to provide high-level content to architects so that they can consider application development options with SAP BTP.

We started by explaining the extensibility concept as SAP uses this aspect for application development. However, as we mentioned, it doesn’t have to be an extension application that is tightly dependent on standard solutions. You can build independent applications using powerful features of SAP BTP application development features and services.

Then, we talked about LCNC application platforms and SAP’s offerings in this area, including SAP AppGyver. For pro-code development, we continued by discussing three runtime environment options: Cloud Foundry, ABAP, and Kyma. After this, we came to the core of application development, where we covered different application types you can develop on SAP BTP, including frontend applications using SAPUI5 and SAP Fiori and backend applications using the CAP and RAP models. We also briefly touched upon HANA database native development, while referring to a later chapter where it will be covered in more detail.

Next, we discussed SAP Mobile Services for mobile development, and then we covered application development tools, mainly IDE applications such as SAP Business Application Studio.

Then, we discussed launchpad applications for organizing how we present applications to end users. Here, we discussed the SAP Launchpad service, SAP Work Zone, and SAP Mobile Start as digital experience services.

We discussed non-functional design previously in dedicated chapters. Here, in this chapter, we wanted to correlate what we discussed previously with the application development aspects. Then, we briefly touched upon miscellaneous SAP BTP services that can be leveraged as peripheral capabilities next to the applications you develop. Finally, we discussed deployment considerations and highlighted essential topics and SAP BTP services in this area, such as the SAP Continuous Integration and Delivery service and the SAP Cloud Transport Management service.

You should now have an idea of how to develop applications in SAP BTP and understand the relevant concepts, processes, and services. In the next chapter, we will cover another exciting topic, digital process automation, and what SAP BTP offers in this area.