Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 


When you develop mobile apps to consume SAP Mobile Services, onboarding can be a complex process to manage. The onboarding process needs to take care of the following details:

  • How to get the application configuration, either by providing it in code, retrieving it from the SAP Discovery Service, or by having the user scan a QR code.

  • How to handle the different authentication types: basic, OAuth, SAML, etc.

  • How to enforce security by enabling the passcode polices defined in the mobile server.

In addition, an effective onboarding process should manage the following considerations:

  • How to acquire user consent for data collection. This is a legal requirement in many countries.

  • How to ensure users review and agree to the end user license agreement (EULA).

  • How to change the user passcode when needed.

  • If the app is put into background for a while, how to display a screen allowing the user to input their passcode to unlock the app when it’s brought back to foreground.


To demonstrate the onboarding flow, we will start with a coding example, which starts the onboarding process using the Flow v2 component:
flowContext = FlowContext(
appConfig = AppConfig.Builder().applicationId("flowsv2.basic").build

Using the preceding code, the entire onboarding process can be handled automatically, as illustrated by the following sequence of screens.

These screens represent the Flow steps that the user will encounter when onboarding to the mobile app:

  1. The EULA is displayed first, allowing the user to understand and agree to the terms and conditions of using the app.

  2. When onboarding starts, the client code only provides the application ID to the Flow component, so Flow needs a way to get the complete application configuration to determine how and where to authenticate the user. The screen shown above uses a QR code for this purpose.

  3. With the QR code scanned, the complete application configuration is retrieved and the Flow component recognizes that basic authentication is required to authenticate the user, so the corresponding screen with username and password input fields is displayed. Noted that if the application is configured to use OAuth, SAML or Certificate-based security, the authentication steps would be different.

  4. After user authentication, Flow will automatically retrieve the passcode policy settings from the mobile server and display the passcode creation and verification steps if passcode policy is enabled.

  5. If the user’s device supports fingerprint authentication, and the passcode policy enables it, the fingerprint enablement step follows.


The preceding code demonstrates the onboarding flow, but how do we handle the case where the mobile app is restarted?

We call this the ‘Restore’ flow, and no code change is required at all. The same code snippet shown above can be used to start either the onboarding or restore flow because there is an ‘auto-switch’ logic built in. The Flow component checks the onboarding status and decides whether to switch to the ‘Restore’ flow automatically.

Supporting Callbacks

The Flow component provides additional support for simplifying your efforts in developing mobile apps in the form of callbacks. For example, there is a callback function in ‘FlowStateListener’, called ‘onAppConfigRetrieved’, which allows the client code to handle cases where the complete application configuration is not available, and yet still use the same code structure and not require an ‘if…else…’ statement to deal with different situations.

Observe Flow Status

To determine whether the onboarding flow finished successfully, or perhaps got cancelled before completion, you can use ‘onActivityResult’ on the Activity that started the Flow.
override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
super.onActivityResult(requestCode, resultCode, data)
when (requestCode) {
FlowConstants.FLOW_ACTIVITY_REQUEST_CODE.toInt() -> {
logger.debug("Default flow request code returns.")
if (resultCode == Activity.RESULT_OK)
Snackbar.make(fab, "Flow cancelled.", Snackbar.LENGTH_LONG).show()

After onboarding or restore finishes, ‘okHttp’ will be ready. The client code can get it from ‘ClientProvider.get()’ to perform API calls.

The Flow component also has a ‘state listener’ mechanism, allowing the client code to observe the state status with ‘FlowStateListener’. This will be the subject of future articles.


With the code snippet and the screenshots above, we’ve tried to give you a sense of how easy it is to use the Flow component. But Flow also provides additional flexibility and process simplification, with such features as:

  • Configuring the EULA content URL, or even excluding this step.

  • Configuring which activation method to use, either Discovery Service or a QR code scan.

  • Passing in a QR code parser to scan your own special QR code formats.

  • Supporting customized passcode validation logic.

  • Specifying which OAuth client to use.

  • Developing your own flows using the framework.

We’re going to publish additional articles like this one, discussing different aspects of the Flow component. If you have any questions, please leave them here: