SAPUI5 Momentum
I was fortunate to be invited to participate in the Blogger Program at SAP TechEd && d-code last week. I had a busy week of meetings and meet-ups, keynotes, briefings, etc. and I also did a couple of presentations on SAPUI5.
One of my takeaways from the event was that there is growing recognition amongst the SAP developer community that this SAPUI5 thing might be something of some relevance to them. In my opinion this is a good thing.
Technical people, especially Developers, are a pretty sceptical bunch and need time to understand new technology releases and to build trust that they will serve them well. And for SAP UI Developers this is especially so due to many false starts in this area over the past decade. The obvious example is WebDynpro which has never really gained much traction. There are two main contributors to this. The first is that SAP never seemed to get on board themselves – for example the only WebDynpro transaction I recall using much is SOAMANAGER. The second reason is that WebDynpro screens never seemed like the answer the end users’ were calling for.
SAP are certainly committed to SAPUI5 – and committed to oData too which is an important thing to be recognised. SAPUI5 is SAP’s “go to” technology for building user interfaces across their entire product range. Tangble evidence of this is that the number of available Fiori apps has now passed 500 and this initiative continues to have a strong focus.
And the screens produced with the SAPUI5 libraries do look pretty good. In an area where people can be very subjective it is hard to find anyone who does not like the cool blue Fiori-style. It goes beyond the look of each individual control too. The SDK has tons of examples that shown in the context of a full application. In this way they are also serve as part of a more subtle campaign to guide the developers, who typically aren’t great UI designers, in how to combine these fundamental UI components into complete applications with suitable aesthetics. Essentially the demo apps that show how things work also serve as part of more holistic design patterns, thereby encouraging a consistency that would be impossible if every developer went their own way.
As mentioned, I twice presented an ASUG session that was designed to help the total newcomer to SAPUI5 understand where it fits in relation to other web technologies as well as the rest of the SAP technology stack. Those who attended the second session got a smoother “user experience” as a self inflicted technical issue disrupted things a little in the first – but in both sessions there were many in the room who realised SAPUI5 was an important technology they needed to add to their skill set.
Don’t be fooled by any personal scepticism or jeering from the sidelines. The SAPUI5 libraries are very good and can stack up beside the others popular JavaScript libraries. The data binding stuff is very slick. As John Patterson, whose opinion I highly respect, says – “It just works!”. I am also coming to appreciate the way SAP has implemented the MVC design pattern and there is no doubt the library has an extensive set of very sophisticated controls.
So let me suggest a few tips about how you can start on the road to becoming a true SAP Web Developer. Others will have their own suggestions and I encourage them to put them in the comments.
- Learn the fundamental web technologies of HTTP, HTML, CSS and especially JavaScript. As you do so consider why HTTP is on this list. Hint – I didn’t say find out what these things are, I said “learn”.
- Learn how to use the debugging tools of your favourite web browser. I recommend Google Chrome but ultimately it is a personal choice. Knowing the purpose of these tools and how they work will help you with Step 1. Not to mention debugging tools can be handy during the development lifecycle – but you knew that right? 😎
- Download the OpenUI5 SDK from GitHub, install it, and start reading. There are tons of guides, examples, etc. and all the code is there too.
- Setup your own personal development environment on your local machine. 😉 Improve it the second time. And the third. Etcetera.
- Start building stuff because Steps 1 through 4 won’t make you a web developer. It is a skill that requires considerable familiarity before you become even a little bit competent. It takes time, practise, evaluation, etc. and lots and lots of refactoring.
There are of course plenty more things you need to learn and do to successfully add SAP Web Developer to your resume – I have planted some seeds in this article if you look close enough.
And let me close by pointing out how important the right attitude and an inquisitive mind are. Chris Solomon captures this aspect better than I ever could in his recent post My path to learning OpenUI5…..deeper down the rabbit hole and back again!
learning Javascript used to mean you weren’t a “serious software developer”. today, not learning Javascript means the same thing.
— monkchips (@monkchips) September 22, 2010
Excellent write-up Graham. Matt Harding made an excellent point on twitter recently that iith the ilbrary being open on github you can see the developer guidelines on github.
If we all conform to this it will make other code easier to read.
openui5/guidelines.md at master · SAP/openui5 · GitHub
Cheers,
Nigel
Hi Robbo,
<grumpy old man hat on>
Really? To me the blue crystal (meth) design although being nice and flat and simple just screams "SAP APPLICATION". Somewhat like the persisted use of menu bars at bottom of screen in Fiori (a carry-over from designing for mobile (and particularly iOS) first) drives me crazy - in multiple user experience sessions when designing apps I've had to remove these and move them up the screen because people just didn't expect them there!
I would caveat your statement thus " ... anyone who does not like the cool blue Fiori-style more than WebDynpro."
</grumpy hat>
Really agree with your point 4 -
build stuff using the lib, build lots of it, look at what you built and redo it. I think of the code that makes up the SAPUI5 screens of EnterpriseJungle (yes, that is UI5 and it looks damn sight better than cool blue! 😉 ), hardly any of the screen have their first iteration code in them.
The data binding are cool - and even allow awesome stuff like websockets to "just work".
I'd add to the list of thing to learn - Git and GitHub - the former so you understand what you are doing with the latter where you will find a wealth of examples of how to do cool stuff with UI5.
Personal preference, but highly recommended - XML definitions whenever you can use them for view definition. When you can't, try to figure out why, because you probably can, just that it's not documented as well for that tiny minority use case.
Never stop learning!
Cheers,
Chris
haha gotta agree with this one.... "To me the blue crystal (meth) design although being nice and flat and simple just screams "SAP APPLICATION"." .....over and over, that is the impression I get. I *know* that SAP (hopefully) is trying to convey that the Fiori design is much more the "feel" (the flow from page to page, the behavior of controls, etc) than the "look"....but I think they do a BAD job at the moment to convey that the "look" portion is really easy to customize to say customer branding or such. Yes, they speak of modifying CSS and/or using something like Web IDE now for themeing (with LESS-like functionality) but they do not really discuss that much....as if it is a "given" that folks will change the "look" themselves. However, we all know that most people either (1) just take what is given because they don't want the "headaches" of changing it or (2) just think "it is what it is".....both will just assume what Fiori "looks like" based on what they first see....or continual see such as in SAP presentations, demos, screenshots, marketing material, etc.....so they don't get the "spark of creativity" of what *may* be possible....which something like EnterpriseJungle shows clearly. I think SAP needs to do a MUCH better job communicating this aspect else yes, it will quickly become known as the usual, sparse, gray, cold "SAP application".
Yes Chris, for some client / applications like the blue because it looks like sap and in others that is exactly what you don't want.
And for those that don't want a SAP theme it needs to be easy to create one.
I think the developers should spend some quality time on learning Javascript. It looks like Java (even its name suggests it) but it's not. Prototype inheritance and function closures are two big things that usually bite new developers. At least they still bite me. It has also some other quirks.
Also +1 for Git/Mercurial. It's so much better to be able to split development into smaller chunk instead of one big initial transport. Collaboration is also much easier when you have Bitbucket or Github account. Only bummer is that you can't share Eclipse project with two repositories (ABAP and Git).
Cheers
But, what would you advise for stateful/transactional applications for power/desktop users? My vote currently is WDA/FPM. But if I understand correct, according an SAP Insider interview couple of months back, that the vision for this (in SAP HR) is also transitioning to SAPUI5?
Hi Wouter,
you are correct that SAP's forward looking vision for all user interfaces is SAPUI5 - of course this does not mean you can't use WDA & FPM if you want to. Currently available skills are a clear determining factor when choosing which technology to use.
But if you take the time to become experienced with creating Gateway services and building SAPUI5 applications that consume them I am confident you will see that these technologies can cater for the needs of all types of users.
Cheers
Graham Robbo
Hi Graham,
I absolutely agree on the Gateway/API standpoint from SAP backend. But I still have my doubts about the SAPUI5 frontend solution for Transactional/Stateful/Power applications.
I think the total cost of development and maintenance will -currently- be cheaper when created in WDA/FPM technologies (also by means of the tooling).But maybe I am still thinking too much about 'power users' and 'power applications', maybe someday everything will transition in specific role based applications like the current use case for Fiori ( 1 task, only few screens ). But than I would again think the maintenance cost will be too high?
But for current time and near future, I can't imagine developing the same power app with all the advanced standard functionalities ( e.g. filtering, layouts, ... ) and reusing standard SAP ( e.g. search help ) that is possible in WDA/FPM, doing the same in SAPUI5.
Regards,
Wouter
Wow! Thanks for the mention. I did attend BOTH of your SAP TechEd && d-code sessions in Las Vegas this past week. Personally, I think you are beating yourself up too hard over the first session.....you were LITERALLY the FIRST session right after the keynote and thus had to deal with technical issues beyond your control. True to form though, you STILL made the most of it and pulled off a nice LIVE session. I always appreciate that your sessions are LIVE code and screens....no PowerPoint slides and/or recorded video demos. THANKS for that! I think the fact that your second session was near completely full speaks to the fact that people must have found your first session of value regardless of your "hiccups" and spread the word to others. I found both contained good information and glad I was able to attend.
As for jumping into Open/SAP UI5....I think you nailed it on all fronts in your blog above...and you were far less long-winded than mine by a looooonnnnggg stretch. haha 😆
Err... I really hope that Aprove/Reject/Go "don't know where" "bar" can be docked at the top.. (or maybe even left or right...)? 🙂
Hi Graham, great post, comme d'habitude.
I wanted to pick up on a couple of points.
You said:
Technical people, especially Developers, are a pretty sceptical bunch and need time to understand new technology releases and to build trust that they will serve them well. And for SAP UI Developers this is especially so due to many false starts in this area over the past decade
Yes, there are some developers that are skeptical and need time to understand new technology; but I'd argue that good developers are the opposite - open to new ideas and always learning. Like I said in a previous conversation, when people ask what I do, I say "I learn" (this informed a post by John Appleby that also refers to you: How to become a great consultant) - this is me striving to be a good developer.
You said:
...in how to combine these fundamental UI components into complete applications with suitable aesthetics...
Indeed this is a key point that is missed by many. I still see myself as a plumber, a backend developer with an integration bent, but I've been building UI5 based apps (Fiori and non-Fiori) for a good while now. And while I'd never call myself a designer, the apps that the UI5 toolkit allow me to build, especially by using and combining controls with help from the SDK documentation, best practices and design guidelines, turn out great from a UI perspective. That's because of the immense hard work and expertise of the UI5 team that cause things to work well both at the micro level and the macro level.
Before I finish this comment, here's another opinion for free - those graphic studio designers coming up with static whole-screen application designs to the nearest pixel, and then throwing it over the wall to developers to "make it happen", are building a narrow niche for themselves. A toolkit like UI5, with its great pluggable UI components (small 'c'), is a sweet spot between flexible and reusable controls, CSS customisability and good looking results. Something that a plumber like me, with a foot in the frontend and a foot in the backend, can use.
Nice comment. When I started in computers, in the DTP industry in the early 90s, designers were very technical. Our tools were extremely hard to use and often required programming, knowledge of PostScript etc. In the last 25 years designers have in many cases reverted just to using Photoshop to build mock ups for someone to design.
But as Jobs knew well, design is not just how it looks, but how it feels, works, and makes the beholder feel. Design is emotion and Photoshop is not enough.
My suspicion is that the time is ripe for a cultural renaissance of the technical designer. Like the Pompidou Center, we shall call them plumbers!
Regarding WD and FPM...
After doing some OpenSAP courses, reading lots of docs and presentations about SAP UX strategy and sharing opinions here at SCN, IMHO it's still very hard to believe that WD (and specially FPM) are part of the SAP UX strategy. In theory they might be, in practice I don't think so.
If they were, I'd expect at least new business functions inside SAP ECC being developed using them. The very few things I have seen using WD are the SOAMANAGER as said by Graham, other configuration stuff as BRF+ and the NF-e solution inside GRC for the brazilian market (and user screens are not 100% done using WD).
Personally I don't know any SAP transaction done using FPM... does anyone know any? What about a customer application using it?
Talking about news skills to be learned I would add:
Git/GitHub - My opinion regarding such skills is that you can't fully learn them just by yourself. You got to be committed (or commiting) on working in a collaborative repository. Of course you can contribute in OpenUI5 repository as well... but I believe that this could not be trivial for those who are starting a new journey. SCN can be a great place to know people who would like to contribute to your idea! Why not sharing it in a blog or inside UI5 place?
For example, I am creating an app which uses an Article Search API from New York Times in order to learn javascript/ui5 and many other stuff. If you would like to contribute, please fell more than welcome!
fabiopagoti/NYT-Article-Search-on-SAPUI5 · GitHub
Development methodology - Creating apps using the same methods from old times (aka Waterfall) shouldn't work now. It's not hard to find functional consultants not aware of the power of ABAP and what kind of stuff can be done with it. Can you thing about an average SD or MM consultant studying UI5 in order to know how it can be used to solve a business requirement? Sorry, but I can't.
Deployment - Git enables so many different deployment models and strategies. This is such a deep topic but will be necessary for everybody working with a distributed source code system.
Node.js and some packages like grunt - This seems to be the "official" way of setting up a local development for working with OpenUI5. I am starting to read about it and I can guarantee that it's not just a javascript library to be learned (like jQuery for example)
jQuery - because knowing javascript doesn't mean knowing jQuery (but maybe should mean)
ABAP - Yes! ABAP! The backend is still there and it's still done in ABAP. Being honest, I don't know if there will be a clear separation between frond-end and back-end developers inside SAP ecosystem. You might argue about that, but ABAP developers have been working as full stack developers for many years, creating tables, coding business logic and designing screens no matter if they were done using classical dynpros, BSP, ITS, WDA, FPM or whatever. Of course, now the architecture is more challenging and there are way more stuff to learn... but frond end development will never be enough to create a useful application.
Hana - If you need to learn about a back end done in ABAP, you should be familiar with Hana as well. Companies would rather have full stack developers if possible.
Security - With so many web services being created and consumed, you got to be confident about how you are exposing data from the company you work for.
Well.. I sure I'm forgot some stuff.. Really.. there are so many things to be learned!
Cheers,
Fábio Pagoti
Hi,
regarding FPM apps. In-store inventory management and merchendasing solution for IS Retail is using FPM. Though it uses only freestyle components. I believe whole PLM solution is built using FPM as well as ESS/MSS ABAP version. I might be wrong here. Also some new stuff like configuration for Read access loging solution uses web dynpro.
I am not saying that there is a future for FPM. I am just saying that SAP ecosystem is really big and you can find various UI technologies. Let's not talk about CRM, right? How is UI5 going to be integrated with WebUI?
Cheers
Correct. FPM is also heavily used in HR (Renewal) and also in TM Transportation Management module. I recently saw a interview at SAP Insider where they said HR will be moving torward SAPUI5 as well, but I don't know if it will be for power applications ...
I believe SAP's UX strategy is that WebUI, FPM, UI5 and GUI are more alined to eachotter UI/UX way, but the technologies will still be seperate for each module.
( CRM = WebUI, HR = FPM, ... )
SAP GUI 7.40 now also has a Blue Crystal Theme.
Thanks for the info Martin!
Yes, SAP ecosystem is extremely huge. As an ABAP developer I was very interested in FPM the first time I heard about it... but it seems there is zero customer adoption. All such modules which you mention are not part of my expertise so it's good to know there is some usage somewhere.
Cheers,
Hi,
these days I always suggest to use FPM when building web dynpro apps. It's a really fast way for building apps. Three of my last customers use FPM. Deciding between web dynpro and UI5 is another story.
Cheers
BRF+ I had forgotten that!
I have used WDA for BRF+ and SOAMANAGER.
Thanks Fabio
Hi Fabio,
There are lots, really LOTS of SAP standard applications built on FPM. In the customer I am now we have Travel Management, EHS, Enterprise Asset Management (Work Orders/Notifications), and Purchase in FPM. And every* new application we develop is also in FPM ( *preferred method, there are exceptions).
And a new Chart and Carousel UIBBs were just released in &40 SP8.
** Team FPM ** Carousel UIBB
** TEAM FPM ** - A new Chart UIBB
Cheers,
Custodio
Good to hear that it is a preferred method. What are the exceptions, heavily customized/specific UI applications? Or do you still wrap them?
Great article and good comments as always.
Only one thing to add, we need more demos, loads more.
And yes that on my own task list now.
And a great thanks to all who have helped get SAP to this point, hopefully this mean no more WDPj
Hello Graham,
I would like take this opportunity to share some of my thoughts about SAPUI5 with you.
Some years ago, before SAPUI5 public announcement, I was developing web applications using ExtJS and PHP and I wanted to bring that knowledge to the ABAP development. But unfortunately, the only web technology accepted at that time was WDA. BSP was mistakenly tagged by people as "old technology".
When I read for the first time about SAPUI5 I was really excited. I believed that I would finally have the opportunity to transfer what I learned with ExtJS/PHP to SAPUI5/ABAP. I decided to invest my time to learn SAPUI5 and then I had my first disapointment - The JSONModel. Despite the fact that JSON is widely used in all other javascript frameworks SAP decided to embrace oData. The oDataModel has much more features than JSONModel. But is not easy to generate oData, even in the JSON format, and then I realized how much is SAPUI5 tied to the SAP Netweaver Gateway. To get things worse, oDataModel is a server side model, what leads to stateful apps.
SAP decided to open SAPUI5, what was a very good decision, but in my humble opinion creating a new name for it (OpenUI5) helps to get people confused about the framework.
The "Fiori wave" came obfuscate SAPUI5, that is now just the thing is under the hood and people don't care about. If you read the new SAP UX Strategy you will find it cited only two times.
The landscape recommended by SAP to run Fiori apps couldn't be more complex. The need of a "Frontend Server", a second WebAS to host the apps, Netweaver Gateway, ... , kills one of the great benefits of SAPUI5 that is the fact that it could be installed and upgraded without the need of upgrading the entire system (one of WDA problems).
I do believe that this way it is getting more and more difficult to convince and motivate people to learn SAPUI5 and use it (myself included).
Best regards,
Christian
Thanks for your comments Christian,
you make some interesting points about JSON. You are correct that the JSONModel has less features than the ODataModel - but to my thinking that is because oData is much more than JSON.
JSON is a message format whereas oData is a message protocol.
Because oData is self-describing, has a well defined set of operations that implement CRUD methods, and URI conventions for passing Query options, the model can be built to support these features and the UI controls can also exploit them at runtime.
So, by example, I know the Northwind sample oData service has an endpoint at http://services.odata.org/Northwind/Northwind.svc/.
I can discover what this service offers because it is self-describing so the URL http://services.odata.org/Northwind/Northwind.svc/$metadata tells me all about it.
I see I can get a list of all Products with the URL http://services.odata.org/Northwind/Northwind.svc/Products and a specific product by passing the ProductId in the URL. http://services.odata.org/Northwind/Northwind.svc/Products(5)
I see that the Product is supplied by SupplierID 2 so I could request that suppliers details, but even easier I can modify the Product request to also return Supplier details with the URL http://services.odata.org/Northwind/Northwind.svc/Products(5)?$expand=Supplier
This is pretty powerful stuff that a obfuscated JSON endpoint alone could never hope to emulate.
And, if you really like JSON, just append the option $format=json to your oData request and it will return the message in JSON format. http://services.odata.org/Northwind/Northwind.svc/Products(5)?$expand=Supplier&$format=json
Cheers
Graham Robbo
Playing devil's advocate now Robbo 😉 Wow look at all those ways that you used your prior knowledge of the protocol to get more information. How incredibly not HATEOAS. 😈
Wouldn't it be nice if we could do content negotiation and pass an Accept: application/json-odata? Nope, that's not what we do, so break RESTful ideas again.
I use UI5 because I find the bindings and MVC model and ability to accept theming compellingly easy to use, but I'm perhaps doing this in a different way than many - I don't use OData, I don't even use Gateway, all my code lives in the cloud. I might end up consuming content from an on premise system, but probably wouldn't use the UI5 components to consume directly.
How I talk to my UI5 frontend is my choice and I use as simple JSON so I can get the fastest lowest bandwidth UI possible.
I still use OData - using Olingo libs to expose OData out of my HCP apps - but that's for consumption by things like SAP Jam that will leverage the protocol to do many things that would be incredibly time consuming for me to build.
So I'll climb off my hobby horse, and state, OData is SAP's chosen direction for data communication. As such get used to using it. But this does not mean you have to use it for everything and there are many times where I'd suggest it is bad to do so. But it's here to stay - deal with it. 🙂
Brilliant! 😆