Mobile solutions came in many flavours and software architects are sometimes struggling choosing the right components for their mobile scenario. Is also important that the chosen architecture fits perfectly into existing customer landscapes, which vary vastly.
The following should help solution architects to get insights into typical solution architectures for mobile projects and follow best practices. Besides discussing the typical component and product setup. Security aspects, like authentication, Single-Sign-On and Identity propagation are out of scope of this document.
Following products will be covered: SAP Cloud Platform Mobile Service for development and operations, SAP Cloud Platform Connector, SAP Mobile Platform SDK, SAP Cloud Platform SDK for iOS, SAP Gateway, SAP Cloud Platform Integration, SAP HANA
Description:
This is the simplest scenario possible, where a mobile app is accessing a Sample OData service provided by Mobile Services itself. An simple mobile app 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.
Products used:
Description:
All components for a given solution are located within SAP Cloud Platform and working together to constitute a solution. The back-end system is typically a SAP HANA database, exposing the data using XSODATA directly to mobile services.
This solution is quick to setup and easy to maintain, since all components are on the same platform.
Use when:
Often used in "green field" projects, where from project start, all components are developed from scratch and simple OData services are enough to consume on the mobile application part and no additional business logic (middle tier) is needed. In this case the mobile app will become a fat client, even in pure online scenarios.
Variants:
Other OData exposing systems are valid variants for this approach.
Products used:
Description:
All components for a given solution are located within SAP Cloud Platform and working together to constitute a solution. The back-end system is typically a SAP HANA database.
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 JAVA application exposing Odata, mostly using Apache Olingo - an open source framework.
This solution is quick to setup and easy to maintain, since all components are on the same platform and provides best flexibility in data processing. Nevertheless, the additional middle layer means additional project effort and cost.
Use when:
Often used in "green field" projects, where from project start, 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 Portal pages or Web Apps are accessing the same data source. With the possibility to provide channel specific logic, this scenario is widely used.
Variants:
In medium or small projects the JAVA tier can be replaces with the XSEngine. The middle tier is then implemented in server-side JavaScript.
Sometimes the Java tier or the HANA DB are in other SAP Cloud Platform accounts - this setup requires additional attention to the security, since multi-account security needs to be setup and maintained.
Products used:
Description:
This scenarios is a hybrid-scenario in regards of cloud architecture, since parts of the solution are located on-premise in the customer landscape other parts are in SAP Cloud Platform. In order to securely connect the on-premise data sources SAP Cloud Platform offers the SAP Cloud Platform Connector, which establishes an inside-out connection to the customers SAP Cloud Platform account. The Connector also allows whitelisting of on-premise resources and provides means for Identity Propagation to on-premise systems.
The OData producer in this scenario is normally 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 and there is no need to create a solution from scratch. The data in existing ERP systems are very valuable and it is much cheaper and more agile to "just" put an extension project on top of it. This solution architecture is the blueprint for this.
Variants:
On-premise SAP Gateway architectures may vary. Also, the use of a SAP Gateway Hub installation can be substituted with SAP Cloud Platform OData Provisioning.
Products used:
Description:
Sometimes the data to be mobilized is not in an SAP but in a 3rd party system. Architecture-wise the same components apply as in the previous example. The various options to expose the 3rd party data as OData is the only difference to it.
There is on additional thing to mention: In fact, OData is necessary for offline applications only. For online-only mobile applications a rest-based service would be sufficient and the back-end system can be directly connected via the SAP Cloud Platform Connector.
There are several ways to produce OData and there are two different approaches to it. First you can implement the OData service using a programming language. This approach provides most flexibility. The second option is to use a Integration Product like SAP Cloud Platform Integration.
SAP Cloud Platform Integration:
SAP Cloud Platform Integration allows to convert SOAP or REST-based data sources to OData using advance mappings for CRUDQ (Create, Read Update, Delete and Query operations).
A more exhaustive list of OData producers can be found here: http://www.odata.org/ecosystem/
Use when:
Your on-premise system is not an SAP system.
Variants:
On-premise SAP Gateway architectures may vary. Also, the use of a SAP Gateway Hub installation can be substituted with SAP Cloud Platform OData Provisioning.
Products used:
Description:
The scenarios we have discussed so far had in common that the data access was done directly against an OData service in 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 Cloud Platform. This would separate the actual ERP system and the mobile data scenario in the sense that mobile users will not touch the ERP directly.
Important in this scenario is to understand the data behavior in regards to data aging, data movement and bi- or unidirectional data transport.
The need for a proper OData producer is the same as in other scenarios.
Use when:
In case of Business-to-Consumer scenarios (B2C) this is a good approach to scale the anticipated load of consumer access off the back-end system. Here, all consumer traffic will be handled by the staging area and production systems can concentrate on providing services internally.
Besides B2C scenarios, situations with a huge amount of data is another candidate for this solution architecture.
Variants:
Depending on the technology used by the system of record (source) and the cloud staging area (target) different technologies can be used to transport the date from source to the target. Possible options are ETL tools or data replication technologies. Which one fits best should be carefully evaluated on a case by case basis.
Products used:
The following should help solution architects to get insights into typical solution architectures for mobile projects and follow best practices. Besides discussing the typical component and product setup. Security aspects, like authentication, Single-Sign-On and Identity propagation are out of scope of this document.
Following products will be covered: SAP Cloud Platform Mobile Service for development and operations, SAP Cloud Platform Connector, SAP Mobile Platform SDK, SAP Cloud Platform SDK for iOS, SAP Gateway, SAP Cloud Platform Integration, SAP HANA
Scenarios
Name: No Back-End
Description:
This is the simplest scenario possible, where a mobile app is accessing a Sample OData service provided by Mobile Services itself. An simple mobile app 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.
Products used:
- SAP Cloud Platform Mobile Service for development and operations
- SAP Mobile Platform SDK or SAP Cloud Platform SDK for iOS
Name: Direct OData Service in SAP Cloud Platform
Description:
All components for a given solution are located within SAP Cloud Platform and working together to constitute a solution. The back-end system is typically a SAP HANA database, exposing the data using XSODATA directly to mobile services.
This solution is quick to setup and easy to maintain, since all components are on the same platform.
Use when:
Often used in "green field" projects, where from project start, all components are developed from scratch and simple OData services are enough to consume on the mobile application part and no additional business logic (middle tier) is needed. In this case the mobile app will become a fat client, even in pure online scenarios.
Variants:
Other OData exposing systems are valid variants for this approach.
Products used:
- SAP Cloud Platform Mobile Service for development and operations
- SAP Mobile Platform SDK or SAP Cloud Platform SDK for iOS
- SAP Cloud Platform SAP HANA service
Name: OData Service in SAP Cloud Platform
Description:
All components for a given solution are located within SAP Cloud Platform and working together to constitute a solution. The back-end system is typically a SAP HANA database.
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 JAVA application exposing Odata, mostly using Apache Olingo - an open source framework.
This solution is quick to setup and easy to maintain, since all components are on the same platform and provides best flexibility in data processing. Nevertheless, the additional middle layer means additional project effort and cost.
Use when:
Often used in "green field" projects, where from project start, 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 Portal pages or Web Apps are accessing the same data source. With the possibility to provide channel specific logic, this scenario is widely used.
Variants:
In medium or small projects the JAVA tier can be replaces with the XSEngine. The middle tier is then implemented in server-side JavaScript.
Sometimes the Java tier or the HANA DB are in other SAP Cloud Platform accounts - this setup requires additional attention to the security, since multi-account security needs to be setup and maintained.
Products used:
- SAP Cloud Platform Mobile Service for development and operations
- SAP Mobile Platform SDK or SAP Cloud Platform SDK for iOS
- SAP Cloud Platform SAP HANA service
- SAP Cloud Platform Java Server
Name: SAP Gateway OData Service on-premise
Description:
This scenarios is a hybrid-scenario in regards of cloud architecture, since parts of the solution are located on-premise in the customer landscape other parts are in SAP Cloud Platform. In order to securely connect the on-premise data sources SAP Cloud Platform offers the SAP Cloud Platform Connector, which establishes an inside-out connection to the customers SAP Cloud Platform account. The Connector also allows whitelisting of on-premise resources and provides means for Identity Propagation to on-premise systems.
The OData producer in this scenario is normally 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 and there is no need to create a solution from scratch. The data in existing ERP systems are very valuable and it is much cheaper and more agile to "just" put an extension project on top of it. This solution architecture is the blueprint for this.
Variants:
On-premise SAP Gateway architectures may vary. Also, the use of a SAP Gateway Hub installation can be substituted with SAP Cloud Platform OData Provisioning.
Products used:
- SAP Cloud Platform Mobile Service for development and operations
- SAP Mobile Platform SDK or SAP Cloud Platform SDK for iOS
- SAP Cloud Platform Connector
- SAP NetWeaver (includes SAP Gateway)
- SAP ERP
- SAP Cloud Platform OData Provisioning
Name: 3rd Party Back-end System on-premise
Description:
Sometimes the data to be mobilized is not in an SAP but in a 3rd party system. Architecture-wise the same components apply as in the previous example. The various options to expose the 3rd party data as OData is the only difference to it.
There is on additional thing to mention: In fact, OData is necessary for offline applications only. For online-only mobile applications a rest-based service would be sufficient and the back-end system can be directly connected via the SAP Cloud Platform Connector.
There are several ways to produce OData and there are two different approaches to it. First you can implement the OData service using a programming language. This approach provides most flexibility. The second option is to use a Integration Product like SAP Cloud Platform Integration.
SAP Cloud Platform Integration:
SAP Cloud Platform Integration allows to convert SOAP or REST-based data sources to OData using advance mappings for CRUDQ (Create, Read Update, Delete and Query operations).
- Programming options (not complete, but often used):
- .NET - often used when the data source is an Microsoft SQL Server. .NET skillset 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 would be possible. Olingo uses JAVA to implement the services.
- SAP Gateway - using a secondary database connection and ABAP to implement the services
A more exhaustive list of OData producers can be found here: http://www.odata.org/ecosystem/
Use when:
Your on-premise system is not an SAP system.
Variants:
On-premise SAP Gateway architectures may vary. Also, the use of a SAP Gateway Hub installation can be substituted with SAP Cloud Platform OData Provisioning.
Products used:
- SAP Cloud Platform Mobile Service for development and operations
- SAP Mobile Platform SDK or SAP Cloud Platform SDK for iOS
- SAP Cloud Platform Connector
- SAP Cloud Platform Integration
- 3rd party back-end system
Name: Back-end system on-premise with data staging in SAP Cloud Platform
Description:
The scenarios we have discussed so far had in common that the data access was done directly against an OData service in 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 Cloud Platform. This would separate the actual ERP system and the mobile data scenario in the sense that mobile users will not touch the ERP directly.
Important in this scenario is to understand the data behavior in regards to data aging, data movement and bi- or unidirectional data transport.
The need for a proper OData producer is the same as in other scenarios.
Use when:
In case of Business-to-Consumer scenarios (B2C) this is a good approach to scale the anticipated load of consumer access off the back-end system. Here, all consumer traffic will be handled by the staging area and production systems can concentrate on providing services internally.
Besides B2C scenarios, situations with a huge amount of data is another candidate for this solution architecture.
Variants:
Depending on the technology used by the system of record (source) and the cloud staging area (target) different technologies can be used to transport the date from source to the target. Possible options are ETL tools or data replication technologies. Which one fits best should be carefully evaluated on a case by case basis.
Products used:
- SAP Cloud Platform Mobile Service for development and operations
- SAP Mobile Platform SDK or SAP Cloud Platform SDK for iOS
- SAP Cloud Platform Connector
- SAP Cloud Platform Integration
- SAP HANA with Smart Data Integration
- SAP Managed Tags:
2 Comments
