Skip to content

Solution Architecture

With a plethora of choices Architects are spoiled for choice when it comes to Mobile Solutions. Additionally, the choices that are made must also complement existing landscapes at a variety of customers, seamlessly.

The image and guidelines below, will help start the relevant discussions and provide insights into some typical architecture patterns.

SAP Mobile Services general architecture

Sample Back-End Scenario

This is the simplest scenario possible, where a mobile app is accesses a Sample OData service contained within the mobile services itself. A simple mobile app, a REST client or even a plain HTTP Client can then be used to access the data in the sample service.

Use when:

This scenario is suitable for developers to quickly check and validate the correct use of the mobile SDK in their application. Administrators can use this scenario to validate configuration settings, specifically in the area of security.

This is not a productive scenario.

Variants:

Instead of the Sample Service provided, you are free to use any publicly available service or a mock services created with Mobile Back-End Tools

Products used:

  • SAP Mobile Services
  • SAP BTP SDK for iOS, SAP BTP SDK for Android, mobile development kit, SAP Mobile Cards, Mobile Back-End Tools or Sample Service

SAP Mobile Services - Sample Service Architecture

Existing OData Service in SAP Business Technology Platform

In this scenario all the components for a given solution exist within the SAP Business Technology Platform.

This extension scenario sits on top of an existing back-end OData or REST services that can be directly consumed via mobile services. Such a setup can be used when the existing OData services deliver quality data so and can be consumed by mobile applications directly. This is often the case for pure online apps and where newly written solutions should be extended to support mobile use cases. The role of mobile services in this scenario is to add capabilities like governance (via application policies), supportability, usage analysis, push and others to the mobile consumption channel.

With all the components cohabiting the platform, such a solution speaks volumes in its simplicity both in terms of maintenance as well as initial setup.

Use when:

Mobile applications need access to existing services.

Variants:

Any OData or RESTful API reachable by mobile services directly can be a valid variants for this approach.

Products used:

  • SAP Mobile Services
  • SAP BTP SDK for iOS, SAP BTP SDK for Android, mobile development kit, SAP Mobile Cards
  • Existing OData service

SAP Mobile Services - Existing Services architecture

New OData Service in SAP Business Technology Platform

In this scenario all the components for a given solution exist within the SAP Business Technology Platform.

Following the traditional three-tier architecture, a business layer logic is responsible for providing business logic according to the use case. This layer is build based on a Java application exposing OData built with mobile back-end tools.

The persistence layer is a relational database running within the SAP Business Technology Platform.

The front end will be provided by a mobile application.

This solution is quick to setup and easy to maintain, since all the components are on the same platform and provides the best flexibility in data processing.

Use when:

Often used in “green field” projects. All components are developed from scratch. The middle layer in this scenario allows for complex data processing and filtering. This is a good approach if other channels, like web apps, are accessing the same data source. With the possibility to provide channel specific logic, this scenario is widely used.

Variants:

Databases could differ, for example you can choose between SAP HANA or PostgreSQL.

Products used:

  • SAP Mobile Services
  • SAP BTP SDK for iOS, SAP BTP SDK for Android, mobile development kit, SAP Mobile Cards
  • SAP HANA
  • PostgreSQL
  • mobile back-end tools

SAP Mobile Services - New OData Service

SAP Gateway OData Services on-Premises

This scenarios is a hybrid-scenario in regards of cloud architecture, since parts of the solution are located on-premises while other parts are in SAP Business Technology Platform. In order to securely connect the on-premise data sources SAP Business Technology Platform offers the SAP Cloud Connector as part of SAP Business Technology Platform Connectivity, which establishes an inside-out connection to the customers SAP Business Technology Platform account. The connector supports allowing of on-premise resources and provides means for Identity Propagation to on-premise systems to allow Single-Sign on towards the back-end systems. You can find more information about SAP Cloud Connector here: SAP Cloud Connector

The OData producer in this scenario is typically the SAP Gateway. Since the SAP Gateway is capable of providing sophisticated business logic in the service implementation itself, there is no need for an additional business logic layer. All necessary behavior can be implemented using ABAP in SAP Gateway.

Use when:

This is the most widely used scenario when existing business systems are extended. The data in existing SAP S/4HANA or Enterprise Resource Planning (ERP) systems both complex and enterprise-critical valuable. Therefore, putting an extension project on top of it is the most appropriate choice in terms of agility and sustainability. This solution architecture is the blueprint for this.

Variants:

On-premise SAP Gateway architectures may vary. Do also consider that the SAP Business Technology Platform OData Provisioning may provide replacement to or complement features of the on-premise SAP Gateway.

Products used:

  • SAP Mobile Services
  • SAP BTP SDK for iOS, SAP BTP SDK for Android, mobile development kit, SAP Mobile Cards
  • SAP Cloud Connector
  • SAP Gateway or mobile back-end tools
  • SAP S/4HANA / ERP

SAP Mobile Services - SAP Gateway Architecture

3rd Party Back-End System on-Premises

In cases where the data sources are non-SAP systems, the components of the architecture remain unchanged from the previous example with the non-SAP nature of the data source being the only difference.

OData services are necessary, only for offline applications. For online mobile applications, a rest-based service could suffice and the back-end system can be directly accessed via the SAP Cloud Connector.

There are several approaches to producing OData services from a data source. One may implement the OData service in its entirety using a programming language. Alternatively, one may use an integration product like SAP Business Technology Platform Integration.

SAP Business Technology Platform Integration: SAP Business Technology Platform Integration enables the mapping of SOAP or REST-based data sources to OData using advanced mappings for CRUD (Create, Read Update, Delete operations).

Programming options (not complete, but often used):

  • mobile back-end tools. Model-driven approach to create or integrate OData and REST-based APIs. JAVA skills needed for custom logic extensions.

  • .NET – often used when the data source is an Microsoft SQL Server. .NET skill set is required.

  • Apache Olingo – provides multiple options to connect to various data sources, e.g. JPA or JDBC, but also a mapping to SOAP services could be possible. Olingo uses JAVA to implement the services. This framework is rather low-level and significant effort is needed to implement a service in its entirety. SAP recommends using Mobile Back-End Tools instead.

  • SAP Gateway – using a secondary database connection and ABAP to implement the services

An exhaustive list of OData producers can be found here: OData.org

Use when:

Your on-premises system is not an SAP system.

Variants:

Depending on the nature of the system of record the choice of the implementation technology varies. For example, if your business records are located in a Microsoft SQL Server it can be beneficial to use .NET to keep the overall solution in the same ecosystem. Using the mobile back-end tools can be a powerful tool for 3rd party integration in a mobile scenario.

Products used:

  • SAP Mobile Services
  • SAP BTP SDK for iOS, SAP BTP SDK for Android, mobile development kit, SAP Mobile Cards
  • SAP Cloud Connector
  • SAP Business Technology Platform Integration or mobile back-end tools
  • 3rd party back-end system

SAP Mobile Services - 3rd Party back end on-premises

Back-End System on-Premises with Data Staging in SAP Business Technology Platform

The scenarios discussed so far have in common that the data access was done directly against an OData service served from the ERP or database – the one system of record. Another option to do this is to use a data staging layer and copy the date from the system of record to a SAP Business Technology Platform. This would decouple the actual back-end system and the mobile data scenario in the sense that mobile users will not touch the back-end directly.

Important in this scenario is to understand the data behavior in regards to data aging, data movement and bidirectional or unidirectional data transport, because this is not a scenario where data is handled directly on a request/response basis. Instead, the mobile application works with data copies.

The need for a standard compliant OData producer is the same as in other scenarios.

Use when:

In the case of Business-to-Consumer (B2C) scenarios, this approach unburdens the anticipated load of consumer access off of the back-end system. Here, all consumer traffic will be handled by the staging area and production systems can concentrate on providing core services.

Additionally, scenarios with a significantly large amounts of data are suitable candidates for this solution architecture.

This scenario has also been used when migrating an existing MBO (Mobile Business Object) data model from Sybase Unwired Platform to the SAP Mobile Services.

Variants:

Depending on the technology used by the system of record (source) and the cloud staging area (target), various technologies can be used to transport the data from the source system to the target. Possible options are Extract, Transform, Load (ETL) tools or data replication technologies. Which one fits best should be carefully evaluated on a case by case basis. Another variant could be to keep the data near the system of record on-premise. Such a configuration applies in those cases where significant computing resources are necessary to manage the data.

Products used:

  • SAP Mobile Services
  • SAP BTP SDK for iOS, SAP BTP SDK for Android, mobile development kit, SAP Mobile Cards
  • SAP Cloud Connector
  • mobile back-end tools

SAP Mobile Services - Data Staging Scenario

Real Life Customer Examples

In real-world customer scenarios the services in use quickly drive complexity in the architecture. The examples above should be seen as a foundation for further discussions and not as reference architectures in themselves. The following solution diagrams are real world, productive customer scenarios.

The first example is a multi-channel experience where the web channel is provided with a UI5 application on SAP Business Technology Platform. Interesting to note, are the number of back-end systems (SAP and non-SAP) that have been integrated into this solution.

SAP Mobile Services - Customer Solution A

The second example is more straightforward where a mobile solution integrates into an on-premises warehouse system.

SAP Mobile Services - Customer Solution B


Last update: April 14, 2021