Skip to Content

SAPUI5: To much error messages

Hi,

i use oData and therefore create an error like this:

DATA: lo_exception TYPE REF TO /iwbep/cx_mgw_busi_exception,

            lo_container TYPE REF TO /iwbep/if_message_container.


      lo_container = mo_context->get_message_container( ).


        lo_container->add_messages_from_bapi(

          EXPORTING

            it_bapi_messages          = lt_return

*              iv_error_category         =

                iv_determine_leading_msg  = abap_true

                iv_entity_type            = iv_entity_name

                it_key_tab                = it_key_tab

                iv_add_to_response_header = abap_true

        ).





      CREATE OBJECT lo_exception

        EXPORTING

*         textid      =

*         previous    =

         message_container      = lo_container

*         http_status_code = '500'

*         http_header_parameters =

*         sap_note_id =

*         msg_code    =

*          entity_type = iv_entity_name

*          message     = 'Konnte nicht gespeichert werden!'

*         message_unlimited      =

*         filter_param     =

*         operation_no     =

        .


      RAISE EXCEPTION lo_exception.

but i always get more error-messages then i supose to get:

only the one in the middle is the error i added.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Mar 07, 2017 at 10:24 AM

    Hi Michael,

    What UI5 version are you using? What NW ABAP / SAP GW do you have? Would you mind posting your error response here (in JSON would be great)?

    I know this issue pretty well... When you send an error from SAP GW to the frontend you will receive a certain response structure on the frontend. This structure contains a leading message and could possibly have zero ore more detail messages. Here is an example:

    Let's assume the following dummy SAP GW ABAP code:

      METHOD employees_get_entityset.
        RAISE EXCEPTION TYPE /iwbep/cx_mgw_not_impl_exc
          EXPORTING
            textid = /iwbep/cx_mgw_not_impl_exc=>method_not_implemented
            method = 'EMPLOYEES_GET_ENTITYSET'.
      ENDMETHOD.

    Triggering this service implementation code with/sap/opu/odata/sap/ZNABI_EMPLOYEE_SRV/Employees?$format=json will result with the following error message in the response (in JSON format):

    {
      "error" : {
        "code" : "/IWBEP/CM_MGW_RT/021",
        "message" : {
          "lang" : "en",
          "value" : "Method 'EMPLOYEES_GET_ENTITYSET' not implemented in data provider class."
        },
        "innererror" : {
          "application" : {
            "component_id" : "",
            "service_namespace" : "/SAP/",
            "service_id" : "ZNABI_EMPLOYEE_SRV",
            "service_version" : "0001"
          },
          "transactionid" : "58BDC3218BC10D60E10080000AF0030E",
          "timestamp" : "20170307090853.3367070",
          "Error_Resolution" : {
            "SAP_Transaction" : "Run transaction /IWFND/ERROR_LOG on SAP Gateway hub system (System Alias LOCAL) and search for entries with the timestamp above for more details",
            "SAP_Note" : "See SAP Note 1797736 for error analysis (https://service.sap.com/sap/support/notes/1797736)"
          },
          "errordetails" : [
            {
              "code" : "/IWBEP/CX_MGW_NOT_IMPL_EXC",
              "message" : "Method 'EMPLOYEES_GET_ENTITYSET' not implemented in data provider class",
              "propertyref" : "",
              "severity" : "error",
              "target" : ""
            }
          ]
        }
      }
    }
    

    In this example we raised one exception. However, SAP GW actually has a leading message (code = /IWBEP/CM_MGW_RT/021) and one error detail (code=/IWBEP/CX_MGW_NOT_IMPL_EXC). As you can see in both cases the message is almost the same: the leading message ends with a dot while the error detail message does not end with a dot! That meas only the code and the dot in the messages itself differ! That's exactly why SAPUI5 assumes there are 2 different messages and thus UI5 displays the "one" message twice. From an endusers perspective this is a desaster.

    SAPUI5 has a logic that discovers duplicate messages and removes them. Here is the corresponding ui5 ODataMessageParser.js code on github:

    // Messages from an error response should contain duplicate messages - the main error should be the
    // same as the first errordetail error. If this is the case, remove the first one.
    if (aMessages.length > 1) {
        if (
            aMessages[0].getCode()    == aMessages[1].getCode() &&
            aMessages[0].getMessage() == aMessages[1].getMessage()
        ) {
            aMessages.shift();
        }
    }


    In other words: If the GW would send for both messages the same code and the same message (including the dot) then you would only see the message only once in the UI! From the UI5 code mentioned above you can also see that UI5 only compares the first two messages. That means if SAP GW send you the messages in a different order (I think this is your case, too) then you would keep seeing (leading) messages twice

    // this would show the leading message twice
    [oLeadingMessage, oSomeOtherMessage, oLeadingMessage]

    // you would see the message only only once on UI
    [oLeadingMessage, oLeadingMessage, oSomeOtherMessage]


    Anyway... IMHO this is a bug in the GW. I believe either the leading message should be available only once (and not in the details) or code + message should be exactly the same.

    From your screenshot I can tell that the one message has a dot and the other does not. Furthermore, I guess that the codes differ as well. That's why you see the message twice.

    Best,
    Nabi

    Add comment
    10|10000 characters needed characters exceeded

    • I missed, that i also redefined the Methods:

      /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_BEGIN

      /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_END

      the coding was just empty, but this was the origin of the dupplicated messages.

  • Sep 03, 2017 at 07:27 AM

    If all the options are failing, why dont you filter the unwanted errors(by error key) before binding it to the message managaer?

    Add comment
    10|10000 characters needed characters exceeded

  • Mar 03, 2017 at 02:40 PM

    RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
    EXPORTING
    textid = if_t100_message=>default_textid " <- this line is needed, else an empty line exists in innererror!
    message_container = lo_container.

    Add comment
    10|10000 characters needed characters exceeded