continue from here My Journey to UI5 – Part 2
This is the last part (at least for now, since holidays are coming!) of my blog series.
Here I would like to share a couple of hints/tricks I personally found useful.
Please, take in mind my UI5 Application runs on a different server, integrated into a Django/Python application and that my system is not so up to date (it’s NW 731) so many issues I found could be already resolved in more recent versions.
Anyway, enjoy it!
Give a sprint to your system!
Reading the official documentation here you can see that you can pass custom headers to your OData model, something pretty useful, right?
Yeah!
There is a little problem in my system: the standard handler in gateway, just “forget” to pass them in the following methods and class!
So, even if I feel them on UI5-side, and the gateway intercept them, in my services, at the end I find nothing.
After some (a lot!) debug, following call after call, I found the little demon responsible of filling the headers for the next classes.
It’s the class /IWFND/CL_SODATA_PROCESSOR in INIT_REQUEST method, a long one indeed: at the start of it, I can see all my custom headers available but once I exit it.. puff! No more trace of them.
I did a little enhancement at the end of the method to add also my custom headers
ENHANCEMENT 1 ZGW_ODATA_CPARM. “active version
*
*Retrieve all parameters and add to et_parameters if they start as ZZ
*We use ZZ to try stay in SAP standard nomenclature about custom objects in
*Standard namespace
DATA: it_params TYPE tihttpnvp,
i_param TYPE ihttpnvp,
param_out TYPE /IWCOR/IF_ODATA_TYPES=>parameter_values_s.
mo_context->get_parameter(
exporting iv_name = ‘IWFND/ALL_PARAMETERS’
importing ev_value = it_params ).
LOOP AT it_params INTO i_param..
check i_param–name(2) = ‘ZZ’ or i_param–name(2) = ‘zz’.
READ TABLE et_parameter
WITH KEY name = i_param–name
TRANSPORTING NO FIELDS.
CHECK sy–subrc NE 0.
param_out–name = i_param–name.
param_out–value = i_param–value.
TRANSLATE param_out–name to UPPER CASE.
APPEND param_out TO et_parameter.
ENDLOOP.
ENDENHANCEMENT.
ENDMETHOD. “init_request
As you can see, I used the SAP naming convention to avoid any future problem, checking my paramters start with ZZ or zz (and obviously manage in the same way also in UI5).
Now I can receive and use them also in my methods generated!
Cute, right?
Everybody say “Reverse Proxy”!
One of the most common issue everyone faces playing with web development and accessing services from all around the world is the CORS
There are many and many solutions to solve them: just google them and you can spend long sleepless night in a ….errrr.. fun way
The most common (and less heavy to implement for a developer) is setting up a Reverse Proxy.
Oh! Uh! What a magic word!
Yeah, it’s easy and quick and everyone suggest it.
Sadly it’s soooo hard to find a guide on how setup it!
I’m still guessing why I cannot find any guide but since a feel good, I share my knowledge, so precious, with you.
I’m working with Apache so the first step is to install the mod_proxy package: done!
Then there are few rows to add in the configuration file
<VirtualHost *:80>
ProxyPreserveHost On
# Servers to proxy the connection, or;
# List of application servers:
# Usage:
# ProxyPass / http://[IP Addr.]:[port]/
# ProxyPassReverse / http://[IP Addr.]:[port]/
# Example:
# ProxyPass /
ProxyPass /sap/opu/odata/sap/ZCUSTOMERS_VENDORS_SRV/ http://<yourserver>/sap/opu/odata/sap/ZCUSTOMERS_VENDORS_SRV/
ProxyPassReverse /sap/opu/odata/sap/ZCUSTOMERS_VENDORS_SRV/ http://<yourserver>/sap/opu/odata/sap/ZCUSTOMERS_VENDORS_SRV/
WSGIPassAuthorization On
Header set Access-Control-Allow-Origin “*”
Header always set Access-Control-Allow-Methods “POST,PUT, GET, OPTIONS”
What do these rows do?
I explain in a not technical way: they take the service you are invoking (/sap/opu/odata/sap/ZCUSTOMERS_VENDORS_SRV/ and tell the browser and the server hosting your application to manage it like http://<yourserver>/sap/opu/odata/sap/ZCUSTOMERS_VENDORS_SRV/
In this way the server is fooled to think the service you are invoking from SAP is in the same domain, avoiding the CORS issue.
Double trouble!
In SAP we use a tons of different nice data type, domains and elements and we are used to manage them pretty transparently apart a bit of casting when need.
When we create in SEGW an OData service importing a dictionary, SAP manage itself to convert into the corresponding OData element.
And when it comes to number we can see both integer than decimals data element.
According to this, when we create a JSON in our UI5 application, we pass number without quotes while strings with them.
And all works!
Mmmm.. no, not really this way.
As you can read in this post there is a little corner in standard SAP that require not integer numbers to be passed as string, with quotes!
I do not dare to ask SAP why this since the floating point, decimals and so on are correctly recognized in SEGW service, but just take this in mind when you start to play with JSON and decimals!
That’s all, folks!
These are just 3 issues I faced, but they have been the biggest mountain to get over to me and I lost long hours trying to catch up with them.
I hope these few pages and blog post will help someone and even myself if some expert slap my head pointing out some error!
For me, now that I got the ropes of UI5, the biggest challenge will be on: complete override of the CSS!
I do not even know if it’s possible but, after a couple of weeks at the seaside, I’ll be back trying it!