SAP Business Technology Platform (SAP BTP, formerly SAP Cloud Platform) provides the SAP Fiori Cloud for quickly mobilizing applications in SAP Business Suite and SAP S/4HANA.
SAP Fiori Cloud enables you to renew your UX with minimum cost and effort. SAP Fiori Cloud connects to on-premise systems as well as SAP S/4HANA Cloud systems for integrating with the business data. SAP Fiori Cloud allows users to access SAP Fiori apps using the SAP Fiori launchpad, which is the single point of access for all the SAP Fiori apps on SAP BTP.
Content of SAP Fiori Cloud
SAP Fiori Cloud offers three types of services.
Runtime and Configuration Services
This is a set of services required to configure and run SAP Fiori apps and SAP Fiori launchpad. These services allow you to define catalogs, groups, and roles, as well as assign SAP Fiori apps to catalogs and groups. You can also create multiple SAP Fiori launchpads using these services. These services enable navigation and personalization as well.
Lifecycle Management Services
As the name suggests, these services provide ways to package, upgrade, and transport cloud-ready SAP Fiori content.
Development Services
These services allow developers to build and extend SAP Fiori apps. SAP Web IDE is the most important tool as part of these services.
Note: Not all SAP Fiori apps are cloud-ready and available on SAP Fiori Cloud. SAP releases standard SAP Fiori apps selectively based on demand and technical feasibility. However, you can push any of your custom SAP Fiori apps on SAP Fiori Cloud.
Architecture and Landscape
In this post, we’ll go through various architectural options while using a cloud/on-premise hybrid option for SAP Fiori Cloud. The two important architectural styles can be classified based on how the user accesses the SAP Fiori launchpad: from inside the network or from the Internet.
Based on this, the architectural types are as follows:
- Internal access point
- External access point
Let’s consider each of these types in more detail.
Internal Access Point
Many customers are apprehensive about exposing their business data to the cloud but are keen to reap the benefits of a cloud-based SAP Fiori infrastructure. This architectural pattern takes care of these requirements by ensuring that data never reaches the cloud, while SAP Fiori launchpad and other SAP Fiori resources are accessed from the SAP Fiori Cloud.
The figure below gives a high-level overview of the internal access point architecture. SAP Web Dispatcher is a very important component of this architecture style because it determines where each call from the client should be routed. When the user/client makes an initial call to SAP Fiori launchpad, SAP Web Dispatcher sees that it’s a call to SAP Fiori launchpad-related sources and delegates the call to SAP BTP. All the calls to load the SAPUI5 library and to load each SAP Fiori app-related resource are also directed to SAP BTP.
When these resources run on the user’s browser, they need business data to be displayed and thus make calls to OData services. These calls will be delegated to the on-premise SAP Gateway system. Upon data retrieval, the data will be shown on the user’s browser. So far, the data has never entered SAP BTP and is retained within the customer’s network. This architecture style can be used from mobile phones as well; however, this will only work if the mobile phone is connected to the internal network.
This is a unique scenario where a customer makes use of SAP Fiori Cloud, and still, none of the business data passes through the cloud, thus meeting complex data flow requirements.
Next, we’ll see access from the external access point, which can be from anywhere on the Internet.
External Access Point
As the name suggests, this architectural style exposes both the business data and the SAP Fiori apps to the Internet. Both internal and external users access the SAP Fiori launchpad by connecting to SAP BTP. The SAP Fiori launchpad, the SAPUI5 library, and the accessed UI content of SAP Fiori apps are all fetched from the SAP Fiori app repository.
OData services are also routed through SAP BTP, thus there is no requirement for SAP Web Dispatcher. SAP Cloud Platform connects to on-premise systems via the Cloud Connector, which is a small server hosted by and part of the on-premise network. OData service calls are fetched to the SAP Gateway system through Cloud Connector, and data is fetched or updated.
This figure shows the external access point architecture.
Authentication to SAP BTP is based on Security Assertion Markup Language (SAML) 2.0 for browser-based single sign-on (SSO), which is a standard feature of SAP BTP. For connecting to backend systems such as SAP Gateway, SAP BTP creates a token based on the logged-in user’s identity and passes it along with the connection. The backend server may confirm the identity using a SAML 2.0-compliant identity provider.
Using the OData Provisioning Service
As you’ve seen in the previous architectures, the landscape involves having an SAP Gateway server for provisioning the OData services. However, SAP BTP provides an additional service for OData provisioning, which can be used to replace the SAP Gateway server.
The next figure shows such an architecture, where the SAP Gateway server has been replaced by SAP OData Provisioning.
The data flow is like the previous architecture with the SAP Gateway server; the only difference is that data is extracted by the OData provisioning service, which connects to the backend again using the Cloud Connector.
Editor’s note: This post has been adapted from a section of the book SAP Fiori Certification Guide: Development Associate Exam by Krishna Kishor Kammaje.
Comments