Exercise 1: Basic Setup - Generated Mock Data

Exercise 1 shows the basic mockserver setup with auto-generated data. The app in ex1/ was created using the SAP Fiori Application Generator and demonstrates zero-configuration mock data generation from metadata.

1.1 Understanding the Generated App Structure

New to Fiori Apps? If you need to generate your own app, see the Fiori Application Prerequisites section for step-by-step guidance using Fiori Tools or EasyUI5 Generator.

What's in ex1/:

  • Fiori Elements app generated from BookshopService
  • Automatic mock data generation - no custom data files needed
  • UI5 middleware configuration for mockserver integration

1.2 Key Configuration Files

📁 ex1/ui5-mock.yaml - The Core Mockserver Configuration:

ex1/ui5-mock.yaml View on GitHub ↗
- name: sap-fe-mockserver
  beforeMiddleware: csp
  configuration:
    mountPath: /
    services:
      - urlPath: /bookshop # Intercept calls to /bookshop
        metadataPath: ./webapp/localService/mainService/metadata.xml # Service definition
        mockdataPath: ./webapp/localService/mainService/data # Data folder (empty for now)
        generateMockData: true # Auto-generate mock data
    annotations: []

Key Points:

  • generateMockData: true - Mockserver creates data automatically based on metadata
  • urlPath: /bookshop - Intercepts all calls to the BookshopService
  • metadataPath - Points to the real service metadata, created on app generation
  • mockdataPath - Directory for custom data files (we'll use this in later exercises)

1.3 Important: Removing Backend Configuration for Offline Development

Critical Step for Generated Apps : When Fiori tools generates an app, it includes backend configuration in ui5-mock.yaml that still connects to the real service. For true offline development, you must remove this configuration.

Generated apps include this in ui5-mock.yaml (REMOVE THIS):

# ❌ Remove this section for offline mockserver development
backend:
  - path: /bookshop
    url: http://localhost:4004

Why remove it?

  • With backend configuration present, the app bypasses the mockserver and connects to the real service
  • This defeats the purpose of offline development and testing
  • Removes the backend dependency that the mockserver is designed to eliminate
In this tutorial : All ui5-mock.yaml files have been pre-configured for offline development with backend sections removed.

1.4 What You'll See When Running

1. Start the app:

npm run start:ex1

2. Explore the generated data:

  • List Report : Shows books with generated titles, authors, prices
  • Generated variety : Different data types (strings, numbers, dates, booleans)
  • Draft entries : Some rows have blue left border (draft mode simulation)

3. Test the actions:

  • CAP buttons work : promoteBook, setDiscount, generateReport, refreshCatalog
  • Parameter dialogs : Actions with parameters show input forms
  • No responses : Actions do not work (we will implement the actions in the next exercises)

1.5 Understanding Auto-Generated Data

The mockserver analyzes the metadata and creates mock data:

// How the mockserver interprets metadata:
String properties (title, author) → "Generated String 1", "Generated String 2"
Decimal properties (price) → Random numbers with correct precision
Integer properties (stock) → Random whole numbers
Date properties (createdAt) → Current date with variations
Boolean properties (IsActiveEntity) → true/false
UUID properties (ID) → Proper GUID format

1.6 Key Learning Points

✅ Advantages:

  • Zero Configuration : Works immediately without any custom setup
  • Metadata-Driven : Data structure matches your real service exactly
  • Action Support : All OData actions and functions are recognized (even if they fail)
  • Draft Simulation : Simulates draft editing

⚠️ Limitations:

  • Data is random and changes on restart
  • Actions don't have business logic
  • No cross-entity business rules
  • Can't simulate specific scenarios consistently

Next Steps

Exercise 2 will show how to replace generated data with your own controlled JSON files for predictable testing scenarios.