GET_ENTITY and Key Handling

Explanation

GET_ENTITY returns one business object based on key values. The most common issue is wrong key handling, especially for SAP fields with leading zeros such as customer, material, vendor or document numbers. OData key values arrive as external strings. The ABAP implementation must read key values from IT_KEY_TAB or request context and convert them if needed before database access. If conversion is ignored, the service may return 404 or blank data even though the record exists in SAP.

Code example

* Purpose:* Read one customer entity using key value from OData request.* Handle SAP internal format before database lookup. METHOD customerset_get_entity.   DATA lv_kunnr TYPE kunnr.   * Read key value sent in OData URL  READ TABLE it_key_tab INTO DATA(ls_key) WITH KEY name = 'CustomerId'.   IF sy-subrc <> 0 OR ls_key-value IS INITIAL.    RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception.  ENDIF.   lv_kunnr = ls_key-value.   * Convert customer number to internal format if needed  CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'    EXPORTING      input  = lv_kunnr    IMPORTING      output = lv_kunnr.   SELECT SINGLE kunnr, name1, ort01    FROM kna1    INTO @DATA(ls_kna1)    WHERE kunnr = @lv_kunnr.   IF sy-subrc <> 0.    RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception.  ENDIF.   er_entity = CORRESPONDING #( ls_kna1 ). ENDMETHOD.

Real project scenario

A material detail OData service fails when Fiori passes material 12345. MARA stores it with internal leading zeros. Adding conversion exit handling fixes the issue.

Common mistakes

- Not reading key values correctly. - Ignoring leading zero conversion. - Returning initial entity instead of proper error. - Not checking authorization for the key.

Best practices

- Read key values carefully. - Apply conversion exits. - Return meaningful errors. - Check authorization for sensitive entities.

Interview angle

A good answer should mention IT_KEY_TAB, key conversion and meaningful not-found handling.