Home
1
Abap

Resistor Color Duo in Abap: Complete Solution & Deep Dive Guide

Tabs labeled

Resistor Color Duo in ABAP: The Complete Guide to Decoding Resistor Values

Decoding resistor color codes is a classic programming challenge that tests fundamental data mapping and manipulation skills. In the enterprise world of SAP, this task translates directly to handling coded values, transforming data, and building robust logic. This guide provides a comprehensive solution in ABAP, explaining how to map color names to their numeric values to calculate a resistor's two-digit code, a core skill for any ABAP developer.

The Resistor Color Code Challenge: A Developer's Rite of Passage

Ever felt like you're translating a foreign language when dealing with system codes or sensor data? You're not alone. In many real-world applications, especially with IoT integrations in an SAP environment, raw data comes in a non-numeric format that needs to be converted into something your program can understand. This is the essence of the Resistor Color Duo problem.

The challenge is straightforward yet profound: electronic resistors use colored bands to represent their resistance value. Your task is to write an ABAP program that takes the first two color bands as input and outputs their combined two-digit numeric value. For example, if the first band is "Brown" (value 1) and the second is "Black" (value 0), your program should return the integer 10.

This may seem like a simple exercise, but mastering it builds the foundation for complex data transformation logic required in countless SAP modules, from Materials Management (MM) to Plant Maintenance (PM). This guide will walk you through every step, transforming you from a novice to a pro in handling this common programming pattern.

What is the Resistor Color Duo Problem?

The core of the problem lies in a fixed mapping between colors and numbers. This is a standard established by the electronics industry to ensure uniformity. For this specific challenge, we only need to focus on the first two bands, which determine the most significant digits of the resistance value.

The Color-to-Value Mapping

The standard mapping for the first ten colors is as follows:

  • Black: 0
  • Brown: 1
  • Red: 2
  • Orange: 3
  • Yellow: 4
  • Green: 5
  • Blue: 6
  • Violet: 7
  • Grey: 8
  • White: 9

The Objective

Your program must accept an input, typically a list or table of strings containing color names. It should then look at the first two colors in that list, find their corresponding numeric values, and concatenate them to form a single two-digit integer.

For instance:

  • Input: [ "Green", "Blue", "Yellow" ] → Process "Green" (5) and "Blue" (6) → Output: 56
  • Input: [ "Red", "Violet" ] → Process "Red" (2) and "Violet" (7) → Output: 27

This task requires clean data lookup, string or integer manipulation, and robust error handling for invalid inputs, all of which are daily tasks for an ABAP developer.

Why This Logic is Crucial for ABAP Developers

While you might not be building circuits with your SAP system, the pattern of mapping symbolic names to values is everywhere in the ABAP world. This exercise from the kodikra ABAP learning path is designed to sharpen skills that are directly transferable to enterprise-level development.

Real-World SAP Scenarios

  • Status Codes: Mapping technical status codes (e.g., 'A', 'B', 'C') to user-friendly descriptions ("Approved", "Pending", "Rejected") in reports.
  • Data Migration: Translating values from a legacy system's coding scheme to SAP's standard codes during a data migration project (e.g., using LSMW or custom BAPIs).
  • IoT and Manufacturing Integration: An SAP S/4HANA system connected to factory floor machinery might receive status signals as colors (e.g., a machine's status light is "Red"). An ABAP program would need to translate "Red" into a specific system code to trigger a maintenance order.
  • Customizing Tables: Reading from customizing tables (T-tables) where keys (like a country code 'US') are mapped to values ('United States'). The logic is identical: look up a key, get a value.

Mastering this simple problem ensures you have the foundational logic to build complex, reliable, and maintainable enterprise applications.

How to Implement the Resistor Color Duo Solution in ABAP

The most professional and reusable way to implement this logic in ABAP is by using ABAP Objects. We will create a global class, ZCL_RESISTOR_COLOR_DUO, with a public method to perform the decoding. This approach promotes encapsulation and makes the logic easily testable and consumable by other programs.

We'll start by defining the class structure and then implement the method logic.

Step 1: The Class Definition (`ZCL_RESISTOR_COLOR_DUO.abap`)

First, we define the class interface. This includes the public method DECODE_VALUE which will take a standard table of strings as input and return an integer. Using a standard table type like STRING_TABLE makes our method versatile.


CLASS zcl_resistor_color_duo DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    "! <p>Decodes the first two resistor color bands into a two-digit number.</p>
    "! @parameter colors | A table of strings representing the color bands.
    "! @parameter result | The calculated two-digit integer value.
    METHODS decode_value
      IMPORTING
        colors       TYPE string_table
      RETURNING
        VALUE(result) TYPE int4
      RAISING
        cx_sy_itab_line_not_found.

  PROTECTED SECTION.
  PRIVATE SECTION.
    "! <p>Helper method to map a single color string to its numeric value.</p>
    "! @parameter color_name | The color name (e.g., 'black').
    "! @parameter value      | The corresponding integer value (0-9).
    METHODS get_color_value
      IMPORTING
        color_name   TYPE string
      RETURNING
        VALUE(value) TYPE int4.

ENDCLASS.

Step 2: The Class Implementation (`ZCL_RESISTOR_COLOR_DUO.abap`)

Now, we implement the logic for the defined methods. The private helper method GET_COLOR_VALUE will contain the core mapping logic using a CASE statement. The public method DECODE_VALUE will call this helper for the first two colors and combine the results.


CLASS zcl_resistor_color_duo IMPLEMENTATION.

  METHOD decode_value.
    " Ensure there are at least two colors in the input table.
    IF lines( colors ) < 2.
      RAISE EXCEPTION TYPE cx_sy_itab_line_not_found.
    ENDIF.

    " Read the first and second color bands from the input table.
    " READ TABLE is safe here because we've checked the line count.
    DATA(first_color) = colors[ 1 ].
    DATA(second_color) = colors[ 2 ].

    " Convert the color names to their numeric values using the helper method.
    DATA(first_digit) = get_color_value( first_color ).
    DATA(second_digit) = get_color_value( second_color ).

    " Combine the two digits to form the final number.
    " For example, if first_digit = 1 and second_digit = 0, result becomes 10.
    result = first_digit * 10 + second_digit.
  ENDMETHOD.


  METHOD get_color_value.
    " Convert input color to lowercase to make the matching case-insensitive.
    DATA(lv_color_lower) = to_lower( color_name ).

    " Map the color string to its integer value.
    CASE lv_color_lower.
      WHEN 'black'.
        value = 0.
      WHEN 'brown'.
        value = 1.
      WHEN 'red'.
        value = 2.
      WHEN 'orange'.
        value = 3.
      WHEN 'yellow'.
        value = 4.
      WHEN 'green'.
        value = 5.
      WHEN 'blue'.
        value = 6.
      WHEN 'violet'.
        value = 7.
      WHEN 'grey'.
        value = 8.
      WHEN 'white'.
        value = 9.
      WHEN OTHERS.
        " If an unknown color is provided, raise an exception.
        " This is crucial for robust error handling.
        RAISE EXCEPTION TYPE cx_sy_conversion_error.
    ENDCASE.
  ENDMETHOD.

ENDCLASS.

Step 3: Detailed Code Walkthrough

Let's break down the implementation to understand each part thoroughly.

  1. Class Definition: We define a PUBLIC, FINAL class. FINAL means this class cannot be inherited, which is a good practice for utility classes. The DECODE_VALUE method is public, making it the entry point for any consumer program. It raises CX_SY_ITAB_LINE_NOT_FOUND to signal to the caller that the input table was too small.
  2. Helper Method GET_COLOR_VALUE: This private method encapsulates the mapping logic. It's private because no program outside this class needs to know *how* we get the value, only that we can. This is a core principle of object-oriented programming.
  3. Case-Insensitive Matching: Inside GET_COLOR_VALUE, we use the built-in function to_lower(). This makes our logic more robust, as it will correctly handle "Brown", "brown", or "BROWN".
  4. The CASE Statement: This is the simplest and most readable way to implement the color-to-value mapping for a small, fixed set of values. It's highly efficient for this scenario.
  5. Error Handling: The WHEN OTHERS block in the CASE statement is critical. If an invalid color is passed, we raise a standard exception, CX_SY_CONVERSION_ERROR, to clearly signal that the input data was bad. Similarly, DECODE_VALUE checks if at least two colors are provided.
  6. Accessing Table Rows: In DECODE_VALUE, we use the modern table expression syntax colors[ 1 ] and colors[ 2 ]. This is a concise way to read table lines, available in ABAP 7.40 and higher. It's cleaner than the older READ TABLE ... INDEX ... syntax.
  7. Calculating the Final Value: The line result = first_digit * 10 + second_digit is a simple and efficient mathematical way to combine two digits. If first_digit is 5 and second_digit is 6, this becomes 5 * 10 + 6 = 56. This is often more performant than converting the digits to strings, concatenating them, and converting back to an integer.

Solution Logic Flowchart

Here is a visual representation of the logic inside our DECODE_VALUE method.

    ● Start (Input: colors table)
    │
    ▼
  ┌───────────────────────────┐
  │ Check: lines(colors) < 2? │
  └────────────┬──────────────┘
               │
    Yes ╱      ╲ No
       │        │
       ▼        ▼
┌──────────────┐  ┌───────────────────────────────────┐
│ Raise        │  │ Read first_color = colors[ 1 ]    │
│ Exception    │  │ Read second_color = colors[ 2 ]   │
└──────────────┘  └─────────────────┬─────────────────┘
       │                          │
    ● End                         ▼
                          ┌───────────────────────────┐
                          │ Call get_color_value()    │
                          │ for first_color  → digit1 │
                          └────────────┬──────────────┘
                                       │
                                       ▼
                          ┌───────────────────────────┐
                          │ Call get_color_value()    │
                          │ for second_color → digit2 │
                          └────────────┬──────────────┘
                                       │
                                       ▼
                          ┌───────────────────────────┐
                          │ Calculate:                │
                          │ result = digit1 * 10 + digit2 │
                          └────────────┬──────────────┘
                                       │
                                       ▼
                                  ● End (Return result)

Where This Logic Fits in a Real SAP System

A global class like this is a reusable asset. You can call it from anywhere in your SAP system. Here's a simple example of a local executable program (a report) that uses our class. You can create this in transaction SE38 or using ABAP Development Tools (ADT) in Eclipse.

Example Caller Program (`Z_TEST_RESISTOR_DECODER`)


REPORT z_test_resistor_decoder.

DATA: go_decoder TYPE REF TO zcl_resistor_color_duo,
      gt_colors  TYPE string_table,
      gv_value   TYPE int4.

START-OF-SELECTION.
  " Instantiate our decoder class
  CREATE OBJECT go_decoder.

  " Prepare the input data
  gt_colors = VALUE #( ( 'blue' ) ( 'green' ) ).

  TRY.
      " Call the method to get the value
      gv_value = go_decoder->decode_value( gt_colors ).

      " Display the result
      WRITE: / |Input Colors: { gt_colors[ 1 ] }, { gt_colors[ 2 ] }|.
      WRITE: / |Decoded Value: { gv_value }|.

    CATCH cx_sy_itab_line_not_found.
      WRITE: / |Error: Not enough colors provided.|.
    CATCH cx_sy_conversion_error.
      WRITE: / |Error: Invalid color name found in input.|.
  ENDTRY.

" --- Another test case ---
  APPEND 'red' TO gt_colors. " gt_colors now contains 'blue', 'green', 'red'
  
  TRY.
      gv_value = go_decoder->decode_value( gt_colors ).
      WRITE: / |---------------------------------|.
      WRITE: / |Input Colors: { gt_colors[ 1 ] }, { gt_colors[ 2 ] }|.
      WRITE: / |Decoded Value: { gv_value }|.
    CATCH cx_root INTO DATA(lx_error).
      WRITE: / |An unexpected error occurred: { lx_error->get_text( ) }|.
  ENDTRY.

Executing the Code

You can test this in your SAP environment by following these steps:

  1. Using transaction SE24 or ADT, create the class ZCL_RESISTOR_COLOR_DUO and paste the definition and implementation code. Activate the class.
  2. Using transaction SE38 or ADT, create the executable program Z_TEST_RESISTOR_DECODER, paste the code above, and activate it.
  3. Execute the program (press F8).

The expected output will be:

Input Colors: blue, green
Decoded Value:           65
---------------------------------
Input Colors: blue, green
Decoded Value:           65

Alternative Approaches and Performance Considerations

While the CASE statement is perfect for this scenario, it's important for a senior developer to know alternative patterns and their trade-offs. For a larger set of key-value pairs, a different approach might be more efficient or maintainable.

Alternative: Using a Hashed Internal Table for Lookup

If we had hundreds of colors to map, a CASE statement would become unwieldy. A more scalable solution is to store the mapping in an internal table with a `HASHED` key. This provides near-constant time O(1) lookup, which is more performant than a `CASE` statement that performs sequential comparisons.

Here's how the `get_color_value` method could be refactored:


" --- Redefined private section of the class ---
PRIVATE SECTION.
  TYPES:
    BEGIN OF ty_color_map,
      name  TYPE string,
      value TYPE int4,
    END OF ty_color_map.

  TYPES:
    tt_color_map TYPE HASHED TABLE OF ty_color_map
                 WITH UNIQUE KEY name.

  DATA:
    color_map TYPE tt_color_map.

  METHODS:
    get_color_value
      IMPORTING
        color_name   TYPE string
      RETURNING
        VALUE(value) TYPE int4,
    
    constructor. " Special method to initialize data

" --- Redefined implementation ---
METHOD constructor.
  " This method is called automatically when the object is created.
  " We fill our mapping table here once.
  color_map = VALUE #(
    ( name = 'black'  value = 0 )
    ( name = 'brown'  value = 1 )
    ( name = 'red'    value = 2 )
    ( name = 'orange' value = 3 )
    ( name = 'yellow' value = 4 )
    ( name = 'green'  value = 5 )
    ( name = 'blue'   value = 6 )
    ( name = 'violet' value = 7 )
    ( name = 'grey'   value = 8 )
    ( name = 'white'  value = 9 )
  ).
ENDMETHOD.

METHOD get_color_value.
  DATA(lv_color_lower) = to_lower( color_name ).

  TRY.
      " Use a table expression for a direct, high-performance lookup.
      value = color_map[ name = lv_color_lower ]-value.
    CATCH cx_sy_itab_line_not_found.
      " If the color is not in our map, raise an error.
      RAISE EXCEPTION TYPE cx_sy_conversion_error.
  ENDTRY.
ENDMETHOD.

Comparison of Approaches

Here's a breakdown of the pros and cons of each method.

Aspect CASE Statement Hashed Internal Table
Readability Excellent for a small, fixed set of values. Very clear and straightforward. Good. The logic is separated into data (the table) and action (the lookup).
Performance Extremely fast for 10 items. The ABAP kernel highly optimizes it. Performance degrades linearly (O(n)) as items increase. Theoretically faster (O(1) average time) for large datasets. For 10 items, the difference is negligible.
Maintainability Easy to add a new color, but can become very long if many items are added. Excellent. New mappings can be added to the constructor without touching the lookup logic. This is a more scalable design.
Flexibility Static and hard-coded. Cannot be changed at runtime. Very flexible. The mapping table could be filled from a database table (e.g., a customizing table) instead of being hard-coded.

Comparing Lookup Mechanisms

This diagram illustrates the conceptual difference between the two lookup strategies.

  ┌───────────────────────┐      ┌───────────────────────────┐
  │ CASE Statement Logic  │      │ Hashed Table Logic        │
  └───────────────────────┘      └───────────────────────────┘
              │                              │
              ▼                              ▼
  ● Input: "green"                     ● Input: "green"
              │                              │
              ▼                              ▼
    ◆ Is it "black"? No              ┌──────────────────┐
    │                                │ Calculate Hash   │
    ▼                                │ of "green" → 0x4A│
    ◆ Is it "brown"? No              └────────┬─────────┘
    │                                         │
    ▼                                         ▼
    ◆ ... (sequential checks)          ┌──────────────────┐
    │                                  │ Direct Jump to   │
    ▼                                  │ Address 0x4A     │
    ◆ Is it "green"? Yes               └────────┬─────────┘
    │                                         │
    ▼                                         ▼
  ● Return Value: 5                    ● Return Value: 5

For the Resistor Color Duo problem, both approaches are excellent. However, knowing the hashed table pattern is essential for more complex, data-driven applications you will inevitably build. You can find more advanced data structure examples in our complete ABAP guide.

Frequently Asked Questions (FAQ)

What is the purpose of the `zcl_` prefix in ABAP?
In ABAP, objects created by customers or developers must start with 'Z' or 'Y'. The `cl` is a common naming convention to denote a Class. So, `ZCL_` is the standard prefix for a global customer class, making it easy to identify in the system.
Why use a Class instead of a simple Function Module?
While a Function Module could achieve the same result, using a Class (ABAP Objects) offers better encapsulation, reusability, and testability. It allows you to group related data (like the color map) and methods together, and enables unit testing with tools like ABAP Unit. It is the modern and preferred approach for new development.
How can I handle invalid color inputs more gracefully?
Our solution raises an exception, which is a robust way to handle errors. The calling program is forced to handle this exception using a `TRY...CATCH` block. An alternative for less critical scenarios could be to return a default value, like -1, to indicate an error, though exceptions are generally cleaner as they clearly separate the success path from the error path.
Is this solution compatible with older SAP versions?
The code uses modern ABAP syntax (like inline declarations with `DATA(...)` and table expressions with `[...]`) which became standard with ABAP 7.40. For older systems (e.g., SAP ECC 6.0 on a lower NetWeaver version), you would need to replace these with older syntax, such as explicit `DATA` declarations and the `READ TABLE ... INDEX ...` statement.
What's the difference between `CONCATENATE` and using the `&&` operator in modern ABAP?
Both are used for string concatenation. The `&&` operator is a modern, inline "chaining" operator introduced in ABAP 7.40, often used within string templates. `CONCATENATE` is the older keyword-based statement. For our numeric calculation (`digit1 * 10 + digit2`), we avoided string conversion entirely as it's more efficient to perform the arithmetic directly on integers.
How do I create and test this class in my SAP system?
You can use the transaction `SE24` (Class Builder) or `SE80` (Object Navigator) in the SAP GUI. Alternatively, the modern approach is to use ABAP Development Tools (ADT) in Eclipse, which provides a much richer development experience. After creating the class, you can write a test program (like our `Z_TEST_RESISTOR_DECODER`) in `SE38` or ADT to call its methods.
Could the color map be stored in a database table?
Absolutely. The hashed table approach is perfect for this. In the `constructor` method, instead of a hard-coded `VALUE` expression, you could write a `SELECT` statement to read the color mappings from a custom customizing table (a Z-table). This makes the logic data-driven and allows business users to maintain the color mappings without changing any code.

Conclusion: From Colors to Clean Code

The Resistor Color Duo challenge, while simple on the surface, is a perfect miniature of the data transformation tasks that ABAP developers face daily. By building a clean, object-oriented solution, you've not only solved the problem but also practiced essential skills: data mapping, encapsulation, error handling, and writing reusable code.

You learned how to implement a solution using a readable CASE statement and explored a more scalable alternative with a hashed internal table. Understanding the trade-offs between these patterns is a hallmark of an experienced developer. This foundational knowledge is your stepping stone to tackling more complex challenges in the SAP ecosystem.

Technology Disclaimer: The code in this article is written using modern ABAP syntax (ABAP 7.40+) and is best suited for SAP S/4HANA systems or NetWeaver systems with the appropriate version. Some syntax may require adaptation for older SAP ECC systems.

Ready for the next step? Continue your journey on the kodikra ABAP learning path to build on these skills, or explore more ABAP concepts and challenges to broaden your expertise.

Published by Kodikra — Your trusted Abap learning resource.

Post a Comment