I’ve been working my way through the excellent opensap.com course, Building Apps with the ABAP RESTful Application Programming Model, when I came across the most egregious anti-pattern built into the very fabric of RAP.
(Fun fact, egregious used to mean really really good. Now it means really really excessively bad).
Week 5 is accessing an external OData service using a Custom Entity.
For some strange reason, parts were working fine until 6pm last night, when suddenly I started getting authentication errors… which were circumvented with the following code:
* https://blogs.sap.com/2019/10/20/how-to-call-a-remote-odata-service-from-the-trial-version-of-sap-cloud-* platform-abap-environment/
http_client->get_http_request( )->set_authorization_basic(
i_username = 'ES5 username'
i_password = 'ES5 password'
).
I don’t know, perhaps “they” decided to switch on authentication. Anyway I digress.
What really ticked me off was that when I had finished the app, I discovered that if I didn’t include these calls in my implementation of IF_RAP_QUERY_PROVIDER~SELECT
io_request->get_requested_elements( ).
io_request->get_sort_elements( ).
I’d get a dump on the value help for agency ID.
I looked more closely at io_request concrete implementation, and found this:
METHOD if_rap_query_request~get_sort_elements.
ms_interface_methods_called-get_sort_elements = abap_true.
rt_sort_elements = mt_sort_elements.
ENDMETHOD.
METHOD ensure_relevant_methods_called.
TRY.
IF ms_requested-fill_data = abap_true AND ms_interface_methods_called-get_sort_elements = abap_false AND mt_sort_elements IS NOT INITIAL.
RAISE EXCEPTION cx_rap_query_not_fully_implmtd=>as_indicated_by_missing_call( co_interface_methods-get_sort_elements ).
ENDIF.
...
So someone has decided that a GET method, which in any reasonable, rational universe should never have a side effect – if it’s not called, an exception will be raised.
Frankly, I’m morally shocked that such an antipattern has made it into an intrinsic part of RAP.
I’d love to hear the rationale…