Is there a nice way to use ABAP-Logger in OData exceptions?

[abap-logger]

Is there a nice way to use ABAP-Logger in OData exceptions?

[kjetil-kilhavn]

I would be interested to hear about anything you do in this respect. So far I am just barely dipping my toes, and have set up for one entity set logging (to application log) when a request does not process all the options (DONE-list does not match TODO-list) or an exception occurs - but I am only just getting started and sneak it in along with other changes.

However, it isn't clear to me whether you want to log the gateway exceptions or use the ABAP Logger as source for the messages returned with an exception.
I log the exceptions by catching the business and technical exceptions, adding them to the application log, and then re-raising the exception.

  METHOD log_and_raise_gw_exception.
    CHECK io_busi_exception IS BOUND AND io_busi_exception IS NOT INITIAL
    OR    io_tech_exception IS BOUND AND io_tech_exception IS NOT INITIAL.

    DATA(lo_logger) = get_logger( ).
    IF io_busi_exception IS BOUND AND io_busi_exception IS NOT INITIAL.
      IF lo_logger IS BOUND.
        lo_logger->e( io_busi_exception ).
        lo_logger->save( ).
      ENDIF.
      RAISE EXCEPTION io_busi_exception.
    ELSEIF io_tech_exception IS BOUND AND io_tech_exception IS NOT INITIAL.
      IF lo_logger IS BOUND.
        lo_logger->e( io_tech_exception ).
        lo_logger->save( ).
      ENDIF.
      RAISE EXCEPTION io_tech_exception.
    ENDIF.
  ENDMETHOD.

In my query implementation

   TRY.
       set_logger( zcl_logger_factory=>create_log( object    = '...'
                                                   subobject = '...'
                                                   desc      = |OData query: ...|
                                                   auto_save = abap_true ) ).
       get_..._handler(  )->get_entityset( EXPORTING io_request          = io_tech_request_context
                                           IMPORTING es_response_context = es_response_context
                                                     et_entities         = et_entityset
                                                     es_processing_todo  = DATA(ls_requested_processing)
                                                     es_processing_done  = DATA(ls_completed_processing) ).
       IF ls_requested_processing <> ls_completed_processing.
         IF get_logger(  ) IS BOUND.
           MESSAGE w020(zopu_bse) WITH ls_completed_processing ls_requested_processing INTO DATA(l_message).
           get_logger(  )->add( ).
         ENDIF.
       ENDIF.
     CATCH /iwbep/cx_mgw_busi_exception INTO DATA(lo_busi_exception).
       log_and_raise_gw_exception( io_busi_exception = lo_busi_exception ).
     CATCH /iwbep/cx_mgw_tech_exception INTO DATA(lo_tech_exception).
       log_and_raise_gw_exception( io_tech_exception = lo_tech_exception ).
   ENDTRY.

Perhaps neither pretty or fancy, but I have to start somewhere :-)

[andkopp]

There is no integration today. As you already pointed out, the backend implementation of an OData service is working with a special message container. The message container has methods to add free text messages, BAPI messages and other type of messages so in this point it is quite similar to the logger interface.

The difference is that the message container and its messages are sent to the OData client. Maybe you don't want that for all internal messages you write to application log.

One approach would be to support the message container type as input of the add() method of the logger interface and extract and log all messages it contains.
As SAP gateway components are available on all systems starting from 7.4, it would increase the requirements for this logger class.

Another approach is to have two calls where you need it: one for the message container, another for the logger. I think I would choose this one. The advantage is that you are more flexible and that the sequence of messages is correct. When you would log the complete message container (containing multiple messages) at the end of the OData method and you would have logged messages with the logger before, the sequence of message could get mixed up.

[andkopp]

I see no problem with your approach. Just one hint: Errors raised by OData services are already written to the application log. Just run transaction /IWBEP/ERROR_LOG in your backend system and click on the button "Application Log". You can see that the error is written in the object /IWBEP, subobject RUNTIM.

[AlexandreHT]

Though I have no knowledge of the context, I'll take @andkopp to the word ("Errors raised by OData services are already written to the application log.") and consider this enhancement is not relevant.
Please reopen if I'm wrong.