As promise in the previous blog Build Custom SAPUI5 Application, we will expose here the technical details behind the application. We will describe how we can create a SAPUI5 Application in SAP Business Technology Platform and then we will highlight main components implemented in this application.

The source code of this application is available at following GitHub repository Cloud ALM Application examples.You may clone this repository in your own SAP Business Application Studio space.

Cloning the SAP UI5 application in SAP BAS

Here are prerequisite steps to have your own development environment in order to build the SAP UI5 standalone application in SAP Business Technology Platform. All those steps can be performed in a SAP BTP Trial account.

Create development Space

As first step, create a development space and connect to cloud foundry. The dev space creation is triggered by following link:

From the SAP Business Application Studio, create a Full Stack Cloud Application Space:

Clone the project

From the Welcome page, use the Clone from Git to clone the project from the Git repository.

At this point you should have the full code available in your development space.

Configure Destinations

The application is relying on the destination services provided by BTP. These destinations are the endpoints used to communicate with the SAP Cloud ALM APIs.

We will set up 2 destinations:

• SAP cloudalmapi_sandbox to access the sandbox environment
• and the SAP cloudalmapi which will access a live environment (optional if you don’t have your own environment).

Note: For live environment, the authentication mechanism used here is OAuth2ClientCredentials so URL, Client ID and Token Service URL are required. Check this link for more information. SAP Cloud ALM Extend with APIs (Part 2): Get started with SAP Cloud ALM API | SAP Blogs.

To create a destination:

• Select your account and subaccount:
  
• Select Destinations from the Connectivity section on the left side, then New Destination
• Create destination SAP cloudalmapi_sandbox as follow:
  Setting the property WebIDEEnabled to true will make this destination available in your development space.
  Notice that the access to https://sandbox.api.sap.com do not require authentication as it is a demo API.
• Optionally, you may set up the second destination SAP cloudalmapi to point to your existing SAP Cloud ALM instance. Here is an example of destination pointing to a real instance
  The authentication mechanism used here is OAuth2ClientCredentials so URL, Client ID and Token Service URL are required.

Starting the application

To run the application, it is possible to either start it locally or build, deploy and run in BTP. We will have to look to both options.

Run application locally

When running locally, a dedicated configuration file (launch.json) is needed. This file is not part of the git repository and must be created as follow:

• Go to the Run Configurations tab in SAP Business Application Studio and create a new configuration
  
• Select your app,
• For the UI5 version, select latest,
• For the Destination Type, select Connect to SAP System,
• Choose one of the destinations defined above (only one can be selected from the wizard).

Note that if more than one destination is needed (this is the case here), you have to update the generated file manually:

“args”: [

      “–“,

      “–ui5”,

      “–backendConfig”,

      “[{\”path\”:\”/cloudalmapi\”,\”pathPrefix\”:\”/api\”,\”destination\”:\”cloudalmapi\”},          {\”path\”:\”/SAPCALM\”,\”pathPrefix\”:\”/SAPCALM\”,\”destination\”:\”cloudalmapi_sandbox\”}]”

],

Run the application in BTP

In order to run the application in BTP, here are steps to follow:

• on the mta.yaml file, right click and select Build MTA Project, a file archive.mtar is generated in the folder mta_archive.
• from the archive.mtar, right click and select Deploy MTA Archive, select the account, subaccount where the destinations are defined.
• Once deployed, the application should be available as standalone application in your subaccount.

Destinations

As additional information, notice the file xs-app.json, this is where the routes are defined that will forward the backend request to the correct destination (similar to the file launch.json)

Standalone App Router

Architecture of the application

How it works

This application is following the MVC pattern:

• Model: all the model logic is in the ModelManager.js file. This component is responsible to communicate with the REST Cloud ALM APIs through the proper destination. It is also responsible to notify the Views when data are ready to be displayed.
• View: All views are located in the directory webapp/view. View mainly contains UI elements as displayed in the application: Project List view, Pie Chart view, Kanban view….
• Controller: All controllers are located in the directory webapp/controller. They are responsible for communication between the views and the model manager.

Model Manager

In SAPUI5 Application, OData model is usually the preferred approach as it allows to directly bind model with the service API. In this application example, we are accessing a Cloud ALM APIs which is a Rest API. This is the purpose of the ModelManager.js.

The Model Manager has multiple roles:

• Connect to the Cloud ALM APIs to perform GET/PUT/PATCH ajax request,
• Compute statistics data based on raw data,
• Create or refresh JSON Model,
• Send events to the listening views to notify when data are ready.

Connection to the destinations

The Model Manager is connecting to the Projects and Tasks APIs. As we explained, we can connect to either to Sandbox or Production destination. A dedicated method is available for selecting the right route.

REST Requests

All our calls are using REST protocol and return JSON data. For GET request, a dedicated method loadData() is available from the JSONModel object (JSONModel API Reference).

Load Projects Request

We just have to fill the headers with the correct information (the API Key depends on the API you are consuming; you can find it on API Hub) and then call the loadData method (Don’t worry about the fireEvent method, it will be explained later). You can find code snippets to use this method properly in the documentation of the API you want to consume, on the API Hub website.

For other request types (like POST,PATCH,DELETE…) we will have to use Ajax requests.

Delete Task Request

Eventing

All requests made to the Rest APIs are asynchronous. In addition, when retrieving all tasks for a project, a PieChart model is generated based on task status field (example method generateStatisticModel).

All this processing may take time and should not freeze the UI.

For this purpose, the Model Manager inherits from the EventProvider class and implements custom events:

• requestLoadProjectStart
• requestLoadProjectEnd
• requestLoadTasksStart
• requestLoadTasksEnd

Each View/Controller can register to one or more events and react accordingly: refresh, busy indicator…

Main Workflow

Find below the two main workflows described in detail.

Load Projects

This workflow details projects load process.

Load Projects Workflow

1. From the main application, a destination is selected. A REST call to /GET Projects is triggered,
2. Projects load process into the Projects Model is started. RequestLoadProjectsStart event is sent to ProjectList.controller to activate busy indicator.
3. Once all projects are fully loaded into the model, RequestLoadProjectsEnd event is sent and ProjectList.view is updated.

Load Tasks

This workflow details tasks loading process.

Load Tasks Workflow

1. From the application, a project is selected from the ProjectList.view. A REST call to /GET Tasks is triggered,
2. Tasks load process into Tasks Model is started. RequestLoadTasksStart event is sent to PieChart.controller and Kanban.controller to activate busy indicator.
3. Once all tasks are fully loaded into the model, two methods are triggered: generateStatisticsModel() to compute task status distribution, generateKanbanModel() to distribute tasks in the right lane.
4. Each computed figures are stored into its own model: TaskStatistics model and KabanModel model.
5. Once all models are ready, RequestLoadTasksEnd event is sent to PieChart.view and Kanban.view for update.

Hope this little example helped you in understanding all capabilities that SAP Cloud ALM APIs may offers through SAP Business Hub API.

Thanks for reading.