Over the course of last year, I’ve published several blog posts covering SAP Build Apps and connectivity with other SAP systems. In those posts I’ve used various products available in the SAP Build portfolio, such as SAP Build Code to develop a CAP-based data service and SAP Build Work Zone to publish a web application created in SAP Build Apps.
This year, we have combined the SAP Build portfolio into a new commercial offering with a simplified licensing model to ease adoption. SAP Build is the unified SAP low-code, pro-code and AI assisted development platform designed to modernize enterprise software and embrace digital transformation.
In this new blog series, I will build upon the data service created last year and use various options related to SAP Mobile Services to create (mobile) applications. The blog posts are set up like a tutorial and will provide actionable insights and detailed steps to guide developers effectively.
The following sections offer a detailed walkthrough of the mobile app development process using SAP Build and Mobile Development Kit (MDK). Each step is designed to ensure precision and clarity, enabling developers to replicate the process seamlessly.
Many tutorials and demos make use of unauthenticated data sources to avoid the rather tedious process of making the connections work. This makes sense for quick demos, but does not reflect the reality we are in. In this series, I am going to show you what it is really like to use authentication and role-based access, and how to work around some quirks that are currently in the toolchain.
This year, I've switched to Drawio for creating the diagram.
As mentioned, I am going to continue the blog series based on what I’ve published last year and reuse the data service. A quick recap:
In Consuming SAP with SAP Build Apps - Connectivity options for low-code development - part 1 I have created a very simple data model in SAP Business Application Studio containing a Product entity, added some sample data, and made sure only authenticated users were able to access it. In the following blog post Consuming SAP with SAP Build Apps - Connectivity options for low-code development - part 2 I have added more fine grained Role-based access control.
A few posts later, Consuming SAP with SAP Build Apps - refining data sources with CAP while keeping a clean core showcases using CAP to combine the Product entity with a subset of external data from an S/4HANA system: Supplier information from BusinessPartnerA2X.
And in the last relevant part, Consuming SAP with SAP Build Apps - adding application logic with CAP while keeping the core clean I have added custom application logic in the data service to manipulate some of the data coming from the S/4HANA system.
The SAP Build Lobby serves as the central hub for project creation and management. We begin by selecting the option to Create a new application project.
Notice that the SAP Build Lobby’s user interface has been revamped.
After selecting the Objective – build an Application, click Next and select Mobile. We could also use the Full-Stack option, which we’ve also used to create, test and deploy our data service in the previous blog series. However, for this blog post I will use the dedicated Mobile development environment. This environment contains more tools related to mobile use cases.
After selecting Next, we have basically one choice: Mobile Application. This enables us to develop platform-agnostic, metadata-based applications that can be created once and deployed across multiple platforms.
After selecting Next, we can give the project a name and description and have the choice to select a Dev Space. You can create a new one or select an existing one – if available. Take note that you cannot have more than two Dev Spaces running simultaneously with SAP Business Application Studio. If you already have two Dev Spaces running, then please navigate to the Dev Space Manager via the link Additional Application Types and shut down at least one of them before creating a new mobile specific Dev Space.
Select Review to move to the next step in the project creation wizard.
The summary page gives you a clear overview of your selected choices for you to review. If all looks good, please go ahead and select Create.
You will navigate back to the SAP Build Lobby main page where you can see your project being created. This can take a few seconds to up to a minute, as the Dev Space is being created and spun up.
Once the project is created, select the project name, which is a link to open SAP Business Application Studio with your mobile Dev Space.
A mobile development perspective is opened within SAP Business Application Studio, providing access to tools specifically tailored for mobile application development. This environment facilitates integration, editing, debugging, and deployment activities for your mobile application.
In the Storyboard view of SAP Business Application Studio, initiate the process of creating a new Mobile Services application by selecting the + button in the Runtime Resources section.
If you have not signed into the Cloud Foundry runtime of your target environment yet, then you will be asked to sign in now. The easiest way to do this, is by using the SSO Passcode and opening a new browser page to generate the passcode. Copy the passcode and paste it into the field to sign in. All can be done with just a few clicks.
Make sure to use the Cloud Foundry Endpoint from your target runtime environment, as it may differ from your development environment. You can find the endpoint in the Overview tab of the target subaccount’s BTP cockpit.
After signing in, you’ll need to select the Cloud Foundry Organization and Cloud Foundry Space.
Once signed in and the target is selected, the SAP Mobile Services instance active in this environment will be used to create a new application configuration. If there already application configurations defined in this SAP Mobile Services instance, then they will be listed and you could select one (but we won’t …).
Select the + button to create a new mobile application configuration. We will provide an Application Name and Application ID and select IAS for the Security Settings. We can skip the sample OData ESPM, as we have created our own data service.
In the Next step, we will configure a Mobile Services specific destination that is associated with the mobile application configuration. Note that this is not a BTP destination that will be visible in the BTP Cockpit. You will rather find it in the Mobile Services Admin UI.
There are multiple ways to configure this destination. I will showcase two options:
Let's start with the easiest way by using an existing BTP Destination.
We first provide a name for the destination. Then, select the Destination Type SAP Destination Service. The dropdown list for Cloud Destination Name will show all destinations defined in the subaccount. When we deployed the CAP service to BTP, a destination was created and configured for handling the authentication. By using the SAP Destination Service, we can make use of the same destination for the mobile services app. This saves us from having to configure the authentication.
After selecting the destination, we are done and select Create App.
You can skip this part if the above worked for you. In case you have a data service, but there is no BTP Destination defined for accessing it, we can configure an Internet Destination. This is a bit more work to configure. I will use the same destination as reference here to configure it in this example. You can apply the same to connect to other OData services exposed to the internet.
First, we provide a Destination Name.
Most of the remaining items can be copied from the BTP Destination that was already created during the deployment of the CAP service, except for the client secret.
In the screenshot below I have opened the destination deployed together with the data service. Items to be copied:
We have one item remaining that cannot be copied from the BTP destination: the client secret. It is hidden. Where can we find this secret? I’ll provide you one way to find it. I am sure there are more ways and maybe even easier way to get it (feedback is welcome 😉 ).
Navigate to the subaccount where you have deployed the data service and open the Cloud Foundry Space where the service is running. Check the Instances tab and select the uaa instance (named: <your service name>-uaa) deployed with your data service and select the link View Credentials. You will find the “clientsecret” in the JSON structure shown.
Once the form is completed, click the Create App button. The application configuration will now be created in SAP Mobile Services. This will take a few minutes. Once configured successfully, the state will change to Started.
However, before we continue adding the app to the project, we must fix and enhance the configuration. For this we need to navigate to the SAP Mobile Services Admin UI. You can easily open the correct instance by selecting the Mobile Services link.
Now we need to resolve an issue with the destination settings. Navigate to the Connectivity settings.
As you can see, the destination that was created is not configured for Authentication. Select the destination and select Edit.
Ensure to configure the destination as described earlier. Luckily, most of the fields are already filled with the correct information. For the SSO Mechanism select OAuth2 User Token Exchange instead of No Authentication. Select Token Service URL Type : Dedicated. Click Next and Finish to save the destination configuration.
Regardless of which method you've used to create the mobile destination, we need to activate one more feature for our app in SAP Mobile Services.
Navigate to the SAP Mobile Services Admin Cockpit to configure Cross Context Single Sign-On (SSO) for the newly defined mobile app. This feature in SAP Mobile Services allows users to reuse their OAuth tokens obtained in one context (like a desktop browser or mobile browser) in another context (like a native mobile app). This eliminates the need for users to log in again when switching between platforms. It allows for seamless user authentication across multiple backend systems. In our case, we have a CAP-based service deployed to BTP, that makes use of an external data source coming from an S/4HANA system.
In the application configuration, navigate to the Security settings.
Select the Edit button and tick Enable Cross Context SSO. Cross Context SSO streamlines user experiences by eliminating the need for multiple logins.
Click OK to update the Security settings and navigate back to the application’s Settings.
We can test the Destination within the SAP Mobile Services Admin Cockpit to verify its functionality and resolve potential issues before we even deploy the application to a mobile device. This ensures that the mobile application interacts seamlessly with backend systems, and we can avoid lengthy and troublesome debugging session on the mobile device.
When selecting Ping, the connection between SAP Mobile Services and the data source is checked. If this is not successful, then you need to check the URL you’ve specified.
Next to Ping, there is another button to open the OData Application Destination Test. Select this to open a simple UI that you can use to check the OData service.
You should be able to see entity data from Products, as well as entity data from MySupplier. If you do not see this data, then you’ll need to double check your configuration settings. There is no point adding the application to the project without access to this (meta)data, as the metadata is used to create the application’s data model and user interface structure.
Navigate back to SAP Business Application Studio, ensure the destination is selected and click the Add App to Project button.
This will initiate a passcode generation process. The passcode must be manually entered to validate access.
A notification in the bottom-right appears that helps you to open a hyperlink to create an SSO passcode.
Copy the passcode and go back to SAP Business Application Studio to paste the passcode into the prompted field at the top of the screen.
Once the application is added to the project you will see the Storyboard again, which is now updated with the newly added application and destination.
You can check the data model of the external resource by selecting the item and clicking View Diagram. This will open a graphical view of the mobile destination’s metadata, which is stored in an XML file. The model should be the same as what I’ve shown in the prerequisites section.
Switch back to the Storyboard view and create a UI application. This will open a UI creation wizard to generate the MDK UI. You can change the application name if needed and select the MDK template type. In our case, we will go for the CRUD type, allowing users to create, read, update and delete entity data.
For the target MDK Client version, ensure the highest version is selected and enable auto-deployment to SAP Mobile Services after creation.
After selecting Next, on the second page of the wizard select Service Type OData. We do not want to enable mobile Offline capabilities because the data service we have created is not able to handle this.
We do want to select all data collections from the data source.
Select Finish. You will see an Action page prompting to overwrite the vscode settings. I think merging is the best option here (although you don't have that option).
After selecting Finish, the UI application is created and the application’s metadata bundle is deployed to SAP Mobile Services. Upon successful deployment, the MDK Application Editor is opened, showing an onboarding dialog containing a QR code.
Any SAP Mobile Services Client app can download the metadata from SAP Mobile Services after finishing the onboarding steps.
Now that the application has been deployed, we can use a so-called ‘player’ to ‘execute’ the combination of metadata and JavaScript on a device. It is possible to build such a player app yourself, customized to your needs. However, in most cases a generic client is good enough. We have published such a generic MDK client in the public app stores.
You can find the “SAP Mobile Services Client” in the Apple AppStore as well as the Google Play Store. Download and install this app on your device.
You can now scan the QR code with the Mobile Svcs app.
A short video of the mobile onboarding process can be seen below. Steps:
In this blog post I have outlined the steps to create a cross-platform mobile application in SAP Build starting from the SAP Build Lobby, all the way to having the application running on a mobile device. The mobile user of the app can access business data that is protected through authorization and role-based access control.
This serves as a starting point to further application development steps.
As always, feedback is welcome to improve the blog posts, but most importantly the products involved.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
24 | |
12 | |
11 | |
10 | |
9 | |
8 | |
7 | |
7 | |
7 | |
5 |