Home
3
Abap

Kindergarten Garden in Abap: Complete Solution & Deep Dive Guide

a computer with a keyboard and mouse

ABAP Kindergarten Garden: The Ultimate Guide to String Parsing and Data Mapping

Solving the ABAP Kindergarten Garden problem involves parsing a two-line string diagram that represents rows of plants. This comprehensive guide teaches you to map specific plants—Grass, Clover, Radishes, and Violets—to 12 children by calculating character offsets based on their alphabetical order, using core ABAP string manipulation and internal table operations.

Have you ever stared at a cryptic, fixed-width text file from a legacy system, wondering how to turn that wall of characters into meaningful data? It’s a common challenge for ABAP developers, where raw data from files, IDocs, or RFC calls needs to be meticulously parsed and transformed. It often feels like you're trying to decipher an ancient script with nothing but a rusty key.

This is where mastering fundamental data manipulation techniques becomes your superpower. The "Kindergarten Garden" problem from the exclusive kodikra.com learning curriculum, while seemingly simple, is a perfect microcosm of these real-world challenges. It forces you to think critically about string offsets, data mapping, and structured data access—skills that separate a novice from an expert ABAP programmer. By mastering this module, you're not just arranging virtual plants; you're building the foundational logic needed to tackle complex data integration tasks in any SAP environment.

What is the Kindergarten Garden Problem?

The core task is to interpret a simple diagram and determine which plants belong to a specific child. The problem establishes a clear set of rules and a fixed context, making it an excellent exercise for practicing algorithmic thinking within ABAP's structured programming paradigm.

The Scenario Rules

The setup involves a kindergarten class with a garden. Here are the constraints you must work with:

  • The Children: There is a fixed roster of 12 children, always in the same alphabetical order: Alice, Bob, Charlie, David, Eve, Fred, Ginny, Harriet, Ileana, Joseph, Kincaid, and Larry.
  • The Garden Diagram: The garden is represented by a two-line string. Each line represents a row of plants. Newlines (\n) separate the two rows.
  • Plant Distribution: Each child is responsible for a small plot of four plants, arranged in a 2x2 square. This means they get two plants from the top row and two from the bottom row.
  • The Plants: There are four types of plants, each represented by a single character code:
    • G for Grass
    • C for Clover
    • R for Radishes
    • V for Violets

For example, consider this diagram:


VRCGVVRVCGGVVRVCGG
VVRCGVVRVCGGVVRVCG

Alice, being the first child, is assigned the first two plants from each row. Her plot consists of V and R from the top row and V and V from the bottom row. Bob, the second child, gets the next two plants (C and G from the top, R and C from the bottom), and so on down the line.

Why Is This Problem a Crucial Exercise for ABAP Developers?

At first glance, this might seem like a trivial puzzle. However, its solution requires the precise application of several fundamental ABAP concepts that are used daily in professional development. This kodikra module is designed to sharpen your skills in areas that are critical for building robust SAP applications.

The primary value lies in practicing data transformation. In the world of SAP, data rarely arrives in the exact format you need. You're constantly receiving data from external systems via flat files, XML, or JSON, and it's your job to parse it, validate it, and map it to SAP structures like BAPIs or internal tables. This problem simulates that process on a smaller scale.

You'll gain hands-on experience with:

  • String Manipulation: Using functions like SUBSTRING and statements like SPLIT to dissect raw string data is a non-negotiable skill.
  • Internal Table Operations: The solution relies on managing lists of data, such as the children's names and the final list of plants. Mastering READ TABLE, APPEND, and understanding sy-tabix is essential.
  • Algorithmic Logic: You must devise a repeatable algorithm to calculate the correct position (offset) in the string for any given child. This builds the problem-solving part of your brain.
  • Code Encapsulation: By building the solution within an ABAP Class (ZCL_*), you practice modern, object-oriented principles, making your code reusable, testable, and maintainable.

Tackling this challenge prepares you for real-world tasks like parsing bank statement files (which are often fixed-width), processing legacy data during a system migration, or handling custom EDI/IDoc segments.

How to Solve the Kindergarten Garden Problem in ABAP

Our approach will be to create a global ABAP class (e.g., ZCL_KINDERGARTEN_GARDEN) with a public method, GET_PLANTS. This method will take the garden diagram and a child's name as input and return an internal table containing the names of that child's four plants.

The Complete ABAP Solution

Here is the full implementation of the class. We will break down each part of the logic in the following sections.


CLASS zcl_kindergarten_garden DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    TYPES:
      BEGIN OF ty_plant,
        name TYPE string,
      END OF ty_plant,
      ty_plant_table TYPE STANDARD TABLE OF ty_plant WITH EMPTY KEY.

    METHODS get_plants
      IMPORTING
        diagram TYPE string
        student TYPE string
      RETURNING
        VALUE(plants) TYPE ty_plant_table
      RAISING
        cx_sy_illegal_argument.

  PRIVATE SECTION.
    CONSTANTS:
      BEGIN OF child,
        alice   TYPE string VALUE 'alice',
        bob     TYPE string VALUE 'bob',
        charlie TYPE string VALUE 'charlie',
        david   TYPE string VALUE 'david',
        eve     TYPE string VALUE 'eve',
        fred    TYPE string VALUE 'fred',
        ginny   TYPE string VALUE 'ginny',
        harriet TYPE string VALUE 'harriet',
        ileana  TYPE string VALUE 'ileana',
        joseph  TYPE string VALUE 'joseph',
        kincaid TYPE string VALUE 'kincaid',
        larry   TYPE string VALUE 'larry',
      END OF child.

    TYPES:
      ty_children_table TYPE STANDARD TABLE OF string WITH EMPTY KEY.

    METHODS get_plant_name
      IMPORTING
        code          TYPE char1
      RETURNING
        VALUE(name)   TYPE string
      RAISING
        cx_sy_illegal_argument.

ENDCLASS.



CLASS zcl_kindergarten_garden IMPLEMENTATION.

  METHOD get_plants.
    " Define the list of children in alphabetical order
    DATA(lt_children) = VALUE ty_children_table(
      ( child-alice )
      ( child-bob )
      ( child-charlie )
      ( child-david )
      ( child-eve )
      ( child-fred )
      ( child-ginny )
      ( child-harriet )
      ( child-ileana )
      ( child-joseph )
      ( child-kincaid )
      ( child-larry )
    ).

    " Split the diagram into two rows based on the newline character
    DATA: lt_rows TYPE TABLE OF string.
    SPLIT diagram AT cl_abap_char_utilities=>cr_lf INTO TABLE lt_rows.

    " Ensure the diagram has exactly two rows
    IF lines( lt_rows ) <> 2.
      RAISE EXCEPTION TYPE cx_sy_illegal_argument
        EXPORTING
          text = 'Diagram must contain exactly two rows.'.
    ENDIF.

    DATA(lv_row1) = lt_rows[ 1 ].
    DATA(lv_row2) = lt_rows[ 2 ].

    " Find the student's position in the list (case-insensitive)
    DATA(lv_student_lower) = to_lower( student ).
    READ TABLE lt_children WITH KEY table_line = lv_student_lower TRANSPORTING NO FIELDS.

    " If student is not found, raise an exception
    IF sy-subrc <> 0.
      RAISE EXCEPTION TYPE cx_sy_illegal_argument
        EXPORTING
          text = |Student '{ student }' not found.|.
    ENDIF.

    " Calculate the starting position (offset) in the string for this student.
    " sy-tabix is 1-based, so we subtract 1 for a 0-based calculation.
    " Each student has 2 plants, so we multiply by 2.
    DATA(lv_offset) = ( sy-tabix - 1 ) * 2.

    " Extract the 2 plant codes for this student from each row
    DATA(lv_plant_codes) = lv_row1+lv_offset(2) && lv_row2+lv_offset(2).

    " Convert the 4 plant codes into full plant names and add to the result table
    DO 4 TIMES.
      DATA(lv_current_code) = lv_plant_codes+sy-index-1(1).
      APPEND VALUE #( name = get_plant_name( lv_current_code ) ) TO plants.
    ENDDO.

  ENDMETHOD.


  METHOD get_plant_name.
    CASE code.
      WHEN 'G'.
        name = 'Grass'.
      WHEN 'C'.
        name = 'Clover'.
      WHEN 'R'.
        name = 'Radishes'.
      WHEN 'V'.
        name = 'Violets'.
      WHEN OTHERS.
        RAISE EXCEPTION TYPE cx_sy_illegal_argument
          EXPORTING
            text = |Invalid plant code: '{ code }'|.
    ENDCASE.
  ENDMETHOD.

ENDCLASS.

Core Concepts Explained

To understand the solution, let's break down the key ABAP features we used.

1. String Manipulation: SPLIT and Substring Access

The input diagram is a single string containing a newline character. Our first task is to separate it into two distinct strings, one for each row. The SPLIT statement is perfect for this.


SPLIT diagram AT cl_abap_char_utilities=>cr_lf INTO TABLE lt_rows.

This line takes the diagram string and breaks it wherever it finds the carriage return/line feed character (cl_abap_char_utilities=>cr_lf), placing the resulting parts into the internal table lt_rows.

Next, we use substring access, also known as "slicing," to extract the specific characters for a child. The syntax lv_row1+lv_offset(2) is a powerful and concise way to do this. It means: "starting at character position lv_offset in the string lv_row1, take 2 characters."

2. Internal Tables and READ TABLE

Internal tables are ABAP's workhorse for handling collections of data. We use a table, lt_children, to store the ordered list of student names. The most critical operation here is finding a student's position.


READ TABLE lt_children WITH KEY table_line = lv_student_lower TRANSPORTING NO FIELDS.

This statement searches lt_children for an entry matching the lowercase student name. After this statement executes, the system variable sy-tabix will contain the row number (index) where the student was found. This index is the key to our entire algorithm.

3. The Offset Calculation Algorithm

This is the heart of the logic. Once we have the student's index from sy-tabix, we can calculate where their plants are located in the row strings.


DATA(lv_offset) = ( sy-tabix - 1 ) * 2.
  • sy-tabix - 1: sy-tabix is 1-based (Alice is at index 1, Bob at 2, etc.). String offsets are 0-based (the first character is at offset 0). We subtract 1 to convert the table index to a correct starting offset. For Alice (index 1), the offset is 0. For Bob (index 2), the offset is 2.
  • * 2: Each child is responsible for two plants per row. So, we multiply the zero-based index by 2 to find the starting character for their plot.

Code Walkthrough and Logic Flow

Let's trace the execution for a request like get_plants( diagram = '...', student = 'Charlie' ).

Here is a visual representation of the overall data flow:

    ● Start (Input: Garden Diagram String, Child's Name)
    │
    ▼
  ┌─────────────────────────┐
  │ Split Diagram into 2 Rows │
  └───────────┬─────────────┘
              │
              ▼
  ┌──────────────────────────┐
  │ Find Child's Index (0-11) │
  └───────────┬──────────────┘
              │
              ▼
  ┌───────────────────────────┐
  │ Calculate String Offset (Index * 2) │
  └───────────┬───────────────┘
              │
              ▼
  ┌───────────────────────────┐
  │ Extract 2 Plants from Row 1 │
  └───────────┬───────────────┘
              │
              ▼
  ┌───────────────────────────┐
  │ Extract 2 Plants from Row 2 │
  └───────────┬───────────────┘
              │
              ▼
  ┌───────────────────────────────────┐
  │ Convert Plant Codes to Full Names │
  └───────────┬───────────────────────┘
              │
              ▼
    ● End (Output: Table of 4 Plant Names)
  1. Initialization: The get_plants method is called. The lt_children table is populated with the 12 names.
  2. Splitting the Diagram: The input diagram string is split into lt_rows. lv_row1 and lv_row2 now hold the plant data for each row.
  3. Finding the Student: The input student name 'Charlie' is converted to 'charlie'. The READ TABLE statement searches lt_children. It finds 'charlie' at the 3rd position. The system variable sy-tabix is set to 3.
  4. Calculating the Offset: The formula ( sy-tabix - 1 ) * 2 is executed. This becomes ( 3 - 1 ) * 2 = 4. The offset for Charlie's plants is 4.

This offset calculation is the most critical step. Let's visualize it:

    ● Child: "Charlie"
    │
    ▼
  ┌────────────────────────┐
  │ Children List          │
  │ 1. Alice               │
  │ 2. Bob                 │
  │ 3. Charlie  <───── Found at Index 3
  └──────────┬─────────────┘
             │
             ▼
    ◆ Index = 3
    │
    ▼
  ┌────────────────────────┐
  │ Offset = (Index - 1) * 2 │
  │        = (3 - 1) * 2   │
  │        = 4             │
  └──────────┬─────────────┘
             │
             ▼
    ● Start Position for Substring is 4
  1. Extracting Plant Codes:
    • The code executes lv_row1+4(2), which gets the 5th and 6th characters from the first row.
    • It then executes lv_row2+4(2), getting the 5th and 6th characters from the second row.
    • These four characters are concatenated into the lv_plant_codes string.
  2. Mapping Codes to Names: The code loops 4 times. In each iteration, it takes one character from lv_plant_codes, passes it to the helper method get_plant_name, and gets back the full name (e.g., 'V' becomes 'Violets').
  3. Returning the Result: Each full plant name is appended to the `plants` returning table. After the loop, the method finishes and returns the populated table.

Alternative Approaches and Best Practices

While our solution is clean and efficient, it's always valuable to consider alternatives and refinements. This helps in developing a deeper understanding and preparing for different scenarios.

Using a Hashed Table for Plant Name Lookups

In our solution, we used a CASE statement inside the get_plant_name method. This is perfectly fine for only four options. However, if there were hundreds of plant types, a CASE statement would become unwieldy. A more scalable approach would be to use a hashed internal table for the lookup.

You could define a table type for mapping codes to names and populate it once, perhaps in the class constructor, for highly efficient lookups.


" In the class definition
TYPES:
  BEGIN OF ty_plant_map,
    code TYPE char1,
    name TYPE string,
  END OF ty_plant_map,
  ty_plant_map_table TYPE HASHED TABLE OF ty_plant_map WITH UNIQUE KEY code.

" In the get_plant_name method (or pre-filled in constructor)
DATA(lt_plant_map) = VALUE ty_plant_map_table(
  ( code = 'V' name = 'Violets' )
  ( code = 'R' name = 'Radishes' )
  ...
).

READ TABLE lt_plant_map WITH TABLE KEY code = iv_code INTO DATA(ls_plant).
IF sy-subrc = 0.
  rv_name = ls_plant-name.
ENDIF.

Pros and Cons of Data Structure Choices

Choosing the right data structures is key to writing good code. Here's a comparison related to our solution.

Technique / Data Structure Pros Cons
Standard Table for Children List Simple to declare and populate. The problem has a fixed, small number of children, so performance is not a concern. READ TABLE on a large standard table performs a linear scan, which can be slow. Not ideal for thousands of entries.
Sorted/Hashed Table for Children Extremely fast lookups (binary search or hash algorithm). Highly scalable. Slightly more complex to define. Requires defining a unique key. Overkill for a list of only 12 items.
CASE Statement for Plant Names Very readable and straightforward for a small, fixed set of options. No overhead of creating and populating a table. Does not scale well. Becomes difficult to manage if the number of options grows significantly.
Helper Method (get_plant_name) Promotes code reuse and separation of concerns (Single Responsibility Principle). Makes the main method cleaner. Adds a very minor performance overhead of a method call, which is negligible in this context.

Frequently Asked Questions (FAQ)

1. What is `sy-tabix` and why is it so important in this solution?

sy-tabix is a system field in ABAP that holds the index of the line that was just processed in an internal table loop or read operation. After a successful READ TABLE statement, it contains the row number of the found entry. We use it to determine the student's position in the alphabetical list, which is the cornerstone of our offset calculation.

2. Why do you subtract 1 from `sy-tabix` when calculating the offset?

ABAP internal table indices (and thus sy-tabix) are 1-based, meaning the first row is index 1. However, string offsets are 0-based, where the first character is at offset 0. To convert from the 1-based table index to the 0-based string offset, we must subtract 1.

3. What is the difference between `STRING` and `CHAR` data types in ABAP?

CHAR is a fixed-length data type. If you declare DATA lv_char TYPE c LENGTH 10, it will always occupy 10 characters in memory, padded with spaces if the assigned value is shorter. STRING is a dynamic-length data type that adjusts its memory usage to the actual length of the text it holds. For the garden diagram, which can vary, STRING is the more appropriate and modern choice.

4. Could this problem be solved without the `SPLIT` statement?

Yes, it could. You could first find the position of the newline character (\n) to determine the length of the first row. Then, you could calculate offsets into the single, large string. For the second row's plants, you would add the length of the first row (plus the newline character) to the child's base offset. However, using SPLIT makes the logic much cleaner and easier to read.

5. Why is the student's name converted to lowercase before searching?

This makes the search case-insensitive. By converting both the input name (e.g., 'Alice', 'alice', 'ALICE') and the stored names in our list to a consistent case (lowercase), we ensure that the match is successful regardless of the input's capitalization. This is a standard practice for robust data comparison.

6. Is there a built-in function to find an item's index in an ABAP table like `indexOf()` in other languages?

No, ABAP does not have a direct indexOf() function for internal tables. The standard ABAP pattern is to use READ TABLE ... and then check the value of sy-subrc (to see if it was found) and sy-tabix (to get its index), just as we did in our solution.

7. Where can I find more challenges to practice my ABAP skills?

This problem is part of a structured learning curriculum designed to build your skills progressively. To continue your journey and tackle more complex challenges, you can explore the complete ABAP guide on kodikra.com and see all the modules available in the ABAP Learning Roadmap.

Conclusion: From Garden Plots to Production Code

The Kindergarten Garden problem, sourced from the exclusive kodikra.com curriculum, serves as a powerful lesson in fundamental ABAP programming. We've journeyed through string parsing with SPLIT and substring access, leveraged internal tables with READ TABLE, and implemented a precise algorithm to map a logical entity (a child) to a physical data location (a position in a string).

The techniques you've practiced here—calculating offsets, transforming data, and encapsulating logic within a class—are not just academic exercises. They are the building blocks you will use to build, maintain, and debug complex interfaces and reports in any SAP system. By mastering these basics, you equip yourself to handle the diverse data challenges that define the career of an ABAP developer.

Disclaimer: The code and concepts discussed are based on modern ABAP syntax available in SAP S/4HANA and recent versions of SAP NetWeaver. Ensure your system supports features like inline declarations (DATA(...)) for the provided solution to work as-is.

Published by Kodikra — Your trusted Abap learning resource.

Post a Comment