Exploring Runtime Environments And Programming Models

This lesson contains the following topics:

• Joule Studio Runtime (SAP Managed)
• Additional Runtime Environments (Customer Managed)
• Programming Models
• SAP Fiori
• Mobile Applications
• SAP Mobile Development Kit versus SAP BTP SDK for iOS and SAP BTP ADK for Android
• Summary

Cloud Foundry has established itself as a "go to" runtime environment for developers. This is due to several of its inherent features:

• Multiple buildpacks are available supporting different runtime possibilities such as Node.js, JAVA, .NET, Python, etc.
• Cloud native specifics such as routing, load balancing, containerization and multitenancy are built into the environment thus freeing the developer to concentrate more on their application logic
• Cloud Foundry supports Cloud Application Programming Model. This programming model provides a simplified developer experience for application development. It will be discussed below.

For a more in depth discussion of developing Cloud Foundry applications please see: Developing Applications on SAP BTP, Cloud Foundry runtime

In some use cases it is necessary to make use of containers when an application is deployed. Containers are a way to run an application by bundling up and packaging the application and its dependencies such that they run in a virtualized environment. Kubernetes adds container management (i.e., creating, scaling, failover) to the equation. Kyma takes the next step by adding what Kubernetes doesn't namely features such as monitoring, logging, event consumption, authentication, logging, tracing, monitoring and alerting just to name a few.

For a more in depth discussion of developing Kyma applications please see: Developing Applications in SAP BTP, Kyma Runtime

For use cases based on ABAP, the platform has a full fledged ABAP environment that can be used to run everything from simple side-by-side extensions to custom built multitenancy-enabled SaaS applications. Some of the features of the ABAP environment are:

• Based off of the ABAP language: A proven language used by millions of developers for over a quarter of a century used to build mission critical enterprise apps
• A quarterly release schedule so development processes and runtime features are always at the forefront of innovation
• A unique feature "System Hibernation": An instance can be suspended or stopped (without deleting resources) to save costs

For a more in depth discussion of developing ABAP applications please see: Learning the Basics of ABAP Programming on SAP BTP

The good news is that three environments are available for organizations to choose from when deploying applications. The tricky part as always is "which should I choose"? While each customer and use case is unique (and should therefore always be evaluated on its own merits) there are some general factors we can list to help with making this decision:

Consider Cloud Foundry when the use case calls for:

• Enterprise-grade business applications and services
• Cloud-native web applications
• "Small" to "medium" extension build with SAP Build Apps / SAP Build Code

Consider Kyma for use cases involving:

• Cloud-native development of apps and services​
• Highly scalable, microservice-based apps​
• The need for a service mesh to handle communication between different services

Consider ABAP to

• Enable ABAP developers to go to the cloud
• Migrate and adapt add-ons to the cloud
• Create robust transactional cloud apps
• Create user centric cloud extensions

CAP is a framework of languages, libraries, and tools for building enterprise-grade cloud applications. It guides developers along a golden path of proven best practices, which are served out of the box by generic providers cloud-natively, thereby relieving application developers from tedious recurring tasks. Ultimately CAP gives developers a way to create full stack applications quickly and easily.

One of the features of CAP is its focus on domain. By domain we mean the focus is on "what" is wanted and the "how" what is wanted is implemented is left up to the framework. The focus on domain is manifested by using Core Data Services (CDS). Using CDS developers can design data models, service definitions, queries, and expressions. CAP is the appropriate choice when deploying to either the Cloud Foundry or Kyma environments and as such provides a uniform programming model for the different languages supported by those environments (i.e., JAVA, JavaScript, Python, etc.).

For more information on CAP please see: Getting started with SAP Cloud Application Programming Model

Using RAP ABAP developers can create SAP HANA optimized OData services and Web APIs that can be used across any and all transactional, analytical and integration scenarios. Similar as to CAP, RAP also focuses on domain. Using CDS developers can model objects such as data definitions, business objects, service definitions and service bindings.

For more information on RAP please see: Getting Started with Creating an SAP Fiori Elements App Based on an OData V4 RAP Service

As a practical matter the choice of runtime environment dictates the programming model and vice versa. Thus if a use case calls for a specific runtime environment (i.e., Kyma or ABAP) then the choice of programming model is made automatically as a result. If any runtime environment is suitable then the decision can be made based on the programming model best suited. As mentioned earlier each use case stands on its own and must be evaluate independently. In many instances both programming models are suitable so resist the temptation to "overthink" it. One of the most important factors to consider is the developer skillset necessary based on programming model chosen. To wit:

CAP:

• Understanding of Core Data Services​
• Expertise in Java/Node.js or in any major programming language​
• Kubernetes, Docker and microservices​ knowledge (for Kyma)
• Node.js and Python for serverless functions (for Kyma)

RAP:

• Understanding of Core Data Services​ (as used in ABAP)
• Ability to write modern ABAP code​ (ABAP Cloud)
• Knowledge of SAP Fiori / SAPUI5 to create UIs

What it is: A cloud based service running on the platform providing mobile application development capabilities. It is not an app that end-users install; it's a tool for developers and administrators.

Purpose & Key Features:

• Connectivity: Securely connects mobile apps to various backend systems (both SAP systems like SAP Cloud ERP and non-SAP systems).
• Security: Manages user authentication, single sign-on (SSO), and secure data access.
• Offline Access: Enables apps to function without a constant internet connection by managing offline data synchronization (Offline OData).
• Push Notifications: Provides the infrastructure to send push notifications from backend systems to mobile devices.
• App Lifecycle Management: Helps administrators manage, monitor, and analyze the usage of mobile apps.
• SDKs (Software Development Kits): Provides developers with tools and libraries to accelerate the development of native iOS and Android apps that are tightly integrated with the SAP ecosystem.

Analogy: SAP Mobile Services is the engine room and control tower for an enterprise's mobile strategy. It provides all the essential plumbing, security, and management capabilities needed to run robust mobile applications, but it's invisible to the final business user.

What it is: A native mobile app for iOS and Android that acts as a central, personalized entry point.

Purpose & Key Features:

• Central Launchpad: Provides a single place for users to access all their relevant native and web-based (Fiori) SAP applications.
• Role-Based Content: The content shown (apps, tasks, news) is tailored to the user's specific role and responsibilities.
• Integrated "To Do" Inbox: Aggregates all approval workflows and tasks from different SAP systems (like SAP Cloud ERP, SAP SuccessFactors, etc.) into one unified list.
• Widgets: Offers home screen widgets for iOS and Android, allowing users to see important information (like new tasks) at a glance without opening the app.
• Intelligent Search: Allows users to search for apps and business information across the enterprise.
• Notifications: Serves as the central hub for receiving and acting on push notifications.

Analogy: SAP Mobile Start is the personalized digital front door to a users workplace. Instead of searching for different apps or websites, they can open this one app to see their urgent tasks, launch the applications they need, and stay informed.

What it is: A framework and content type for creating and displaying simple, context-aware "micro-apps." These cards are presented in a wallet-style user interface.

Purpose & Key Features:

• Glanceable Information: Designed to provide key information quickly without needing to open a full application. Examples include a sales order summary, a leave request detail, or a product's stock level.
• Simple Actions: Cards can include simple action buttons, such as "Approve," "Reject," or "Postpone."
• Template-Based: Can be easily created by administrators using templates in SAP Mobile Services, often without writing any code.
• Context-Aware: Can be triggered based on location, notifications, or by scanning a QR code.
• Consumption: While there is a standalone SAP Mobile Cards app, the primary way to consume these cards is directly within the SAP Mobile Start app, where they appear as digestible pieces of information.

Analogy: SAP Mobile Cards are like a digital wallet for a users relevant business information. Each card is a small, easy-to-read summary of one specific item, allowing users to quickly check details and take action, much like pulling out a specific credit card or ID from a real wallet.

• An event happens in a backend system (e.g., a new purchase order in SAP Cloud ERP).
• SAP Mobile Services is configured to connect to SAP Cloud ERP. It securely fetches the purchase order data and formats it into a "Mobile Card."
• SAP Mobile Services then sends a push notification to a users device.
• The user sees the notification and opens SAP Mobile Start.
• Inside SAP Mobile Start, they see the new task in their "To Do" list. Tapping on it reveals the SAP Mobile Card with the purchase order details and "Approve" / "Reject" buttons.
• They tap "Approve." This action is sent back through SAP Mobile Services, which securely updates the status of the purchase order in the SAP Cloud ERP system.

The MDK is a metadata-driven development framework. This means developers won't write traditional UI code; instead, they will define their app's pages, controls, and logic in a descriptive format (metadata), which the MDK client then renders as a native application.

Key Characteristics:

• Low-Code/No-Code: Enables rapid development through a visual editor and predefined components. Business analysts and citizen developers can build simple apps, while professional developers can extend them with JavaScript.
• Cross-Platform: A single project codebase can be deployed as a native app on iOS and Android, and also as a web application.
• Native User Experience: Unlike web-wrapper technologies, MDK renders actual native UI controls on each platform, providing a high-performance, native look and feel.
• Development Environment: You can build MDK apps in SAP Business Application Studio (a cloud-based IDE) or with the MDK extension for Visual Studio Code.
• Lifecycle Management: Apps are easily deployed and updated through SAP Mobile Services, allowing for seamless updates without requiring a new app store submission for every change.

Target Audience:

• Business Process Experts & Citizen Developers
• Professional developers looking for high productivity and cross-platform development.

Best For:

• Simple to moderately complex enterprise apps like approvals, data entry, asset management, and simple workflows where speed of development is a priority.

This is a toolkit for professional iOS developers to build native enterprise apps that adhere to Apple's design principles while incorporating SAP's Fiori design language for enterprise use.

Key Characteristics:

• Native Development: Built for Swift and the Xcode IDE, giving developers full control over the app and deep access to all iOS device features (e.g., Face ID, Core ML, ARKit).
• Fiori for iOS: Provides a rich library of pre-built, enterprise-ready UI components (charts, object cells, timelines, etc.) that ensure a consistent and intuitive user experience.
• Powerful Backend Services: Includes robust libraries for handling complex enterprise requirements like secure onboarding, end-to-end encryption, powerful offline OData synchronization, and remote notifications.
• Wizard-Driven Generation: The SDK includes an assistant tool in Xcode that can generate a starter application with all the necessary connections and boilerplate code, significantly speeding up initial project setup.

Target Audience:

• Professional iOS developers with experience in Swift and Xcode.

Best For:

• Complex, high-performance, mission-critical iOS apps that require a highly polished user experience and deep integration with device hardware, such as for field service technicians or sales executives.

This is the Android equivalent of the iOS SDK, providing a complete set of tools for professional Android developers to create native enterprise apps.

Key Characteristics:

• Native Development: Built for Kotlin (and Java) and the Android Studio IDE. It allows developers to leverage the full power of the Android platform and its ecosystem.
• Fiori for Android: Offers a library of Fiori-compliant UI components tailored for the Android Material Design system, ensuring a native and user-friendly experience.
• Robust Backend Services: Mirrors the iOS SDK's capabilities, providing powerful libraries for authentication, secure data storage, comprehensive offline OData synchronization, and push notifications.
• Wizard-Driven Generation: Like its iOS counterpart, the SDK includes a wizard that integrates with Android Studio to quickly generate a ready-to-run starter app connected to your backend.

Target Audience:

• Professional Android developers with experience in Kotlin/Java and Android Studio.

Best For:

• Sophisticated native Android apps, especially those deployed on specialized or ruggedized Android devices common in logistics, warehouse management, and manufacturing.