RAP / CDS / ODatabeginner

SAPUI5 and Fiori Tools Part 2: Set Up BAS or VS Code and Generate an App

Key takeaway

Set up SAP Fiori tools in Business Application Studio or VS Code, connect to an OData service and generate a clean SAP Fiori/SAPUI5 application project.

Explanation

📌 KEY POINTS
✅ Use SAP Business Application Studio or VS Code with the SAP Fiori tools extensions.
✅ Test the OData service ($metadata, sample data) BEFORE generating the app.
✅ The generator creates manifest, Component, views, ui5.yaml and npm scripts.
💡 Run locally with "npm start" against the real backend or a mock server.

▶ SAP FIORI TOOLS TUTORIAL: SET UP BAS OR VS CODE AND GENERATE AN APP

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU WILL BUILD

You will generate a working SAP Fiori application project using SAP Fiori tools.

You can use:

SAP Business Application Studio; or
Visual Studio Code with SAP Fiori tools installed.

Exact generator screens change over time, so focus on the decisions.

━━━━━━━━━━━━━━━━━━━━
▶ 1. PREPARE THE DEVELOPMENT ENVIRONMENT

Before generating the project, confirm:

supported Node/tooling version;
SAP Fiori tools extensions;
access to the backend;
destination or system connection;
OData service availability.

━━━━━━━━━━━━━━━━━━━━
▶ 2. PROVE THE ODATA SERVICE FIRST

Do not generate the UI against an untested service.

Check:

service URL;
metadata;
entity set;
authentication;
sample data.

━━━━━━━━━━━━━━━━━━━━
▶ 3. START THE APPLICATION GENERATOR

Choose the application type that matches the design.

For freestyle SAPUI5, choose the appropriate basic application/template.

For metadata-driven floorplans, Fiori Elements may be the better path.

━━━━━━━━━━━━━━━━━━━━
▶ 4. NAME THE PROJECT PROPERLY

Use stable names:

namespace;
module/application name;
title;
description.

Avoid test1/demo2 if the project may survive beyond a sandbox.

━━━━━━━━━━━━━━━━━━━━
▶ 5. UNDERSTAND GENERATED FILES

Typical important areas include:

webapp/manifest.json;
Component.js;
view/;
controller/;
model/;
i18n/;
test/;
project configuration.

Generated code is a starting point, not magic.

━━━━━━━━━━━━━━━━━━━━
▶ 6. RUN LOCALLY

Use the supported Fiori tools run configuration.

Test with real backend data where appropriate, or mock data for isolated UI development.

The first run should prove:

application boots;
model loads;
service is reachable;
no major console error occurs.

━━━━━━━━━━━━━━━━━━━━
▶ CHECKPOINT

You should be able to generate, run and explain the basic project structure.

━━━━━━━━━━━━━━━━━━━━
▶ COMMON MISTAKES

Generating before the backend contract is ready.
Confusing Fiori tools with Fiori Elements.
Ignoring namespace/app ID governance.
Editing generated configuration without understanding it.

━━━━━━━━━━━━━━━━━━━━
▶ INTERVIEW TAKEAWAY

“I use SAP Fiori tools in BAS or VS Code to scaffold the project, but I first validate the backend service. I keep naming and manifest configuration production-ready and then run the app locally before adding custom behavior.”

Code example

ABAP Code

# ===== Step 1: check the service first =====# GET /sap/opu/odata4/sap/zui_purchreq_o4/srvd/sap/zui_purchreq/0001/$metadata   -> 200 # ===== Step 2: generate (VS Code / BAS) =====# Command palette -> "Fiori: Open Application Generator"#   template: Basic (freestyle) or List Report (Fiori Elements)#   data source: connect to system / destination -> choose service#   module name: zpurchreq   namespace: com.company   (stable names!) # ===== Step 3: generated project (simplified) =====# zpurchreq/#   package.json          npm scripts (start, build, deploy)#   ui5.yaml              local dev server + backend proxy#   ui5-mock.yaml         mock server configuration#   webapp/#     Component.js  manifest.json  index.html#     view/  controller/  i18n/  localService/ (metadata for mocks) # ===== ui5.yaml: proxy to the backend (simplified) =====specVersion: "3.0"metadata:  name: zpurchreqtype: applicationserver:  customMiddleware:    - name: fiori-tools-proxy      afterMiddleware: compression      configuration:        backend:          - path: /sap            url: https://s4dev.example.com:44300            client: "100" # ===== Step 4: run =====# npm start            -> app with real backend (via proxy)# npm run start-mock   -> app with mock data (no backend needed)# npm run build        -> dist/ for deployment (Part 7)

Real project scenario

A project is generated successfully but shows authentication errors at runtime. The issue is the system connection, not the UI template. Proving the service and destination first avoids unnecessary frontend changes.

Common mistakes

Backend not tested first.
Wrong app template.
Weak naming.
Ignoring runtime console/network errors.

Best practices

Validate backend first.
Use clear namespace/app ID.
Understand generated artifacts.
Run a minimal baseline before customization.

Interview angle

Explain what SAP Fiori tools generate and the checks you perform before starting custom UI development.

Practice this lesson

Quick check

1. Which file routes local OData calls to the backend system in a Fiori tools project?

2. Which practice is risky when sharing a generated Fiori project in Git?

3. What should you verify before generating a Fiori app with the Fiori tools generator?

Interview questions

1. A generated app works on one developer's machine but not on another's: 401/404 on OData calls. What do you check?

Answer it in your own words first, then compare.

2. Describe how you set up and generate a SAPUI5 app with SAP Fiori tools.

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.