Project 1 — Travel Booking Inspector

When to start: after ABAP Foundations and Lesson 5 of ABAP SQL, CDS & RAP.

Approximate duration: one working day

Project overview

Build a Travel Booking Inspector that combines your ABAP foundation with the data-modeling concepts from Lessons 1–5.

The application receives a Travel ID and displays useful information about:

the travel
the customer
the bookings
the carrier for each booking
the flight connection for each booking

You will also calculate a small summary in ABAP.

Use only concepts learned through Lesson 5 of ABAP SQL, CDS & RAP.

---

1. Learning objectives

By the end of the project, you should have used:

Object-Oriented ABAP
ABAP SQL
CDS View Entities
calculated elements
CASE expressions
filters
joins
associations
path expressions

---

2. Business scenario

Given a Travel ID, your application should display:

Travel information
Customer information
Booking information
Carrier information
Connection information
A small trip summary

Example output shape:

Travel 00000123

Customer:
John Smith

Dates:
2026-05-10 -> 2026-05-20

Bookings: 3
Different carriers: 2

1. Lufthansa
   FRA -> JFK
   Departure: 10:30
   Arrival:   13:15

2. United Airlines
   JFK -> SFO
   Departure: 15:00
   Arrival:   18:10

3. Lufthansa
   SFO -> FRA
   Departure: 19:30
   Arrival:   14:20

The exact output format is up to you.

---

3. Required architecture

Your solution must follow this general architecture:

/DMO data
    ↓
CDS View Entities
    ↓
Reader class
    ↓
Runner class

The Runner should not contain direct SQL against /DMO/* database tables.

The Reader should consume your CDS entities.

The CDS layer should own reusable data modeling and relationships.

---

4. Objects to create

Use your own student/group suffix in place of ###.

Create at least:

2 CDS View Entities
1 Reader class
1 Runner class

Suggested naming:

ZI_PROJECT_TRAVEL_###
ZI_PROJECT_BOOKING_###
ZCL_PROJECT_READER_###
ZCL_PROJECT_RUNNER_###

You may choose different names if they are clear and consistent.

---

5. Suggested development sequence

A sensible order is:

1. Inspect the /DMO sources
2. Draw the relationships
3. Build Travel CDS
4. Preview Travel CDS
5. Build Booking CDS
6. Add associations
7. Verify Follow Association
8. Add calculated element
9. Preview and test CDS
10. Build Reader
11. Test Reader methods
12. Build Runner
13. Add summary logic
14. Test edge cases
15. Clean up names/output
16. Write architecture explanation

You do not have to follow this exact order, but avoid trying to build the entire application at once.

---

6. Data sources

Use SAP Flight Reference Scenario data.

Your project should use data from objects such as:

/DMO/TRAVEL
/DMO/BOOKING
/DMO/I_CUSTOMER
/DMO/I_CARRIER
/DMO/I_CONNECTION

You may inspect related /DMO/* objects where necessary.

Do not create or modify objects in the /DMO/ namespace.

---

7. Travel CDS requirements

Create a CDS View Entity representing one travel record.

It should expose enough information to support the application.

At minimum, include fields equivalent to:

TravelId
CustomerId
CustomerName
BeginDate
EndDate
BookingFee
TotalPrice
CurrencyCode
TravelStatus

Your exact field names may differ.

Required relationship

The travel model must use at least one CDS association.

A natural relationship is:

Travel -> Customer

Use an appropriate target CDS entity from the SAP Flight Reference Scenario.

The customer name should be obtained through the association or a path expression rather than by performing a separate lookup in the Runner.

---

8. Booking CDS requirements

Create a second CDS View Entity representing bookings belonging to a travel.

At minimum, expose fields equivalent to:

TravelId
BookingId
CarrierId
CarrierName
ConnectionId
FlightDate
DepartureAirportId
DestinationAirportId
DepartureTime
ArrivalTime
FlightPrice
CurrencyCode

Your exact field names may differ.

---

9. Required associations

Across the project, use at least three CDS associations.

The project should include relationships comparable to:

Travel -> Customer
Booking -> Carrier
Booking -> Connection

You may add more if they improve your model.

---

10. Composite-key requirement

At least one association must use a composite-key relationship.

Your Booking -> Connection relationship is a good candidate.

Before writing the association:

1. inspect the key of the target connection entity;
2. identify all source fields required to match that target;
3. use the complete relationship in the ON condition.

Do not assume that ConnectionId by itself uniquely identifies a connection.

---

11. Association exposure

Expose at least one association in a CDS element list.

Then use ADT Data Preview to verify it with:

Follow Association

Record which association you followed and what target data you inspected.

Example:

Association followed: _Carrier
Target checked: /DMO/I_CARRIER

---

12. Calculated CDS requirement

Create at least one calculated CDS element.

Choose something useful to the project.

Examples:

RouteCode
DeparturePeriod
CustomerDisplayName
TravelDurationCategory

Possible examples:

FRA -> JFK

or:

Morning
Afternoon
Evening

Use techniques from Lesson 3 such as:

CASE
CONCAT_WITH_SPACE
typed literals

Do not calculate the same value again in the Runner if it already belongs to the CDS model.

---

13. Reader class requirements

Create one Reader class for the project.

Suggested name:

ZCL_PROJECT_READER_###

The Reader should expose at least these two operations:

GET_TRAVEL
GET_BOOKINGS

GET_TRAVEL

Input:

Travel ID

Output:

one travel result
found/not-found information

You may use a Boolean result or another clear mechanism to indicate whether the travel exists.

GET_BOOKINGS

Input:

Travel ID

Output:

all bookings belonging to that travel

Sort the result in a meaningful order.

For example:

BookingId

or:

FlightDate + DepartureTime

---

14. Reader constraints

The Reader must:

• select from your CDS entities;
• use ABAP SQL;
• use host variables where appropriate;
• keep SQL out of the Runner;
• return clearly typed results;
• use deterministic ordering where output order matters.

The Reader must not:

• perform direct /DMO/* database-table lookups from the Runner;
• duplicate relationship logic that already belongs in CDS;
• use a separate Reader for every associated object merely to simulate joins manually.

---

15. Runner requirements

Create an executable console class.

Suggested name:

ZCL_PROJECT_RUNNER_###

Implement:

IF_OO_ADT_CLASSRUN

Use one Travel ID as the input for the project run.

Example:

DATA travel_id TYPE /dmo/travel-travel_id VALUE '00000123'.

Use a Travel ID that exists in your system for your successful test case.

---

16. Runner responsibilities

The Runner should:

1. instantiate the Reader;
2. request the Travel record;
3. handle the not-found case;
4. request all bookings for the Travel;
5. print the Travel/customer information;
6. print the Booking details;
7. calculate and display the required summary.

The Runner should not:

• contain direct SQL against /DMO/* tables;
• reproduce CDS association logic;
• repeat calculations that already belong to CDS.

---

17. Required ABAP summary logic

The Runner must calculate at least these two values in ABAP:

Number of bookings
Number of different carriers

Example:

Bookings: 4
Different carriers: 2

The purpose of this requirement is to keep some genuine application logic in ABAP rather than placing everything in CDS.

You may use:

internal tables
LOOP
READ TABLE
table expressions
sorted/hashed helper tables

Choose a solution that is clear and appropriate.

---

18. Required success case

Test with a Travel ID that exists and has at least one Booking.

Your output should include:

Travel ID
Customer name
Travel dates
Booking count
Different-carrier count
Booking details

For each booking, display at least:

Carrier name
Route
Flight date
Departure time
Arrival time

---

19. Required not-found case

Test with a Travel ID that does not exist.

Expected behavior should be similar to:

Travel 99999999 was not found.

Do not let the application continue as if a valid Travel had been loaded.

---

20. Required no-bookings case

If your demo data contains a Travel with no bookings, test it.

Expected behavior:

Travel found.
No bookings exist for this travel.

If your system does not contain such a Travel, explain how your application would behave in that case.

---

21. Required test cases

Document at least three test cases.

Test 1 — Existing Travel with bookings

Travel ID:
Expected result:
Actual result:

Test 2 — Unknown Travel

Travel ID:
Expected result:
Actual result:

Test 3 — Additional case

Choose one:

Travel with multiple carriers
Travel with one carrier
Travel with many bookings
Travel with no bookings

Record:

Travel ID:
Scenario:
Expected result:
Actual result:

---

22. Architecture and design questions

Include a short explanation of your final architecture.

Use a diagram similar to:

Runner
  ↓
Reader
  ↓
Travel CDS + Booking CDS
  ↓
Associations
  ↓
SAP /DMO data

Then explain your architecture and design decisions:

Why does the Runner not query the database directly?

Why are Customer, Carrier, and Connection relationships modeled in CDS?

Which logic belongs in CDS?

Which logic belongs in ABAP?

Why did you create two CDS entities instead of one very large entity?

Why is Booking -> Connection modeled with a composite ON condition?

Why is the calculated element defined in CDS?

Why are booking count and distinct-carrier count calculated in ABAP?

Why is the Reader still useful when CDS already models the data?

---

23. Technical constraints

Your submitted solution must:

• use modern define view entity syntax;
• use ABAP SQL, not obsolete Open SQL terminology/syntax;
• use meaningful CDS aliases;
• use explicit CDS element lists;
• use at least three associations;
• expose at least one association;
• use at least one path expression;
• use at least one composite-key association condition;
• use at least one calculated CDS element;
• use one Reader class;
• use one Runner class;
• keep direct SQL out of the Runner;
• keep the project read-only.

Do not implement:

INSERT
UPDATE
DELETE
RAP
OData
Service Definitions
Service Bindings
Fiori Elements
UI annotations

Those topics belong later in the course.

---

24. What is not part of the project

Do not add concepts that have not yet been taught merely to make the project appear more advanced.

This project does not require:

CDS aggregation
GROUP BY
HAVING
RAP behavior
transactional writes
OData
UI annotations
Fiori Elements
custom persistence tables

The challenge is to combine the concepts you already know correctly.

---

25. Stretch goals

These are optional.

Complete them only after the mandatory requirements work.

Stretch goal 1 — Departure period

Add:

Morning
Afternoon
Evening

based on departure time.

---

Stretch goal 2 — First and last flight

Calculate in ABAP:

earliest departure
latest arrival

for the selected Travel.

---

Stretch goal 3 — Carrier summary

Display each carrier used by the Travel exactly once.

Example:

Carriers used:
Lufthansa
United Airlines

---

Stretch goal 4 — Country enrichment

Extend the booking model so the route output contains country information for departure and destination airports.

Use CDS relationships rather than Runner-side lookups.

---

Stretch goal 5 — Compare JOIN and ASSOCIATION designs

Create a temporary alternative implementation for one relationship using an explicit join.

Write a short comparison:

JOIN version
ASSOCIATION version

Explain which design you prefer for the reusable relationship and why.

---

26. Deliverables

Submit:

Travel CDS View Entity
Booking CDS View Entity
Reader class
Runner class
Architecture diagram/explanation
Test-case results

Also include the names of all objects you created.

Example:

ZI_PROJECT_TRAVEL_017
ZI_PROJECT_BOOKING_017
ZCL_PROJECT_READER_017
ZCL_PROJECT_RUNNER_017

---

27. Submission checklist

CDS

• At least two CDS View Entities exist.
• define view entity is used.
• Travel data is modeled separately from Booking data.
• At least three associations exist across the project.
• Travel -> Customer is modeled.
• Booking -> Carrier is modeled.
• Booking -> Connection is modeled.
• At least one association uses a complete composite-key condition.
• At least one path expression is used.
• At least one association is exposed.
• Follow Association has been tested.
• At least one calculated CDS element exists.
• CDS Data Preview works for both main entities.

Reader

• Reader class exists.
• GET_TRAVEL exists.
• GET_BOOKINGS exists.
• Reader selects from CDS entities.
• Reader uses host variables where appropriate.
• Reader uses deterministic ordering where needed.

Runner

• Runner implements IF_OO_ADT_CLASSRUN.
• Runner contains no direct /DMO/* table SQL.
• Existing Travel case works.
• Unknown Travel case works.
• Booking count is calculated.
• Distinct-carrier count is calculated.
• Booking output is readable.

Documentation

• Architecture diagram is included.
• CDS vs ABAP responsibilities are explained.
• Composite-key association reasoning is explained.
• At least three test cases are documented.
• Object names are listed.

---

28. Evaluation criteria

The project should be evaluated primarily on correctness and design rather than code volume.

Suggested weighting:

Area	Weight
CDS modeling and relationships	30%
Association/cardinality/key correctness	20%
Reader/Runner architecture	20%
ABAP summary logic	10%
Error handling and testing	10%
Code clarity and explanation	10%

A smaller, clean solution is preferable to a larger solution with duplicated logic or incorrect relationships.

---

29. Useful ADT shortcuts

Action	Shortcut
Open ABAP Development Object	Ctrl + Shift + A
Code completion	Ctrl + Space
Syntax check	Ctrl + F2
Activate current object	Ctrl + F3
Activate inactive objects	Ctrl + Shift + F3
CDS Data Preview	F8
Run console class	F9
Format source	Shift + F1

---

30. Final goal

By the end of the project, you should be able to explain your application from top to bottom:

What data is stored?
What does CDS model?
Which relationships are associations?
What does the Reader retrieve?
What does the Runner calculate?
How are missing results handled?

The project is complete when the application works and you can explain why the solution is structured the way it is.