Debugging and testing your application can be complicated. It can be rather easy to test it locally and with mock-ups, but when you want to take it to the next level and test it with live data, remote services, or customize some defaults, it gets much harder.
To improve the run experience and the developer’s productivity, SAP Business Application Studio introduced the Run Configurations tool. It provides the option to test the application with different configurations that are quick and easy to set and save the developer tedious manual steps.
The tool uses the VS Code launch configuration concept, so each run configuration is de facto a launch configuration. It provides different options to run the application without changing the application itself.
In this blog, I’ll give an overview on running a full-stack application created in the ‘Full-Stack Application Using Productivity Tools’ dev space.
The full-stack application is a CAP application with an SAP Fiori/MDK UI, and the different run options the tool provides are based on the capabilities of these technologies.
To create a new run configuration, you first need to open the Run Configurations View from the activity bar. Then, create a new run configuration from the + button on the Run Configurations View, and select the option that shows your application name and PT in brackets (indicating your application is of type ‘productivity tools’).
Creating a new run configuration.
When you create a new run configuration, it will be created with the following defaults:
Default run configuration.
Let’s review the different run configuration options:
You can run your application with either a local database (SQLite in-memory database) or with an instance of SAP HANA Cloud.
If you select to run with SAP HANA Cloud, you’ll need to select an instance from the list of available instances. Your application will then be bound to this instance, (You need to be logged on to a specific CF space to see the list). If you don’t have an instance, check out the documentation to see how to easily create one using the Cloud Foundry Tools.
Any time you change your application schema, you must select the ‘Deploy data model to the SAP HANA instance before running’ checkbox.
If you choose the dummy authentication, the application user automatically passes all authorization checks, thus disabling all user authorization checks.
If you choose the ‘XSUAA’ option, then the application authorization will be handled by the XSUAA service using a bound service instance.
The run configuration will either provision a new instance of the XSUAA service for you when you create a new configuration, or it will prompt you to create a new instance when you edit a configuration. In both cases, the instance that is created is unique for your application. If the expected instance was already created by a previous run configuration, or by another colleague working on the same application, then it will be reused. (You need to be logged on to a specific CF space to generate a new service or check for an existing service).
If you check the ‘Update the XSUAA instance with the application roles before running’, each time you run the application, the security data will be deployed to the XSUAA service instance. Since this action takes time, I would recommend checking it only when you make changes in your application security data (i.e. roles).
Another important thing to point out, is that, to run with XSUAA, the application uses the approuter. The approuter component implements the necessary authentication flow with XSUAA.
You can choose the SAPUI5 version and theme with which you want to test your application with. The default selection is compatible with the version defined when the project is generated.
If your application consumes external OData services, you can choose to either run it with mock or live data.
If you choose live data, for each OData service, you must specify the target configuration that refers to the external OData service:
BTP destination name and an optional path to the service endpoint
Endpoint URL, optional path, and optional headers
Now, let’s dive a little deeper to understand how the run configuration works:
As I mentioned in the beginning, the Run Configuration tool uses the VS Code launch configuration concept.
When you create a new run configuration, a new launch configuration is created and a corresponding .env file is created with it. (If you have several files, they will be called .env1, .env2, and so on.) The .env file is read and injected to the command when it is executed.
When you run the run configuration, you actually run the launch configuration. The launch configuration runs the app using the ‘cds watch’ command.
Before launching the application, a prelaunch task and its depending tasks are executed. It runs npm install, builds the MDK project, and generates a launchpad page.
To support the default run configuration values, the default .env file contains a definition for the dummy authentication strategy.
Whenever the run configuration is bound to a BTP service instance, its credentials are saved in the corresponding .env file.
Additional tasks are created in the 'tasks.json' file to support other possible configurations, such as deploying the application’s schema. By the way, you can view all the tasks that are created in the 'tasks.json' file and also run them independently using the command Terminal-> Run Task.
When you select a customized SAPUI5 version and/or theme, the customized value is passed to the task that generates the launchpad page used for the local run.
When you select to run with live data, the target information for each OData service is added to the .env file.
I hope this blog was helpful and that you are as excited as I am with these new capabilities, and eager to try them out.
To get more information about SAP Business Application Studio, check out our documentation.
Looking forward to your feedback. Feel free to add your comments below or send us ideas.