SAP UI/UX one year on – What has changed and what do you choose ?

About this time last year I wrote a series of blogs on what options you had if you wanted to put a new UI/UX on top of SAP – based on the number of times the series was read, it seems plenty of people are interested in this.

The reasons for wanting to not use SAPGUI and the technical options available are still valid from these blogs (Part 1 – Options, Part 2 – Recommendations), but as always things have moved on, and these changes are the reason for this updated blog.

3 major things that have happened are :-

SAP Mobile Platform – Sybase Unwired Platform, Mobilizer and Syclo all got mashed together and stamped SMP 3.0. SMP is also offered as a Cloud Edition for the SAP Productivity Mobile Apps. Good links are available here.

Fiori was born which is the brand name for a bunch (currently 25 – but growing) SAPUI5/Gateway apps that allow simplified access to SAP Business Suite from your desktop, tablet and phone (or phablet) – These can be added to and extended and show that the best architectural option for building UI’s on top of SAP Business Suite is definately SAPUI5 (or your UI technology of choice) and SAP NetWeaver Gateway.

SAP Screen Personas was also born and whilst in the initial release this only allowed SAPGUI to be skinned with Microsoft Silverlight, it now supports SAPUI5 as well (with some restrictions).

So how might these developments impact your decisions for a UI renovation project ?

Below I have included an example decision tree that I developed (sorry for the size….), your specific version of this will be different based on your IT landscape, unique use-cases and your personal preferences.

One option missing is what you do if you have WebDynpro / BSP / CRMUI screens that you wanted to “Personas” (a common question I am asked) – it doesn’t seem that SAP has plans for a tool here (but the frameworks are being supported), so I have been looking at Capriza as an option – the topic of another blog in the future.

8 Comments

Great blog – I’m really interested in SMP since I haven’t experimented with it, or any kind of offline apps. You’ve sparked some questions, though, as I’m a pretty new developer.

Is Adobe Forms the best way to create a non-mobile offline app? I’m also unfamiliar with the technology, plus .NET developers are plentiful these days, so might that be a possible strategy? Also, when would you ever need an offline desktop app?

For an offline mobile app, is it advisable to create an offline web app, store the HTML and whatnot on the phone and cache transactions through cookies to avoid the need for developing a native app?

Maybe the answers to these questions are “it depends,” and maybe it depends on internal skillsets and whether or not you have Gateway. I’m interested to hear your thoughts.

As for your first point, you are right Adobe form would not be used for a mobile app, but could be used for getting information to a laptop that may not always be connected (for example a vendor create application) – you are right that you could write another off-line app in .NET or also HTML5…..

The decision tree isn’t supposed to be a “golden” answer, but an example – if you favour .NET, dislike Adobe, etc etc you will create your own “rules”.

I suppose the subjective nature of a decision tree like this is just a testament to the freedom of loose coupling. It would be a good exercise for every developer to fill that out so they know what technologies they would use given a certain requirement.

thanks for clarifying, I am always worried that there is a risk of projects choosing their technology before considering the organisation’s strategy, eg, single point of entry, 1 url entry point in the whole SAP infrastructure etc and with how many is it, circa 16,000 SAP Portal customers the consideration should be given to the UI container technology and strategy and re-use of existing infrastructure. Aviad has pointed out elsewhere that Fiori and Portal are aligned which is good. Of course not every situation is about Portal but that should be an initial consideration, entry point.

Regarding the diagram above, I would go one step further and give the comment, that, SAP Gui Transactions always risk giving Users more authorisation and power than is often intended in the specification of the task.

A Custom UI developed on any of the technologies you describe will always be the safest and most secure way to lock down a User’s authorisations.