SAPUI5 Vs other SAP UI Technologies – JSPDynPage, Web Dynpro Java/ABAP
SAPUI5 is HTML5 with additional SAP features – MVC architecture in development, number of libraries. SAPUI5 is based on principle – Build and run on any device. With mobility becoming important requirement for enterprise applications, SAPUI5 gains weightage in new developments across organizations.
We have been developing custom applications or customizing SAP standard objects which majorly make use of BAPI, Z function modules, UI is created either using wizard or using tag library code(JSP Dynpage). How and in what all areas does SAPUI5 development differs from these UI technologies? I have tried to collate major points in this context.
SAPUI5 is lighter UI technology compared to Web Dynpro. Major difference in development is in the way interaction is done with backend system. In case of Web Dynpro for Java model is created out of BAPI, Z function module or Web Service and interaction is done with backend. In case of Web Dynpro ABAP, interaction happens by directly calling BAPI or Z function module, tables can be directly queried.
When it comes SAPUI5, it supports ODATA compliant services for interacting with backend system. It means if we need to transact huge data with backend system, then performance will be at risk. UI Development using SAPUI5 has wizard based UI creation option also. When it comes to usage, SAPUI5 can be run on any device, but not the case with Web Dynpro. SAPUI5 has UI elements specific to mobile platforms.
SAPUI5 look and feel is much better compared to Web Dynpro, JSP Dynpage. We can reuse all the developments of Web Dynpro i.e. business logic packaged in function modules. For this we need to wrap them in ODATA compliant services.
There are many scenarios for which we need to explore when it comes to development of SAPUI5 applications. Some of them are: Consider a scenario where we need Adobe print option in SAPUI5 application; consider a scenario where the workflow is involved; consider a scenario in which status has to be saved.
Hi,
nice blog. SAPUI5 is the future for SAP web products, comparing it's benefits with other UI technologies is not really fair. Typical investment vs. support obligations scenario.
SAPUI5 is a >12 MB "beast". You have to make it lightweight before releasing it to your users. Besides, WDJ can also use EJB as a model.
Certain limitations apply, the browser on the device needs to be pretty advanced for SAP UI5 to work. It's more like: any device with an OS released in the last 2 or 3 years can run SAPUI5.
Agreed, but that is because SAP invests in SAPUI5 and tries to apply new design principles to the UI/UX. You can of course achieve the same with a JSP page.
I'm curious why you think performance will be a problem with the OData approach? JSON is pretty lightweight and with services like HANA XS, one could argue performance will be better since we can optionally bypass the app server and deliver the data straight to the UI. Curious to see what your thoughts are on this.
I would agreed that the OData approach would be pretty 'heavy'. There is a ton of meta-data included in a OData structure.. Parsing that via any clientside tech would take longer than a custom 'thin' JSON structure.
Craig,
What sort of metadata are you referring to? Are you referring to what gets returned with the HTTP HEAD verb? Because that's not something that necessarily gets consumed at the UI layer. It's analogous to a WSDL document in the SOAP web services world. For basic CRUD operations, OData does in fact use the thin JSON structure you refer to (at least whenever you're not consuming OData services in the Atom format). OData and REST in general is pretty lightweight, and arguably has less overhead when you consider the fact that more and more service providers (e.g. SAP HANA XS) can deliver the OData directly to the UI without having to go through the application server.
Thanks,
James
OData adds some significant overhead to the data transferred, besides needing additional hardware / CPU power. You can take a look at my blog: http://scn.sap.com/community/netweaver-gateway/blog/2012/06/27/performance-of-sap-gateway
If you want to receive the ID of a company, in "pure" JSON it is {"id":1}. With OData, you get several pages of meta information before you get to the ID and then you get additional pages of meta information.
While this impact is minimal to the end user as long as the data stays on the server, as soon as you separate the UI from the server you have to transmit this additional data over the network. At least on a mobile device the client will have to implement $filter, $top, $skip to minimize the data transferred, but this also means bad UX, as a.g. ever click on next inside a table causes a round trip from client to server. That's bad on a mobile internet connection (latency).
With 1 request and same # KB transmitted in "pure" JSON, you get all the data to the device and can act locally on it, while with oData you get only the first 10 entries. As long as you do not have a real need for oData (and start screen, list, detail, detail, confirm, etc does rarely justify it), it adds overhead: HW, Architecture, coding, network.
Hi Tobias,
I don't think you can necessarily point to that article (which is fantastic by the way) as a baseline metric these days since SAP NetWeaver Gateway has since introduced support for the JSON format with SP04 (e.g. using the $format=json query string parameter). As you stated, an OData service using the Atom format will contain a lot of overhead with the XML markup. On the other hand, an OData service which formats the results using JSON should be pretty lightweight. And, with the advent of SAP HANA XS, you don't necessarily have to go through SAP NetWeaver Gateway to begin with - UI applications can potentially go right to the source to retrieve domain values for input helps, drop down lists, and so on.
Thanks,
James
Hi James,
I am aware of the json option, and when I say you get the oData overhead, I mean the protocol, not the output format.
https://sapes1.sapdevcenter.com/sap/opu/odata/sap/ZGWSAMPLE_SRV/BusinessPartnerCollection('0100000002')/SalesOrders?$format=json
You get the meta data for a sales order:
__metadata":{"uri":"https://sapes1.sapdevcenter.com:443/sap/opu/odata/sap/ZGWSAMPLE_SRV/SalesOrderCollection('0500000091')","type":"ZGWSAMPLE_SRV.SalesOrder"}
Looking at Sales Order Collection, you get the reference to Business Partner and Line Items.
That's the kind of information you need to build the app, but after you have done this, do you still need all this meta information? This can be implicitely integrated either into the model or the flow. You need this dynamically when you backend changes rapidly, but for that you should have a middleware. The oData entries contain a properties section, that's the main information you are interested in. As for the rest transmitted: in most cases you simply won't use it.
About HANA XS: this is only true when you use HANA XS. When your frontend is on another system - and that is the case in >99% - you won't benefit from it.