Lesson 22 — Independent Practice: Repair a Service Ticket SLA Calculator

Independent practice: 3 hours
Environment: SAP BTP ABAP Trial + Eclipse ADT
Prerequisite: Lesson 22 — ABAP Unit, Debugging, ATC & Performance

This is an independent development task. You have all the required business rules and starter code, but the corrections and most tests are for you to implement. It uses new objects; you do not have to change any previous course application.

1. Your development ticket

A support team uses a small calculator to determine how many hours it has to respond to a customer ticket.

Users have reported three problems:

“High-priority tickets receive too much time, VIP tickets appear to receive extra time instead of less time, and unknown priority codes are accepted.”

Your task is to reproduce each problem, write automated tests, debug the faulty logic, correct it, and document the outcome.

Confirmed business rules

Priority	Meaning	Normal response time
H	High	2 hours
N	Normal	8 hours
Any other code	Unsupported priority	0 hours, indicating an invalid input

For a VIP customer, reduce the response time by one hour, but never go below one hour for a valid priority. Invalid priorities must always return zero, including for VIP customers.

Only uppercase H and N are valid priorities. A blank or lowercase code is unsupported and must return zero.

Examples:

Input	Expected hours
High, not VIP	2
Normal, not VIP	8
High, VIP	1
Normal, VIP	7
Invalid X, not VIP	0
Invalid X, VIP	0

The method returns a number of response hours, not an actual date or timestamp. Time zones, calendars, holidays, and service-level agreements with working-hours schedules are outside the scope of this exercise.

2. Create your own class

Step 2.1 — Choose the package

1. Open your SAP BTP ABAP project in Eclipse ADT.
2. Find your existing writable package or create ZPKG_L22_001.
3. Use your own numeric suffix consistently instead of 001.

Step 2.2 — Create the ABAP class

1. Right-click the package.
2. Select New → ABAP Class or New → Other ABAP Repository Object… → ABAP Class.
3. Name the class ZCL_L22_TICKET_SLA_001.
4. Description: Service ticket response time - repair exercise.
5. Finish the wizard and replace the generated global source with the code below.

3. Starter code — intentionally incorrect

Do not repair it yet. Activate, execute, and identify what the program currently returns.

CLASS zcl_l22_ticket_sla_001 DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

    TYPES ty_priority TYPE c LENGTH 1.

    CLASS-METHODS response_hours
      IMPORTING
        iv_priority TYPE ty_priority
        iv_is_vip   TYPE abap_bool
      RETURNING VALUE(rv_hours) TYPE i.
ENDCLASS.

CLASS zcl_l22_ticket_sla_001 IMPLEMENTATION.

  METHOD response_hours.

    IF iv_priority = 'H'.
      rv_hours = 4.
    ELSE.
      rv_hours = 8.
    ENDIF.

    IF iv_is_vip = abap_true.
      rv_hours = rv_hours + 1.
    ENDIF.

  ENDMETHOD.

  METHOD if_oo_adt_classrun~main.

    DATA(hours) = response_hours(
      iv_priority = 'H'
      iv_is_vip   = abap_false ).

    out->write( |High-priority result: { hours } hour(s)| ).
    out->write( 'Expected: 2 hour(s)' ).

  ENDMETHOD.

ENDCLASS.

Activate with Ctrl+F3. Execute with F9 or Run As → ABAP Application (Console).

Write down the incorrect value displayed by the console. A valid source file can contain business-rule defects.

4. Write your ABAP Unit test class

Open the class in Eclipse ADT and select the Test Classes tab at the bottom of the editor.

Paste the following starting point. It includes one complete test; implement the other five tests yourself using the business-rules table in Section 1.

CLASS ltc_ticket_sla DEFINITION FINAL FOR TESTING
  DURATION SHORT
  RISK LEVEL HARMLESS.

  PRIVATE SECTION.
    METHODS high_standard FOR TESTING.
    METHODS normal_standard FOR TESTING.
    METHODS high_vip FOR TESTING.
    METHODS normal_vip FOR TESTING.
    METHODS invalid_standard FOR TESTING.
    METHODS invalid_vip FOR TESTING.
ENDCLASS.

CLASS ltc_ticket_sla IMPLEMENTATION.

  METHOD high_standard.
    DATA(actual) = zcl_l22_ticket_sla_001=>response_hours(
      iv_priority = 'H'
      iv_is_vip   = abap_false ).

    cl_abap_unit_assert=>assert_equals(
      exp = 2
      act = actual
      msg = 'High-priority response time must be 2 hours' ).
  ENDMETHOD.

  METHOD normal_standard.
    " TODO: Call response_hours with N and abap_false.
    " TODO: Assert that the result is 8.
  ENDMETHOD.

  METHOD high_vip.
    " TODO: Call response_hours with H and abap_true.
    " TODO: Assert that the result is 1.
  ENDMETHOD.

  METHOD normal_vip.
    " TODO: Call response_hours with N and abap_true.
    " TODO: Assert that the result is 7.
  ENDMETHOD.

  METHOD invalid_standard.
    " TODO: Call response_hours with X and abap_false.
    " TODO: Assert that the result is 0.
  ENDMETHOD.

  METHOD invalid_vip.
    " TODO: Call response_hours with X and abap_true.
    " TODO: Assert that the result is 0.
  ENDMETHOD.

ENDCLASS.

Important: The empty TODO methods currently count as tests but do not test anything. They must contain a real assertion before your work is complete.

Run the first test

1. Save and activate the global class and test-class include.
2. Right-click the class and choose Run As → ABAP Unit Test.
3. Alternatively, use Ctrl+Shift+F10.
4. Open the ABAP Unit results view.
5. Confirm high_standard fails before changing the business logic.

Complete all six tests

Write calls to ZCL_L22_TICKET_SLA_001=>RESPONSE_HOURS and assertions for every scenario in Section 1. Do not change an expected result merely to match the faulty starter class.

5. Debug the defects

1. Open the Global Class tab.
2. Set a breakpoint on IF iv_priority = 'H'. by double-clicking the gutter beside the line number.
3. Set another breakpoint on rv_hours = rv_hours + 1..
4. Run the console class or a failing unit test.
5. In the debugger, inspect iv_priority, iv_is_vip, and rv_hours.
6. For VIP cases, run the high_vip and normal_vip test methods so that the second breakpoint is reached.

Record answers to these questions:

• Why does a high-priority ticket receive the wrong hours?
• Which statement changes the VIP response time in the wrong direction?
• What happens when an unsupported priority is supplied?
• What should happen to an invalid priority before any VIP adjustment?

6. Repair the implementation

Change only the response_hours method to implement all documented rules. You may use IF, CASE, and a conditional return as appropriate.

Check for valid priorities before applying VIP adjustments. Do not add database calls, HTTP requests or new configuration objects—the calculation should remain a pure method that is easy to test.

Mandatory acceptance tests

After your correction:

• All six ABAP Unit tests contain assertions.
• All six tests pass.
• High priority without VIP returns 2.
• Normal priority without VIP returns 8.
• High VIP returns 1.
• Normal VIP returns 7.
• Invalid priority returns 0 in both VIP and non-VIP cases.
• The console example prints 2 for high priority.

Keep the final test class; do not remove it after the repair.

7. Run ATC and record the findings

1. Select ZCL_L22_TICKET_SLA_001 in Project Explorer.
2. Right-click and choose Run As → ABAP Test Cockpit.
3. Alternatively, press Ctrl+Shift+F2.
4. Review the ATC Problems view.
5. Correct actionable findings in your class, if any, and rerun the check.

If ATC reports no findings, record "ATC completed with no findings". If your tenant does not allow this check, record the specific restriction instead of claiming a successful run.

8. Apply the SQL performance principle

Use the ZL22_ORDERS_001 table from the guided lesson. If that table was not created, return to the guided SQL exercise first.

The support manager asks:

“Show only the order IDs and amounts for high-priority orders with amounts greater than 110.”

In the SQL lab class, create another ABAP SQL SELECT that:

1. Reads from ZL22_ORDERS_001.
2. Selects only order_id and amount.
3. Filters for priority = 'H'.
4. Filters for amount > 110.
5. Displays the number of records and their selected fields.

With the five seed records from the guided lesson, the expected order IDs are 000003 and 000005, giving two records.

Do not read every row and column and then filter in an ABAP loop. The point is to push the restrictions into the SQL request.

If you prefer to keep the original SQL lab unchanged, add a new method or new console class for this query.

9. Investigate one additional edge case

Choose one of these inputs and write one additional automated test:

• A blank priority, supplied as space.
• Lowercase h, which must not be treated as uppercase H.
• Lowercase n, which must not be treated as uppercase N.

In your test method, call response_hours twice with your chosen priority: once with iv_is_vip = abap_false and once with iv_is_vip = abap_true. Assert 0 for both results. This checks that unsupported input stays invalid even when the customer is a VIP.

Explain why your chosen test adds value beyond the six required scenarios.

10. Deliverables and developer handover

Submit or demonstrate these items:

Deliverable	Evidence
Corrected global class	ZCL_L22_TICKET_SLA_001 activated; console prints 2
ABAP Unit tests	Six nonempty test methods, all passing
Debugging diagnosis	Notes describing the original logic problems and the values inspected
ATC result	Actual findings or recorded access restriction
SQL filter	Two results (000003, 000005) on the unmodified demo dataset
Extra test	One additional test with assertions for both VIP and non-VIP inputs, plus its explanation
Developer handover	Concise account of the bug, correction and verification

Use this short structure for your handover:

Maintenance ticket: Service Ticket Response Time

1. Original problem:
2. How I reproduced it:
3. Tests added and expected outcomes:
4. Root cause found in the debugger:
5. Code changed:
6. ABAP Unit results after the fix:
7. ATC result or environment restriction:
8. SQL improvement:
9. Remaining limitation or follow-up:

11. Self-review

Before handing in your work, ask yourself:

1. Did you write tests before fixing the code?
2. Do the tests verify business requirements rather than the current implementation?
3. Could a different developer understand the bug from your handover?
4. Have you demonstrated both a passing and a deliberately failing unit test?
5. Can you explain why the SQL result is smaller without claiming to have benchmarked performance?

Success means you can diagnose and repair unfamiliar ABAP code independently, using repeatable evidence—not just that a class activates.